vdr-1.7.12 + reelbox + 2 Anysee E30C USB devices
Sadly quite often my vdr stops working, with the following error:
localhost vdr: [2626] buffer usage: 70% (tid=2625) localhost vdr: [2626] buffer usage: 80% (tid=2625) localhost vdr: [2626] buffer usage: 90% (tid=2625) localhost vdr: [2626] buffer usage: 100% (tid=2625) localhost vdr: [2626] ERROR: driver buffer overflow on device 1 localhost vdr: [2626] ERROR: driver buffer overflow on device 1 (repeated over and over again)
Just killing vdr and reloading the DVB driver doesn't fix this. I have to reboot the machine to get everything working again. Now I was wondering, when this happens how can I make vdr exit with say exit code 9, so that I can make the runvdr reboot the machine.
Thanks,
Josce
Am Dienstag, den 23.02.2010, 20:49 +0200 schrieb Josce:
vdr-1.7.12 + reelbox + 2 Anysee E30C USB devices
Sadly quite often my vdr stops working, with the following error:
localhost vdr: [2626] buffer usage: 70% (tid=2625) localhost vdr: [2626] buffer usage: 80% (tid=2625) localhost vdr: [2626] buffer usage: 90% (tid=2625) localhost vdr: [2626] buffer usage: 100% (tid=2625) localhost vdr: [2626] ERROR: driver buffer overflow on device 1 localhost vdr: [2626] ERROR: driver buffer overflow on device 1 (repeated over and over again)
Does it happen on all channels? I have the same problem, but only with HD channels. When i switch to a different channel. the problem goes away until it comes up after a while.
I assume that the hdplayer on the eHD card gets stuck.
Just killing vdr and reloading the DVB driver doesn't fix this. I have to reboot the machine to get everything working again. Now I was wondering, when this happens how can I make vdr exit with say exit code 9, so that I can make the runvdr reboot the machine.
Thanks,
Josce
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 24.2.2010 09:18, Falk Spitzberg wrote:
Am Dienstag, den 23.02.2010, 20:49 +0200 schrieb Josce:
vdr-1.7.12 + reelbox + 2 Anysee E30C USB devices
Sadly quite often my vdr stops working, with the following error:
localhost vdr: [2626] buffer usage: 70% (tid=2625) localhost vdr: [2626] buffer usage: 80% (tid=2625) localhost vdr: [2626] buffer usage: 90% (tid=2625) localhost vdr: [2626] buffer usage: 100% (tid=2625) localhost vdr: [2626] ERROR: driver buffer overflow on device 1 localhost vdr: [2626] ERROR: driver buffer overflow on device 1 (repeated over and over again)
Does it happen on all channels? I have the same problem, but only with HD channels. When i switch to a different channel. the problem goes away until it comes up after a while.
I assume that the hdplayer on the eHD card gets stuck.
Yes it seems to happen on all channels.
Josce
Perhaps it's the same problem as I have with my unmodded FF-Card
Same here on vdr-1.7.12 with reel snap -r14440 ( starts on update to vdr-1.7.11 ) terractec-1200 dvb-c card latest vanilla kernel sources.
this is on all sky channels with resolution 1920 x 1080
If i go down to vdr-1.7.10, all problems are gone.
On 24.02.2010 18:11, Joerg Bornkessel wrote:
Perhaps it's the same problem as I have with my unmodded FF-Card
Same here on vdr-1.7.12 with reel snap -r14440 ( starts on update to vdr-1.7.11 ) terractec-1200 dvb-c card latest vanilla kernel sources.
this is on all sky channels with resolution 1920 x 1080
If i go down to vdr-1.7.10, all problems are gone.
What about VDR 1.7.11 and 1.7.13 (just to further narrow this down)?
Klaus
On 24.02.2010 18:11, Joerg Bornkessel wrote:
Perhaps it's the same problem as I have with my unmodded FF-Card
Same here on vdr-1.7.12 with reel snap -r14440 ( starts on update to vdr-1.7.11 ) terractec-1200 dvb-c card latest vanilla kernel sources.
this is on all sky channels with resolution 1920 x 1080
If i go down to vdr-1.7.10, all problems are gone.
What about VDR 1.7.11 and 1.7.13 (just to further narrow this down)?
Klaus,
In my case its fixed with recompile 'our all beloved' plugin ** with another CXXFLAGS ( 1.7.13 not tested yet )
Sorry, my fault :(
On Fri, Mar 5, 2010 at 7:31 AM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
What about VDR 1.7.11 and 1.7.13 (just to further narrow this down)?
I have experienced this problem several times today while on HD h264 channels. Like previously posted:
Mar 12 15:02:23 vdr: [20675] buffer usage: 70% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 80% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 90% (tid=20674) Mar 12 15:02:25 vdr: [20675] buffer usage: 100% (tid=20674)
VDR was unresponsive and had to be restarted to fix.
Best regards, Derek
On Fri, Mar 12, 2010 at 3:08 PM, VDR User user.vdr@gmail.com wrote:
On Fri, Mar 5, 2010 at 7:31 AM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
What about VDR 1.7.11 and 1.7.13 (just to further narrow this down)?
I have experienced this problem several times today while on HD h264 channels. Like previously posted:
Mar 12 15:02:23 vdr: [20675] buffer usage: 70% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 80% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 90% (tid=20674) Mar 12 15:02:25 vdr: [20675] buffer usage: 100% (tid=20674)
VDR was unresponsive and had to be restarted to fix.
Best regards, Derek
Sorry, forgot to mention this is with VDR-1.7.13...
I have experienced this problem several times today while on HD h264 channels. Like previously posted:
Mar 12 15:02:23 vdr: [20675] buffer usage: 70% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 80% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 90% (tid=20674) Mar 12 15:02:25 vdr: [20675] buffer usage: 100% (tid=20674)
VDR was unresponsive and had to be restarted to fix.
Best regards, Derek
Sorry, forgot to mention this is with VDR-1.7.13...
I confirm - with vdr 1.7.13 still have the same issue
Goga
Hi,
Am 13.03.2010 11:30, schrieb Goga777:
I have experienced this problem several times today while on HD h264 channels. Like previously posted:
Mar 12 15:02:23 vdr: [20675] buffer usage: 70% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 80% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 90% (tid=20674) Mar 12 15:02:25 vdr: [20675] buffer usage: 100% (tid=20674)
VDR was unresponsive and had to be restarted to fix.
Best regards, Derek
Sorry, forgot to mention this is with VDR-1.7.13...
I confirm - with vdr 1.7.13 still have the same issue
I assume, you both use vdr-xine. It would be a good idea to create a backtrace in that situation to rule out vdr-xine as source of this issue.
Bye.
I have experienced this problem several times today while on HD h264 channels. Like previously posted:
Mar 12 15:02:23 vdr: [20675] buffer usage: 70% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 80% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 90% (tid=20674) Mar 12 15:02:25 vdr: [20675] buffer usage: 100% (tid=20674)
VDR was unresponsive and had to be restarted to fix.
Best regards, Derek
Sorry, forgot to mention this is with VDR-1.7.13...
I confirm - with vdr 1.7.13 still have the same issue
I assume, you both use vdr-xine. It would be a good idea to create a backtrace in that situation to rule out vdr-xine as source of this issue.
yes, I'm using the vdr-xine 093 please advice how should I use backtrace
thanks
Goga
Hi,
Am 14.03.2010 12:46, schrieb Goga777:
I have experienced this problem several times today while on HD h264 channels. Like previously posted:
Mar 12 15:02:23 vdr: [20675] buffer usage: 70% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 80% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 90% (tid=20674) Mar 12 15:02:25 vdr: [20675] buffer usage: 100% (tid=20674)
VDR was unresponsive and had to be restarted to fix.
Best regards, Derek
Sorry, forgot to mention this is with VDR-1.7.13...
I confirm - with vdr 1.7.13 still have the same issue
I assume, you both use vdr-xine. It would be a good idea to create a backtrace in that situation to rule out vdr-xine as source of this issue.
yes, I'm using the vdr-xine 093 please advice how should I use backtrace
When VDR is unresponsive, type something like that:
gdb /path/to/vdr `pidof vdr`
At the gdb prompt, issue the following command:
thread apply all bt
and provide the output.
Bye.
On 14 March 2010 21:47, Reinhard Nissl rnissl@gmx.de wrote:
Hi,
Am 14.03.2010 12:46, schrieb Goga777:
I have experienced this problem several times today while on HD h264 channels. Like previously posted:
Mar 12 15:02:23 vdr: [20675] buffer usage: 70% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 80% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 90% (tid=20674) Mar 12 15:02:25 vdr: [20675] buffer usage: 100% (tid=20674)
VDR was unresponsive and had to be restarted to fix.
Best regards, Derek
Sorry, forgot to mention this is with VDR-1.7.13...
I confirm - with vdr 1.7.13 still have the same issue
I assume, you both use vdr-xine. It would be a good idea to create a backtrace in that situation to rule out vdr-xine as source of this issue.
yes, I'm using the vdr-xine 093 please advice how should I use backtrace
I see similar problems with xineliboutput, but I'm not sure it's exactly the same problem. I don't have to restart VDR, restarting the vdr-sxfe client is sufficient.
In the logs I get
Mar 17 13:54:43 htpc vdr: [3710] [xine..put] cXinelibServer::Play_PES Buffer overflow (TCP/PIPE) Mar 17 13:54:43 htpc vdr: [3710] [xine..put] cXinelibServer::Play_PES Buffer overflow (TCP/PIPE) Mar 17 13:54:43 htpc vdr: [3710] [xine..put] cXinelibServer::Play_PES Buffer overflow (TCP/PIPE) [ repeat X times..]
Mar 17 13:54:54 htpc vdr: [3710] [xine..put] cXinelibServer::Play_PES Buffer overflow (TCP/PIPE) Mar 17 13:54:54 htpc vdr: [3710] [xine..put] cXinelibServer::Play_PES Buffer overflow (TCP/PIPE) Mar 17 13:54:54 htpc vdr: [3710] [xine..put] cXinelibServer: Too many TCP buffer overflows, dropping client Mar 17 13:54:54 htpc vdr: [3710] [xine..put] cXinelibServer::Play_PES Write/Queue error (TCP/PIPE) Mar 17 13:54:54 htpc vdr: [3710] [xine..put] Closing connection 0
Sometimes the logs has the buffer usage messages as well;
Mar 16 01:38:17 htpc vdr: [8370] [xine..put] cXinelibServer::Play_PES Buffer overflow (TCP/PIPE) Mar 16 01:38:17 htpc vdr: [8370] [xine..put] cXinelibServer: Too many TCP buffer overflows, dropping client Mar 16 01:38:17 htpc vdr: [8370] [xine..put] cXinelibServer::Play_PES Write/Queue error (TCP/PIPE) Mar 16 01:38:19 htpc vdr: [8371] buffer usage: 70% (tid=8370) Mar 16 01:38:19 htpc vdr: [8371] buffer usage: 80% (tid=8370) Mar 16 01:38:19 htpc vdr: [8371] buffer usage: 90% (tid=8370) Mar 16 01:38:19 htpc vdr: [8371] buffer usage: 100% (tid=8370) Mar 16 01:38:20 htpc vdr: [8370] ERROR: thread 8429 won't end (waited 3 seconds) - canceling it... Mar 16 01:38:20 htpc vdr: [8370] [xine..put] Closing connection 0 Mar 16 01:38:20 htpc vdr: [8371] buffer usage: 60% (tid=8370)
This is a problem since the vdr-sxfe client doesn't exit, it just freezes. It would be better if it exit, then it could reconnect if scripted to do so.
Some output from gdb;
[root@htpc ~]# gdb /usr/local/bin/vdr `pidof vdr` GNU gdb (GDB) Fedora (7.0.1-33.fc12) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-redhat-linux-gnu". For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/bin/vdr...done. Attaching to program: /usr/local/bin/vdr, process 1809 Reading symbols from /usr/lib/libjpeg.so.62...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 0xaf599b70 (LWP 3711)] [New Thread 0xb17f8b70 (LWP 3710)] [New Thread 0xb21f9b70 (LWP 1822)] [New Thread 0xb35fbb70 (LWP 1820)] [New Thread 0xb3ffcb70 (LWP 1819)] [New Thread 0xb49fdb70 (LWP 1818)] [New Thread 0xb53feb70 (LWP 1817)] [New Thread 0xb5dffb70 (LWP 1815)] [New Thread 0xb6b1bb70 (LWP 1814)] Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libcap.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libcap.so.2 Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /usr/lib/libfreetype.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libfreetype.so.6 Reading symbols from /usr/lib/libfontconfig.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libfontconfig.so.1 Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libattr.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libattr.so.1 Reading symbols from /lib/libexpat.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libexpat.so.1 Reading symbols from /usr/lib/gconv/ISO8859-1.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Reading symbols from /usr/local/src/VDR/PLUGINS/lib/libvdr-xineliboutput.so.1.7.11...done. Loaded symbols for /usr/local/src/VDR/PLUGINS/lib/libvdr-xineliboutput.so.1.7.11 Reading symbols from /usr/local/src/VDR/PLUGINS/lib/libvdr-femon.so.1.7.11...(no debugging symbols found)...done. Loaded symbols for /usr/local/src/VDR/PLUGINS/lib/libvdr-femon.so.1.7.11 Reading symbols from /usr/local/src/VDR/PLUGINS/lib/libvdr-webvideo.so.1.7.11...done. Loaded symbols for /usr/local/src/VDR/PLUGINS/lib/libvdr-webvideo.so.1.7.11 Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /usr/local/lib/libwebvi.so.0...done. Loaded symbols for /usr/local/lib/libwebvi.so.0 Reading symbols from /usr/lib/libpython2.6.so.1.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libpython2.6.so.1.0 Reading symbols from /lib/libutil.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /usr/lib/gconv/ISO_6937.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/gconv/ISO_6937.so 0x007fe424 in __kernel_vsyscall () Missing separate debuginfos, use: debuginfo-install expat-2.0.1-8.fc12.i686 fontconfig-2.8.0-1.fc12.i686 freetype-2.3.11-3.fc12.i686 glibc-2.11.1-1.i686 libattr-2.4.44-1.fc12.i686 libcap-2.16-5.fc12.i686 libgcc-4.4.3-4.fc12.i686 libjpeg-6b-46.fc12.i686 libstdc++-4.4.3-4.fc12.i686 libxml2-2.7.6-1.fc12.i686 python-libs-2.6.2-4.fc12.i686 zlib-1.2.3-23.fc12.i686 (gdb) thread apply all bt
Thread 10 (Thread 0xb6b1bb70 (LWP 1814)): #0 0x007fe424 in __kernel_vsyscall () #1 0x00ae6f72 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x08100bfe in cCondVar::TimedWait (this=0x85e16e0, Mutex=..., TimeoutMs=1000) at thread.c:127 #3 0x080a467f in cDvbTuner::Action (this=0x85e1120) at dvbdevice.c:352 #4 0x081005f0 in cThread::StartThread (Thread=0x85e1120) at thread.c:257 #5 0x00ae2ab5 in start_thread () from /lib/libpthread.so.0 #6 0x00a0ddce in clone () from /lib/libc.so.6
Thread 9 (Thread 0xb5dffb70 (LWP 1815)): #0 0x007fe424 in __kernel_vsyscall () #1 0x00a033d6 in poll () from /lib/libc.so.6 #2 0x080ea4a7 in cSectionHandler::Action (this=0x84d25c0) at sections.c:184 #3 0x081005f0 in cThread::StartThread (Thread=0x84d25c0) at thread.c:257 #4 0x00ae2ab5 in start_thread () from /lib/libpthread.so.0 #5 0x00a0ddce in clone () from /lib/libc.so.6
Thread 8 (Thread 0xb53feb70 (LWP 1817)): #0 0x007fe424 in __kernel_vsyscall () #1 0x00ae6f72 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x08100bfe in cCondVar::TimedWait (this=0x85e8da8, Mutex=..., TimeoutMs=1000) at thread.c:127 #3 0x080a467f in cDvbTuner::Action (this=0x85e87e8) at dvbdevice.c:352 #4 0x081005f0 in cThread::StartThread (Thread=0x85e87e8) at thread.c:257 #5 0x00ae2ab5 in start_thread () from /lib/libpthread.so.0 #6 0x00a0ddce in clone () from /lib/libc.so.6
Thread 7 (Thread 0xb49fdb70 (LWP 1818)): #0 0x007fe424 in __kernel_vsyscall () #1 0x00a033d6 in poll () from /lib/libc.so.6 #2 0x080ea4a7 in cSectionHandler::Action (this=0x85e8f40) at sections.c:184 #3 0x081005f0 in cThread::StartThread (Thread=0x85e8f40) at thread.c:257 #4 0x00ae2ab5 in start_thread () from /lib/libpthread.so.0 #5 0x00a0ddce in clone () from /lib/libc.so.6
Thread 6 (Thread 0xb3ffcb70 (LWP 1819)): #0 0x007fe424 in __kernel_vsyscall () #1 0x00ae6f72 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x08100bfe in cCondVar::TimedWait (this=0x85f5348, Mutex=..., TimeoutMs=5000) at thread.c:127 #3 0x00f7aa0a in cUdpScheduler::Action (this=0x85f5318) at tools/udp_pes_scheduler.c:750 #4 0x081005f0 in cThread::StartThread (Thread=0x85f5318) at thread.c:257 #5 0x00ae2ab5 in start_thread () from /lib/libpthread.so.0 #6 0x00a0ddce in clone () from /lib/libc.so.6
Thread 5 (Thread 0xb35fbb70 (LWP 1820)): #0 0x007fe424 in __kernel_vsyscall () #1 0x00a033d6 in poll () from /lib/libc.so.6 #2 0x00f75237 in cXinelibServer::Action (this=0x85f2878) at frontend_svr.c:1844 #3 0x081005f0 in cThread::StartThread (Thread=0x85f2878) at thread.c:257 #4 0x00ae2ab5 in start_thread () from /lib/libpthread.so.0 #5 0x00a0ddce in clone () from /lib/libc.so.6
Thread 4 (Thread 0xb21f9b70 (LWP 1822)): #0 0x007fe424 in __kernel_vsyscall () #1 0x00a063b1 in select () from /lib/libc.so.6 #2 0x08105287 in cFile::FileReady (FileDes=11, TimeoutMs=<value optimized out>) at tools.c:1372 #3 0x080b8f23 in cLircRemote::Action (this=0x8656a70) at lirc.c:73 #4 0x081005f0 in cThread::StartThread (Thread=0x8656a80) at thread.c:257 #5 0x00ae2ab5 in start_thread () from /lib/libpthread.so.0 #6 0x00a0ddce in clone () from /lib/libc.so.6
Thread 3 (Thread 0xb17f8b70 (LWP 3710)): #0 0x007fe424 in __kernel_vsyscall () #1 0x00ae6f72 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x08100cf0 in cCondWait::Wait (this=0xb5e01820, TimeoutMs=100) at thread.c:71 #3 0x080e8997 in cRingBuffer::WaitForGet (this=0xb5e017d0) at ringbuffer.c:64 #4 0x080e8a82 in cRingBufferLinear::Get (this=0xb5e017d0, Count=@0xb17f829c) at ringbuffer.c:350 #5 0x0809e7b9 in cTSBuffer::Get (this=0xb5e81528) at device.c:1636 #6 0x080a318d in cDvbDevice::GetTSPacket (this=0x85de850, Data=@0xb17f833c) at dvbdevice.c:699 #7 0x080a0333 in cDevice::Action (this=0x85de850) at device.c:1441 #8 0x081005f0 in cThread::StartThread (Thread=0x85de850) at thread.c:257 #9 0x00ae2ab5 in start_thread () from /lib/libpthread.so.0 #10 0x00a0ddce in clone () from /lib/libc.so.6
Thread 2 (Thread 0xaf599b70 (LWP 3711)): #0 0x007fe424 in __kernel_vsyscall () #1 0x00a033d6 in poll () from /lib/libc.so.6 #2 0x081054eb in cPoller::Poll (this=0xaf5992bc, TimeoutMs=100) at tools.c:1196 #3 0x0809eb88 in cTSBuffer::Action (this=0xb5e81528) at device.c:1613 #4 0x081005f0 in cThread::StartThread (Thread=0xb5e81528) at thread.c:257 #5 0x00ae2ab5 in start_thread () from /lib/libpthread.so.0 #6 0x00a0ddce in clone () from /lib/libc.so.6
Thread 1 (Thread 0xb77ad6d0 (LWP 1809)): #0 0x007fe424 in __kernel_vsyscall () #1 0x00ae6f72 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x08100bfe in cCondVar::TimedWait (this=0x8164260, Mutex=..., TimeoutMs=1000) at thread.c:127 #3 0x080e4958 in cRemote::Get (WaitMs=1000, UnknownCode=0x0) at remote.c:191 #4 0x0810b910 in main (argc=25, argv=0xbfc42794) at vdr.c:928
I'm running VDR version 1.7.11.
Am 17.03.2010 07:23, schrieb Torgeir Veimo:
On 14 March 2010 21:47, Reinhard Nissl rnissl@gmx.de wrote:
Hi,
Am 14.03.2010 12:46, schrieb Goga777:
> I have experienced this problem several times today while on HD h264 > channels. Like previously posted: > > Mar 12 15:02:23 vdr: [20675] buffer usage: 70% (tid=20674) > Mar 12 15:02:24 vdr: [20675] buffer usage: 80% (tid=20674) > Mar 12 15:02:24 vdr: [20675] buffer usage: 90% (tid=20674) > Mar 12 15:02:25 vdr: [20675] buffer usage: 100% (tid=20674) > > VDR was unresponsive and had to be restarted to fix. > > Best regards, > Derek
Sorry, forgot to mention this is with VDR-1.7.13...
I confirm - with vdr 1.7.13 still have the same issue
I assume, you both use vdr-xine. It would be a good idea to create a backtrace in that situation to rule out vdr-xine as source of this issue.
yes, I'm using the vdr-xine 093 please advice how should I use backtrace
I see similar problems with xineliboutput, but I'm not sure it's exactly the same problem. I don't have to restart VDR, restarting the vdr-sxfe client is sufficient.
Hmm, looks like xine / vdr-sxfe would be to blame. There are some cases where vdpau leaks images while decoding h264 video and when no more images are left, xine / vdr-sxfe freezes and vdr runs into an buffer overflow.
Does this happen too when not using vdpau?
Bye.
I have experienced this problem several times today while on HD h264 channels. Like previously posted:
Mar 12 15:02:23 vdr: [20675] buffer usage: 70% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 80% (tid=20674) Mar 12 15:02:24 vdr: [20675] buffer usage: 90% (tid=20674) Mar 12 15:02:25 vdr: [20675] buffer usage: 100% (tid=20674)
VDR was unresponsive and had to be restarted to fix.
Best regards, Derek
Sorry, forgot to mention this is with VDR-1.7.13...
I confirm - with vdr 1.7.13 still have the same issue
I assume, you both use vdr-xine. It would be a good idea to create a backtrace in that situation to rule out vdr-xine as source of this issue.
yes, I'm using the vdr-xine 093 please advice how should I use backtrace
When VDR is unresponsive, type something like that:
gdb /path/to/vdr `pidof vdr`
At the gdb prompt, issue the following command:
thread apply all bt
and provide the output.
but with my buffer overflow problem the vdr is working without any deadlock. I can such messages only in syslog. That's why I can't do backtrace
Goga
On Tue, Feb 23, 2010 at 10:49 AM, Josce Josce@welho.com wrote:
localhost vdr: [2626] buffer usage: 70% (tid=2625) localhost vdr: [2626] buffer usage: 80% (tid=2625) localhost vdr: [2626] buffer usage: 90% (tid=2625) localhost vdr: [2626] buffer usage: 100% (tid=2625) localhost vdr: [2626] ERROR: driver buffer overflow on device 1 localhost vdr: [2626] ERROR: driver buffer overflow on device 1 (repeated over and over again)
I have experienced this problem as well. However, I thought xine-lib was the culprit. I don't recall seeing it after updating my xine-lib however so you may want to try that. I've been using xine-lib-1.2 revision 11427.
On 24.2.2010 20:05, VDR User wrote:
On Tue, Feb 23, 2010 at 10:49 AM, JosceJosce@welho.com wrote:
localhost vdr: [2626] buffer usage: 70% (tid=2625) localhost vdr: [2626] buffer usage: 80% (tid=2625) localhost vdr: [2626] buffer usage: 90% (tid=2625) localhost vdr: [2626] buffer usage: 100% (tid=2625) localhost vdr: [2626] ERROR: driver buffer overflow on device 1 localhost vdr: [2626] ERROR: driver buffer overflow on device 1 (repeated over and over again)
I have experienced this problem as well. However, I thought xine-lib was the culprit. I don't recall seeing it after updating my xine-lib however so you may want to try that. I've been using xine-lib-1.2 revision 11427.
I don't use xine-lib, so that can't be it.
Josce
-
Christopher Reimer -
Falk Spitzberg -
Goga777 -
Joerg Bornkessel -
Josce -
Klaus Schmidinger -
Reinhard Nissl -
Torgeir Veimo -
VDR User