Re: [vdr] vdr-1.7.15 problem with TV
Hi, Have you updated the firmware of the tt 2300? Check the mailinglist archives for instructions. You need also the newest drivers. BR. Halim -- Halim Sahin E-Mail: halim.sahin (at) t-online.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with TV
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 -- Halim Sahin E-Mail: halim.sahin (at) t-online.de ___ 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). ___ 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] 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] 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] 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
Re: [vdr] vdr-1.7.15 problem with TV
On 29 July 2010 21:55, Morfsta morf...@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? ___ 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, 30 Jul 2010 09:17:23 +0200 Theunis Potgieter theunis.potgie...@gmail.com wrote: On 29 July 2010 21:55, Morfsta morf...@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. -- TH * http://www.realh.co.uk ___ 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 30 July 2010 15:40, Tony Houghton h...@realh.co.uk wrote: On Fri, 30 Jul 2010 09:17:23 +0200 Theunis Potgieter theunis.potgie...@gmail.com wrote: On 29 July 2010 21:55, Morfsta morf...@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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with TV
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.potgie...@gmail.com wrote: On 29 July 2010 21:55, Morfstamorf...@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. ___ 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 Thu, Jul 29, 2010 at 12:55 PM, Morfsta morf...@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). ___ 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 Thu, Jul 29, 2010 at 12:55 PM, Morfsta morf...@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! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with TV
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... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.15 problem with TV
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-xine-0.9.3-1.7.12.diff Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
