Hi
I've just installed vdr-1.7.15 on my development box which has a single TT-2300 DVB card and CAM installed. I'm using vdr-xine as my front end.
When I switch to any live SD channel, I only get 3 seconds of audio/video and then then "channel not available". A few seconds later the picture comes back, for another 3 seconds, then unavailable.
logs look like this:
Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started (pid=2499, tid=2532) Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started (pid=2499, tid=2533) Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended (pid=2499, tid=2533) Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended (pid=2499, tid=2532) Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available! Jul 25 10:41:18 localhost vdr: [2499] switching to channel 1 Jul 25 10:41:18 localhost vdr: [2535] receiver on device 1 thread started (pid=2499, tid=2535) Jul 25 10:41:18 localhost vdr: [2536] TS buffer on device 1 thread started (pid=2499, tid=2536) Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:41:22 localhost vdr: [2536] TS buffer on device 1 thread ended (pid=2499, tid=2536) Jul 25 10:41:22 localhost vdr: [2535] buffer stats: 282564 (13%) used Jul 25 10:41:22 localhost vdr: [2535] receiver on device 1 thread ended (pid=2499, tid=2535) Jul 25 10:41:29 localhost vdr: [2499] switching to channel 1 Jul 25 10:41:29 localhost vdr: [2499] info: Channel not available!
The same setup works fine under vdr-1.6.0.
Any ideas?
When I switch to any live SD channel, I only get 3 seconds of audio/video and then then "channel not available". A few seconds later the picture comes back, for another 3 seconds, then unavailable.
Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started (pid=2499, tid=2532) Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started (pid=2499, tid=2533) Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended (pid=2499, tid=2533) Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended (pid=2499, tid=2532) Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available! Jul 25 10:41:18 localhost vdr: [2499] switching to channel 1 Jul 25 10:41:18 localhost vdr: [2535] receiver on device 1 thread started (pid=2499, tid=2535) Jul 25 10:41:18 localhost vdr: [2536] TS buffer on device 1 thread started (pid=2499, tid=2536) Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:41:22 localhost vdr: [2536] TS buffer on device 1 thread ended (pid=2499, tid=2536) Jul 25 10:41:22 localhost vdr: [2535] buffer stats: 282564 (13%) used Jul 25 10:41:22 localhost vdr: [2535] receiver on device 1 thread ended (pid=2499, tid=2535) Jul 25 10:41:29 localhost vdr: [2499] switching to channel 1 Jul 25 10:41:29 localhost vdr: [2499] info: Channel not available!
The same setup works fine under vdr-1.6.0.
Incidentally, I tried the attached patch for vdr-xine and the VPID issue, but it had no effect.
Also tried recording a channel via skincurses without xine-ui attached, but still get the above errors and corresponding console messages: SetPlayMode: 1 SetPlayMode: 0
Is there more debugging I can turn on? Why am I getting the "receiver on device 1 thread ended" ?
Thanks Simon
Any ideas or suggestions from anyone?
When I switch to any live SD channel, I only get 3 seconds of audio/video and then then "channel not available". A few seconds later the picture comes back, for another 3 seconds, then unavailable.
Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started (pid=2499, tid=2532) Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started (pid=2499, tid=2533) Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended (pid=2499, tid=2533) Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended (pid=2499, tid=2532) Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available! Jul 25 10:41:18 localhost vdr: [2499] switching to channel 1 Jul 25 10:41:18 localhost vdr: [2535] receiver on device 1 thread started (pid=2499, tid=2535) Jul 25 10:41:18 localhost vdr: [2536] TS buffer on device 1 thread started (pid=2499, tid=2536) Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:41:19 localhost vdr: [2535] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:41:22 localhost vdr: [2536] TS buffer on device 1 thread ended (pid=2499, tid=2536) Jul 25 10:41:22 localhost vdr: [2535] buffer stats: 282564 (13%) used Jul 25 10:41:22 localhost vdr: [2535] receiver on device 1 thread ended (pid=2499, tid=2535) Jul 25 10:41:29 localhost vdr: [2499] switching to channel 1 Jul 25 10:41:29 localhost vdr: [2499] info: Channel not available!
The same setup works fine under vdr-1.6.0.
Incidentally, I tried the attached patch for vdr-xine and the VPID issue, but it had no effect.
Also tried recording a channel via skincurses without xine-ui attached, but still get the above errors and corresponding console messages: SetPlayMode: 1 SetPlayMode: 0
Is there more debugging I can turn on? Why am I getting the "receiver on device 1 thread ended" ?
Thanks Simon
--------------------------------------------------------------------------------
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Isn't it about time that VDR had a native out of the box plugin for X11 output with H264 acceleration? There's so many problems with having xine or xinelibout plugins developed by 3rd parties and relying on syncing up with xine etc...
On 29 July 2010 21:55, Morfsta morfsta@gmail.com wrote:
Isn't it about time that VDR had a native out of the box plugin for X11 output with H264 acceleration? There's so many problems with having xine or xinelibout plugins developed by 3rd parties and relying on syncing up with xine etc...
Like the softdevice plugin?
On Fri, 30 Jul 2010 09:17:23 +0200 Theunis Potgieter theunis.potgieter@gmail.com wrote:
On 29 July 2010 21:55, Morfsta morfsta@gmail.com wrote:
Isn't it about time that VDR had a native out of the box plugin for X11 output with H264 acceleration? There's so many problems with having xine or xinelibout plugins developed by 3rd parties and relying on syncing up with xine etc...
Like the softdevice plugin?
I think the point is the OP wants it to be built in to VDR instead of a plugin. Personally I don't have a problem with having to use a plugin for display, provided it's well supported and closely tracks core VDR development. But I use the Debian packages (based on VDR 1.6 and xine 1.1) so I don't know how much hassle this causes when trying to use the bleeding edge. It would be nice to have BBC HD and ITV HD if I could be bothered to put in the effort. There are some unofficial VDR 1.7 debian packages, but there seem to be about 3 sets, so what to choose? Something more official in Debian's "experimental" section would be nice.
I would get far more involved with VDR, particularly the Debian side of things, but I decided some time ago it would never be quite the program I want (nor are mythtv, freevo or gnome-dvb-daemon) and I'd rather write my own rival, so I wouldn't be able to commit long term to maintaining VDR plugins and packages.
On 30 July 2010 15:40, Tony Houghton h@realh.co.uk wrote:
On Fri, 30 Jul 2010 09:17:23 +0200 Theunis Potgieter theunis.potgieter@gmail.com wrote:
On 29 July 2010 21:55, Morfsta morfsta@gmail.com wrote:
Isn't it about time that VDR had a native out of the box plugin for X11 output with H264 acceleration? There's so many problems with having xine or xinelibout plugins developed by 3rd parties and relying on syncing up with xine etc...
Like the softdevice plugin?
I think the point is the OP wants it to be built in to VDR instead of a plugin. Personally I don't have a problem with having to use a plugin for display, provided it's well supported and closely tracks core VDR development. But I use the Debian packages (based on VDR 1.6 and xine 1.1) so I don't know how much hassle this causes when trying to use the bleeding edge. It would be nice to have BBC HD and ITV HD if I could be bothered to put in the effort. There are some unofficial VDR 1.7 debian packages, but there seem to be about 3 sets, so what to choose? Something more official in Debian's "experimental" section would be nice.
I would get far more involved with VDR, particularly the Debian side of things, but I decided some time ago it would never be quite the program I want (nor are mythtv, freevo or gnome-dvb-daemon) and I'd rather write my own rival, so I wouldn't be able to commit long term to maintaining VDR plugins and packages.
Correct me if I'm wrong, but that would be backwards to VDR's roadmap. VDR has now also moved the hardware output devices to be a plugin.
-- TH * http://www.realh.co.uk
I would like to dump xine though it is getting stable, it's still a lot of extra crap that needs installing to use it that just waste disk space. Softdevice doesn't support vdpau though does it? I'm still confused about the layers. Seems like X is the layer between vdr and vdpau driver, but we seem to need xine to talk to X and we need vdr-xine plugin to talk to xine. too many layers. We need a plugin that talks directly to X if not the video driver itself. Vdr could talk directly to the driver for video out of the Nexus-s. Why not the main video card?
On 7/30/2010 6:40 AM, Tony Houghton wrote:
On Fri, 30 Jul 2010 09:17:23 +0200 Theunis Potgietertheunis.potgieter@gmail.com wrote:
On 29 July 2010 21:55, Morfstamorfsta@gmail.com wrote:
Isn't it about time that VDR had a native out of the box plugin for X11 output with H264 acceleration? There's so many problems with having xine or xinelibout plugins developed by 3rd parties and relying on syncing up with xine etc...
Like the softdevice plugin?
I think the point is the OP wants it to be built in to VDR instead of a plugin. Personally I don't have a problem with having to use a plugin for display, provided it's well supported and closely tracks core VDR development. But I use the Debian packages (based on VDR 1.6 and xine 1.1) so I don't know how much hassle this causes when trying to use the bleeding edge. It would be nice to have BBC HD and ITV HD if I could be bothered to put in the effort. There are some unofficial VDR 1.7 debian packages, but there seem to be about 3 sets, so what to choose? Something more official in Debian's "experimental" section would be nice.
I would get far more involved with VDR, particularly the Debian side of things, but I decided some time ago it would never be quite the program I want (nor are mythtv, freevo or gnome-dvb-daemon) and I'd rather write my own rival, so I wouldn't be able to commit long term to maintaining VDR plugins and packages.
On Thu, Jul 29, 2010 at 12:55 PM, Morfsta morfsta@gmail.com wrote:
Isn't it about time that VDR had a native out of the box plugin for X11 output with H264 acceleration? There's so many problems with having xine or xinelibout plugins developed by 3rd parties and relying on syncing up with xine etc...
The only problem is that I doubt it will ever happen. Although I did hear talk about making the vdpau elements from xine-lib into an own library, which I guess would be a step closer. I use xine-lib-1.2 + xine-ui + vdr-xine. However, I never actually use xine-ui and so on since my box is a dedicated htpc. I will never run VDR in a window or want to have any desktop type environment there. Surely there's a lot I have to install that I'll never use but I don't ever see a time when VDR will be able to bypass all that for users such as myself (with dedicated VDR into tv).
On Thu, Jul 29, 2010 at 12:55 PM, Morfsta morfsta@gmail.com wrote:
Isn't it about time that VDR had a native out of the box plugin for X11 output with H264 acceleration? There's so many problems with having xine or xinelibout plugins developed by 3rd parties and relying on syncing up with xine etc...
This is all very fascinating, but can anyone offer a suggestion to how I can debug my 3 seconds of live TV problem?
When I switch to any live SD channel, I only get 3 seconds of audio/video and then then "channel not available". A few seconds later the picture comes back, for another 3 seconds, then unavailable.
Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started (pid=2499, tid=2532) Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started (pid=2499, tid=2533) Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended (pid=2499, tid=2533) Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended (pid=2499, tid=2532) Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available!
On Fri, Jul 30, 2010 at 10:38 PM, Simon Baxter linuxtv@nzbaxters.com wrote:
This is all very fascinating, but can anyone offer a suggestion to how I can debug my 3 seconds of live TV problem?
When I switch to any live SD channel, I only get 3 seconds of audio/video and then then "channel not available". A few seconds later the picture comes back, for another 3 seconds, then unavailable.
Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started (pid=2499, tid=2532) Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started (pid=2499, tid=2533) Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended (pid=2499, tid=2533) Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended (pid=2499, tid=2532) Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available!
Not enough information. Assuming channel 1 is a real channel for you, check your xine log and cam log also. Usually "Channel not available" seems to mean the cam can't decrypt the channel or the tuner is in use already (such as a timer is active on another channel).
On Fri, Jul 30, 2010 at 10:38 PM, Simon Baxter linuxtv@nzbaxters.com wrote:
This is all very fascinating, but can anyone offer a suggestion to how I can debug my 3 seconds of live TV problem?
When I switch to any live SD channel, I only get 3 seconds of audio/video and then then "channel not available". A few seconds later the picture comes back, for another 3 seconds, then unavailable.
Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started (pid=2499, tid=2532) Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started (pid=2499, tid=2533) Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended (pid=2499, tid=2533) Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended (pid=2499, tid=2532) Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available!
Not enough information. Assuming channel 1 is a real channel for you, check your xine log and cam log also. Usually "Channel not available" seems to mean the cam can't decrypt the channel or the tuner is in use already (such as a timer is active on another channel).
This is a test box with no timers or other front ends, so the tuner isn't in use anywhere. Above result happens no matter which channel I change to - 3 seconds of live TV then thread ends.
I've also tested using a FF card (so no xine front end) and still only getting 3 seconds of video.
Using vdr-xine, XINE logs, all I'm getting is: vdr: osdflush: n: 3, 32.6, timeout: 0, result: 0 vdr: osdflush: n: 2, 20.2, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.2, timeout: 0, result: 0 vdr: osdflush: n: 3, 33.6, timeout: 0, result: 0 vdr: osdflush: n: 3, 30.3, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.2, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.1, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.1, timeout: 0, result: 0
CAM logs as follows: SetPlayMode: 1 Slot 2: ==> Date Time (4) 2: --> 01 01 A0 10 01 90 02 00 04 9F 84 41 07 D8 70 07 24 57 00 02 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 07 01 91 04 00 40 00 41 80 02 01 00 . . . . . . . . @ . A . . . . Slot 2: open session 00400041 Slot 2: new MMI (session id 5) 2: --> 01 01 A0 0A 01 92 07 00 00 40 00 41 00 05 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 82 00 0B 01 90 02 00 05 9F 88 01 02 01 01 80 02 01 00 . . . . . . . . . . . . . . . . . . . . . Slot 2: <== Display Control (5) Slot 2: ==> Display Reply (5) 2: --> 01 01 A0 0B 01 90 02 00 05 9F 88 02 02 01 01 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 82 00 61 01 90 02 00 05 9F 88 0C 58 02 9F 88 03 0B 97 41 6C 70 68 61 43 72 79 70 74 9F 88 03 01 20 9F 88 03 08 50 72 65 73 73 20 4F 4B 9F 88 03 14 59 6F 75 20 61 72 65 20 6E 6F 74 20 65 6E 74 69 74 6C 65 64 9F 88 03 1B 74 6F 20 72 65 63 65 69 76 65 20 74 68 69 73 20 70 72 6F 67 72 61 6D 6D 65 20 21 80 02 01 00 . . . . . a . . . . . . . . X . . . . . . A l p h a C r y p t . . . . . . . . P r e s s O K . . . . Y o u a r e n o t e n t i t l e d . . . . t o r e c e i v e t h i s p r o g r a m m e ! . . . . Slot 2: <== Menu Last (5) Slot 2: <== Text Last (5) 'AlphaCrypt' Slot 2: <== Text Last (5) '' Slot 2: <== Text Last (5) 'Press OK' Slot 2: <== Text Last (5) 'You are not entitled' Slot 2: <== Text Last (5) 'to receive this programme !' SetPlayMode: 0 Slot 2: ==> Ca Pmt (3) 5 1 2: --> 01 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 EE 01 00 07 01 09 04 06 06 E4 51 frame: (0, 0)-(-1, -1), zoom: (1.00, 1.00) Slot 2: ==> Date Time (4) 2: --> 01 01 A0 10 01 90 02 00 04 9F 84 41 07 D8 70 07 25 03 00 02 Slot 2: ==> Close MMI (5) 2: --> 01 01 A0 09 01 90 02 00 05 9F 88 00 00 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 05 01 95 02 00 05 80 02 01 00 . . . . . . . . . . . . . Slot 2: close session 5 2: --> 01 01 A0 06 01 96 03 00 00 05
Just an off the wall guess, buffer problem? Not that much ram needed, but how much does the system have?
On 7/31/2010 12:29 AM, Simon Baxter wrote:
On Fri, Jul 30, 2010 at 10:38 PM, Simon Baxter linuxtv@nzbaxters.com wrote:
This is all very fascinating, but can anyone offer a suggestion to how I can debug my 3 seconds of live TV problem?
When I switch to any live SD channel, I only get 3 seconds of audio/video and then then "channel not available". A few seconds later the picture comes back, for another 3 seconds, then unavailable.
Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started (pid=2499, tid=2532) Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started (pid=2499, tid=2533) Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended (pid=2499, tid=2533) Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended (pid=2499, tid=2532) Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available!
Not enough information. Assuming channel 1 is a real channel for you, check your xine log and cam log also. Usually "Channel not available" seems to mean the cam can't decrypt the channel or the tuner is in use already (such as a timer is active on another channel).
This is a test box with no timers or other front ends, so the tuner isn't in use anywhere. Above result happens no matter which channel I change to - 3 seconds of live TV then thread ends.
I've also tested using a FF card (so no xine front end) and still only getting 3 seconds of video.
Using vdr-xine, XINE logs, all I'm getting is: vdr: osdflush: n: 3, 32.6, timeout: 0, result: 0 vdr: osdflush: n: 2, 20.2, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.2, timeout: 0, result: 0 vdr: osdflush: n: 3, 33.6, timeout: 0, result: 0 vdr: osdflush: n: 3, 30.3, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.2, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.1, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.1, timeout: 0, result: 0
CAM logs as follows: SetPlayMode: 1 Slot 2: ==> Date Time (4) 2: --> 01 01 A0 10 01 90 02 00 04 9F 84 41 07 D8 70 07 24 57 00 02 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 07 01 91 04 00 40 00 41 80 02 01 00 . . . . . . . . @ . A . . . . Slot 2: open session 00400041 Slot 2: new MMI (session id 5) 2: --> 01 01 A0 0A 01 92 07 00 00 40 00 41 00 05 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 82 00 0B 01 90 02 00 05 9F 88 01 02 01 01 80 02 01 00 . . . . . . . . . . . . . . . . . . . . . Slot 2: <== Display Control (5) Slot 2: ==> Display Reply (5) 2: --> 01 01 A0 0B 01 90 02 00 05 9F 88 02 02 01 01 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 82 00 61 01 90 02 00 05 9F 88 0C 58 02 9F 88 03 0B 97 41 6C 70 68 61 43 72 79 70 74 9F 88 03 01 20 9F 88 03 08 50 72 65 73 73 20 4F 4B 9F 88 03 14 59 6F 75 20 61 72 65 20 6E 6F 74 20 65 6E 74 69 74 6C 65 64 9F 88 03 1B 74 6F 20 72 65 63 65 69 76 65 20 74 68 69 73 20 70 72 6F 67 72 61 6D 6D 65 20 21 80 02 01 00 . . . . . a . . . . . . . . X . . . . . . A l p h a C r y p t . . . . . . . . P r e s s O K . . . . Y o u a r e n o t e n t i t l e d . . . . t o r e c e i v e t h i s p r o g r a m m e ! . . . . Slot 2: <== Menu Last (5) Slot 2: <== Text Last (5) 'AlphaCrypt' Slot 2: <== Text Last (5) '' Slot 2: <== Text Last (5) 'Press OK' Slot 2: <== Text Last (5) 'You are not entitled' Slot 2: <== Text Last (5) 'to receive this programme !' SetPlayMode: 0 Slot 2: ==> Ca Pmt (3) 5 1 2: --> 01 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 EE 01 00 07 01 09 04 06 06 E4 51 frame: (0, 0)-(-1, -1), zoom: (1.00, 1.00) Slot 2: ==> Date Time (4) 2: --> 01 01 A0 10 01 90 02 00 04 9F 84 41 07 D8 70 07 25 03 00 02 Slot 2: ==> Close MMI (5) 2: --> 01 01 A0 09 01 90 02 00 05 9F 88 00 00 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 05 01 95 02 00 05 80 02 01 00 . . . . . . . . . . . . . Slot 2: close session 5 2: --> 01 01 A0 06 01 96 03 00 00 05
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
If I run vdr-1.6.0 it works fine, it's just vdr-1.7.15 that doesn't. So I'm not thinking this is a system problem.
Just an off the wall guess, buffer problem? Not that much ram needed, but how much does the system have?
On 7/31/2010 12:29 AM, Simon Baxter wrote:
On Fri, Jul 30, 2010 at 10:38 PM, Simon Baxter linuxtv@nzbaxters.com wrote:
This is all very fascinating, but can anyone offer a suggestion to how I can debug my 3 seconds of live TV problem?
When I switch to any live SD channel, I only get 3 seconds of audio/video and then then "channel not available". A few seconds later the picture comes back, for another 3 seconds, then unavailable.
Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started (pid=2499, tid=2532) Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started (pid=2499, tid=2533) Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended (pid=2499, tid=2533) Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended (pid=2499, tid=2532) Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available!
Not enough information. Assuming channel 1 is a real channel for you, check your xine log and cam log also. Usually "Channel not available" seems to mean the cam can't decrypt the channel or the tuner is in use already (such as a timer is active on another channel).
This is a test box with no timers or other front ends, so the tuner isn't in use anywhere. Above result happens no matter which channel I change to - 3 seconds of live TV then thread ends.
I've also tested using a FF card (so no xine front end) and still only getting 3 seconds of video.
Using vdr-xine, XINE logs, all I'm getting is: vdr: osdflush: n: 3, 32.6, timeout: 0, result: 0 vdr: osdflush: n: 2, 20.2, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.2, timeout: 0, result: 0 vdr: osdflush: n: 3, 33.6, timeout: 0, result: 0 vdr: osdflush: n: 3, 30.3, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.2, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.1, timeout: 0, result: 0 vdr: osdflush: n: 1, 10.1, timeout: 0, result: 0
CAM logs as follows: SetPlayMode: 1 Slot 2: ==> Date Time (4) 2: --> 01 01 A0 10 01 90 02 00 04 9F 84 41 07 D8 70 07 24 57 00 02 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 07 01 91 04 00 40 00 41 80 02 01 00 . . . . . . . . @ . A . . . . Slot 2: open session 00400041 Slot 2: new MMI (session id 5) 2: --> 01 01 A0 0A 01 92 07 00 00 40 00 41 00 05 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 82 00 0B 01 90 02 00 05 9F 88 01 02 01 01 80 02 01 00 . . . . . . . . . . . . . . . . . . . . . Slot 2: <== Display Control (5) Slot 2: ==> Display Reply (5) 2: --> 01 01 A0 0B 01 90 02 00 05 9F 88 02 02 01 01 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 82 00 61 01 90 02 00 05 9F 88 0C 58 02 9F 88 03 0B 97 41 6C 70 68 61 43 72 79 70 74 9F 88 03 01 20 9F 88 03 08 50 72 65 73 73 20 4F 4B 9F 88 03 14 59 6F 75 20 61 72 65 20 6E 6F 74 20 65 6E 74 69 74 6C 65 64 9F 88 03 1B 74 6F 20 72 65 63 65 69 76 65 20 74 68 69 73 20 70 72 6F 67 72 61 6D 6D 65 20 21 80 02 01 00 . . . . . a . . . . . . . . X . . . . . . A l p h a C r y p t . . . . . . . . P r e s s O K . . . . Y o u a r e n o t e n t i t l e d . . . . t o r e c e i v e t h i s p r o g r a m m e ! . . . . Slot 2: <== Menu Last (5) Slot 2: <== Text Last (5) 'AlphaCrypt' Slot 2: <== Text Last (5) '' Slot 2: <== Text Last (5) 'Press OK' Slot 2: <== Text Last (5) 'You are not entitled' Slot 2: <== Text Last (5) 'to receive this programme !' SetPlayMode: 0 Slot 2: ==> Ca Pmt (3) 5 1 2: --> 01 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 EE 01 00 07 01 09 04 06 06 E4 51 frame: (0, 0)-(-1, -1), zoom: (1.00, 1.00) Slot 2: ==> Date Time (4) 2: --> 01 01 A0 10 01 90 02 00 04 9F 84 41 07 D8 70 07 25 03 00 02 Slot 2: ==> Close MMI (5) 2: --> 01 01 A0 09 01 90 02 00 05 9F 88 00 00 Slot 2: receive data 1/1 2: --> 01 01 81 01 01 2: <-- 01 01 A0 05 01 95 02 00 05 80 02 01 00 . . . . . . . . . . . . . Slot 2: close session 5 2: --> 01 01 A0 06 01 96 03 00 00 05
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
If I run vdr-1.6.0 it works fine, it's just vdr-1.7.15 that doesn't. So I'm not thinking this is a system problem.
have made a bit of a breakthrough - I've found any vdr version up to and including vdr-1.7.11 works fine. From vdr-1.7.12 I get the 3 seconds of live TV problem.
Tested vdr-1.7.0,1,2,3,4,5,6,7,8,9,10,11,12,14,15.
This is in the HISTORY for vdr-1.7.12: - The PCR pid in generated PMTs is now set to the channel's PCR pid again. - Fixed determining the frame duration on channels where the PTS deltas jitter by +/-1 around 3600. - The PCR pid is now recorded for channels where this is different from the video PID. To facilitate this, the interfaces of cTransfer, cTransferControl, cRecorder and cReceiver have been modified, so that the PIDs are no longer given in separate parameters, but rather the whole channel is handed down for processing. The old constructor of cReceiver is still available, but it is recommended to plugin authors that they switch to the new interface as soon as possible. When replaying such a recording, the PCR packets are sent to PlayTsVideo()
Could it be something to do with this?
Summary of problem: - vdr-1.7.12 or newer I get 3 seconds (or so) of live TV before "SetPlayMode: 0", blank screen, sequence of "channel not available", then a few seconds of TV (repeats) - system has TT-1501 abd TT-2300 cards - usage of vdr-xine-0.9.3 or not makes no difference. i.e. TT-2300 FF card has same problem with no vdr-xine loaded. - any vdr version 1.7.11 or older does not show this fault.
any ideas?
Hi, Have you updated the firmware of the tt 2300? Check the mailinglist archives for instructions. You need also the newest drivers. BR. Halim
Hi, Ok, I use xineliboutput and vdr-xione here with no errors under vdr-1.7.15. If you have then check you xine-lib installation and the used videodriver. Sorry no other idea. Br. halim
Hi, Ok, I use xineliboutput and vdr-xione here with no errors under vdr-1.7.15. If you have then check you xine-lib installation and the used videodriver. Sorry no other idea. Br. halim
I'm pretty sure it's not xine-lib related.
I also have a FF card (TT-2300) which I run with no plugins - and get the same problem.
Summary of problem: - vdr-1.7.12 or newer I get 3 seconds (or so) of live TV before "SetPlayMode: 0", blank screen, sequence of "channel not available", then a few seconds of TV (repeats) - system has TT-1501 abd TT-2300 cards - usage of vdr-xine-0.9.3 or not makes no difference. i.e. TT-2300 FF card has same problem with no vdr-xine loaded.
- vdr-1.7.11 or older does not show this fault. i.e. vdr-1.7.9 and vdr-1.7.10 work 100% perfect.
Summary of problem: vdr-1.7.12 or newer I get 3 seconds (or so) of live TV before screen goes blank system has TT-1501 abd TT-2300 cards - makes no difference whether xine plugin is running or not same problem running through TT-2300 FF card vdr-1.7.<=11 works fine. vdr-1.7.>=12 shows the problem
I'm still no futher with this, can anyone please help?
I turned on ci.c debugging to see what happens differently between vdr-1.7.11 and vdr-1.7.15.
1.7.11 -> switch to channel 1 and on the console I see: SetPlayMode: 0 Slot 1: ==> Ca Pmt (3) 5 1 1: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 EB 01 00 07 01 09 04 06 06 E4 52 Slot 1: ==> Ca Pmt (3) 4 1 1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1
in messages, I see: Aug 28 12:53:15 freddy vdr: [17052] switching to channel 1 Aug 28 12:53:15 freddy vdr: [17104] TS buffer on device 1 thread ended (pid=17052, tid=17104) Aug 28 12:53:15 freddy vdr: [17103] buffer stats: 80840 (3%) used Aug 28 12:53:15 freddy vdr: [17103] receiver on device 1 thread ended (pid=17052, tid=17103) Aug 28 12:53:15 freddy vdr: [17105] receiver on device 1 thread started (pid=17052, tid=17105) Aug 28 12:53:15 freddy vdr: [17106] TS buffer on device 1 thread started (pid=17052, tid=17106) Aug 28 12:53:16 freddy vdr: [17105] cVideoRepacker: switching to MPEG1/2 mode Aug 28 12:53:16 freddy vdr: [17105] cVideoRepacker: operating in MPEG1/2 mode
i.e. ALL OK
In vdr-1.7.15 on the same box, I see: SetPlayMode: 0 Slot 2: ==> Ca Pmt (3) 5 1 2: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 04 06 06 E4 54 Slot 2: ==> Ca Pmt (3) 4 1 2: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1 [v] DiscontinuityDetected: triggering soft start [vAVM]buffered 7.1 frames (v:12.2, a:7.1) SetPlayMode: 0 Slot 2: ==> Ca Pmt (3) 5 1 2: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 04 06 06 E4 54 Slot 1: ==> Ca Pmt (3) 4 1 1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1 [v] DiscontinuityDetected: triggering soft start [vAVM]buffered 7.3 frames (v:13.0, a:7.3) SetPlayMode: 0 Slot 1: ==> Ca Pmt (3) 5 1 1: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 04 06 06 E4 54 Slot 2: ==> Ca Pmt (3) 4 1 2: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1 [v]
and in messages: Aug 28 12:50:10 freddy vdr: [16633] receiver on device 2 thread started (pid=16557, tid=16633) Aug 28 12:50:10 freddy vdr: [16634] TS buffer on device 2 thread started (pid=16557, tid=16634) Aug 28 12:50:11 freddy vdr: [16633] cVideoRepacker: switching to MPEG1/2 mode Aug 28 12:50:11 freddy vdr: [16633] cVideoRepacker: operating in MPEG1/2 mode Aug 28 12:50:14 freddy vdr: [16634] TS buffer on device 2 thread ended (pid=16557, tid=16634) Aug 28 12:50:14 freddy vdr: [16633] buffer stats: 192700 (9%) used Aug 28 12:50:14 freddy vdr: [16633] receiver on device 2 thread ended (pid=16557, tid=16633) Aug 28 12:50:21 freddy vdr: [16557] switching to channel 1 Aug 28 12:50:21 freddy vdr: [16635] receiver on device 1 thread started (pid=16557, tid=16635) Aug 28 12:50:21 freddy vdr: [16636] TS buffer on device 1 thread started (pid=16557, tid=16636) Aug 28 12:50:22 freddy vdr: [16635] cVideoRepacker: switching to MPEG1/2 mode Aug 28 12:50:22 freddy vdr: [16635] cVideoRepacker: operating in MPEG1/2 mode Aug 28 12:50:25 freddy vdr: [16636] TS buffer on device 1 thread ended (pid=16557, tid=16636) Aug 28 12:50:25 freddy vdr: [16635] buffer stats: 173712 (8%) used Aug 28 12:50:25 freddy vdr: [16635] receiver on device 1 thread ended (pid=16557, tid=16635)
i.e. I get 3 second "bursts" of live TV, but blank screen as the receiver threads restart
Why am I getting a "SetPlayMode: 0" and "receiver on device 2 thread ended (pid=16557, tid=16633)" for no reason??
On 28.08.2010 03:07, Simon Baxter wrote:
Summary of problem: vdr-1.7.12 or newer I get 3 seconds (or so) of live TV before screen goes blank system has TT-1501 abd TT-2300 cards - makes no difference whether xine plugin is running or not same problem running through TT-2300 FF card vdr-1.7.<=11 works fine. vdr-1.7.>=12 shows the problem
I'm still no futher with this, can anyone please help?
I turned on ci.c debugging to see what happens differently between vdr-1.7.11 and vdr-1.7.15.
1.7.11 -> switch to channel 1 and on the console I see: SetPlayMode: 0 Slot 1: ==> Ca Pmt (3) 5 1 1: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 EB 01 00 07 01 09 04 06 06 E4 52 Slot 1: ==> Ca Pmt (3) 4 1 1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1
in messages, I see: Aug 28 12:53:15 freddy vdr: [17052] switching to channel 1 Aug 28 12:53:15 freddy vdr: [17104] TS buffer on device 1 thread ended (pid=17052, tid=17104) Aug 28 12:53:15 freddy vdr: [17103] buffer stats: 80840 (3%) used Aug 28 12:53:15 freddy vdr: [17103] receiver on device 1 thread ended (pid=17052, tid=17103) Aug 28 12:53:15 freddy vdr: [17105] receiver on device 1 thread started (pid=17052, tid=17105) Aug 28 12:53:15 freddy vdr: [17106] TS buffer on device 1 thread started (pid=17052, tid=17106) Aug 28 12:53:16 freddy vdr: [17105] cVideoRepacker: switching to MPEG1/2 mode Aug 28 12:53:16 freddy vdr: [17105] cVideoRepacker: operating in MPEG1/2 mode
i.e. ALL OK
In vdr-1.7.15 on the same box, I see: SetPlayMode: 0 Slot 2: ==> Ca Pmt (3) 5 1 2: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 04 06 06 E4 54 Slot 2: ==> Ca Pmt (3) 4 1 2: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1 [v] DiscontinuityDetected: triggering soft start
You may want to find out where this message comes from (it certainly doesn't come from the core VDR).
[vAVM]buffered 7.1 frames (v:12.2, a:7.1) SetPlayMode: 0 Slot 2: ==> Ca Pmt (3) 5 1 2: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 04 06 06 E4 54 Slot 1: ==> Ca Pmt (3) 4 1 1: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1 [v] DiscontinuityDetected: triggering soft start [vAVM]buffered 7.3 frames (v:13.0, a:7.3) SetPlayMode: 0 Slot 1: ==> Ca Pmt (3) 5 1 1: --> 00 01 A0 16 01 90 02 00 03 9F 80 32 0D 05 03 ED 01 00 07 01 09 04 06 06 E4 54 Slot 2: ==> Ca Pmt (3) 4 1 2: --> 00 01 A0 20 01 90 02 00 03 9F 80 32 17 04 03 ED 01 00 07 01 09 04 06 06 E4 54 02 05 19 00 00 04 05 7D 00 00 SetPlayMode: 1 [v]
and in messages: Aug 28 12:50:10 freddy vdr: [16633] receiver on device 2 thread started (pid=16557, tid=16633) Aug 28 12:50:10 freddy vdr: [16634] TS buffer on device 2 thread started (pid=16557, tid=16634) Aug 28 12:50:11 freddy vdr: [16633] cVideoRepacker: switching to MPEG1/2 mode Aug 28 12:50:11 freddy vdr: [16633] cVideoRepacker: operating in MPEG1/2 mode Aug 28 12:50:14 freddy vdr: [16634] TS buffer on device 2 thread ended (pid=16557, tid=16634) Aug 28 12:50:14 freddy vdr: [16633] buffer stats: 192700 (9%) used Aug 28 12:50:14 freddy vdr: [16633] receiver on device 2 thread ended (pid=16557, tid=16633) Aug 28 12:50:21 freddy vdr: [16557] switching to channel 1 Aug 28 12:50:21 freddy vdr: [16635] receiver on device 1 thread started (pid=16557, tid=16635) Aug 28 12:50:21 freddy vdr: [16636] TS buffer on device 1 thread started (pid=16557, tid=16636) Aug 28 12:50:22 freddy vdr: [16635] cVideoRepacker: switching to MPEG1/2 mode Aug 28 12:50:22 freddy vdr: [16635] cVideoRepacker: operating in MPEG1/2 mode Aug 28 12:50:25 freddy vdr: [16636] TS buffer on device 1 thread ended (pid=16557, tid=16636) Aug 28 12:50:25 freddy vdr: [16635] buffer stats: 173712 (8%) used Aug 28 12:50:25 freddy vdr: [16635] receiver on device 1 thread ended (pid=16557, tid=16635)
i.e. I get 3 second "bursts" of live TV, but blank screen as the receiver threads restart
Why am I getting a "SetPlayMode: 0" and "receiver on device 2 thread ended (pid=16557, tid=16633)" for no reason??
When a receiver is detached from a device, the play mode is set to pmNone (which is 0).
My guess would be that the "DiscontinuityDetected: triggering soft start" is generated by the output device, and that causes the transfer mode to be stoped and restarted. Maybe the output device chokes on something in the TS stream?
Klaus
Hi,
Am 29.08.2010 15:06, schrieb Klaus Schmidinger:
DiscontinuityDetected: triggering soft start
You may want to find out where this message comes from (it certainly doesn't come from the core VDR).
This is just an implementation detail of vdr-xine.
Why am I getting a "SetPlayMode: 0" and "receiver on device 2 thread ended (pid=16557, tid=16633)" for no reason??
When a receiver is detached from a device, the play mode is set to pmNone (which is 0).
My guess would be that the "DiscontinuityDetected: triggering soft start" is generated by the output device, and that causes the transfer mode to be stoped and restarted. Maybe the output device chokes on something in the TS stream?
I doubt that vdr-xine does anything which would cause transfer mode to be stopped and restarted.
Bye.
Am 29.08.2010 15:06, schrieb Klaus Schmidinger:
DiscontinuityDetected: triggering soft start
You may want to find out where this message comes from (it certainly doesn't come from the core VDR).
This is just an implementation detail of vdr-xine.
Why am I getting a "SetPlayMode: 0" and "receiver on device 2 thread ended (pid=16557, tid=16633)" for no reason??
When a receiver is detached from a device, the play mode is set to pmNone (which is 0).
My guess would be that the "DiscontinuityDetected: triggering soft start" is generated by the output device, and that causes the transfer mode to be stoped and restarted. Maybe the output device chokes on something in the TS stream?
I doubt that vdr-xine does anything which would cause transfer mode to be stopped and restarted.
I have the same problem (transfer mode stopping) with plain VDR (no plugins) and a FF card. i.e. works fine in vdr-1.7.(<=)11 but not in vdr-1.7.(>=12)
Happy to do any captures etc - any suggestions??
Am 30.08.10 02:05, schrieb Simon Baxter:
I have the same problem (transfer mode stopping) with plain VDR (no plugins) and a FF card. i.e. works fine in vdr-1.7.(<=)11 but not in vdr-1.7.(>=12)
have you upgraded the firmware for your FF card, too?
Bye, Matthias
On 30.08.2010 02:05, Simon Baxter wrote:
Am 29.08.2010 15:06, schrieb Klaus Schmidinger:
DiscontinuityDetected: triggering soft start
You may want to find out where this message comes from (it certainly doesn't come from the core VDR).
This is just an implementation detail of vdr-xine.
Why am I getting a "SetPlayMode: 0" and "receiver on device 2 thread ended (pid=16557, tid=16633)" for no reason??
When a receiver is detached from a device, the play mode is set to pmNone (which is 0).
My guess would be that the "DiscontinuityDetected: triggering soft start" is generated by the output device, and that causes the transfer mode to be stoped and restarted. Maybe the output device chokes on something in the TS stream?
I doubt that vdr-xine does anything which would cause transfer mode to be stopped and restarted.
I have the same problem (transfer mode stopping) with plain VDR (no plugins) and a FF card. i.e. works fine in vdr-1.7.(<=)11 but not in vdr-1.7.(>=12)
Happy to do any captures etc - any suggestions??
The only place where a 3 second timeout plays a role that also might cause a channel to become unavailable is in cDevice::Action(), under
// Check whether the TS packets are scrambled:
Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here. This could be caused by recording the PCR packets since version 1.7.12. To debug this, just disable this check, and/or put in some debug printouts.
Klaus
The only place where a 3 second timeout plays a role that also might cause a channel to become unavailable is in cDevice::Action(), under
// Check whether the TS packets are scrambled:
Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here. This could be caused by recording the PCR packets since version 1.7.12. To debug this, just disable this check, and/or put in some debug printouts.
Klaus
How do I do this? Is it as simple as : - startScrambleDetection = 0; + startScrambleDetection = 1;
or comment out: // if (startScrambleDetection) { // cCamSlot *cs = CamSlot(); // CamSlotNumber = cs ? cs->SlotNumber() : 0; // if (CamSlotNumber) { // bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL; // int t = time(NULL) - startScrambleDetection; // if (Scrambled) { // if (t > TS_SCRAMBLING_TIMEOUT) // DetachReceivers = true; // } // else if (t > TS_SCRAMBLING_TIME_OK) { // DescramblingOk = true; // startScrambleDetection = 0; // } // } // }
or something else?
My guess would be that the "DiscontinuityDetected: triggering soft start" is generated by the output device, and that causes the transfer mode to be stoped and restarted. Maybe the output device chokes on something in the TS stream?
The only place where a 3 second timeout plays a role that also might cause a channel to become unavailable is in cDevice::Action(), under
// Check whether the TS packets are scrambled:
Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here. This could be caused by recording the PCR packets since version 1.7.12. To debug this, just disable this check, and/or put in some debug printouts.
I've added some markers in device.c as per: // Check whether the TS packets are scrambled: bool DetachReceivers = false; bool DescramblingOk = false; int CamSlotNumber = 0; if (startScrambleDetection) { cCamSlot *cs = CamSlot(); CamSlotNumber = cs ? cs->SlotNumber() : 0; if (CamSlotNumber) { bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL; int t = time(NULL) - startScrambleDetection; if (Scrambled) { printf("scramble detect ONE"); if (t > TS_SCRAMBLING_TIMEOUT) DetachReceivers = true; } else if (t > TS_SCRAMBLING_TIME_OK) { printf("scramble detect TWO"); DescramblingOk = true; startScrambleDetection = 0; } } }
Am getting lots of "scramble detect ONE" messages as per above.......
Now what?
// Check whether the TS packets are scrambled:
Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here. This could be caused by recording the PCR packets since version 1.7.12. To debug this, just disable this check, and/or put in some debug printouts.
Thanks Klaus
I've commented out the below section in device.c, and I now get continuous video, but some video skips and lots of: Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2 mode Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: switching to MPEG1/2 mode Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2 mode
Here's what I changed in device.c
void cDevice::Action(void) { if (Running() && OpenDvr()) { while (Running()) { // Read data from the DVR device: uchar *b = NULL; if (GetTSPacket(b)) { if (b) { int Pid = TsPid(b); // Check whether the TS packets are scrambled: bool DetachReceivers = false; bool DescramblingOk = false; int CamSlotNumber = 0; if (startScrambleDetection) { cCamSlot *cs = CamSlot(); CamSlotNumber = cs ? cs->SlotNumber() : 0; // if (CamSlotNumber) { // bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL; // int t = time(NULL) - startScrambleDetection; // if (Scrambled) { // if (t > TS_SCRAMBLING_TIMEOUT) // DetachReceivers = true; // } // else if (t > TS_SCRAMBLING_TIME_OK) { // DescramblingOk = true; // startScrambleDetection = 0; // } // } } // Distribute the packet to all attached receivers: Lock();
Any ideas?
// Check whether the TS packets are scrambled:
Maybe some packets have the TS_SCRAMBLING_CONTROL bits set here. This could be caused by recording the PCR packets since version 1.7.12. To debug this, just disable this check, and/or put in some debug printouts.
Thanks Klaus
I've commented out the below section in device.c, and I now get continuous video, but some video skips and lots of: Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2 mode Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: switching to MPEG1/2 mode Sep 3 21:36:29 freddy vdr: [31301] cVideoRepacker: operating in MPEG1/2 mode
This cVideoRepacker problem has also been fixed with the attached patch.
So I've managed to get vdr-1.7.15 working just fine now, by disabling this scramble check in device.c. Bit of a dirty hack!!!
Here's what I changed in device.c
void cDevice::Action(void) { if (Running() && OpenDvr()) { while (Running()) { // Read data from the DVR device: uchar *b = NULL; if (GetTSPacket(b)) { if (b) { int Pid = TsPid(b); // Check whether the TS packets are scrambled: bool DetachReceivers = false; bool DescramblingOk = false; int CamSlotNumber = 0; if (startScrambleDetection) { cCamSlot *cs = CamSlot(); CamSlotNumber = cs ? cs->SlotNumber() : 0; // if (CamSlotNumber) { // bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL; // int t = time(NULL) - startScrambleDetection; // if (Scrambled) { // if (t > TS_SCRAMBLING_TIMEOUT) // DetachReceivers = true; // } // else if (t > TS_SCRAMBLING_TIME_OK) { // DescramblingOk = true; // startScrambleDetection = 0; // } // } } // Distribute the packet to all attached receivers: Lock();
Any ideas?
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 09/03/10 22:12, Simon Baxter wrote:
... So I've managed to get vdr-1.7.15 working just fine now, by disabling this scramble check in device.c. Bit of a dirty hack!!!
Here's what I changed in device.c
void cDevice::Action(void) { if (Running() && OpenDvr()) { while (Running()) { // Read data from the DVR device: uchar *b = NULL; if (GetTSPacket(b)) { if (b) { int Pid = TsPid(b); // Check whether the TS packets are scrambled: bool DetachReceivers = false; bool DescramblingOk = false; int CamSlotNumber = 0; if (startScrambleDetection) { cCamSlot *cs = CamSlot(); CamSlotNumber = cs ? cs->SlotNumber() : 0; // if (CamSlotNumber) { // bool Scrambled = b[3] & TS_SCRAMBLING_CONTROL; // int t = time(NULL) - startScrambleDetection; // if (Scrambled) { // if (t > TS_SCRAMBLING_TIMEOUT) // DetachReceivers = true; // } // else if (t > TS_SCRAMBLING_TIME_OK) { // DescramblingOk = true; // startScrambleDetection = 0; // } // } } // Distribute the packet to all attached receivers: Lock();
Looks like there are TS packets in your stream that are marked as "scrambled", but not unscrambled by the CAM.
Do you have any CAM in your system at all?
Are the channels where this happens scrambled?
Do these channels have separate VPID and PPID?
Does the problem go away if, instead of the above change, you comment out the line
(Channel->Ppid() == Channel->Vpid() || AddPid(Channel->Ppid())) &&
in cReceiver::AddPids()?
Klaus
Need to confirm the tuner is still working also. When my dual tuner card died, the drivers still loaded but vdr couldn't access the tuners.
On 7/30/2010 11:12 PM, VDR User wrote:
On Fri, Jul 30, 2010 at 10:38 PM, Simon Baxterlinuxtv@nzbaxters.com wrote:
This is all very fascinating, but can anyone offer a suggestion to how I can debug my 3 seconds of live TV problem?
When I switch to any live SD channel, I only get 3 seconds of audio/video and then then "channel not available". A few seconds later the picture comes back, for another 3 seconds, then unavailable.
Jul 25 10:39:46 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:46 localhost vdr: [2532] receiver on device 1 thread started (pid=2499, tid=2532) Jul 25 10:39:46 localhost vdr: [2533] TS buffer on device 1 thread started (pid=2499, tid=2533) Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: switching to MPEG1/2 mode Jul 25 10:39:48 localhost vdr: [2532] cVideoRepacker: operating in MPEG1/2 mode Jul 25 10:39:50 localhost vdr: [2533] TS buffer on device 1 thread ended (pid=2499, tid=2533) Jul 25 10:39:50 localhost vdr: [2532] buffer stats: 201536 (9%) used Jul 25 10:39:50 localhost vdr: [2532] receiver on device 1 thread ended (pid=2499, tid=2532) Jul 25 10:39:57 localhost vdr: [2499] switching to channel 1 Jul 25 10:39:57 localhost vdr: [2499] info: Channel not available!
Not enough information. Assuming channel 1 is a real channel for you, check your xine log and cam log also. Usually "Channel not available" seems to mean the cam can't decrypt the channel or the tuner is in use already (such as a timer is active on another channel).
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-
Halim Sahin -
Klaus Schmidinger -
Matthias Fechner -
Morfsta -
Reinhard Nissl -
Simon Baxter -
Theunis Potgieter -
Timothy D. Lenz -
Tony Houghton -
VDR User