BUG: More CCcam issues causing failed recordings (24/04/2012 iQ image)

[F1Mad]

Hi all,

I've just had another CCcam issue that has caused a failed recording. Please bear with me, because this same issue spans across 3 separate bugs, which I'll document in separate threads...

I returned back to the Twin to see the that the screen was frozen on a still image from "Puss in Boots 3D". The OSD's CCcam info suggested that the ECM time was just over 5 secs. I couldn't revive the playback, so I ended up flicking to a different channel, which worked OK. But when I flicked back, the frozen image was gone, and was now just black. The OSD was still showing the same info as it was when I first came back to a frozen screen. Notice, to do this screengrab through the WebControl panel, I had to choose "Screengrab (OSD)" as none of the other options would actually return a result (still had the spinny AJAX "Loading..." message):


Anyway, I restarted the CCcam service (running CCcam2104) in the hope that I could revive this channel, but it didn't work:


When I brought up the OSD again, this time it thought the channel was FTA!:


When I hit the "List" button (to look at the recordings), I noticed that the HDD was only just spinning up! So it seems that not only did the recording fail (even though it still appeared to be recording!), it also put the HDD to sleep. The next screen shows how the program was apparently still recording, but only seemed to record about 10 mins of the film before it failed:


Anyway, in short, another missed recording!

 

[ellie1998]

To be honest with ecm of 5.515 it's hardly surprising the box is having a brainfart.
You need to sort that out before you can expect a picture to show let alone record anything.
Either your server isn't up to much or your hammering your internet with upload/downloads.

I have a twin here but it's in the sons room as the missus prefers the 800se he records to our server on the network with no problems, though he hasn't got this image on at the moment.
The only thing he moans about is sometimes on changing channels the video locks but the audio changes channel, he reboots the box to get it working.

 

[F1Mad]

To be honest with ecm of 5.515 it's hardly surprising the box is having a brainfart.
You need to sort that out before you can expect a picture to show let alone record anything.
Either your server isn't up to much or your hammering your internet with upload/downloads.

Mate, I'm trying to get to the bottom of that, but with little success. The first thing I blamed was my internet connection. I therefore upgraded from my 10MB connection (which has otherwise been faultless for years) to 30MB through Virgin. I've had some internet connectivity problems, which is why I eventually had a Virgin engineer come out and upgrade the connections inside the house (apparently, they were ancient!). Even though this significantly reduced the "noise" on the system, it still wasn't perfect, so the cabling into the house was checked and found to be "not perfect". Hence, another engineer on his way out tomorrow. Now, that aside, whenever I have a problem with ECM, I test my internet connectivity AND do a test on pingtest.net. A lot of the times, there's NOTHING wrong with the internet connection! OK, I think, next thing to test is the provider, so I get a 1 month subscription with another provider (hence why I need the CCCam switcher to be working OK!). Guess what! When 1 provider is having issues, generally the other one isn't, and vice versa. To top that off, sometimes, I've noticed that the Twin itself seems to be causing the issue. This *may* be coincidence, but on many occassions when the channel has "frozen", when I click on the remote's OK button to come up, it all starts working again! You can tell that this is all starting to drive me a little nuts, which is why I'm considering getting a regular Sly card to use in the Twin (I *could* do this, right?). The thing that's putting me off is that recordings don't seem to always be working, whether they're FTA or not!

I have a twin here but it's in the sons room as the missus prefers the 800se he records to our server on the network with no problems, though he hasn't got this image on at the moment.
The only thing he moans about is sometimes on changing channels the video locks but the audio changes channel, he reboots the box to get it working.

Yep, I too had that several times, and was told it was because I didn't have the latest image. But guess what - even with the 29/03/2012 it would still do that! Not had it happen on the 14/04/2012, but I've had other crashes that have NOT happened on other images (backward step?). :S

 

[CG121]

pinging random servers proves nothing, ping the server your cccam connects to via the command prompt..
(obviously you know the download speed of the connection is meaningless here, if anything, choose a slower connection as more people use the higher speed connections and increase the congestion..)

Many pay servers are greedy and/or don't understand how to load balance their card>client ratio..

In my experience, 90% of ecm problems are down to the server and not the client and no amount of changing ISPs/Routers etc will help

 

[F1Mad]

CG121, some very good comments there. Here's my take on it...

pinging random servers proves nothing, ping the server your cccam connects to via the command prompt..

Pinging doesn't tell you anything, I'm afraid, and here are a few points to consider:
* Anyone can set up a server to NOT respond to pinging (ICMP) at all, it doesn't mean it's not available though.
* If you *do* successfully ping a machine, it just tells you that the machine *may* be available, but not if the specific PORT you're interested in is available.
* You can't ping specific ports with the command line tool, but you can use something like the "paping" (see here paping - Cross-platform TCP port testing, emulating the functionality of ping (port ping) - Google Project Hosting)
* Even if you successfully see whether the correct port number is responding, it doesn't tell you whether the server is sending you the response for CCcam in a timely fashion.
* The same machine may be being used to decrypt on more than 1 port number (ie the same server could be used for multiple endpoints using different port nos)
* The reason I want to ping ANOTHER server is to rule out my internet connection. Just pinging the server that's failing to respond fast enough won't tell me this! So, what I'm doing is using pingtest.net and pinging a node somewhere in Germany (which if the geolocation info for my chosen providers is correct, is where their servers are). That then gives me an idea on whether connectivity to Germany from my ISP is fast-responding at that time or not.

(obviously you know the download speed of the connection is meaningless here, if anything, choose a slower connection as more people use the higher speed connections and increase the congestion..)

That's a brilliant point, actually! Most people will automatically go towards the higher bandwidth offering, even if they don't necessarily need/use it -Gordon Gecko got that one right on the 2nd attempt! It's also probably why I'm seeing more issues since moving to the higher bandwidth.

Many pay servers are greedy and/or don't understand how to load balance their card>client ratio..

Yeah, I think you're dead right here, mate. Let's face it, people can't kick up too much of a stink about things! With the provider that I got the 1 month sub from, for testing - they advertised "glitch free", etc, etc. But when you read their FAQ, it does say that, due to internet issues, you might experience problems. Backside covered there, then! :S

In my experience, 90% of ecm problems are down to the server and not the client and no amount of changing ISPs/Routers etc will help

I've got to agree. Working in IT, I know how flaky connectivity can be even at the best of times. There are SO many possible nodes of failure, and trying to guarantee something like this when relying on a load of 3rd parties is a bloody nightmare! Having said that, in all my Googling around, it seems that there are loads of people out there with very little glitching! I don't know - all I know is that, if I factor in the cost of my time, I'm better off just getting a Sly card and hosting my own internal service. Having said that, the Twin is still letting me down on even FTA recordings, so am I just better off moving to Sly completely?

 

[CG121]

You could look at getting a few 24hr test lines from various sources and see if it's a common problem I suppose.
(always check the feedback posts from other clients to guage if the problem is more widespread or not)

Re the ping, yea, I only intended it as a simple test between routers and you're correct in that it may not respond, but it might show any high spikes along the same path CCcam is using if it does

IMHO, you should switch to mgcamd as it allows better control over ECM timeouts, whereas CCcam does not.

I use mgcamd for my Nagra3 server where clients connect to Card Server Proxy (rather than direct to the server)

The main problem with CCcam is this, say the CAS you're using has a key interval time around 10 seconds, this is the time you'll be able to clear a channel before it freezes since the last keyset was issued. Softcams also have a timeout which will freeze the channel after x number of seconds have elapsed without an ECM answer. mgcamd allows it to be set and CCcam (unless it's been updated recently) doesn't.

The server knows the key interval time and balances the card:client connections and may decide to wait 7 seconds (while it services other clients) before sending an ECM reply..If the softcam timed out after 4 seconds, the picture freezes. However, mgcamd would wait (if correctly configured) until 8 seconds say before it panics and as it got a reply after 7000ms, allows glitch free viewing

This means that the softcam can timeout with valid keys

Just a thought

 

[F1Mad]

Hmmm, I thought I replied to this before, but the post isn't here? Anyway, I'll try again...

IMHO, you should switch to mgcamd as it allows better control over ECM timeouts, whereas CCcam does not.

I use mgcamd for my Nagra3 server where clients connect to Card Server Proxy (rather than direct to the server)

The main problem with CCcam is ...

Just a thought

You lost me a bit (I thought that ECM requests happen every 7-8 secs, and if the response is longer than 0.5secs, then you get a glitch), but I'm more that willing to be educated on the best way to set this up. I've messed about with the mg_cfg file a bit to get full debug, to work out what's going on, but the log file can get quite large (must figure out how to filter stuff out that doesn't seem useful!). For example, what does the following line mean?

[cccamd] Card remove from blahblah.server.com:xxxx (xxxxxxxx)

I get a load of those lines, but I don't know what they mean...

 

[CG121]

Hmmm, I thought I replied to this before, but the post isn't here? Anyway, I'll try again...



You lost me a bit (I thought that ECM requests happen every 7-8 secs, and if the response is longer than 0.5secs, then you get a glitch), but I'm more that willing to be educated on the best way to set this up. I've messed about with the mg_cfg file a bit to get full debug, to work out what's going on, but the log file can get quite large (must figure out how to filter stuff out that doesn't seem useful!). For example, what does the following line mean?

[cccamd] Card remove from blahblah.server.com:xxxx (xxxxxxxx)

I get a load of those lines, but I don't know what they mean...

Re the ECM timeout, let's say you set mgcamd to timeout after 5 seconds and you use card server proxy to force a delay of 8 seconds (which we would use to test the maximum timeouts before you get a glitch) on a system that has a key interval of say 9 seconds..

The client has both the now and next keys and should be able to maintain a picture (as it has valid keys) even though we're deliberately delaying the next ECM answer. It doesn't though as it times itself out 5 seconds after sending the next ECM..

The importance of knowing this applies only to single card servers where the key interval time remains constant. Where multiple cards exist, for different encryption systems, each have their own key interval and you would therefore have to choose the lowest..

The reason why we care is that if you have a server and can set it to timeout after 9 seconds (instead of 5) you can better allow for congestion and therefore increase the number of clients per card (as the server knows it can queue clients for longer)

As for your log entry, if this is as a result of using a pay server, it could simply mean the card is configured to be available but has been removed.

 

[F1Mad]

Re the ECM timeout, let's say you set mgcamd to timeout after 5 seconds and you use card server proxy to force a delay of 8 seconds (which we would use to test the maximum timeouts before you get a glitch) on a system that has a key interval of say 9 seconds..

The client has both the now and next keys and should be able to maintain a picture (as it has valid keys) even though we're deliberately delaying the next ECM answer. It doesn't though as it times itself out 5 seconds after sending the next ECM..

The importance of knowing this applies only to single card servers where the key interval time remains constant. Where multiple cards exist, for different encryption systems, each have their own key interval and you would therefore have to choose the lowest..

The reason why we care is that if you have a server and can set it to timeout after 9 seconds (instead of 5) you can better allow for congestion and therefore increase the number of clients per card (as the server knows it can queue clients for longer)

Ah, OK, I *think* I'm getting it. It's because you're using a PROXY that you're able to do this, right? If so, what do you need to create a proxy? Is it just another machine/device that can run mgcamd, but with different settings?

Incidentally, I'm not impressed with mgcamd so far. Not only do I not have immediate visibility of what server it's trying to talk to, and what the ECM is (thanks to the image bug of not showing this info on the OSD as we're talking about on another thread!), but I've experienced some long term freezes. What *seems* to happen is that mgcamd doesn't receive a response from the pay server, and mgcamd keeps on trying to contact that SAME server after every time out. I've messed about with the settings for retry (eg N: { 07 } 1 5), but I can't get mgcamd to try another server (it just seems to keep trying the same one!). The only solution seems to be to restart the mgcamd service. This has happened both with mgcamd135 and mgcamd138.

As for your log entry, if this is as a result of using a pay server, it could simply mean the card is configured to be available but has been removed.

Yes, it is a pay server that I'm pointing to. To be honest, because of the constant annoying issues I'm having with clearing and recording more than 1 channel (it seems that 1 of the pay server groups I'm using will simply not allow clearing of 2 simulataneous channels!), I'm thinking of getting a Sly card to cover the viewing that I quite simply can't deal with having glitches (ie the all Sly channels, HD package, and Movies), and then use the pay server (since I'm paid up for the next 10 months!) for other other stuff (like Sly Sports, foreign sports, etc).

So, is it possible with ANY of these softcams to use specific servers for specific channels?

 

[CG121]

To be honest I can't remember if you're using clines with mgcamd (cccamd.list) or newcamd lines (newcamd.list) or both

Before you blame mgcamd though, you have to remember that the server may send an ECM reply to mgcamd which would prevent it switching to an alternate server..If this is the case, the server is at fault for sending outdated/incorrect or empty responses.

Obviously the best solution is to sign up to 1 server that caters for all the required packages...

Their is nothing worse than a pay server that doesn't know how to setup their own proxy (and they all use proxies) and this tends to be the case with pay servers. People that setup free family/friend servers tend to be the more experienced users and know what they're doing, pay servers only care for $$$..

Also, if you are using CCcam clines, you can't expect to gain much as you're not using the newcamd protocol.

In my opinion, the best solution is to find a server that:
1. Uses card server proxy to;
i) organise the services
ii) balance the client load
iii) use efficient cluster caching with other servers to combat load, cater for anti share and increase packages offered
2. Uses the extended newcamd protocol so all providers are served via a single port.
3. Has cards to open all the services required.

If you find the problems persist, after trying a server that is configured efficiently, you should then look closer at the softcam.

An important caveat for users with twin tuners that use pay servers....
(and this applies to users recording 2 or more services from the same transponder on single tuner boxes)

MANY of them employ ECM monitoring, by this I mean that if they know the key interval is 9 seconds and you are recording 2 channels at once, your line will be requesting at a key interval of 4 or 5. This will lock down the server as it will think you've shared your line out to another box or a mate..

As for CSP itself, it's not a card server or a softcam..Think of it as traffic management, a middleman.

It can run on various platforms. I myself use it on a Windows XP server (JavaVM) and it connects to SBOX (the card server) running on a remote DM500 (where the card is). Clients talk to CSP via the net (vpn), CSP talks to SBOX via the net (vpn) and SBOX talks to the card (local card slot, so internal comms).
The DM500 (running the card and sbox) also runs mgcamd (the softcam) and has to talk (vpn) to CSP and then wait for a reply as sbox is configured purely as a server and not as a softcam...
I should add, this is only the case as CSP and the DM500 are not on the same LAN. For obvious security reasons, the CSP install is pretty much untraceable and further still, the user.xml (usernames/password etc) is also kept online offshore (and pw protected).

CSP has been configured with 'backup' servers (oscam), however the card would need to be moved from the DM500 to the oscam reader for that to function...
The commercial pay servers would obviously have the backups configured in case of primary failure (failsafe) as they can afford more cards and network more using the clustered cache (unless they are the aforementioned shysters that only want your $$$ lol)

EDIT:
You could ask the server that is unreliable to filter out the CAID so only the other line opens it..

 

[F1Mad]

Wow, thanks for the feedback!

To be honest I can't remember if you're using clines with mgcamd (cccamd.list) or newcamd lines (newcamd.list) or both

I'm using clines from 2 providers in a single cccamd.list file. The reason I'm using 2 providers is that I needed another pay server/provider to compare against to work out if my issues are down to the provider or my ISP. I *have* had some ISP issues, but there are still either issues with the pay servers (both) and/or the box.

Before you blame mgcamd though, you have to remember that the server may send an ECM reply to mgcamd which would prevent it switching to an alternate server..If this is the case, the server is at fault for sending outdated/incorrect or empty responses.

I had pretty much full debug switched on and was monitoring the log using mtail (and a bit of filtering!), and what I noticed was that when the failure was occurring was because it seemed like there was no response from the Pay Server. Now what's causing this? Is this the ISP dropping packets? Or is this the Pay Server at fault? Or is it the softcam, or the box? At the same time that this was going on, I was using "paping" to ping the same pay server on the same port, and this was working OK. So, again, does this mean that packets were dropped for the request by mgcamd (so that the response never came back), or did the pay server just not respond? This problem occurred with both pay server providers!

Obviously the best solution is to sign up to 1 server that caters for all the required packages...

Where do you find this info? I can't see this info for any of the pay servers I've seen on the net, and to be honest, I don't fully know what I need to be looking out for. Can you recommend a provider (via PM?

Their is nothing worse than a pay server that doesn't know how to setup their own proxy (and they all use proxies) and this tends to be the case with pay servers. People that setup free family/friend servers tend to be the more experienced users and know what they're doing, pay servers only care for $$$..

Hmmm, well, I might be forced down this route and I sure as hell am not experienced (not yet!)

Also, if you are using CCcam clines, you can't expect to gain much as you're not using the newcamd protocol.

So far, the only providers that I've come across for this seem to use CCcam. Not seen anything else offered.

In my opinion, the best solution is to find a server that:
1. Uses card server proxy to;
i) organise the services
ii) balance the client load
iii) use efficient cluster caching with other servers to combat load, cater for anti share and increase packages offered
2. Uses the extended newcamd protocol so all providers are served via a single port.
3. Has cards to open all the services required.

If you find the problems persist, after trying a server that is configured efficiently, you should then look closer at the softcam.

Because I can't completely rule out my internet connection for some of these faults, I don't know if this approach would be best! *My* thinking, from all the info that you've helpfully been providing me with, is that maybe I should set up my own CSP to try and reduce the glitching, and maybe provide better debug info. Aside from possibly reducing some of the glitching I'm getting, this might also get to the bottom of the issues I've had with dual tuner recordings (as you suggested above). Trouble is, I know next to nothing about what I need to do, other than I've found a couple of pages that show how I could create a build from the SVN repo. Any suggestions/help you might have in this are, I'd MOST appreciate!

An important caveat for users with twin tuners that use pay servers....
(and this applies to users recording 2 or more services from the same transponder on single tuner boxes)
MANY of them employ ECM monitoring, by this I mean that if they know the key interval is 9 seconds and you are recording 2 channels at once, your line will be requesting at a key interval of 4 or 5. This will lock down the server as it will think you've shared your line out to another box or a mate..

I was convinced that this was going on with my initial pay server provider, and hence another reason to try a 1 month trial with another provider. The latter seems to be more likely to record 2 channels at the same time, whereas the former has always failed. That was until I tried it out in the box suppliers shop and it worked - at least the first time, and that's when the shop started getting shirty!

As for CSP itself, it's not a card server or a softcam..Think of it as traffic management, a middleman.

Yeah, I think I can now see how it can be of benefit for several things. To solve glitching, it can take longer than 0.5s for ECM when it talks to the Pay server, but as long as it responds with the right key in a timely fashion for the client, then all should be good.

It can run on various platforms. I myself use it on a Windows XP server (JavaVM) and it connects to SBOX (the card server) running on a remote DM500 (where the card is). Clients talk to CSP via the net (vpn), CSP talks to SBOX via the net (vpn) and SBOX talks to the card (local card slot, so internal comms).
The DM500 (running the card and sbox) also runs mgcamd (the softcam) and has to talk (vpn) to CSP and then wait for a reply as sbox is configured purely as a server and not as a softcam...
I should add, this is only the case as CSP and the DM500 are not on the same LAN. For obvious security reasons, the CSP install is pretty much untraceable and further still, the user.xml (usernames/password etc) is also kept online offshore (and pw protected).

Could you point me in the right direction on where to download the CSP (I'd prefer a version that can run on Fedora, but if it has to be Windows version I have a both a Server2008R2 and Win7x64 machine that run full time)? And any pointers on some base settings to start with?

CSP has been configured with 'backup' servers (oscam), however the card would need to be moved from the DM500 to the oscam reader for that to function...
The commercial pay servers would obviously have the backups configured in case of primary failure (failsafe) as they can afford more cards and network more using the clustered cache (unless they are the aforementioned shysters that only want your $$$ lol)

So does that mean you've got a single card in the DM500 potentially serving other clients (eg your Twin)? If I give up with pay servers and were to get a Sly card, would I even need to go to all this trouble to use with the Twin, or would I just be better off putting the card in the Twin (has anybody actually done this?)?

EDIT:
You could ask the server that is unreliable to filter out the CAID so only the other line opens it..

No idea what this means, to be honest. Do you mean that any cline that is problematic should be asked to stop clearing for that channel? If so, would the server still respond but send some kind of "not supported" response?

One of the pay server providers has given me 4 clines, and the other 6. I can't pinpoint which cline entry is problematic, as they all seem to cause issues. So I'm not sure this is the way forward.

 

[CG121]

CSP can be obtained via _http://streamboard.gmc.to/svn/CSP/trunk/

My CSP server isn't for satellite, it's used with a DM500C (family owned in another house) that has a Nagra3 card in it.
Other friends and family have DM500Cs and share the cost of the full sub

You don't need CSP if you're going to use a local box (as a server) and that same box, or a few other boxes as oscam will work just fine without CSP.

CSP is really only used if you need to have more cards/connections but I wanted to learn its use, so used it.
Plus, if a certain cable service introduced SID locking (anti-share) it would be CSP and cluster caching that would solve it..

I'll PM you an address, email him for a test line and don't forget to disable the CCcam in mgcamd. (set G: { 01 }

 

[F1Mad]

OK, having found a VERY good CCcam provider, I'm still having problems clearing more than 1 channel simultaneously. So, for example if I'm watching SkyPremiereHD and a timer begins to start recording something on SkyShowcseHD, I get the info message on screen that the recording is starting, but nothing warning me that things are going wrong.
I then go to the List of recordings and see that the timer on the recording is not incrementing. If I now switch to watch that SkyShowcseHD (ie the one I'm recording) and look at the timer for the recording in the List view, I can see it's started incrementing. In fact, when I play back the recording, it's actually playing from the time I flicked over to that channel (ie it wasn't recording until I flicked over to it!).

I'm using CCcam 2.1.3 and the 24/04/2012 iQ image, recording to a networked drive.

What's funny is that SOMETIMES, recording from 2 encrypted channels simultaneously WORKS, but a lot of the times it doesn't. I'm starting to miss too many programs because I'm only able to rely on using a single tuner at a time!

 

[wiz569]

I would suggest that if your still not happy at this stage,you should return the box m8,
this thread is starting to get a little to close to the limits of what we are willing to discuss regarding cs talk

 

[F1Mad]

I would suggest that if your still not happy at this stage,you should return the box m8,
this thread is starting to get a little to close to the limits of what we are willing to discuss regarding cs talk

Sorry, mate, I appreciate tat CS talk can be on the edge, but I've just been doing some testing with FTA channels, and that as issues too. Basically, I would LOVE to return this box and get my money back, but I don't think I've got any hope of that. Anyway, I'm going to open another thread about problems with recording, documenting my recent findings, as I feel that I owe it to others to tell them the problems with this unit...

 

[wiz569]

If the box doesn't do what its advertised to do then I'm sure the wonderful guys at TM would only be too happy to refund you, if only to stop you pointing out its flaws

Sent from my X10i using Tapatalk 2

 

[Abu Baniaz]

If you can connect it to a computer and get the logs, then that would be wonderful in identifying the issue. (If only they did not break the bug logging!)

Is this issue still present on the PLI based beta images too?

 

[F1Mad]

If you can connect it to a computer and get the logs, then that would be wonderful in identifying the issue. (If only they did not break the bug logging!)

Mate, yes I *can* connect to it via computer. What logs do you want me to find (please specify file path too)? Anything in particular to look for? Is this even going to be logged anywhere, considering it doesn't cause any "errors" (it just fails to record)? I'll try and describe the exact problem in another thread, where I'll also be talking about what it does with FTA channels. One thing's for sure - I can't see how the hell someone managed to record 5 channels simultaneously, same transponder/s or not! :S

Is this issue still present on the PLI based beta images too?

I can't comment on that, mate, because I've stuck to the iQ images, in the hope that they'd eventually get it right.

 

[Abu Baniaz]

The IQ team have screwed up the debug logging aspect of the software. By using the software to connect to the receiver, you can record everything that the receiver tries do and also what it attempts to do. This can be returned to TM/IQ to attempt to fix. You are a programmer and may even be able to fix it your self. Have a look at this post

You don't have permission to view the code content. Log in or register now.

There is a beta PLI build image, give it a whirl. If you don't like it, go back to the IQ image.

 

[F1Mad]

The IQ team have screwed up the debug logging aspect of the software. By using the software to connect to the receiver, you can record everything that the receiver tries do and also what it attempts to do. This can be returned to TM/IQ to attempt to fix.

I see what you mean when you say "connect", ie using RS232! Hmmm, I guess I might have to bring the Media Center into play (need to check that it's got a serial port on it though!). Also, got to dig out a serial cable (when was the last time I used one!...).

You are a programmer and may even be able to fix it your self. Have a look at this post:
https://www.digitalworldz.co.uk/index.php?threads/286282/

I'm SOOO tempted to get involved and fixed some of these issues. But then I do have to earn a living too!

There is a beta PLI build image, give it a whirl. If you don't like it, go back to the IQ image.

I've been tempted by this, and the PLI sounds good (as this might also help use the TM as a tuner for MythTV!), but I'm afraid that if I go down that route, I may never come back to the iQ (or proper ViX) images again.