Hello,
recording a HD TV programme still results in a VDR emergency exit even in the latest VDR dev version:
Jun 10 19:38:02 localhost vdr: [5512] live timer 1 (86 1928-2010 'Doctors') added Jun 10 19:38:02 localhost vdr: [5534] timer 1 (86 1928-2010 'Doctors') set to event Fri 10.06.2011 19:30-20:00 'Doctors' Jun 10 19:38:02 localhost vdr: [5512] switching device 1 to channel 86 Jun 10 19:38:02 localhost vdr: [5512] timer 1 (86 1928-2010 'Doctors') start Jun 10 19:38:02 localhost vdr: [5512] Title: 'Doctors' Subtitle: '(null)' Jun 10 19:38:02 localhost vdr: [5512] record /var/lib/video/Doctors/2011-06-10.19.28.86-0.rec Jun 10 19:38:02 localhost vdr: [5512] creating directory /var/lib/video/Doctors Jun 10 19:38:02 localhost vdr: [5512] creating directory /var/lib/video/Doctors/2011-06-10.19.28.86-0.rec Jun 10 19:38:02 localhost vdr: [5512] recording to '/var/lib/video/Doctors/2011-06-10.19.28.86-0.rec/00001.ts' Jun 10 19:38:02 localhost vdr: [5556] recording thread started (pid=5512, tid=5556) Jun 10 19:38:03 localhost vdr: [5524] timer 1 (86 1928-2010 'Doctors') set to event Fri 10.06.2011 19:30-20:00 'Doctors' Jun 10 19:38:33 localhost vdr: [5556] ERROR: video data stream broken Jun 10 19:38:33 localhost vdr: [5556] initiating emergency exit Jun 10 19:38:33 localhost vdr: [5512] emergency exit requested - shutting down
The same problem appears with all HD (H.264) channels, be it BBC HD or HBO HD or anything else.
Could anyone please look into it? :-(
Thanks a lot!
On 10.06.2011 21:41, Luboš Doležel wrote:
By default VDR updates the pids automatically. If you turn that off and thus VDR doesn't get any data from a channel it wants to record, it assumes the driver is "stuck" and performs an "emergency exit" to allow for a driver reload. You can turn that off, too, by setting "Emergency exit" to "no" in the "Miscellaneous" section of the "Setup" menu.
Klaus
On Fri, 10 Jun 2011 21:41:05 +0200 Luboš Doležel lubos@dolezel.info wrote:
Or it should read the pids from the PAT and PMT every time it changes channel instead of using channels.conf for that information. This would also fix the problem of having to scan twice at different times of day to pick up all the channels.
On Fri, 10 Jun 2011 23:31:40 +0200 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
I didn't realise that was what that option did and mine was disabled. What's the default setting? I might have turned it off deliberately to try to stop VDR from updating channels.conf at some point in the past when I was using dvb-apps scan to generate channels.conf and VDR didn't quite recognise the format and created duplicate channels, crashing itself.
On 10.06.2011 23:54, Tony Houghton wrote:
The defualt is "5".
From MANUAL:
DVB:
Update channels = 5 Controls the automatic channel update function. '0' means no update, '1' will only update channel names, '2' will only update PIDs, '3' will update channel names and PIDs, '4' will perform all updates and also add newly found channels, and '5' will also add newly found transponders. Note that adding new transponders only works if the "EPG scan" is active.
Klaus
On 10.6.2011 23:59, Klaus Schmidinger wrote:
Now I know why I disabled this function. Right after enabling it, VDR added CAIDs to all encrypted channels and I cannot tune them any more (I use streamdev-server).
CT HD;CS Link:11973:v:S23.5E:27500:2010=27:2020=cze@4,2023=qaa@4;2021=cze@106:0:D0F,624,D70,D03,D96:14070:3:3214:0
How should I tell VDR not to care about encryption, as the decryption is fully handled by the dvbloopback virtual DVB device (sasc-ng)?
On 11.06.2011 12:24, Klaus Schmidinger wrote:
One solution is to use the patch streamdev/patches/vdr-1.6.0-intcamdevices.patch (also attached) for VDR, so that VDR won't try to decrypt channels received by streamdev-client.
I wrote it in 2008 to allow receiving channels in streamdev client that are already decrypted by the CAM of the "main" VDR instance, while allowing the use of the same channels.conf. (it may not apply cleanly anymore)
On 11.06.2011 00:30, Luboš Doležel wrote:
How should I tell VDR not to care about encryption, as the decryption is fully handled by the dvbloopback virtual DVB device (sasc-ng)?
if a software outside vdr changes things in a way that standards does not apply anymore this software should take care of it i.e. clear encryption flags for those channels so that the channel scan recognizes them in the way it's needed
When the BBC HD channels changed from DVB-S to DVB-S2, my VDR did not notice that, it is set to 3 (update PIDs and Names). I even tried 5 and nothing happened (instead of clobbering the list with additional 1000 useless entries).
So I finally lost my patience and manually modified 22000 to 23000 in channels.conf and I was back on again.
Can this be considered a bug of VDR or did they still work with an outdated NIT?
- M.
your vdr did everything alright.
DVB-S to DVB-S2, my VDR did not notice that, it is set to 3 (update PIDs and Names).
neither Audio-/Video- Pids nor the names of these channels changed.
--- Mario Schulz drcms@arcor.de schrieb am Sa, 11.6.2011:
-
Anssi Hannula -
Klaus Schmidinger -
Lars Bläser -
Luboš Doležel -
Mario Schulz -
Newsy Paper -
Tony Houghton -
VDR User