Re: [vdr] VDR needs some way to detect new tuners on runtime...

2013-08-20 Thread André Weidemann
On 19.08.2013 23:19, Manuel Reimer wrote: Hello, with event based init systems (in my case systemd) it seems to become a big issue to startup VDR. If you install VDR on a SSD device, then startup gets *really* fast. Sometimes that fast, that VDR starts before all devices are initialized.

Re: [vdr] VDR needs some way to detect new tuners on runtime...

2013-08-20 Thread Manuel Reimer
On 08/20/2013 09:40 AM, André Weidemann wrote: Add a line like this after loading the required modules: /sbin/modprobe dvb /sbin/udevadm settle --timeout=30 then start up vdr. Everything should be fine since udevadm only returns after all actions regarding the module load are settled. This

Re: [vdr] Feature request for VDR = multi editing

2013-08-20 Thread Klaus Schmidinger
On 19.08.2013 23:52, Karim wrote: Hi Klaus, I record many movies, shows and series with VDR = then I make a lot of editing. Unfortunately, VDR allows only one editing at a time. Is it possible to improve this feature ? I mean VDR could store all demands in a queue, and launch them one by one,

Re: [vdr] Feature request for VDR = multi editing

2013-08-20 Thread Manuel Reimer
On 08/20/2013 09:49 AM, Klaus Schmidinger wrote: BTW: you should have started an all new thread for this, not reply to VDR needs some way to detect new tuners on runtime... and simply change the subject. Now these two threads are intertwinded... :-( X-Mailer: Microsoft Office Outlook 12.0

Re: [vdr] VDR needs some way to detect new tuners on runtime...

2013-08-20 Thread Klaus Schmidinger
On 19.08.2013 23:19, Manuel Reimer wrote: Hello, with event based init systems (in my case systemd) it seems to become a big issue to startup VDR. If you install VDR on a SSD device, then startup gets *really* fast. Sometimes that fast, that VDR starts before all devices are initialized.

Re: [vdr] VDR needs some way to detect new tuners on runtime...

2013-08-20 Thread Manuel Reimer
On 08/20/2013 10:12 AM, Klaus Schmidinger wrote: So my question to Klaus: Is there something like this planned or would a patch be accepted which adds a feature like this? As far as I know a new dependency (libudev) would be needed. I wouldn't like to add a dependency to libudev. So how

Re: [vdr] VDR needs some way to detect new tuners on runtime...

2013-08-20 Thread Klaus Schmidinger
On 20.08.2013 10:20, Manuel Reimer wrote: On 08/20/2013 10:12 AM, Klaus Schmidinger wrote: So my question to Klaus: Is there something like this planned or would a patch be accepted which adds a feature like this? As far as I know a new dependency (libudev) would be needed. I wouldn't like to

Re: [vdr] Channel IDs - DVB-C and IPTV

2013-08-20 Thread Michael Frank
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 @fnu Thank you Frank for your kind help. Analyzing the streams was the first step towards success. Finally I found the reason why RID would not work with my IPTV-Channels. It's very simple: apparently SVDRP does not like an NID of zero. As soon as

Re: [vdr] VDR needs some way to detect new tuners on runtime...

2013-08-20 Thread Tony Houghton
On Tue, 20 Aug 2013 10:12:25 +0200 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: I wouldn't like to add a dependency to libudev. Why not? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Channel IDs - DVB-C and IPTV

2013-08-20 Thread fnu
Hey Michael, glad to here that you got it work. So after using correct SID, NID and TID, still no EPG from EIT? Since you may not be the only user in Austria, using A1TV's IPTV channels, you may post the proven channel.conf entries with correct SID, NID and TID at vdr-portal.de. === Kind

Re: [vdr] VDR needs some way to detect new tuners on runtime...

2013-08-20 Thread VDR User
On Tue, Aug 20, 2013 at 1:20 AM, Manuel Reimer manuel.rei...@gmx.de wrote: NUMADAPTERS=3 while [[ `find /dev/dvb -name 'adapter*' | wc -l` -lt $NUMADAPTERS ]]; do sleep 1; done runvdr ... could be used to count the number of adapters, and check that number in a loop against the

Re: [vdr] Deactivate a Tuner

2013-08-20 Thread Brian-Imap
On 8/19/2013 11:10 PM, Marc wrote: On 19/08/2013 21:11, Brian-Imap wrote: On 8/18/2013 8:15 PM, Marc wrote: On 18/08/2013 19:27, Brian-Imap wrote: Hi, so I tried to look for some kind of info to help me identify the tuners, this is the most interesting bit I guess: VDR-test-cellar (SDB1):

Re: [vdr] Deactivate a Tuner

2013-08-20 Thread Brian-Imap
On 8/20/2013 6:28 PM, Brian-Imap wrote: On 8/19/2013 11:10 PM, Marc wrote: On 19/08/2013 21:11, Brian-Imap wrote: On 8/18/2013 8:15 PM, Marc wrote: On 18/08/2013 19:27, Brian-Imap wrote: Hi, so I tried to look for some kind of info to help me identify the tuners, this is the most

Re: [vdr] Deactivate a Tuner

2013-08-20 Thread Marc
On 20/08/2013 18:48, Brian-Imap wrote: On 8/20/2013 6:28 PM, Brian-Imap wrote: On 8/19/2013 11:10 PM, Marc wrote: On 19/08/2013 21:11, Brian-Imap wrote: Hi, well Its exactly what I was doing, and I cant see a difference. Here an example of two of the Cine S2 Tuners: VDR-test-cellar (SDB1):

Re: [vdr] Deactivate a Tuner

2013-08-20 Thread Marc
On 20/08/2013 19:45, Marc wrote: On 20/08/2013 18:48, Brian-Imap wrote: Hi Marc, you've lost me. If FE0/0 is a DDBridge tuner, and I make the FF card tuner FE0/0, then I still need to rename the DDBridge Tuner that was FE0/0 to another one within FE{1-3}/0. That means potentially overwriting

Re: [vdr] Deactivate a Tuner

2013-08-20 Thread VDR User
Serial number, assuming that field is used correctly in that device. On Tue, Aug 20, 2013 at 9:48 AM, Brian-Imap brian_dorl...@t-online.dewrote: On 8/20/2013 6:28 PM, Brian-Imap wrote: On 8/19/2013 11:10 PM, Marc wrote: On 19/08/2013 21:11, Brian-Imap wrote: On 8/18/2013 8:15 PM, Marc

Re: [vdr] Feature request for VDR = multi editing

2013-08-20 Thread Karim
OK ! I understood, sorry for the mismatch... Karim ... BTW: you should have started an all new thread for this, not reply to VDR needs some way to detect new tuners on runtime... and simply change the subject. Now these two threads are intertwinded... :-( Klaus