On 10.6.2011 20:33, Klaus Schmidinger wrote:

On 10.06.2011 19:44, Luboš Doležel wrote:

...

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.

Please post the channels.conf entry of such a channel (must be FTA, otherwise I can't receive it).

Klaus

This channel should work across Western/Central Europe with regular-sized dishes. It is FTA.

Channel 4 HD;BSkyB:12607:vC34M2O35S1:S28.2E:27500:2305=2:2307=NAR@4;2306=NAR@106:2309:0:55300:2:2614:0

Thanks!

On 10.6.2011 21:11, VDR User wrote:

...

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? :-(

I've just read a post from another user who had this problem. Apparently his channels.conf contained wrong info and enabling 'update names& pids' (or whatever it's called) fixed it.

Wow, great, that fixed it! Thanks!

I think, however, that this should be either noted somewhere or the VDR should handle the error more gracefully...

On Fri, 10 Jun 2011 21:41:05 +0200 Luboš Doležel lubos@dolezel.info wrote:

On 10.6.2011 21:11, VDR User wrote:

...

I've just read a post from another user who had this problem. Apparently his channels.conf contained wrong info and enabling 'update names& pids' (or whatever it's called) fixed it.

Wow, great, that fixed it! Thanks!

I think, however, that this should be either noted somewhere or the VDR should handle the error more gracefully...

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:

On 10.06.2011 23:27, Tony Houghton 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.

When you switch to a transponder VDR *does* read the PAT/PMT. But if the user's setup tells it *not* to do so, what's VDR supposed to do then?

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.6.2011 23:59, Klaus Schmidinger 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

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:

On 11.06.2011 00:30, Luboš Doležel wrote:

...

On 10.6.2011 23:59, Klaus Schmidinger 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

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)?

I guess that's something the streamdev-server should handle.

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)

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.