Re: [vdr] vdr-1.7.15 problem with TV
On Fri, Jul 30, 2010 at 10:38 PM, Simon Baxter linu...@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
Re: [vdr] vdr-1.7.15 problem with TV
On Fri, Jul 30, 2010 at 10:38 PM, Simon Baxter linu...@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
Re: [vdr] Hulu plugin yet?
On 29/07/10 17:36, VDR User wrote: On Thu, Jul 29, 2010 at 1:22 PM, Timothy D. Lenz tl...@vorgon.com wrote: Now that Hulu is offering HD of sorts (720 with sub), are there any plugins in the works to give vdr hulu access? So far the only thing I've seen are just scripts to shutdown vdr and switch to some other program. If mplayer can play hulu then I guess you could hack together something for the mplayer plugin. I use the PlayOn server on a windows box with djmount.. djmount -o playlists -o allow_other /mnt/media/Movies/DLNA Then use xine to find the playlists... I tried using playon with vmware, but got stuttering. Playback is better on xbmc.. Also the Nintendo Wii plays back very well. It does Netflix too. -- Rob Davis ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with TV
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 Baxterlinu...@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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with TV
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 linu...@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
Re: [vdr] Hulu plugin yet?
Shouldn't need to set up a windows server to add hulu suport. Mythtv can do it, Hulu is supported in linux. Want to reduce overhead, not add to it. On 7/31/2010 9:57 AM, Rob Davis wrote: On 29/07/10 17:36, VDR User wrote: On Thu, Jul 29, 2010 at 1:22 PM, Timothy D. Lenztl...@vorgon.com wrote: Now that Hulu is offering HD of sorts (720 with sub), are there any plugins in the works to give vdr hulu access? So far the only thing I've seen are just scripts to shutdown vdr and switch to some other program. If mplayer can play hulu then I guess you could hack together something for the mplayer plugin. I use the PlayOn server on a windows box with djmount.. djmount -o playlists -o allow_other /mnt/media/Movies/DLNA Then use xine to find the playlists... I tried using playon with vmware, but got stuttering. Playback is better on xbmc.. Also the Nintendo Wii plays back very well. It does Netflix too. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Alternate-Channel-Patch
Dear Rainer, Am Freitag, den 30.07.2010, 21:48 +0200 schrieb Rainer Blickle: there was the alternate channel patch (http://www.vdr-wiki.de/wiki/index.php/Alternative_channel-patch). This patch provides alternative channels for timers, if the programmed channel was not available. Is there any patch providing this functionality for live-tv, too ? sorry, I do not know. If not, i would like to develop such a functionality. Does anybody knows why the patch doesn't get integrated ? Klaus decides what goes into VDR. I do not know if he knows about the patch or if it was sent to this list. Is such a functionality unwanted ? I recommend, that you send this patch to this list to get it reviewed. I guess Klaus will comment on it if he has time. What is the workflow to parcipiate in developing the vdr ? As far as I know, you create a patch and you send it to this list or to Klaus directly. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with TV
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 linu...@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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] priorities in streamdev
On Fri, 30 Jul 2010 15:03:30 +0200, syrius.ml wrote Just an offtopic note: i'm using 2 streamdev-client instances, in the setup menu i get streamdev-client and streamdev-client2. when I change an option from one instance it gets changed in the other's instance menu as well. (it's just an ui issue, setup.conf is updated correctly) Is your libvdr-streamdev-client2.so a (symbolic or hard) link to libvdr-streamdev-client.so? Don't do that. It must be a copy. Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with TV
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? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
