Re: [vdr] Problem with v1.6.0 and two DBS-S cards
Moin! This sounds like a stupid answer to the above question, but I _might_ have the same problem. I'm not sure because I rarely watch live TV. The other day, though, I wasn't able to watch all channels, and I thought there was only one recording active (I have two DVB-T cards). Wasn't able to check because baby woke up ;-) This is with a c't VDR: 1.6.0-6ctvdr2 Cheers, Jan 2008/9/15 Stefan-W. Hahn [EMAIL PROTECTED]: Hello, yesterday I switched my VDR from v1.4.1 to v1.6.0 on a debian system. I'm running two DVB-S cards (Nexus FF and Nova). The update was without any problem. But today I found a problem: When recording on one program I can view at the same time just the channels of the same bouquet but no other ones (two cards!!). But recording simultaniously on two different bouquets works. With v1.4.1 there was no problem in recording one channel and switching to all other channels. I didn't find any hint on the mailinglist or vdr-portal about this problem. Is there any other having the same problem? Are there any hints how to solve this problem? Stefan -- Stefan-W. Hahn It is easy to make things. / mailto:[EMAIL PROTECTED] /It is hard to make things simple. Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. Bundesgesetzblatt: http://www.bgblportal.de/BGBL/bgbl1f/bgbl107s3198.pdf ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with v1.6.0 and two DBS-S cards
From: Stefan-W. Hahn [EMAIL PROTECTED] I'm running two DVB-S cards (Nexus FF and Nova). The update was without any problem. When recording on one program I can view at the same time just the channels of the same bouquet but no other ones (two cards!!). But recording simultaniously on two different bouquets works. With v1.4.1 there was no problem in recording one channel and switching to all other channels. I didn't find any hint on the mailinglist or vdr-portal about this problem. Is there any other having the same problem? Are there any hints how to solve this problem? Did you also update the driver/kernel? Is it a Nova SE with s5h1420 Frontend? check with dmesg if both cards are initialized There is a bug in the driver which was fixed a few days ago (still not in the man v4l-dvb hg): http://linuxtv.org/hg/~pb/v4l-dvb/rev/cd7eae82baf9 http://linuxtv.org/hg/~pb/v4l-dvb/rev/84530ecadf89 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problem with v1.6.0 and two DBS-S cards
Also sprach Martin Dauskardt am Tue, 16 Sep 2008 at 15:12:10 +0200: Hallo, Are there any hints how to solve this problem? Did you also update the driver/kernel? No. When changing the vdr software I didn't change the dvb driver. I'm using a 2.6.24 (commit 49914084e79) kernel. Is it a Nova SE with s5h1420 Frontend? check with dmesg if both cards are initialized It's a Nova CI. Linux video capture interface: v2.00 saa7146: register extension 'dvb'. ACPI: PCI Interrupt :00:08.0[A] - GSI 16 (level, low) - IRQ 20 saa7146: found saa7146 @ mem de8c (revision 1, irq 20) (0x13c2,0x0003). DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.X) adapter has MAC addr = 00:d0:5c:20:30:52 dvb-ttpci: gpioirq unknown type=0 len=0 dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 80002622 dvb-ttpci: firmware @ card 0 supports CI link layer interface dvb-ttpci: adac type set to 0 @ card 0 saa7146_vv: saa7146 (0): registered device video0 [v4l2] saa7146_vv: saa7146 (0): registered device vbi0 [v4l2] DVB: registering frontend 0 (ST STV0299 DVB-S)... input: DVB on-card IR receiver as /class/input/input9 dvb-ttpci: found av7110-0. saa7146: register extension 'budget_ci dvb'. ACPI: PCI Interrupt :00:09.0[A] - GSI 17 (level, low) - IRQ 19 saa7146: found saa7146 @ mem de94e000 (revision 1, irq 19) (0x13c2,0x100f). saa7146 (1): dma buffer size 192512 DVB: registering new adapter (TT-Budget/WinTV-NOVA-CI PCI) adapter has MAC addr = 00:d0:5c:21:fd:e0 input: Budget-CI dvb ir receiver saa7146 (1) as /class/input/input10 budget_ci: CI interface initialised DVB: registering frontend 1 (ST STV0299 DVB-S)... There is a bug in the driver which was fixed a few days ago (still not in the man v4l-dvb hg): http://linuxtv.org/hg/~pb/v4l-dvb/rev/cd7eae82baf9 http://linuxtv.org/hg/~pb/v4l-dvb/rev/84530ecadf89 If my described problem is a problem of the dvb driver, then the question is, what has been changed in vdr to display this faulty behaviour? Stefan -- Stefan-W. Hahn It is easy to make things. / mailto:[EMAIL PROTECTED] /It is hard to make things simple. Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. Bundesgesetzblatt: http://www.bgblportal.de/BGBL/bgbl1f/bgbl107s3198.pdf ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-plugin-mplayer and VCDs
Hello, I have installed the vdr-plugin-mplayer. Now I have a VCD which don't play at all when started from this plugin. When I start mplayer manually, it plays fine when I use vcd://2 as file name. Unfortunately, the plugin uses vcd://. This leads me to two questions: - Is there some sort of standard how VCDs should be structured? I guess vcd:// is synonym for vcd://1? - Is there some way to automatically determine which title needs to be played? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.6.0 device selection order for recordings
Hello, I just upgraded from vdr 1.4.7 to vdr 1.6.0 (from the e-tobi.net experimental repository). That has changed the order in which devices are selected for recording significantly. Now, the only card with the CAM is selected first when recording non-encrypted channels, preventing later timers from recording encrypted channels. This is my hardware setup: DVB1: full-featured card (Hauppauge WinTV DVB-C rev 2.X) DVB2: budget card with CI and CAM (TerraTec Cinergy 1200 DVB-C) DVB3: budget card (TerraTec Cinergy 1200 DVB-C) As a test, I started tree recordings on non-encrypted channels, one after the other. With vdr 1.4.7, these recordings use DVB3, DVB1, and DVB2, sparing the card with the CAM as long as possible. With vdr 1.6.0, the recordings use DVB2 (!), DVB3, and DVB1, but using the the card with the CAM first. So one recording of a non-encrypted channels blocks all encrypted channels. I'm running a pretty standard Debian etch system with kernel 2.6.18-6-686. The root of the vdr 1.6.0 system started as a mere copy of the vdr 1.4.7 system's root, so there shouldn't be too many differences. Is it a problem with my setup or a problem in vdr 1.6.0? What should I do have vdr 'save the CAM for last'? Thanks in advance, Malte ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.6.0 device selection order for recordings
On Tuesday 16 September 2008, Malte Forkel wrote: Hello, I just upgraded from vdr 1.4.7 to vdr 1.6.0 (from the e-tobi.net experimental repository). That has changed the order in which devices are selected for recording significantly. Now, the only card with the CAM is selected first when recording non-encrypted channels, preventing later timers from recording encrypted channels. This is my hardware setup: DVB1: full-featured card (Hauppauge WinTV DVB-C rev 2.X) DVB2: budget card with CI and CAM (TerraTec Cinergy 1200 DVB-C) DVB3: budget card (TerraTec Cinergy 1200 DVB-C) As a test, I started tree recordings on non-encrypted channels, one after the other. With vdr 1.4.7, these recordings use DVB3, DVB1, and DVB2, sparing the card with the CAM as long as possible. With vdr 1.6.0, the recordings use DVB2 (!), DVB3, and DVB1, but using the the card with the CAM first. So one recording of a non-encrypted channels blocks all encrypted channels. I think I ran into a similar problem earlier myself. I have only two cards; one DVB-C TT budget (without CI/CAM) and one DVB-C Hauppauge FF with CI/CAM, and a DXR3 as the primary device. I haven't run into this problem in a while, but I'm not sure why - it might be that I swapped the cards' PCI slots or maybe I just haven't had a scenario where this would bite in a while. But anyway, I agree that VDR should save the CAM for last. And as a nice addition to that, perhaps even change the card used for a recording on the fly if that's what it takes to get all needed programs recorded, for example: Timer 1: 20:00-21:00, non-encrypted Timer 2: 20:30-21:30, non-encrypted (different MUX/$something than timer 1) Timer 3: 21:00-22:00, encrypted Card A: no CAM (can in theory do timers 1 and 2) Card B: CAM (can in theory do timers 1, 2 and 3) So, card A starts recording timer 1. Then, card B starts recording timer 2 (because it's on a different $something than timer 1, so card A can't take care of it simultaneously with timer 1). When timer 3 starts, timer 2 would be changed on the fly to continue recording on card A, and card B would start recording timer 3. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
