Re: [vdr] new drivers
Le samedi 02 février 2008 à 13:13 +0100, Hans Gustafsson a écrit : > I got rid of the xine blue screen/hang by downgrading libX11 and > libX11-devel to the ones from fedora 7 :) OK it works. It puts CPU usage up about 2-5%. I'll tell the openchrome and xine people. Cheers Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
Tony, I got rid of the xine blue screen/hang by downgrading libX11 and libX11-devel to the ones from fedora 7 :) Hope it works for you too. Regards, Hans ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
Hi, Tony Grant schrieb: >> There exists already a fixed version of libxcb but it is not >> available for a stock openSUSE 10.3. On the other hand, my EPIA >> MII-6000E runs openSUSE 10.3 too, using the binary openchrome >> driver package provided at openchrome.org and hasn't deadlocked >> so far though using xxmc. > > What did the opensuse people change? Is is an rpm we can rebuild against > FC8? If you follow the links on openchrome.org, you'll come to this site, where you can find the binary packages for openSUSE 10.3: http://www.logix.cz/michal/devel/suse-openchrome/ > I have had some success with live TV and xine dvb interface. As soon as > I try vdr and your pluggin it stops working. Try attaching gdb to the deadlocked process and provide stack traces for all threads. To get reasonable results you'll have to install debuginfo packages for your distribution. The command will look like that: gdb /path/to/xine `pidof xine` Check the output for missing debug symbols. Type "quit" to leave gdb, install further debuginfo packages and repeat this procedure until you have most symbols loaded. Then use this command to create backtraces for all threads: thread apply all bt Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
Le jeudi 17 janvier 2008 à 19:40 +0100, Reinhard Nissl a écrit : > There exists already a fixed version of libxcb but it is not > available for a stock openSUSE 10.3. On the other hand, my EPIA > MII-6000E runs openSUSE 10.3 too, using the binary openchrome > driver package provided at openchrome.org and hasn't deadlocked > so far though using xxmc. What did the opensuse people change? Is is an rpm we can rebuild against FC8? I have had some success with live TV and xine dvb interface. As soon as I try vdr and your pluggin it stops working. Cheers Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
Le jeudi 17 janvier 2008 à 23:32 +0100, Hans Gustafsson a écrit : > video_out_xxmc: New format. Need to change XvMC Context. > width: 544 height: 576 mpeg: 2 acceleration: 7 > video_out_xxmc: Disposing of surface 3 > 1 1;1 1;1 1;0 1;1 1;1 1;1 1;1 1;1 1;1 1;1 1;1 1;1 1;1 1;1 1;0 0; > video_out_xxmc: Freeing up XvMC Surfaces and subpictures. > video_out_xxmc: Freeing up XvMC Context. > video_out_xxmc: Surface type 0. Capabilities 0x 2 0x 4 > video_out_xxmc: Requests: 0x 2 0x 4 > video_out_xxmc: Creating new XvMC Context 842094169 > load_plugins: plugin mad will be used for audio streamtype 01. > audio_alsa_out:open pause_resume=0 > output sample rate 48000 > audio jump, diff=10387 > set_speed 100 > fixing sound card drift by 2520 pts > set_speed 125000 > set_speed 100 > > Now the picture goes blue and xine is not responding any more. If I > try to change channel, vdr will not respond and the watchdog timer > will expire resulting in a vdr restart. > Can the problem be that the width is set to 544? Not sure but it is interesting that you are seeing the same thing on another type of VIA card. Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
On Jan 17, 2008 7:06 PM, Tony Grant <[EMAIL PROTECTED]> wrote: > > > What video output driver do you use with xine? > > xxmc on VIA Epia M1 > > > Does the behavior change when using for example -V xshm? > > Yes You win > > 100% CPU but it changes channels. > > Back to Xavier and openchrome now? Hi, I have the same problem with xine sometimes showing just a blue screen after a channel change and have the following output from xine when it is started with --verbose=9. snip Duplicated XvMC frame 720 576. 0 1;1 1;0 0;0 0; 1 1;1 1;0 0;0 0; video_out_xxmc: Disposing of subpicture 1 1 1;0 1;0 0;0 0; vdr: osdflush: n: 1, 9.7, timeout: 0, result: 0 Duplicated XvMC frame 720 576. 1 1;0 1;0 0;0 0; 1 1;1 1;0 0;0 0; video_out_xxmc: Disposing of subpicture 0 0 1;1 1;0 0;0 0; vdr: osdflush: n: 1, 9.7, timeout: 0, result: 0 set_speed 125000 audio discontinuity #11, type is 2, disc_off 2452596738 waiting for in_discontinuity update #11 video discontinuity #11, type is 2, disc_off 2452596738 vpts adjusted with prebuffer to 3737993 libmpeg2: output port has XxMC capability video_out_xxmc: VO_PROP_INTERLACED(0) load_plugins: plugin mpeg2 will be used for video streamtype 00. video_out_xxmc: VO_PROP_INTERLACED(1) video_out_xxmc: New format. Need to change XvMC Context. width: 544 height: 576 mpeg: 2 acceleration: 7 video_out_xxmc: Disposing of surface 3 1 1;1 1;1 1;0 1;1 1;1 1;1 1;1 1;1 1;1 1;1 1;1 1;1 1;1 1;1 1;0 0; video_out_xxmc: Freeing up XvMC Surfaces and subpictures. video_out_xxmc: Freeing up XvMC Context. video_out_xxmc: Surface type 0. Capabilities 0x 2 0x 4 video_out_xxmc: Requests: 0x 2 0x 4 video_out_xxmc: Creating new XvMC Context 842094169 load_plugins: plugin mad will be used for audio streamtype 01. audio_alsa_out:open pause_resume=0 output sample rate 48000 audio jump, diff=10387 set_speed 100 fixing sound card drift by 2520 pts set_speed 125000 set_speed 100 Now the picture goes blue and xine is not responding any more. If I try to change channel, vdr will not respond and the watchdog timer will expire resulting in a vdr restart. Can the problem be that the width is set to 544? I am running fedora 8 on an EPIA CN1 with openchrome from 2007-12-27 and vdr-xine-0.8.1. Thanks, Hans ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
Le jeudi 17 janvier 2008 à 19:40 +0100, Reinhard Nissl a écrit : > > 100% CPU but it changes channels. > > Maybe -V xv relaxes CPU load a bit. Yes but sound eventually cuts out. > Well, on my openSUSE 10.3 I cannot use xxmc anymore with my > GF6600 as it dead locks for the same reason. openSUSE 10.3 uses > an libxcb based libX11 and there is a race condition bug in > libxcb which causes the emulated libX11 function XLockDisplay to > deadlock when an application uses multiple threads. Are these the buffer overflows in the log? > There exists already a fixed version of libxcb but it is not > available for a stock openSUSE 10.3. On the other hand, my EPIA > MII-6000E runs openSUSE 10.3 too, using the binary openchrome > driver package provided at openchrome.org and hasn't deadlocked > so far though using xxmc. OK I'll warn Xavier then. Cheers Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
Le jeudi 17 janvier 2008 à 20:47 +0100, Reinhard Nissl a écrit : > > Off topic, but are you saying you run vdr-xine or xineliboutput under X > > with > > the MII-6000E motherboard?? What other plugins do you run? > > femon, epgsearch, radio femon and streamdev on M1 no sweat > > I bought an SP-13000G, but it runs too hot running X so I had to use an FF > > card. Also I can't use the mplayer plugin, as the CPU transcoding makes it > > run too hot too. > > Hmm, was running the mplayer plugin for testing xineplayer but > didn't play anything else than MPEG2, though. > > CPU temperature doesn't look to cause a problem here, but after 3 > Years, the DC-ATX power converter died, as it was operated > without fan. The new power converter seems to cut off power when > getting too hot, so I've added a fan now. My M1 capacitors (MB and morex power supply) fried when we moved to the south of France (spikes). Now I have a UPS to filter the current and a pico120W power supply. The brick is the original one that came with my hush 60W but everything works. I have always run X and xine/vdr-xine temperatures shown only twice at danger level during summer (35°C in the living room) made me turn off the computer. Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
Hi, Simon Baxter schrieb: > Off topic, but are you saying you run vdr-xine or xineliboutput under X with > the MII-6000E motherboard?? What other plugins do you run? femon, epgsearch, radio > I bought an SP-13000G, but it runs too hot running X so I had to use an FF > card. Also I can't use the mplayer plugin, as the CPU transcoding makes it > run too hot too. Hmm, was running the mplayer plugin for testing xineplayer but didn't play anything else than MPEG2, though. CPU temperature doesn't look to cause a problem here, but after 3 Years, the DC-ATX power converter died, as it was operated without fan. The new power converter seems to cut off power when getting too hot, so I've added a fan now. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
> There exists already a fixed version of libxcb but it is not > available for a stock openSUSE 10.3. On the other hand, my EPIA > MII-6000E runs openSUSE 10.3 too, using the binary openchrome > driver package provided at openchrome.org and hasn't deadlocked > so far though using xxmc. Hi Reinhard Off topic, but are you saying you run vdr-xine or xineliboutput under X with the MII-6000E motherboard?? What other plugins do you run? I bought an SP-13000G, but it runs too hot running X so I had to use an FF card. Also I can't use the mplayer plugin, as the CPU transcoding makes it run too hot too. Thanks Simon ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
Hi, Tony Grant schrieb: >> What video output driver do you use with xine? > > xxmc on VIA Epia M1 > >> Does the behavior change when using for example -V xshm? > > Yes You win > > 100% CPU but it changes channels. Maybe -V xv relaxes CPU load a bit. Well, on my openSUSE 10.3 I cannot use xxmc anymore with my GF6600 as it dead locks for the same reason. openSUSE 10.3 uses an libxcb based libX11 and there is a race condition bug in libxcb which causes the emulated libX11 function XLockDisplay to deadlock when an application uses multiple threads. There exists already a fixed version of libxcb but it is not available for a stock openSUSE 10.3. On the other hand, my EPIA MII-6000E runs openSUSE 10.3 too, using the binary openchrome driver package provided at openchrome.org and hasn't deadlocked so far though using xxmc. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
Le jeudi 17 janvier 2008 à 18:53 +0100, Reinhard Nissl a écrit : > Tony Grant schrieb: > > Le jeudi 17 janvier 2008 à 17:53 +0100, Reinhard Nissl a écrit : > > > >> Can you provide an excerpt of VDR's logfile with the content from > >> "switching to channel" up to jan 17 10:25:01? > > > > Easier, I just switched channels and it stops > > You mean, xine stopped, but (see below) ... > > > Jan 17 18:35:59 hush vdr: [4551] caught signal 2 > > Jan 17 18:35:59 hush vdr: [4551] stopping plugin: femon > > Jan 17 18:35:59 hush vdr: [4551] stopping plugin: xine > ... > > Jan 17 18:36:00 hush vdr: [4551] max. latency time 1 seconds > > Jan 17 18:36:00 hush vdr: [4551] exiting, exit code 0 > > VDR was stopped regularly. > > What video output driver do you use with xine? xxmc on VIA Epia M1 > Does the behavior change when using for example -V xshm? Yes You win 100% CPU but it changes channels. Back to Xavier and openchrome now? Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
Tony Grant schrieb: > Le jeudi 17 janvier 2008 à 17:53 +0100, Reinhard Nissl a écrit : > >> Can you provide an excerpt of VDR's logfile with the content from >> "switching to channel" up to jan 17 10:25:01? > > Easier, I just switched channels and it stops You mean, xine stopped, but (see below) ... > Jan 17 18:35:59 hush vdr: [4551] caught signal 2 > Jan 17 18:35:59 hush vdr: [4551] stopping plugin: femon > Jan 17 18:35:59 hush vdr: [4551] stopping plugin: xine ... > Jan 17 18:36:00 hush vdr: [4551] max. latency time 1 seconds > Jan 17 18:36:00 hush vdr: [4551] exiting, exit code 0 VDR was stopped regularly. What video output driver do you use with xine? Does the behavior change when using for example -V xshm? Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new drivers
Le jeudi 17 janvier 2008 à 17:53 +0100, Reinhard Nissl a écrit : > Can you provide an excerpt of VDR's logfile with the content from > "switching to channel" up to jan 17 10:25:01? Easier, I just switched channels and it stops Tony Jan 17 18:34:24 hush vdr: [4551] codeset is 'UTF-8' - known Jan 17 18:34:25 hush vdr: [4551] found 22 locales in ./locale Jan 17 18:34:25 hush vdr: [4551] loading plugin: ./PLUGINS/lib/libvdr-xine.so.1.5.13 Jan 17 18:34:25 hush vdr: [4551] loading plugin: ./PLUGINS/lib/libvdr-femon.so.1.5.13 Jan 17 18:34:25 hush vdr: [4551] loading /video/setup.conf Jan 17 18:34:25 hush vdr: [4551] loading /video/sources.conf Jan 17 18:34:25 hush vdr: [4551] loading /video/diseqc.conf Jan 17 18:34:25 hush vdr: [4551] loading /video/channels.conf Jan 17 18:34:25 hush vdr: [4551] loading /video/timers.conf Jan 17 18:34:25 hush vdr: [4551] loading /video/reccmds.conf Jan 17 18:34:25 hush vdr: [4551] loading /video/svdrphosts.conf Jan 17 18:34:25 hush vdr: [4551] loading /video/remote.conf Jan 17 18:34:25 hush vdr: [4552] video directory scanner thread started (pid=4551, tid=4552) Jan 17 18:34:25 hush vdr: [4552] video directory scanner thread ended (pid=4551, tid=4552) Jan 17 18:34:25 hush vdr: [4553] video directory scanner thread started (pid=4551, tid=4553) Jan 17 18:34:25 hush vdr: [4553] video directory scanner thread ended (pid=4551, tid=4553) Jan 17 18:34:25 hush vdr: [4551] reading EPG data from /video/epg.data Jan 17 18:34:25 hush vdr: [4551] probing /dev/dvb/adapter0/frontend0 Jan 17 18:34:25 hush vdr: [4555] tuner on device 1 thread started (pid=4551, tid=4555) Jan 17 18:34:25 hush vdr: [4556] section handler thread started (pid=4551, tid=4556) Jan 17 18:34:25 hush vdr: [4551] found 1 video device Jan 17 18:34:25 hush vdr: [4551] initializing plugin: xine (0.8.1): Software based playback using xine Jan 17 18:34:25 hush vdr: [4557] XineRemote control thread started (pid=4551, tid=4557) Jan 17 18:34:25 hush vdr: [4557] Entering cXineRemote thread Jan 17 18:34:25 hush vdr: [4551] initializing plugin: femon (1.2.2): Affiche les informations du signal DVB Jan 17 18:34:25 hush vdr: [4551] setting primary device to 2 Jan 17 18:34:25 hush vdr: [4551] assuming manual start of VDR Jan 17 18:34:25 hush vdr: [4551] SVDRP listening on port 2001 Jan 17 18:34:25 hush vdr: [4551] setting current skin to "sttng" Jan 17 18:34:25 hush vdr: [4551] loading /video/themes/sttng-default.theme Jan 17 18:34:25 hush vdr: [4551] starting plugin: xine Jan 17 18:34:25 hush vdr: [4551] starting plugin: femon Jan 17 18:34:25 hush vdr: [4560] KBD remote control thread started (pid=4551, tid=4560) Jan 17 18:34:25 hush vdr: [4551] ERROR: remote control XineRemote not ready! Jan 17 18:34:25 hush vdr: [4551] remote control KBD - learning keys Jan 17 18:34:35 hush vdr: [4551] switching to channel 1 Jan 17 18:34:35 hush vdr: [4562] transfer thread started (pid=4551, tid=4562) Jan 17 18:34:35 hush vdr: [4563] receiver on device 1 thread started (pid=4551, tid=4563) Jan 17 18:34:35 hush vdr: [4564] TS buffer on device 1 thread started (pid=4551, tid=4564) Jan 17 18:34:35 hush vdr: [4551] setting watchdog timer to 60 seconds Jan 17 18:34:35 hush vdr: [4551] timer 1 (2 2050-2210 'Masterchef') set to event Jeu 17.01.2008 21:00-22:00 'Masterchef' Jan 17 18:34:36 hush vdr: [4562] PES packet shortened to 908 bytes (expected: 6158 bytes) Jan 17 18:34:36 hush vdr: [4562] cAudioRepacker(0xC0): skipped 122 bytes while syncing on next audio frame Jan 17 18:34:36 hush vdr: [4562] cAudioRepacker(0xC1): skipped 132 bytes to sync on next audio frame Jan 17 18:34:36 hush vdr: [4562] setting audio track to 1 (0) Jan 17 18:34:37 hush vdr: [4556] changing pids of channel 1 from 5000 +5000:5001=eng,5002=NAR:0:5003 to 5000 +5000:5001=eng,5002=NAR:5004=eng:5003 Jan 17 18:34:37 hush vdr: [4551] retuning due to modification of channel 1 Jan 17 18:34:37 hush vdr: [4551] switching to channel 1 Jan 17 18:34:37 hush vdr: [4562] transfer thread ended (pid=4551, tid=4562) Jan 17 18:34:37 hush vdr: [4551] cTS2PES got 0 TS errors, 3 TS continuity errors Jan 17 18:34:37 hush vdr: [4551] cTS2PES got 0 TS errors, 2 TS continuity errors Jan 17 18:34:37 hush vdr: [4551] cTS2PES got 0 TS errors, 1 TS continuity errors Jan 17 18:34:37 hush vdr: [4551] buffer stats: 68432 (3%) used Jan 17 18:34:37 hush vdr: [4565] transfer thread started (pid=4551, tid=4565) Jan 17 18:34:37 hush vdr: [4564] TS buffer on device 1 thread ended (pid=4551, tid=4564) Jan 17 18:34:37 hush vdr: [4563] buffer stats: 67304 (3%) used Jan 17 18:34:37 hush vdr: [4563] receiver on device 1 thread ended (pid=4551, tid=4563) Jan 17 18:34:37 hush vdr: [4566] receiver on device 1 thread started (pid=4551, tid=4566) Jan 17 18:34:37 hush vdr: [4567] TS buffer on device 1 thread started (pid=4551, tid=4567) Jan 17 18:34:37 hush vdr: [4556] channel 2 (BBC 2 England) event Jeu 17.01.2008 18:15-19:00 'The Weakest Link' status 4 Jan 17 18:34:37 hush vdr: [4556] creating new channel 'ETV,;BSkyB' on S28
Re: [vdr] new drivers
Hi, Tony Grant schrieb: > ZAP to ITV 1 (vertical polarization) > > SetPlayMode: 0 > SetAudioChannelDevice: 0 > SetPlayMode: 1 > [vSetDigitalAudioDevice: 0 > SetAudioChannelDevice: 0 > aAVMClear(0)jeu jan 17 10:25:01 CET 2008 reloading DVB driver It's not clear how much time has passed since zapping to ITV1 but it looks like VDR has crashed or exited. Can you provide an excerpt of VDR's logfile with the content from "switching to channel" up to jan 17 10:25:01? In case VDR has crashed, please provide a backtrace, i. e. run "ulimit -Sc unlimited" before starting VDR to allow a core dump to be written. Then use "gdb /path/to/vdr /path/to/core" and enter the command "bt". Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] new drivers
I pulled the dvb drivers with mercurial made and installed. Nothing has changed: Fire up vdr-xine which tunes to BBC 1 (horizintal polarization) vdr-xine: Client connected! [vaAVM]buffered 35,1 frames (v:39,0, a:35,1) frame: (0, 0)-(720, 576), zoom: (1,00, 1,00) Picture and sound perfect (yesterday there was a thunderstorm which blocked Eurobird from view...) ZAP to ITV 1 (vertical polarization) SetPlayMode: 0 SetAudioChannelDevice: 0 SetPlayMode: 1 [vSetDigitalAudioDevice: 0 SetAudioChannelDevice: 0 aAVMClear(0)jeu jan 17 10:25:01 CET 2008 reloading DVB driver Screen goes black and xine stops responding, needs to be killed. Not advancing very fast and running out of ideas... Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
