After I've upgraded to vdr-1.3.22 I've had problems with "channel not available", when there is any timer recording.
I have one full card and two budgets, all of which are DVB-C, and can (in theory) receive the same channels. Actually (of course) only the full card can receive encrypted channels.
One example was yesterday. There was a timer on channel 5 (not encrypted = can be received on cards 1-3). This timer started on device 1 (full card). When the timer was recording VDR kept saying "channel not available" every time I tried to view encrypted channel.
The timer was started on a full device, which isn't a good idea as all the budget cards too can receive the channel. But even after the timer was running on a full card, I have thought VDR would swap the timer to another card, if the full card was needed for a channel it only could provide. This did not happen now. Why not?
There was no other timers. What I could see in syslog was:
Mar 12 17:09:00 mewtwovdr vdr[29424]: switching device 1 to channel 5 Mar 12 17:09:00 mewtwovdr vdr[29424]: timer 2 (5 1709-1808 'Robot Wars') start Mar 12 17:09:00 mewtwovdr vdr[29424]: Title: 'Robot Wars' Subtitle: '(null)' Mar 12 17:09:00 mewtwovdr vdr[29424]: record /mnt/raid2/vdr/Robot_Wars/2005-03-12.17:09.10.10.rec Mar 12 17:09:00 mewtwovdr vdr[29424]: creating directory /mnt/raid2/vdr/Robot_Wars Mar 12 17:09:00 mewtwovdr vdr[29424]: creating directory /mnt/raid2/vdr/Robot_Wars/2005-03-12.17:09.10.10.rec Mar 12 17:09:04 mewtwovdr vdr[29424]: recording to '/mnt/raid2/vdr/Robot_Wars/2005-03-12.17:09.10.10.rec/001.vdr' Mar 12 17:09:04 mewtwovdr vdr[29555]: file writer thread started (pid=29555, tid=1277964) Mar 12 17:09:04 mewtwovdr vdr[29556]: recording thread started (pid=29556, tid=1294354) Mar 12 17:09:05 mewtwovdr vdr[29424]: switching to channel 2
And later on when trying to view encrypted channel (only receivable on device 1):
Mar 12 17:52:24 mewtwovdr vdr[29424]: switching to channel 8 Mar 12 17:52:24 mewtwovdr vdr[29587]: transfer thread ended (pid=29587, tid=1605648) Mar 12 17:52:24 mewtwovdr vdr[29424]: buffer stats: 58844 (2%) used Mar 12 17:52:24 mewtwovdr vdr[29424]: info: Kanava ei ole k<E4>ytett<E4>viss<E4>! Mar 12 17:52:34 mewtwovdr vdr[29424]: switching to channel 3
The channel 5 from channels.conf:
subtv;Citytv Oy:290000:C0M128:C:5900:353:609=fin:865:0:97:0:2:0
and channel 8:
Animal Planet;Telenor:138000:C0M128:C:6900:1000:1001=eng:302:B00:407:0:8:0
Plugins I have running are:
Subtitles Ttxtsubs Xine Femon Mplayer Osdteletext
Teemu
Rantanen Teemu wrote:
After I've upgraded to vdr-1.3.22 I've had problems with "channel not available", when there is any timer recording.
I have one full card and two budgets, all of which are DVB-C, and can (in theory) receive the same channels. Actually (of course) only the full card can receive encrypted channels.
One example was yesterday. There was a timer on channel 5 (not encrypted = can be received on cards 1-3). This timer started on device 1 (full card). When the timer was recording VDR kept saying "channel not available" every time I tried to view encrypted channel.
The timer was started on a full device, which isn't a good idea as all the budget cards too can receive the channel. But even after the timer was running on a full card, I have thought VDR would swap the timer to another card, if the full card was needed for a channel it only could provide. This did not happen now. Why not?
Because that "shifting" is not active (see cDevice::CanShift()). It's way too complex, so I'm thinking of completey dropping that code, anyway.
As to why the recording started on the primary device, while there were budget cards free at the time, I guess you'll need to do some debugging in cDvbDevice::ProvidesChannel(). Here on my system recordings only use the primary device if all others are already in use.
Klaus
On Sunday 13 March 2005 12:56, Klaus Schmidinger wrote:
Rantanen Teemu wrote:
After I've upgraded to vdr-1.3.22 I've had problems with "channel not available", when there is any timer recording.
I have one full card and two budgets, all of which are DVB-C, and can (in theory) receive the same channels. Actually (of course) only the full card can receive encrypted channels.
One example was yesterday. There was a timer on channel 5 (not encrypted = can be received on cards 1-3). This timer started on device 1 (full card). When the timer was recording VDR kept saying "channel not available" every time I tried to view encrypted channel.
The timer was started on a full device, which isn't a good idea as all the budget cards too can receive the channel. But even after the timer was running on a full card, I have thought VDR would swap the timer to another card, if the full card was needed for a channel it only could provide. This did not happen now. Why not?
[...]
As to why the recording started on the primary device, while there were budget cards free at the time, I guess you'll need to do some debugging in cDvbDevice::ProvidesChannel(). Here on my system recordings only use the primary device if all others are already in use.
I can confirm this bug. I have the same setup with two DVB-S cards, and it also happened here in the past with vdr-1.3.x
If I have two timers for 20:15 I have to ensure that the timer for the full featured card starts before the timer of the budget card.
Could it be that my (and Rantanen's) vdr is configured such that the full featured is not the primary card?
I for myself did not change the primary card setting, as I cannot say without reading logfiles which card number the FF is.
Kind regards, Stefan
Hello,
I have the same bug, and I was thinking it was introduced with the configurable LNB sharing patch, but you are right, without the patch I have the same problem. My system has 2 FF as first card and one budget as third one, but the primary device is the fourth pseudo one for xine.
On Monday 14 March 2005 09:47, Grégoire Favre wrote:
Hello,
I have the same bug, and I was thinking it was introduced with the configurable LNB sharing patch, but you are right, without the patch I have the same problem. My system has 2 FF as first card and one budget as third one, but the primary device is the fourth pseudo one for xine.
Without knowing the exact details how vdr selects where to record from, I think a correct solution would be:
a) is there a card recording on that transponder, then use that card b) is there a free card without CI that can record it, then use that card c) use the next best card, with the primary card last
I think it is necessary to have that checking for a CI. Otherwise it wont work well on systems that have mixed CI and non-CI cards. Or two cards with different CI (e.g. premiere + orf).
Kind regards, Stefan
On Mon, Mar 14, 2005 at 09:57:57AM +0100, Stefan Taferner wrote:
Without knowing the exact details how vdr selects where to record from, I think a correct solution would be:
a) is there a card recording on that transponder, then use that card b) is there a free card without CI that can record it, then use that card c) use the next best card, with the primary card last
One should take into account that some primary device are not real devices also :-)
On Monday 14 March 2005 10:07, Grégoire Favre wrote:
On Mon, Mar 14, 2005 at 09:57:57AM +0100, Stefan Taferner wrote:
Without knowing the exact details how vdr selects where to record from, I think a correct solution would be:
a) is there a card recording on that transponder, then use that card b) is there a free card without CI that can record it, then use that card c) use the next best card, with the primary card last
One should take into account that some primary device are not real devices also :-)
When speaking of "devices" we mean input devices, of course. For example xine and dxr3 are output-only devices.
Or did you mean something else?
--Stefan
Stefan Taferner taferner@kde.org writes:
[...]
The timer was started on a full device, which isn't a good idea as all the budget cards too can receive the channel. But even after the timer was running on a full card, I have thought VDR would swap the timer to another card, if the full card was needed for a channel it only could provide. This did not happen now. Why not?
[...]
As to why the recording started on the primary device, while there were budget cards free at the time, I guess you'll need to do some debugging in cDvbDevice::ProvidesChannel(). Here on my system recordings only use the primary device if all others are already in use.
I can confirm this bug. I have the same setup with two DVB-S cards, and it also happened here in the past with vdr-1.3.x If I have two timers for 20:15 I have to ensure that the timer for the full featured card starts before the timer of the budget card.
Btw, could it be possible to have the ability to manually choose the device for records(timers), live watching and stuff ? Multiple cards handling would be more granular.
Do you think it's a good idea ?
On Mon, 14 Mar 2005, [iso-8859-1] Grégoire Favre wrote:
Hello,
I have the same bug, and I was thinking it was introduced with the configurable LNB sharing patch, but you are right, without the patch I have the same problem. My system has 2 FF as first card and one budget as third one, but the primary device is the fourth pseudo one for xine.
I have seen the same bug. We have to FF DVB-c cards and one CAM connected to the primary card. Yesterday I had two timers at the same time, of which one was recording an encrypted show. This worked well until VDR decided to restart, and after the restart the non-encrypted recording always "took" the primary card (with the CAM), so the second recording that needed the CAM couldn't continue. I had to manually turn off the non-encrypted recording and then restart so that VDR gave the card with the CAM to the correct recording, and then manually reenable the non-encrypted one.
-- Somewhere around the place I've got an unfinished short story about Schroedinger's Dog; it was mostly moaning about all the attention the cat was getting. -- Terry Pratchett, alt.fan.pratchett
-
Grégoire Favre -
Jan Ekholm -
Klaus Schmidinger -
Rantanen Teemu -
Stefan Taferner -
syrius.ml＠no-log.org