...

Is there an easy way to fix this?

Edit the file dvbdevice.c, insert a line "return true;" at the beginning of the method cDvbDevice::ProvidesCa. With this modification you can tune to encoded channels, however you'll never see a "channel not available", you'll just see a black screen. This, btw, also solves the problem of channels that declare they're scrambled when they aren't.

With this modification to dvbdevice.c, I wonder if VDR will still crash when a timer goes off on a channel and all the sudden it becomes encrypted. This would normally cause a broken data stream and VDR would do an emergency exit.

Regards.

On 3/5/07, Stone syphyr@gmail.com wrote:

With this modification to dvbdevice.c, I wonder if VDR will still crash when a timer goes off on a channel and all the sudden it becomes encrypted. This would normally cause a broken data stream and VDR would do an emergency exit.

I *HATE* that vdr does that!!!!!!!! The emergency exit that is.. I mean what's the point?!

Luca Olivetti wrote:

En/na Ondrej Wisniewski ha escrit:

...

I am using VDR 1.4.5 with the integrated auto pid feature and without any CAM. When tuning to an encrypted channel, the CA value gets set accordingly and "channel not available" is displayed. So far so good.

However there are channels that encrypt only certain programs and are free the rest of the time. When tuning to this "free" channel while the program is encrypted, the CA value will be set and "channel not available" shown. But when tuning to the same channel again when it is not encrypted any more it seems that VDR just checks the CA value and displays "channel not available" instead of checking the currently broadcast CA value. So the channel cannot be watched even if it is free in the moment.

This is quite annoying and decreases the WAF a lot :-/

Is there an easy way to fix this?

Edit the file dvbdevice.c, insert a line "return true;" at the beginning of the method cDvbDevice::ProvidesCa. With this modification you can tune to encoded channels, however you'll never see a "channel not available", you'll just see a black screen. This, btw, also solves the problem of channels that declare they're scrambled when they aren't.

Bye

OK, that seems like a good workaround. But it is not a real solution. I mean I still want to see "channel not available" but only when it is really not available (it is currently encrypted). That would be the correct behaviour.

Furthermore I am not sure what happens when a recording on such a channel starts and it is really encrypted. The current solution is safe because it doesn't tune to the channel if the CA value is set. However it has the drawback of not recording even if the channel might be FTA again (that's a real show stopper).

So I propose that VDR should always tune to a channel that is requested, get the current CA value from the data stream (and not from the channels.conf) and then decide if the channel can be shown/recorded. Does that sound like a good solution? Any obvious drawbacks?

Ondrej

Why should VDR crash at all? If the CA value changes, just check if it can be decrypted. If so, continue recording, if not then stop recording. Whatever the case I just don't see a logical reason for VDR to panic-exit or whatever.

I agree, it's a pretty serious problem and many of my timers wern't recorded because of it as well.

Ondrej Wisniewski wrote:

Ondrej Wisniewski wrote:

...

So I propose that VDR should always tune to a channel that is requested, get the current CA value from the data stream (and not from the channels.conf) and then decide if the channel can be shown/recorded. Does that sound like a good solution? Any obvious drawbacks?

@Klaus: is there any chance of integrating this modification in an upcoming version of VDR?

With the new CAM handling I will most likely make it so that channels are skipped only when the user zaps up/down. If a channel is selected explicitly (either by selecting from the Channels menu or by entering the channel number - or any other direct selection) it will always switch to the transponder to get the current CA status.

Even though it looks like this topic has not raised much interest, I think it is important and really should be addressed. VDR has failed recording periodically scheduled programs many times here because the program transmitted after the recording was encrypted. So the next scheduled recording the following day was not started because the channel was marked encrypted in the channels.conf. And VDR mainly being a "video recorder" this really is a serious bug.

I'll look into this one, too.

Klaus