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?
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
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.
hi,
Stone writes:
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 gave up recording encrypted channels with VDR a long time ago. The problem is the VDSB error or something that results in a rebooting cycle for the VDR. It tries to solve the problem in a wrong way, assuming that all delays in starting the video stream are due to driver crashes. While, of course, it is natural to have delays in starting to view an encrypted channel, but the driver's have not crashed for perhaps 1.5 years now.
When live viewing, VDR is much more patient and is able to wait without the emergency exit until the right authorization information is given to the smartcard, and the decryption starts. This can take even half an hour, or 45 min even in my setup (at least it has taken a couple of times that long). (Of course the provider does not change keys every day, so the longer delays are not frequent.)
When VDR tries a timed recording it has no patience to wait for the decryption to start, so it might sometimes succeed (if the provider has not just changed the keys), or then it just destroys all other recordings with the restarting cycle. So it is better not to try to record an encrypted channel.
yours, Jouni
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?!
Stone wrote:
> 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.
I remember these crashes with VDR 1.2.6 but if I'm not wrong there are no restarts any more with 1.4.5. If a channel gets encrypted during live view, the picture just freezes. Then I can safely switch to another channel manually. If the encryption starts during a recording, the recording just stops. But now I'm not so sure any more because VDR could just have restarted without me noticing. And after the restart it doesn't continue the recording because now the CA value is set in the channels.conf
Ondrej ...
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
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?
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.
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.
VDR User wrote:
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.
If the CA value of a channel that is currently recorded changes, VDR stops recording and restarts it, doing the full check whether or not the channel can be decrypted.
Klaus
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
-
Jouni Karvo -
Klaus Schmidinger -
Luca Olivetti -
Ondrej Wisniewski -
Stone -
VDR User