Hi
I'm running vdr-1.5.12 with a TT-1500-C card, CI and alphacrypt multi-cam. All channels are encrypted.
Intermittantly I try and switch to a channel and I get a "Channel not available" message. After switching back and forth between channels, finally the channel will select, and everything's ok.
I've been trying to diagnose it, and so far all I can see is below: Jan 27 20:05:29 callin vdr: [3287] switching to channel 20 Jan 27 20:05:29 callin vdr: [3287] cTS2PES got 2 TS errors, 2 TS continuity errors Jan 27 20:05:29 callin vdr: [3287] buffer stats: 58656 (2%) used Jan 27 20:05:29 callin vdr: [3287] info: Channel not available! Jan 27 20:05:29 callin vdr: [4167] TS buffer on device 1 thread ended (pid=3287, tid=4167) Jan 27 20:05:29 callin vdr: [4166] buffer stats: 58280 (2%) used Jan 27 20:05:29 callin vdr: [4166] receiver on device 1 thread ended (pid=3287, tid=4166)
Can anyone tell me what this cTS2PES error is, and if it's likely to be to do with my problem? What else can I try?
Thanks
Simon
On 01/27/08 08:11, Simon Baxter wrote:
Hi
I'm running vdr-1.5.12 with a TT-1500-C card, CI and alphacrypt multi-cam. All channels are encrypted.
Intermittantly I try and switch to a channel and I get a "Channel not available" message. After switching back and forth between channels, finally the channel will select, and everything's ok.
I've been trying to diagnose it, and so far all I can see is below: Jan 27 20:05:29 callin vdr: [3287] switching to channel 20 Jan 27 20:05:29 callin vdr: [3287] cTS2PES got 2 TS errors, 2 TS continuity errors Jan 27 20:05:29 callin vdr: [3287] buffer stats: 58656 (2%) used Jan 27 20:05:29 callin vdr: [3287] info: Channel not available! Jan 27 20:05:29 callin vdr: [4167] TS buffer on device 1 thread ended (pid=3287, tid=4167) Jan 27 20:05:29 callin vdr: [4166] buffer stats: 58280 (2%) used Jan 27 20:05:29 callin vdr: [4166] receiver on device 1 thread ended (pid=3287, tid=4166)
Can anyone tell me what this cTS2PES error is, and if it's likely to be to do with my problem? What else can I try?
Maybe your CAM needs longer than TS_SCRAMBLING_TIMEOUT (default is 3 seconds) to start decrypting. You can try increasing that number in device.c.
It is also very likely that I am going to remove the two lines
&& !cDevice::SwitchChannel(1) // ...or the next higher available one... && !cDevice::SwitchChannel(-1)) // ...or the next lower available one
from vdr.c, in order to allow switching to a channel where the CAM needs quite a long time, for instance to collect new keys because it hasn't been tuned to an encrypted channel for a while.
Klaus
Intermittantly I try and switch to a channel and I get a "Channel not available" message. After switching back and forth between channels, finally the channel will select, and everything's ok.
Maybe your CAM needs longer than TS_SCRAMBLING_TIMEOUT (default is 3 seconds) to start decrypting. You can try increasing that number in device.c.
It is also very likely that I am going to remove the two lines
&& !cDevice::SwitchChannel(1) // ...or the next higher availableone... && !cDevice::SwitchChannel(-1)) // ...or the next lower available one
from vdr.c, in order to allow switching to a channel where the CAM needs quite a long time, for instance to collect new keys because it hasn't been tuned to an encrypted channel for a while.
Might be related to tuning to a channel which hasn't been tuned to for a while. Here's a short sequence that will cause it: -tune to movies1 boquet 1 -channel not available, vdr skips to movies2 boquet 2 -persistent back and forth between movies1 & movies2, after 5th attempt, channel changes to movies1 -change to food boquet3, channel not available and vdr skips to E! boquet1 -persistent back and forth, then changes to food boquet3 -repeat changing to movies1 & movies2 and the above sequence happens again
But - if I'm persistent and get movies1(bq1), movies2(bq2) and movies3(bq1) to come up, I can use Up/Down to flick one to the other over and over very quickly. If I leave it on movies1(bq1) for more than a few seconds, I get the problem when trying to change.
It doesn't seem to be a problem consistent with specific channels either.
I've tried increasing the TS_SCRAMBLING_TIMEOUT to 6 seconds, and it just takes longer for the channel not available message - doesn't stop the problem happenning.
Any other ideas?
-
Klaus Schmidinger -
Simon Baxter