Hi all!
Our local cable operator transmit on same frequency FTA and scrambled channels. During recording on FTA channel it is not possible to switch to any scrambled channel on the same frequency. "Channel not available!" message received.
At the same time, when recording scrambled channel, switching to FTA or to other scrambled works.
This behavior introduced with vdr-1.5.x versions (at least since 1.5.2, if I remember correctly). vdr-1.4.7 performs fine in same situation.
Regards, AK
On Wed, Oct 17, 2007 at 11:55:55AM +0300, Arthur Konovalov wrote:
Hi all!
Our local cable operator transmit on same frequency FTA and scrambled channels. During recording on FTA channel it is not possible to switch to any scrambled channel on the same frequency. "Channel not available!" message received.
At the same time, when recording scrambled channel, switching to FTA or to other scrambled works.
This behavior introduced with vdr-1.5.x versions (at least since 1.5.2, if I remember correctly). vdr-1.4.7 performs fine in same situation.
I will confirm this, this was main reason for me to change back to 1.4
I also have experienced this with DVB-S, however in my situation I experienced it a bit different.
I was switched to a radio channel which was FTA, a timer was set to record a channel on the same transponder but is scrambled. The vdr info bar showed it was recording. The directory was created but the file 001.vdr was size 0. It also shows that I cannot tune to this channel . I had to stop the timer/recording and switch to the scrambled channel and enable the timer. But from there on I could jump back to the FTA radio channel. Same happens every time I'm on a FTA channel and a timer starts after I tuned to the channel.
Theunis
On 17/10/2007, Arthur Konovalov kasjas@hot.ee wrote:
Hi all!
Our local cable operator transmit on same frequency FTA and scrambled channels. During recording on FTA channel it is not possible to switch to any scrambled channel on the same frequency. "Channel not available!" message received.
At the same time, when recording scrambled channel, switching to FTA or to other scrambled works.
This behavior introduced with vdr-1.5.x versions (at least since 1.5.2, if I remember correctly). vdr-1.4.7 performs fine in same situation.
Regards, AK
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Theunis Potgieter wrote:
I also have experienced this with DVB-S, however in my situation I experienced it a bit different.
I was switched to a radio channel which was FTA, a timer was set to record a channel on the same transponder but is scrambled. The vdr info bar showed it was recording. The directory was created but the file 001.vdr was size 0. It also shows that I cannot tune to this channel . I had to stop the timer/recording and switch to the scrambled channel and enable the timer. But from there on I could jump back to the FTA radio channel. Same happens every time I'm on a FTA channel and a timer starts after I tuned to the channel.
Theunis
On 17/10/2007, *Arthur Konovalov* <kasjas@hot.ee mailto:kasjas@hot.ee> wrote:
Hi all! Our local cable operator transmit on same frequency FTA and scrambled channels. During recording on FTA channel it is not possible to switch to any scrambled channel on the same frequency. "Channel not available!" message received. At the same time, when recording scrambled channel, switching to FTA or to other scrambled works. This behavior introduced with vdr-1.5.x versions (at least since 1.5.2, if I remember correctly). vdr-1.4.7 performs fine in same situation.
Klaus,
what You can tell about fixing this problem? This is main restriction to switch to vdr-1.5 line.
Regards, AK
On 11/08/07 10:52, Arthur Konovalov wrote:
Theunis Potgieter wrote:
I also have experienced this with DVB-S, however in my situation I experienced it a bit different.
I was switched to a radio channel which was FTA, a timer was set to record a channel on the same transponder but is scrambled. The vdr info bar showed it was recording. The directory was created but the file 001.vdr was size 0. It also shows that I cannot tune to this channel . I had to stop the timer/recording and switch to the scrambled channel and enable the timer. But from there on I could jump back to the FTA radio channel. Same happens every time I'm on a FTA channel and a timer starts after I tuned to the channel.
Theunis
On 17/10/2007, *Arthur Konovalov* <kasjas@hot.ee mailto:kasjas@hot.ee> wrote:
Hi all! Our local cable operator transmit on same frequency FTA and scrambled channels. During recording on FTA channel it is not possible to switch to any scrambled channel on the same frequency. "Channel not available!" message received. At the same time, when recording scrambled channel, switching to FTA or to other scrambled works. This behavior introduced with vdr-1.5.x versions (at least since 1.5.2, if I remember correctly). vdr-1.4.7 performs fine in same situation.Klaus,
what You can tell about fixing this problem? This is main restriction to switch to vdr-1.5 line.
Regards, AK
I tried to reproduce this here, but everything worked fine. Here's what I did:
- start VDR with only a single FF card with one CAM - switch to an encrypted channel => channel displays in live mode - start a recording on that channel => recording successful - switch to an FTA channel on the same transponder => channel displays in live mode - start a recording on that channel => recording successful
At this point I had two recordings running on the same transponder, one with an encrypted channel and one FTA.
This also worked the other way round (first recording FTA, then encrypted).
This was done with the version 1.5.13 code base.
Does the problem still persist on your system with VDR 1.5.13?
Klaus
I am using vdr-1.5.13
- start vdr and switch to encrypted channel - set timer on encrypted channel one minute in advance from current time - switch to same Transponder with FTA channel, in my situation a radio channel - once the timer started I cannot switch back to the encrypted channel with message channel is not available. In the recordings list it shows the file but in 0 size. - stop timer is the only way to switch back to encrypted channel.
Theunis
On 08/02/2008, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I tried to reproduce this here, but everything worked fine. Here's what I did:
- start VDR with only a single FF card with one CAM
- switch to an encrypted channel
=> channel displays in live mode
- start a recording on that channel
=> recording successful
- switch to an FTA channel on the same transponder
=> channel displays in live mode
- start a recording on that channel
=> recording successful
At this point I had two recordings running on the same transponder, one with an encrypted channel and one FTA.
This also worked the other way round (first recording FTA, then encrypted).
This was done with the version 1.5.13 code base.
Does the problem still persist on your system with VDR 1.5.13?
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Here is attached log for recording 17:43, after I tried to change back to the channel twice, it started recording, however if I left it, the file would have stayed zero.
On 08/02/2008, Theunis Potgieter theunis.potgieter@gmail.com wrote:
I am using vdr-1.5.13
- start vdr and switch to encrypted channel
- set timer on encrypted channel one minute in advance from current time
- switch to same Transponder with FTA channel, in my situation a radio channel
- once the timer started I cannot switch back to the encrypted channel
with message channel is not available. In the recordings list it shows the file but in 0 size.
- stop timer is the only way to switch back to encrypted channel.
Theunis
On 08/02/2008, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I tried to reproduce this here, but everything worked fine. Here's what I did:
- start VDR with only a single FF card with one CAM
- switch to an encrypted channel
=> channel displays in live mode
- start a recording on that channel
=> recording successful
- switch to an FTA channel on the same transponder
=> channel displays in live mode
- start a recording on that channel
=> recording successful
At this point I had two recordings running on the same transponder, one with an encrypted channel and one FTA.
This also worked the other way round (first recording FTA, then encrypted).
This was done with the version 1.5.13 code base.
Does the problem still persist on your system with VDR 1.5.13?
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 02/08/08 16:32, Theunis Potgieter wrote:
I am using vdr-1.5.13
- start vdr and switch to encrypted channel
- set timer on encrypted channel one minute in advance from current time
- switch to same Transponder with FTA channel, in my situation a radio channel
- once the timer started I cannot switch back to the encrypted channel
with message channel is not available. In the recordings list it shows the file but in 0 size.
- stop timer is the only way to switch back to encrypted channel.
Theunis
I did this now, and it also worked just fine.
Are you using a "plain vanilla" VDR, or are there any patches involved?
Klaus
On 08/02/2008, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I tried to reproduce this here, but everything worked fine. Here's what I did:
- start VDR with only a single FF card with one CAM
- switch to an encrypted channel
=> channel displays in live mode
- start a recording on that channel
=> recording successful
- switch to an FTA channel on the same transponder
=> channel displays in live mode
- start a recording on that channel
=> recording successful
At this point I had two recordings running on the same transponder, one with an encrypted channel and one FTA.
This also worked the other way round (first recording FTA, then encrypted).
This was done with the version 1.5.13 code base.
Does the problem still persist on your system with VDR 1.5.13?
Klaus
mag video # equery uses vdr [ Searching for packages matching vdr... ] [ Colour Code : set unset ] [ Legend : Left column (U) - USE flags from make.conf ] [ : Right column (I) - USE flags packages was installed with ] [ Found these USE variables for media-video/vdr-1.5.13 ] U I - - cmdsubmenu : Allows the creation of submenus in the commands menu + + cutterlimit : Limit IO bandwith used for cutting + + cutterqueue : Adds a queue of recordings to be cutted - - cuttime : Adjust starttime of cutted recording by length of cut out parts - - ddepgentry : remove duplicate EPG entries - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see http://www.gentoo.o rg/proj/en/qa/backtraces.xml - - dolbyinrec : add a dedicated switch to control recording of dolby digital + + dvbplayer : Use some special mpeg-repacker features. Most usable for old recordings or software output devices. + + dvbsetup : Setup for AC3 transfer, disable primary tuner - - dvdarchive : DMH DVD - Archiv ( used by vdr-burn-0.1.0_* ) - - dvdchapjump : Jump on capitels on DMH DVD - Archiv - - dvlfriendlyfnames : filter file names on recording - - dvlrecscriptaddon : enhancement for record-script - - dvlvidprefer : controls video-dir choice on recording + + graphtft : support for grapftft plugin up from vdr-graphtft-0.1.7 - - hardlinkcutter : Speed up cutting by hardlinking unchanged files - - iptv : Enables support for vdr-iptv - - jumpplay : Enables automatic jumping over cut marks while watching a recording - - liemikuutio : Formerly known as AIO (all-in-one) patch, adds some nice must haves - - lircsettings : Allows to change lirc settings delay, freq and timeout values in OSD - - livebuffer : does timeshifting/background recording all the time, allows to rewind live TV - - lnbshare : Enables support for two or more dvb cards sharing the same cable to the lnb + + mainmenuhooks : Allows to replace main menu entries by some special plugins (like epgsearch, extrecmenu, ...) + + menuorg : Enables support for the menuorg-plugin + + noepg : Adds code to selectively disable epg-reception for specific channels - - osdmaxitems : Support for text2skin - - pinplugin : Support for pin plugin - - premiereepgfix : <unknown> - - rotor : Enable support for plugin vdr-rotor for dish-positioner. - - settime : set system time per script instead of via syscal - - setup : Enable support for the plugin vdr-setup - - sortrecords : allows to change sort order of recordings - - sourcecaps : Adds the ability to define capabilities of dvb-cards (e.g. card1 can receive Sat @28.2E) - - submenu : Enable support for the plugin vdr-submenu. - - syncearly : start live display as soon as possible, not waiting for sync of audio and video - - timercmd : Adds submenu for user defined commands in timer menu - - timerinfo : Show with chars +/- if space on HD will suffice for a timer - - ttxtsubs : <unknown> - - validinput : Signal if it is possible to go left/right in lists with chars < > - - vanilla : Do not add extra patches which change default behaviour; DO NOT USE THIS ON A GLOBAL SCALE as the severity of the meaning cha nges drastically - - volctrl : allows volume control using left/right keys - - wareagleicon : Replace original icon set in menu - - yaepg : Enables support for the plugin vdr-yaepg
patches used: cutterlimit, cutterqueue, dvbplayer, dvbsetup, graphtft, mainmenuhooks, menuorg, noepg
gentoo: overlay vdr-1.5
Theunis
On 08/02/2008, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 02/08/08 16:32, Theunis Potgieter wrote:
I am using vdr-1.5.13
- start vdr and switch to encrypted channel
- set timer on encrypted channel one minute in advance from current time
- switch to same Transponder with FTA channel, in my situation a radio channel
- once the timer started I cannot switch back to the encrypted channel
with message channel is not available. In the recordings list it shows the file but in 0 size.
- stop timer is the only way to switch back to encrypted channel.
Theunis
I did this now, and it also worked just fine.
Are you using a "plain vanilla" VDR, or are there any patches involved?
Klaus
On 08/02/2008, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I tried to reproduce this here, but everything worked fine. Here's what I did:
- start VDR with only a single FF card with one CAM
- switch to an encrypted channel
=> channel displays in live mode
- start a recording on that channel
=> recording successful
- switch to an FTA channel on the same transponder
=> channel displays in live mode
- start a recording on that channel
=> recording successful
At this point I had two recordings running on the same transponder, one with an encrypted channel and one FTA.
This also worked the other way round (first recording FTA, then encrypted).
This was done with the version 1.5.13 code base.
Does the problem still persist on your system with VDR 1.5.13?
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 02/08/08 17:17, Theunis Potgieter wrote:
mag video # equery uses vdr [ Searching for packages matching vdr... ] [ Colour Code : set unset ] [ Legend : Left column (U) - USE flags from make.conf ] [ : Right column (I) - USE flags packages was installed with ] [ Found these USE variables for media-video/vdr-1.5.13 ] U I
- cmdsubmenu : Allows the creation of submenus in the commands menu
- cutterlimit : Limit IO bandwith used for cutting
- cutterqueue : Adds a queue of recordings to be cutted
- cuttime : Adjust starttime of cutted recording by
length of cut out parts
- ddepgentry : remove duplicate EPG entries
- debug : Enable extra debug codepaths, like asserts
and extra output. If you want to get meaningful backtraces see http://www.gentoo.o rg/proj/en/qa/backtraces.xml
- dolbyinrec : add a dedicated switch to control recording
of dolby digital
- dvbplayer : Use some special mpeg-repacker features. Most
usable for old recordings or software output devices.
- dvbsetup : Setup for AC3 transfer, disable primary tuner
- dvdarchive : DMH DVD - Archiv ( used by vdr-burn-0.1.0_* )
- dvdchapjump : Jump on capitels on DMH DVD - Archiv
- dvlfriendlyfnames : filter file names on recording
- dvlrecscriptaddon : enhancement for record-script
- dvlvidprefer : controls video-dir choice on recording
- graphtft : support for grapftft plugin up from vdr-graphtft-0.1.7
- hardlinkcutter : Speed up cutting by hardlinking unchanged files
- iptv : Enables support for vdr-iptv
- jumpplay : Enables automatic jumping over cut marks
while watching a recording
- liemikuutio : Formerly known as AIO (all-in-one) patch,
adds some nice must haves
- lircsettings : Allows to change lirc settings delay, freq
and timeout values in OSD
- livebuffer : does timeshifting/background recording all
the time, allows to rewind live TV
- lnbshare : Enables support for two or more dvb cards
sharing the same cable to the lnb
- mainmenuhooks : Allows to replace main menu entries by some
special plugins (like epgsearch, extrecmenu, ...)
- menuorg : Enables support for the menuorg-plugin
- noepg : Adds code to selectively disable
epg-reception for specific channels
- osdmaxitems : Support for text2skin
- pinplugin : Support for pin plugin
- premiereepgfix : <unknown>
- rotor : Enable support for plugin vdr-rotor for
dish-positioner.
- settime : set system time per script instead of via syscal
- setup : Enable support for the plugin vdr-setup
- sortrecords : allows to change sort order of recordings
- sourcecaps : Adds the ability to define capabilities of
dvb-cards (e.g. card1 can receive Sat @28.2E)
- submenu : Enable support for the plugin vdr-submenu.
- syncearly : start live display as soon as possible, not
waiting for sync of audio and video
- timercmd : Adds submenu for user defined commands in timer menu
- timerinfo : Show with chars +/- if space on HD will
suffice for a timer
- ttxtsubs : <unknown>
- validinput : Signal if it is possible to go left/right in
lists with chars < >
- vanilla : Do not add extra patches which change default
behaviour; DO NOT USE THIS ON A GLOBAL SCALE as the severity of the meaning cha nges drastically
- volctrl : allows volume control using left/right keys
- wareagleicon : Replace original icon set in menu
- yaepg : Enables support for the plugin vdr-yaepg
patches used: cutterlimit, cutterqueue, dvbplayer, dvbsetup, graphtft, mainmenuhooks, menuorg, noepg
gentoo: overlay vdr-1.5
Theunis
Please try this with a plain vanilla VDR. If the problem happens there, too, I'll look further into it. However, since I can't reproduce it here, there's probably not much I can do...
Klaus
On 08/02/2008, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 02/08/08 16:32, Theunis Potgieter wrote:
I am using vdr-1.5.13
- start vdr and switch to encrypted channel
- set timer on encrypted channel one minute in advance from current time
- switch to same Transponder with FTA channel, in my situation a radio channel
- once the timer started I cannot switch back to the encrypted channel
with message channel is not available. In the recordings list it shows the file but in 0 size.
- stop timer is the only way to switch back to encrypted channel.
Theunis
I did this now, and it also worked just fine.
Are you using a "plain vanilla" VDR, or are there any patches involved?
Klaus
On 08/02/2008, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
I tried to reproduce this here, but everything worked fine. Here's what I did:
- start VDR with only a single FF card with one CAM
- switch to an encrypted channel
=> channel displays in live mode
- start a recording on that channel
=> recording successful
- switch to an FTA channel on the same transponder
=> channel displays in live mode
- start a recording on that channel
=> recording successful
At this point I had two recordings running on the same transponder, one with an encrypted channel and one FTA.
This also worked the other way round (first recording FTA, then encrypted).
This was done with the version 1.5.13 code base.
Does the problem still persist on your system with VDR 1.5.13?
Klaus
On Fri, Feb 08, 2008 at 04:12:04PM +0100, Klaus Schmidinger wrote:
On 17/10/2007, *Arthur Konovalov* <kasjas@hot.ee mailto:kasjas@hot.ee> wrote:
Hi all! Our local cable operator transmit on same frequency FTA and scrambled channels. During recording on FTA channel it is not possible to switch to any scrambled channel on the same frequency. "Channel not available!" message received. At the same time, when recording scrambled channel, switching to FTA or to other scrambled works. This behavior introduced with vdr-1.5.x versions (at least since 1.5.2, if I remember correctly). vdr-1.4.7 performs fine in same situation.
- start VDR with only a single FF card with one CAM
What about with budget card? With budget cards it happened for me.
On 02/08/08 17:40, Antti Hartikainen wrote:
On Fri, Feb 08, 2008 at 04:12:04PM +0100, Klaus Schmidinger wrote:
On 17/10/2007, *Arthur Konovalov* <kasjas@hot.ee mailto:kasjas@hot.ee> wrote:
Hi all! Our local cable operator transmit on same frequency FTA and scrambled channels. During recording on FTA channel it is not possible to switch to any scrambled channel on the same frequency. "Channel not available!" message received. At the same time, when recording scrambled channel, switching to FTA or to other scrambled works. This behavior introduced with vdr-1.5.x versions (at least since 1.5.2, if I remember correctly). vdr-1.4.7 performs fine in same situation.
- start VDR with only a single FF card with one CAM
What about with budget card? With budget cards it happened for me.
I don't have a budget card with CAM in my system.
Klaus
On 02/08/08 17:58, Klaus Schmidinger wrote:
On 02/08/08 17:40, Antti Hartikainen wrote:
On Fri, Feb 08, 2008 at 04:12:04PM +0100, Klaus Schmidinger wrote:
On 17/10/2007, *Arthur Konovalov* <kasjas@hot.ee mailto:kasjas@hot.ee> wrote:
Hi all! Our local cable operator transmit on same frequency FTA and scrambled channels. During recording on FTA channel it is not possible to switch to any scrambled channel on the same frequency. "Channel not available!" message received. At the same time, when recording scrambled channel, switching to FTA or to other scrambled works. This behavior introduced with vdr-1.5.x versions (at least since 1.5.2, if I remember correctly). vdr-1.4.7 performs fine in same situation.
- start VDR with only a single FF card with one CAM
What about with budget card? With budget cards it happened for me.
I don't have a budget card with CAM in my system.
For further testing I have now modified my cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) function so that it never returns the primary device. So VDR always runs in Transfer-Mode, and both the encrypted and the FTA channel will have to be fetched from my second FF card with CAM (which would then act like a budget card).
Even in this constellation everything worked as expected, and I was able to record the encrypted channel and switch live between the FTA and the encrypted channel.
Klaus
On 02/09/08 11:22, Klaus Schmidinger wrote:
On 02/08/08 17:58, Klaus Schmidinger wrote:
On 02/08/08 17:40, Antti Hartikainen wrote:
On Fri, Feb 08, 2008 at 04:12:04PM +0100, Klaus Schmidinger wrote:
On 17/10/2007, *Arthur Konovalov* <kasjas@hot.ee mailto:kasjas@hot.ee> wrote:
Hi all! Our local cable operator transmit on same frequency FTA and scrambled channels. During recording on FTA channel it is not possible to switch to any scrambled channel on the same frequency. "Channel not available!" message received. At the same time, when recording scrambled channel, switching to FTA or to other scrambled works. This behavior introduced with vdr-1.5.x versions (at least since 1.5.2, if I remember correctly). vdr-1.4.7 performs fine in same situation.
- start VDR with only a single FF card with one CAM
What about with budget card? With budget cards it happened for me.
I don't have a budget card with CAM in my system.
For further testing I have now modified my cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) function so that it never returns the primary device. So VDR always runs in Transfer-Mode, and both the encrypted and the FTA channel will have to be fetched from my second FF card with CAM (which would then act like a budget card).
Even in this constellation everything worked as expected, and I was able to record the encrypted channel and switch live between the FTA and the encrypted channel.
I just read your original posting again, and there you described the problem the other way round. So I also tested recording the FTA channel and then switching to the encrypted channel, but this also works fine here.
So I'm afraid I don't know what's causing this for you.
Klaus
Klaus Schmidinger wrote:
I just read your original posting again, and there you described the problem the other way round. So I also tested recording the FTA channel and then switching to the encrypted channel, but this also works fine here.
So I'm afraid I don't know what's causing this for you.
Very strange. I noticed that message "channel on available" apperars momentarily after switching to another channel. It seems like vdr not trying to decode anything. May be You can provide some lines to vdr code for debugging reason of message "channel not available"? I have interest to solve this problem ;)
Regards, AK
On 02/09/08 18:24, Arthur Konovalov wrote:
Klaus Schmidinger wrote:
I just read your original posting again, and there you described the problem the other way round. So I also tested recording the FTA channel and then switching to the encrypted channel, but this also works fine here.
So I'm afraid I don't know what's causing this for you.
Very strange. I noticed that message "channel on available" apperars momentarily after switching to another channel. It seems like vdr not trying to decode anything. May be You can provide some lines to vdr code for debugging reason of message "channel not available"? I have interest to solve this problem ;)
Please try the attached version of cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView), redirect stdout into a file and send me the result.
Klaus
cDevice *cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView) { printf("\nGetDevice %d %d %d - '%s'\n", Channel->Number(), Priority, LiveView, *Channel->ToText());//XXX // Collect the current priorities of all CAM slots that can decrypt the channel: int NumCamSlots = CamSlots.Count(); int SlotPriority[NumCamSlots]; int NumUsableSlots = 0; if (Channel->Ca() >= CA_ENCRYPTED_MIN) { for (cCamSlot *CamSlot = CamSlots.First(); CamSlot; CamSlot = CamSlots.Next(CamSlot)) { SlotPriority[CamSlot->Index()] = MAXPRIORITY + 1; // assumes it can't be used if (CamSlot->ModuleStatus() == msReady) { if (CamSlot->ProvidesCa(Channel->Caids())) { if (!ChannelCamRelations.CamChecked(Channel->GetChannelID(), CamSlot->SlotNumber())) { SlotPriority[CamSlot->Index()] = CamSlot->Priority(); NumUsableSlots++; } } } } if (!NumUsableSlots) return NULL; // no CAM is able to decrypt this channel } printf("NumUsableSlots = %d\n", NumUsableSlots);//XXX
bool NeedsDetachReceivers = false; cDevice *d = NULL; cCamSlot *s = NULL;
uint32_t Impact = 0xFFFFFFFF; // we're looking for a device with the least impact for (int j = 0; j < NumCamSlots || !NumUsableSlots; j++) { printf("j = %d\n", j);//XXX if (NumUsableSlots && SlotPriority[j] > MAXPRIORITY) continue; // there is no CAM available in this slot for (int i = 0; i < numDevices; i++) { printf("i = %d\n", i);//XXX if (Channel->Ca() && Channel->Ca() <= CA_DVB_MAX && Channel->Ca() != device[i]->CardIndex() + 1) continue; // a specific card was requested, but not this one printf("A\n");//XXX if (NumUsableSlots && !CamSlots.Get(j)->Assign(device[i], true)) continue; // CAM slot can't be used with this device printf("B\n");//XXX bool ndr; if (device[i]->ProvidesChannel(Channel, Priority, &ndr)) { // this device is basicly able to do the job printf("C %d\n", ndr);//XXX if (NumUsableSlots && device[i]->CamSlot() && device[i]->CamSlot() != CamSlots.Get(j)) ndr = true; // using a different CAM slot requires detaching receivers printf("D %d\n", ndr);//XXX // Put together an integer number that reflects the "impact" using // this device would have on the overall system. Each condition is represented // by one bit in the number (or several bits, if the condition is actually // a numeric value). The sequence in which the conditions are listed corresponds // to their individual severity, where the one listed first will make the most // difference, because it results in the most significant bit of the result. uint32_t imp = 0; imp <<= 1; imp |= LiveView ? !device[i]->IsPrimaryDevice() || ndr : 0; // prefer the primary device for live viewing if we don't need to detach existing receivers imp <<= 1; imp |= !device[i]->Receiving() && (device[i] != cTransferControl::ReceiverDevice() || device[i]->IsPrimaryDevice()) || ndr; // use receiving devices if we don't need to detach existing receivers, but avoid primary device in local transfer mode imp <<= 1; imp |= device[i]->Receiving(); // avoid devices that are receiving imp <<= 1; imp |= device[i] == cTransferControl::ReceiverDevice(); // avoid the Transfer Mode receiver device imp <<= 8; imp |= min(max(device[i]->Priority() + MAXPRIORITY, 0), 0xFF); // use the device with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used) imp <<= 8; imp |= min(max((NumUsableSlots ? SlotPriority[j] : 0) + MAXPRIORITY, 0), 0xFF); // use the CAM slot with the lowest priority (+MAXPRIORITY to assure that values -99..99 can be used) imp <<= 1; imp |= ndr; // avoid devices if we need to detach existing receivers imp <<= 1; imp |= device[i]->IsPrimaryDevice(); // avoid the primary device imp <<= 1; imp |= NumUsableSlots ? 0 : device[i]->HasCi(); // avoid cards with Common Interface for FTA channels imp <<= 1; imp |= device[i]->HasDecoder(); // avoid full featured cards imp <<= 1; imp |= NumUsableSlots ? !ChannelCamRelations.CamDecrypt(Channel->GetChannelID(), j + 1) : 0; // prefer CAMs that are known to decrypt this channel printf("E %08X %08X\n", Impact, imp);//XXX if (imp < Impact) { // This device has less impact than any previous one, so we take it. Impact = imp; d = device[i]; NeedsDetachReceivers = ndr; if (NumUsableSlots) s = CamSlots.Get(j); } } } if (!NumUsableSlots) break; // no CAM necessary, so just one loop over the devices } if (d) { printf("X %d\n", d->CardIndex());//XXX if (NeedsDetachReceivers) d->DetachAllReceivers(); if (s) { if (s->Device() != d) { if (s->Device()) s->Device()->DetachAllReceivers(); if (d->CamSlot()) d->CamSlot()->Assign(NULL); s->Assign(d); } } else if (d->CamSlot() && !d->CamSlot()->IsDecrypting()) d->CamSlot()->Assign(NULL); } printf("Z\n");//XXX return d; }
On Sat, Feb 09, 2008 at 11:06:35PM +0100, Klaus Schmidinger wrote:
On 02/09/08 18:24, Arthur Konovalov wrote:
Klaus Schmidinger wrote:
I just read your original posting again, and there you described the problem the other way round. So I also tested recording the FTA channel and then switching to the encrypted channel, but this also works fine here.
So I'm afraid I don't know what's causing this for you.
Very strange. I noticed that message "channel on available" apperars momentarily after switching to another channel. It seems like vdr not trying to decode anything. May be You can provide some lines to vdr code for debugging reason of message "channel not available"? I have interest to solve this problem ;)
Please try the attached version of cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView), redirect stdout into a file and send me the result.
I tried it, with vdr 1.5.14.
As a side-note, i CAN record FTA-channel and watch scrambled channel with another budget-card (i have 2 DVB-T budget tuners).
This experience is with ONE tuner: 1) I can record multiple scrambled channels from same multiplex 2) I can watch FTA-channels while recording scrambled ones. 3) I CAN'T watch scrambled channels while recording FTA channel on same multiplex. 4) I CAN start record on FTA channel, while recording scrambled channel, which is started before recording on FTA (then i can also WATCH any other scrambled channel from same multiplex too)
So while there's no recording on scrambled channel, while recording FTA channel, i can't watch any scrambled channels from same multiplex. When starting recording on scrambled channel (before starting recording on FTA), everything works as should.
Here is debug info with only one tuner in use:
Changing to FTA channel:
GetDevice 3 0 1 - 'MTV3;MTV Oy:658000000:A0B8C23D23G8I0M64P0T8Y0:T:3:305:561=fin:817:0:49:8438:8193:0 ' NumUsableSlots = 0 j = 0 i = 0 A B i = 1 A B C 0 D 0 E FFFFFFFF 180C4C64 i = 2 A B i = 3 A B X 1 Z
started recording:
GetDevice 3 50 0 - 'MTV3;MTV Oy:658000000:A0B8C23D23G8I0M64P0T8Y0:T:3:305:561=fin:817:0:49:8438:8193:0 ' NumUsableSlots = 0 j = 0 i = 0 A B i = 1 A B C 0 D 0 E FFFFFFFF 002C4C64 i = 2 A B i = 3 A B X 1 Z
Change to scrambled channel:
GetDevice 25 0 1 - 'MTV3 MAX;MTV Oy:658000000:A0B8C23D23G8I0M64P0T8Y0:T:3:304:560=fin:817:B00:209:8438:8193:0 ' NumUsableSlots = 4 j = 0 i = 0 A i = 1 A i = 2 A i = 3 A B j = 1 i = 0 A i = 1 A i = 2 A B i = 3 A j = 2 i = 0 A i = 1 A B C 0 D 0 E FFFFFFFF 1412AC41 i = 2 A i = 3 A j = 3 j = 4 j = 5 i = 0 A B i = 1 A i = 2 A i = 3 A X 1 Z
///// in this point appears "channel not available" -error
GetDevice 25 0 1 - 'MTV3 MAX;MTV Oy:658000000:A0B8C23D23G8I0M64P0T8Y0:T:3:304:560=fin:817:B00:209:8438:8193:0 ' NumUsableSlots = 3 j = 0 i = 0 A i = 1 A i = 2 A i = 3 A B j = 1 i = 0 A i = 1 A i = 2 A B i = 3 A j = 2 j = 3 j = 4 j = 5 i = 0 A B i = 1 A i = 2 A i = 3 A Z
On 02/10/08 09:16, Antti Hartikainen wrote:
On Sat, Feb 09, 2008 at 11:06:35PM +0100, Klaus Schmidinger wrote:
On 02/09/08 18:24, Arthur Konovalov wrote:
Klaus Schmidinger wrote:
I just read your original posting again, and there you described the problem the other way round. So I also tested recording the FTA channel and then switching to the encrypted channel, but this also works fine here.
So I'm afraid I don't know what's causing this for you.
Very strange. I noticed that message "channel on available" apperars momentarily after switching to another channel. It seems like vdr not trying to decode anything. May be You can provide some lines to vdr code for debugging reason of message "channel not available"? I have interest to solve this problem ;)
Please try the attached version of cDevice::GetDevice(const cChannel *Channel, int Priority, bool LiveView), redirect stdout into a file and send me the result.
I tried it, with vdr 1.5.14.
As a side-note, i CAN record FTA-channel and watch scrambled channel with another budget-card (i have 2 DVB-T budget tuners).
This experience is with ONE tuner:
- I can record multiple scrambled channels from same multiplex
- I can watch FTA-channels while recording scrambled ones.
- I CAN'T watch scrambled channels while recording FTA channel on same multiplex.
- I CAN start record on FTA channel, while recording scrambled channel, which is started before recording on FTA (then i can also WATCH any other scrambled
channel from same multiplex too)
So while there's no recording on scrambled channel, while recording FTA channel, i can't watch any scrambled channels from same multiplex. When starting recording on scrambled channel (before starting recording on FTA), everything works as should.
Here is debug info with only one tuner in use:
Changing to FTA channel:
GetDevice 3 0 1 - 'MTV3;MTV Oy:658000000:A0B8C23D23G8I0M64P0T8Y0:T:3:305:561=fin:817:0:49:8438:8193:0 ' NumUsableSlots = 0 j = 0 i = 0 A B i = 1 A B C 0 D 0 E FFFFFFFF 180C4C64 i = 2 A B i = 3 A B X 1 Z
started recording:
GetDevice 3 50 0 - 'MTV3;MTV Oy:658000000:A0B8C23D23G8I0M64P0T8Y0:T:3:305:561=fin:817:0:49:8438:8193:0 ' NumUsableSlots = 0 j = 0 i = 0 A B i = 1 A B C 0 D 0 E FFFFFFFF 002C4C64 i = 2 A B i = 3 A B X 1 Z
Change to scrambled channel:
GetDevice 25 0 1 - 'MTV3 MAX;MTV Oy:658000000:A0B8C23D23G8I0M64P0T8Y0:T:3:304:560=fin:817:B00:209:8438:8193:0 ' NumUsableSlots = 4
You wrote that you are using only a single budget card. How can a single budget card have 4 CI slots? And all four of these apparently contain a CAM that is ready?!
What kind of CI hardware and CAM(s) are you using?
Klaus
j = 0 i = 0 A i = 1 A i = 2 A i = 3 A B j = 1 i = 0 A i = 1 A i = 2 A B i = 3 A j = 2 i = 0 A i = 1 A B C 0 D 0 E FFFFFFFF 1412AC41 i = 2 A i = 3 A j = 3 j = 4 j = 5 i = 0 A B i = 1 A i = 2 A i = 3 A X 1 Z
///// in this point appears "channel not available" -error
GetDevice 25 0 1 - 'MTV3 MAX;MTV Oy:658000000:A0B8C23D23G8I0M64P0T8Y0:T:3:304:560=fin:817:B00:209:8438:8193:0 ' NumUsableSlots = 3 j = 0 i = 0 A i = 1 A i = 2 A i = 3 A B j = 1 i = 0 A i = 1 A i = 2 A B i = 3 A j = 2 j = 3 j = 4 j = 5 i = 0 A B i = 1 A i = 2 A i = 3 A Z
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Sun, Feb 10, 2008 at 10:46:25AM +0100, Klaus Schmidinger wrote:
On 02/10/08 09:16, Antti Hartikainen wrote:
NumUsableSlots = 4
You wrote that you are using only a single budget card. How can a single budget card have 4 CI slots? And all four of these apparently contain a CAM that is ready?!
Well one slot for each card ;) System has totally 6 DVB-devices, but at the moment of testing only one (1) DVB-T tuner was available for VDR (3 other devices were DVB-S tuners, including FF-card too).
NumUsableSlots is one less when error about channel not being available appears, so slot of this card disappears somewhere?
On 02/10/08 11:07, Antti Hartikainen wrote:
On Sun, Feb 10, 2008 at 10:46:25AM +0100, Klaus Schmidinger wrote:
On 02/10/08 09:16, Antti Hartikainen wrote:
NumUsableSlots = 4
You wrote that you are using only a single budget card. How can a single budget card have 4 CI slots? And all four of these apparently contain a CAM that is ready?!
Well one slot for each card ;) System has totally 6 DVB-devices, but at the moment of testing only one (1) DVB-T tuner was available for VDR (3 other devices were DVB-S tuners, including FF-card too).
Ah, I see.
NumUsableSlots is one less when error about channel not being available appears, so slot of this card disappears somewhere?
The slot is used to receive the encrypted channel:
Change to scrambled channel:
GetDevice 25 0 1 - 'MTV3 MAX;MTV Oy:658000000:A0B8C23D23G8I0M64P0T8Y0:T:3:304:560=fin:817:B00:209:8438:8193:0 ' NumUsableSlots = 4 ... X 1 Z
The "X 1" output indicates that a DVB card and CAM combination was found that can decrypt this channel.
///// in this point appears "channel not available" -error
Does this message appear immediately after switching to the encrypted channel, or only after a few seconds?
I assume there are a few seconds between switching to the encrypted channel and the "channel not available" message, which would indicate that the CAM is simply not decrypting the channel.
Maybe you could activate the debug outputs in ci.c to see whether VDR actually sends the CA_PMT data to the CAM.
Klaus
Klaus Schmidinger wrote:
Maybe you could activate the debug outputs in ci.c to see whether VDR actually sends the CA_PMT data to the CAM.
Sorry for delay, busy weekend...
I enabled debug outputs in ci.c and made 2 attempts: -crypted channel recording (ok files) -FTA recording and try to switch to crypted channel (bad files)
stdout and syslog files attached. vdr-1.5.14 used.
Regards, AK
On 02/11/08 10:39, Arthur Konovalov wrote:
Klaus Schmidinger wrote:
Maybe you could activate the debug outputs in ci.c to see whether VDR actually sends the CA_PMT data to the CAM.
Sorry for delay, busy weekend...
I enabled debug outputs in ci.c and made 2 attempts: -crypted channel recording (ok files) -FTA recording and try to switch to crypted channel (bad files)
stdout and syslog files attached. vdr-1.5.14 used.
Feb 11 11:20:18 vdr vdr: [23958] cVideoRepacker: switching to MPEG1/2 mode Feb 11 11:20:18 vdr vdr: [23958] cVideoRepacker: operating in MPEG1/2 mode
There is no such output in plain vanilla VDR 1.5.14.
Please run the tests with the original, *unpatched* version 1.5.14 (or, maybe even better, 1.5.13 - since DVB-S2 support isn't going to be part of version 1.6.0) and use as few plugins as possible (best would be without *any* plugins).
Klaus
Klaus Schmidinger wrote:
Please run the tests with the original, *unpatched* version 1.5.14 (or, maybe even better, 1.5.13 - since DVB-S2 support isn't going to be part of version 1.6.0) and use as few plugins as possible (best would be without *any* plugins).
Here we are... Clean vdr-1.5.13 with 2 budget cards (DVB-T and DVB-C with CI) and xine-0.8.1 plugin.
AK
Feb 11 21:51:09 vdr vdr: [27875] VDR version 1.5.13 started Feb 11 21:51:09 vdr vdr: [27875] codeset is 'UTF-8' - known Feb 11 21:51:09 vdr vdr: [27875] found 22 locales in /usr/local/src/vdr-1.5.13/locale Feb 11 21:51:09 vdr vdr: [27875] loading plugin: /usr/local/vdr/PLUGINS/lib/libvdr-xine.so.1.5.13 Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/setup.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/sources.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/diseqc.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/channels.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/timers.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/commands.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/reccmds.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/svdrphosts.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/remote.conf Feb 11 21:51:09 vdr vdr: [27875] loading /usr/local/etc/vdr/keymacros.conf Feb 11 21:51:09 vdr vdr: [27876] video directory scanner thread started (pid=27875, tid=27876) Feb 11 21:51:09 vdr vdr: [27876] video directory scanner thread ended (pid=27875, tid=27876) Feb 11 21:51:09 vdr vdr: [27877] video directory scanner thread started (pid=27875, tid=27877) Feb 11 21:51:09 vdr vdr: [27877] video directory scanner thread ended (pid=27875, tid=27877) Feb 11 21:51:09 vdr vdr: [27875] reading EPG data from /usr/local/etc/vdr/epg.data Feb 11 21:51:09 vdr vdr: [27879] tuner on device 1 thread started (pid=27875, tid=27879) Feb 11 21:51:09 vdr vdr: [27880] section handler thread started (pid=27875, tid=27880) Feb 11 21:51:10 vdr vdr: [27882] tuner on device 2 thread started (pid=27875, tid=27882) Feb 11 21:51:10 vdr vdr: [27883] section handler thread started (pid=27875, tid=27883) Feb 11 21:51:10 vdr vdr: [27875] initializing plugin: xine (0.8.1): Software based playback using xine Feb 11 21:51:10 vdr vdr: [27884] XineRemote control thread started (pid=27875, tid=27884) Feb 11 21:51:10 vdr vdr: [27884] Entering cXineRemote thread Feb 11 21:51:10 vdr vdr: [27875] setting primary device to 3 Feb 11 21:51:10 vdr vdr: [27875] assuming manual start of VDR Feb 11 21:51:10 vdr vdr: [27875] SVDRP listening on port 2001 Feb 11 21:51:10 vdr vdr: [27875] starting plugin: xine Feb 11 21:51:10 vdr vdr: [27890] KBD remote control thread started (pid=27875, tid=27890) Feb 11 21:51:10 vdr vdr: [27875] remote control KBD - keys known Feb 11 21:51:12 vdr vdr: [27886] CAM 1: module ready Feb 11 21:51:13 vdr vdr: [27886] CAM 1: replies to QUERY - multi channel decryption possible Feb 11 21:51:13 vdr vdr: [27875] switching to channel 112 Feb 11 21:51:13 vdr vdr: [27891] transfer thread started (pid=27875, tid=27891) Feb 11 21:51:13 vdr vdr: [27892] receiver on device 2 thread started (pid=27875, tid=27892) Feb 11 21:51:13 vdr vdr: [27893] TS buffer on device 2 thread started (pid=27875, tid=27893) Feb 11 21:51:13 vdr vdr: [27875] setting watchdog timer to 60 seconds Feb 11 21:51:14 vdr vdr: [27891] setting audio track to 1 (0) Feb 11 21:51:15 vdr vdr: [27875] max. latency time 1 seconds
Feb 11 21:51:33 vdr vdr: [27875] switching device 2 to channel 112 Feb 11 21:51:33 vdr vdr: [27875] timer 1 (112 2151-2201 'TITLE EPISODE') start Feb 11 21:51:33 vdr vdr: [27875] Title: 'Kohtumine Fockeritega (Meet The Focker, USA 2004)' Subtitle: '(null)' Feb 11 21:51:33 vdr vdr: [27875] record /video/Kohtumine_Fockeritega_(Meet_The_Focker,_USA_2004)/2008-02-11.21.51.50.99.rec Feb 11 21:51:33 vdr vdr: [27875] creating directory /video/Kohtumine_Fockeritega_(Meet_The_Focker,_USA_2004)/2008-02-11.21.51.50.99.rec Feb 11 21:51:33 vdr vdr: [27875] recording to '/video/Kohtumine_Fockeritega_(Meet_The_Focker,_USA_2004)/2008-02-11.21.51.50.99.rec/001.vdr' Feb 11 21:51:33 vdr vdr: [27894] file writer thread started (pid=27875, tid=27894) Feb 11 21:51:33 vdr vdr: [27895] recording thread started (pid=27875, tid=27895) Feb 11 21:51:33 vdr vdr: [27875] info: Recording started Feb 11 21:51:39 vdr vdr: [27875] max. latency time 7 seconds
Feb 11 21:52:03 vdr vdr: [27875] CAM 1: assigned to device 2 Feb 11 21:52:03 vdr vdr: [27875] switching to channel 113 Feb 11 21:52:03 vdr vdr: [27891] transfer thread ended (pid=27875, tid=27891) Feb 11 21:52:03 vdr vdr: [27875] buffer stats: 184052 (8%) used Feb 11 21:52:03 vdr vdr: [27896] transfer thread started (pid=27875, tid=27896) Feb 11 21:52:07 vdr vdr: [27896] transfer thread ended (pid=27875, tid=27896) Feb 11 21:52:07 vdr vdr: [27875] switching to channel 113 Feb 11 21:52:07 vdr vdr: [27875] buffer stats: 63732 (3%) used Feb 11 21:52:07 vdr vdr: [27875] info: Channel not available!
Feb 11 21:52:13 vdr vdr: [27875] CAM 1: unassigned Feb 11 21:52:13 vdr vdr: [27875] switching to channel 114 Feb 11 21:52:13 vdr vdr: [27899] transfer thread started (pid=27875, tid=27899) Feb 11 21:52:13 vdr vdr: [27899] setting audio track to 1 (0)
Feb 11 21:52:15 vdr vdr: [27875] caught signal 2 Feb 11 21:52:16 vdr vdr: [27875] stopping plugin: xine Feb 11 21:52:16 vdr vdr: [27895] recording thread ended (pid=27875, tid=27895) Feb 11 21:52:16 vdr vdr: [27894] file writer thread ended (pid=27875, tid=27894) Feb 11 21:52:16 vdr vdr: [27875] buffer stats: 126524 (2%) used Feb 11 21:52:16 vdr vdr: [27875] timer 1 (112 2151-2201 'Kohtumine Fockeritega (Meet The Focker, USA 2004)') stop Feb 11 21:52:16 vdr vdr: [27899] transfer thread ended (pid=27875, tid=27899) Feb 11 21:52:16 vdr vdr: [27875] buffer stats: 102084 (4%) used Feb 11 21:52:16 vdr vdr: [27884] Leaving cXineRemote thread Feb 11 21:52:16 vdr vdr: [27884] XineRemote control thread ended (pid=27875, tid=27884) Feb 11 21:52:16 vdr vdr: [27890] KBD remote control thread ended (pid=27875, tid=27890) Feb 11 21:52:16 vdr vdr: [27875] saved setup to /usr/local/etc/vdr/setup.conf Feb 11 21:52:16 vdr vdr: [27879] tuner on device 1 thread ended (pid=27875, tid=27879) Feb 11 21:52:16 vdr vdr: [27893] TS buffer on device 2 thread ended (pid=27875, tid=27893) Feb 11 21:52:16 vdr vdr: [27892] buffer stats: 209808 (10%) used Feb 11 21:52:16 vdr vdr: [27892] receiver on device 2 thread ended (pid=27875, tid=27892) Feb 11 21:52:17 vdr vdr: [27880] section handler thread ended (pid=27875, tid=27880) Feb 11 21:52:17 vdr vdr: [27882] tuner on device 2 thread ended (pid=27875, tid=27882) Feb 11 21:52:17 vdr vdr: [27883] section handler thread ended (pid=27875, tid=27883) Feb 11 21:52:17 vdr vdr: [27875] deleting plugin: xine Feb 11 21:52:18 vdr vdr: [27875] max. latency time 7 seconds Feb 11 21:52:18 vdr vdr: [27875] exiting, exit code 0
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2008.02.11 21:50:59 =~=~=~=~=~=~=~=~=~=~=~= runvdr-test ------------------------- MakePrimaryDevice: 1 ========================= SetVideoFormat: 0 SetVolumeDevice: 40 Slot 1: module ready Slot 1: creating connection 0/1 Slot 1: create connection 0/1 1: --> 00 01 82 01 01 1: <-- 00 01 83 01 01 80 02 01 00 . . . . . . . . . Slot 1: connection created 0/1 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 07 01 91 04 00 03 00 41 80 02 01 00 . . . . . . . . . . A . . . . Slot 1: open session 00030041 Slot 1: new Conditional Access Support (session id 1) 1: --> 00 01 A0 0A 01 92 07 00 00 03 00 41 00 01 Slot 1: ==> Ca Info Enq (1) 1: --> 00 01 A0 09 01 90 02 00 01 9F 80 30 00 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 0B 01 90 02 00 01 9F 80 31 02 0B 00 80 02 01 00 . . . . . . . . . . . 1 . . . . . . . Slot 1: <== Ca Info (1) 0B00 Slot 1: ==> Ca Pmt (1) 3 3 1: --> 00 01 A0 10 01 90 02 00 01 9F 80 32 07 03 00 00 01 00 01 03 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 0D 01 90 02 00 01 9F 80 33 04 00 00 00 81 80 02 01 00 . . . . . . . . . . . 3 . . . . . . . . . Slot 1: <== Ca Pmt Reply (1) 0 00 81
GetDevice 112 0 1 - 'SAT 1;Elion:170000:M64:C:6900:2230:2231=deu;2232=deu:2233:0:1040:1:12:0 ' NumUsableSlots = 0 j = 0 i = 0 A B i = 1 A B C 0 D 0 E FFFFFFFF 018C4C64 i = 2 A B X 1 Z SetAudioChannelDevice: 0 SetVolumeDevice: 40 SetPlayMode: 1 frame: (0, 0)-(-1, -1), zoom: (1,00, 1,00) [v] SetDigitalAudioDevice: 0 SetAudioChannelDevice: 0 [v]
START FTA RECORDING <<<<
GetDevice 112 50 0 - 'SAT 1;Elion:170000:M64:C:6900:2230:2231=deu;2232=deu:2233:0:1040:1:12:0 ' NumUsableSlots = 0 j = 0 i = 0 A B i = 1 A B C 0 D 0 E FFFFFFFF 002C4C64 i = 2 A B X 1 Z frame: (0, 0)-(-1, -1), zoom: (1,00, 1,00)
SWITCH TO ENCRYPTED CH. <<<<
GetDevice 113 0 1 - 'NASN;Elion:170000:M64:C:6900:2240:2241=eng:0:B00:1090:1:12:0 ' NumUsableSlots = 1 j = 0 i = 0 A i = 1 A B C 0 D 0 E FFFFFFFF 0172AC41 i = 2 A j = 1 X 1 Z frame: (0, 0)-(-1, -1), zoom: (1,00, 1,00) SetPlayMode: 0 Slot 1: ==> Ca Pmt (1) 3 1 1: --> 00 01 A0 10 01 90 02 00 01 9F 80 32 07 03 00 00 01 00 01 01 Slot 1: receive data 0/1 1: --> 00 01 81 01 01 1: <-- 00 01 A0 0D 01 90 02 00 01 9F 80 33 04 00 00 00 81 80 02 01 00 . . . . . . . . . . . 3 . . . . . . . . . Slot 1: <== Ca Pmt Reply (1) 0 00 81
GetDevice 113 0 1 - 'NASN;Elion:170000:M64:C:6900:2240:2241=eng:0:B00:1090:1:12:0 ' NumUsableSlots = 1 j = 0 i = 0 A i = 1 A B C 0 D 0 E FFFFFFFF 0152B2A1 i = 2 A j = 1 X 1 Z Slot 1: ==> Ca Pmt (1) 4 1 1: --> 00 01 A0 20 01 90 02 00 01 9F 80 32 17 04 04 42 01 00 07 01 09 04 0B 00 E3 EC 02 08 C0 00 00 04 08 C1 00 00 SetAudioChannelDevice: 0 SetPlayMode: 1 SetPlayMode: 0 Slot 1: ==> Ca Pmt (1) 5 1 1: --> 00 01 A0 16 01 90 02 00 01 9F 80 32 0D 05 04 42 01 00 07 01 09 04 0B 00 E3 EC
GetDevice 113 0 1 - 'NASN;Elion:170000:M64:C:6900:2240:2241=eng:0:B00:1090:1:12:0 '
CHANNEL NOT AVAILABLE <<<<
frame: (0, 0)-(-1, -1), zoom: (1,00, 1,00)
GetDevice 114 0 1 - 'Star!:170000:M64:C:6900:2040:2041=eng:2042:0:1142:1:12:0 ' NumUsableSlots = 0 j = 0 i = 0 A B i = 1 A B C 0 D 0 E FFFFFFFF 0152AC64 i = 2 A B X 1 Slot 1: ==> Ca Pmt (1) 3 4 1: --> 00 01 A0 10 01 90 02 00 01 9F 80 32 07 03 00 00 01 00 01 04 Z
GetDevice 114 0 1 - 'Star!:170000:M64:C:6900:2040:2041=eng:2042:0:1142:1:12:0 ' NumUsableSlots = 0 j = 0 i = 0 A B i = 1 A B C 0 D 0 E FFFFFFFF 0152AC64 i = 2 A B X 1 Z SetAudioChannelDevice: 0 frame: (0, 0)-(-1, -1), zoom: (1,00, 1,00) SetPlayMode: 1 [v] SetDigitalAudioDevice: 0 SetAudioChannelDevice: 0 [a] SetPlayMode: 0 root@vdr:/usr/local/etc/vdr#
On 02/11/08 21:33, Arthur Konovalov wrote:
Klaus Schmidinger wrote:
Please run the tests with the original, *unpatched* version 1.5.14 (or, maybe even better, 1.5.13 - since DVB-S2 support isn't going to be part of version 1.6.0) and use as few plugins as possible (best would be without *any* plugins).
Here we are... Clean vdr-1.5.13 with 2 budget cards (DVB-T and DVB-C with CI) and xine-0.8.1 plugin.
Looks like your CAM can handle multiple parallel decryptions. So I ran the test with a CAM that can do that here, too, but the result was the same as ever - works just fine.
Which kind of CAM are you using?
Klaus
Klaus Schmidinger wrote:
Looks like your CAM can handle multiple parallel decryptions. So I ran the test with a CAM that can do that here, too, but the result was the same as ever - works just fine.
I give up. May be this is really my CAM's problem because of big silence regarding this issue... As temporary workaround I added another (USB DVB-C) card, so now it is possible to record FTA and watch *any* other channel at the same time.
Which kind of CAM are you using?
Dilog Conax Cam. Second hand, maybe defective? But with vdr-1.4.x worked. Really confused. I'll try replace it in near future.
Thanks for Your patience.
AK
On 02/12/08 20:34, Arthur Konovalov wrote:
Klaus Schmidinger wrote:
Looks like your CAM can handle multiple parallel decryptions. So I ran the test with a CAM that can do that here, too, but the result was the same as ever - works just fine.
I give up. May be this is really my CAM's problem because of big silence regarding this issue... As temporary workaround I added another (USB DVB-C) card, so now it is possible to record FTA and watch *any* other channel at the same time.
Which kind of CAM are you using?
Dilog Conax Cam. Second hand, maybe defective? But with vdr-1.4.x worked. Really confused. I'll try replace it in near future.
Maybe this was because VDR 1.4 never tried to use the multiple decrypt functionality of CAMs.
Please try commenting out the line
repliesToQuery = true;
in VDR/ci.c. Does it work then?
Klaus
On Sun, Feb 10, 2008 at 11:40:12AM +0100, Klaus Schmidinger wrote:
///// in this point appears "channel not available" -error
Does this message appear immediately after switching to the encrypted channel, or only after a few seconds?
Few seconds later.
I assume there are a few seconds between switching to the encrypted channel and the "channel not available" message, which would indicate that the CAM is simply not decrypting the channel.
Maybe you could activate the debug outputs in ci.c to see whether VDR actually sends the CA_PMT data to the CAM.
Seems this was really a CAM problem, not a bug in VDR. Trying with other CAM everything works perfectly. Everything at begining just pointed against VDR, because it worked fine with older versions.
So case closed. Sorry for inconvenience. :)
On 02/14/08 06:05, Antti Hartikainen wrote:
On Sun, Feb 10, 2008 at 11:40:12AM +0100, Klaus Schmidinger wrote:
///// in this point appears "channel not available" -error
Does this message appear immediately after switching to the encrypted channel, or only after a few seconds?
Few seconds later.
I assume there are a few seconds between switching to the encrypted channel and the "channel not available" message, which would indicate that the CAM is simply not decrypting the channel.
Maybe you could activate the debug outputs in ci.c to see whether VDR actually sends the CA_PMT data to the CAM.
Seems this was really a CAM problem, not a bug in VDR. Trying with other CAM everything works perfectly. Everything at begining just pointed against VDR, because it worked fine with older versions.
A possible explanation could be that VDR 1.4 didn't use the CAM commands for multiple decryption.
Klaus
Maybe multiple decryption should be a setup feature?
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Klaus Schmidinger Sent: den 14 februari 2008 18:32 To: vdr@linuxtv.org Subject: Re: [vdr] vdr-1.5x: problem with recording FTA and watching scrambled at the same time
On 02/14/08 06:05, Antti Hartikainen wrote:
On Sun, Feb 10, 2008 at 11:40:12AM +0100, Klaus Schmidinger wrote:
///// in this point appears "channel not available" -error
Does this message appear immediately after switching to the encrypted channel, or only after a few seconds?
Few seconds later.
I assume there are a few seconds between switching to the encrypted channel and the "channel not available" message, which would indicate
that
the CAM is simply not decrypting the channel.
Maybe you could activate the debug outputs in ci.c to see whether VDR actually sends the CA_PMT data to the CAM.
Seems this was really a CAM problem, not a bug in VDR. Trying with other CAM everything works perfectly. Everything at begining
just pointed against VDR, because it worked fine with older versions.
A possible explanation could be that VDR 1.4 didn't use the CAM commands for multiple decryption.
Klaus
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
It appears to switch over to encrypted channel after a minute or so.Only if I tried it a couple of times, and only then, once it switched over it starts to record even if the timer was set a few minutes earlier.
Theunis
On 2/10/08, Antti Hartikainen ami+vdr@ah.fi wrote:
On Sun, Feb 10, 2008 at 10:46:25AM +0100, Klaus Schmidinger wrote:
On 02/10/08 09:16, Antti Hartikainen wrote:
NumUsableSlots = 4
You wrote that you are using only a single budget card. How can a single budget card have 4 CI slots? And all four of these apparently contain a CAM that is ready?!
Well one slot for each card ;) System has totally 6 DVB-devices, but at the moment of testing only one (1) DVB-T tuner was available for VDR (3 other devices were DVB-S tuners, including FF-card too).
NumUsableSlots is one less when error about channel not being available appears, so slot of this card disappears somewhere?
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 02/10/08 17:12, Theunis Potgieter wrote:
It appears to switch over to encrypted channel after a minute or so.Only if I tried it a couple of times, and only then, once it switched over it starts to record even if the timer was set a few minutes earlier.
Could it be that your CAM has problems handling FTA and CA channels at the same time?
The CAM I use here has no problem with this.
Klaus
On 2/10/08, Antti Hartikainen ami+vdr@ah.fi wrote:
On Sun, Feb 10, 2008 at 10:46:25AM +0100, Klaus Schmidinger wrote:
On 02/10/08 09:16, Antti Hartikainen wrote:
NumUsableSlots = 4
You wrote that you are using only a single budget card. How can a single budget card have 4 CI slots? And all four of these apparently contain a CAM that is ready?!
Well one slot for each card ;) System has totally 6 DVB-devices, but at the moment of testing only one (1) DVB-T tuner was available for VDR (3 other devices were DVB-S tuners, including FF-card too).
NumUsableSlots is one less when error about channel not being available appears, so slot of this card disappears somewhere?
I believe it is the CAM too, and me being a user :) I'll wait for someone with more experience than myself to better explain and/or know what to look for. Thanks Klaus, great product!
On 2/10/08, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
On 02/10/08 17:12, Theunis Potgieter wrote:
It appears to switch over to encrypted channel after a minute or so.Only if I tried it a couple of times, and only then, once it switched over it starts to record even if the timer was set a few minutes earlier.
Could it be that your CAM has problems handling FTA and CA channels at the same time?
The CAM I use here has no problem with this.
Klaus
On 2/10/08, Antti Hartikainen ami+vdr@ah.fi wrote:
On Sun, Feb 10, 2008 at 10:46:25AM +0100, Klaus Schmidinger wrote:
On 02/10/08 09:16, Antti Hartikainen wrote:
NumUsableSlots = 4
You wrote that you are using only a single budget card. How can a single budget card have 4 CI slots? And all four of these apparently contain a CAM that is ready?!
Well one slot for each card ;) System has totally 6 DVB-devices, but at
the
moment of testing only one (1) DVB-T tuner was available for VDR (3 other devices were DVB-S tuners, including FF-card too).
NumUsableSlots is one less when error about channel not being available appears, so slot of this card disappears somewhere?
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-
Antti Hartikainen -
Arthur Konovalov -
Klaus Schmidinger -
Theunis Potgieter -
Tomas Berglund