Magnus Andersson wrote: > I think you are right "TS continuity errors" it can explain why hardware > encoder is more sensetive than vdr-xine. Note that the "TS continuity error" message is just above the crash position and has probably not been triggered at all. > #0 0xb7d443d1 in kill () from /lib/libc.so.6 > #1 0xb7f24091 in pthread_kill () from /lib/libpthread.so.0 > #2 0xb7f2446b in raise () from /lib/libpthread.so.0 > #3 0xb7d44164 in raise () from /lib/libc.so.6 > #4 0xb7d4563d in abort () from /lib/libc.so.6 > #5 0xb7eeed67 in __cxa_call_unexpected () > from /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5-20050130/libstdc++.so.5 > #6 0xb7eeeda4 in std::terminate () > from /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5-20050130/libstdc++.so.5 > #7 0xb7eef2c8 in __cxa_pure_virtual () > from /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5-20050130/libstdc++.so.5 VDR was killed by purpose, and it looks like a pure virtual function call caused an unhandled exception. Pure virtual function calls often occur if a virtual function is called while the destructor of the object is running or after it has been running. With threading, such things easily happen. (but I remember such things just dropping a message...) > #8 0x080cfa07 in cRingBuffer::EnableGet (this=0x855c070) at ringbuffer.c:77 > #9 0xb7b8a701 in cRingTxtFrames::Signal () > from ./PLUGINS/lib/libvdr-osdteletext.so.1.3.25 > #10 0xb7b89de3 in cTxtReceiver::~cTxtReceiver () > from ./PLUGINS/lib/libvdr-osdteletext.so.1.3.25 osdteletext is just detaching from the video stream, waiting for the receive processing thread to terminate. No clue why this causes problems. All involved virtual functions are still valid. In both cases, the crash involves destructors, so its probably caused by the receive process that ended. Maybe some part of the old channel receive process doesnt end as it should, and sends data into the wild after the processing chain is already gone. Dont know. Cheers, Udo
