Hello!
When I switch from an encrypted channel from my DVB-S (Nexus-S rev. 2.1) to DVB-T Airstar2 vdr crashes almost every time but if I go from a free to air channel it is no problem. If vdr does not crash it goes to the first channel in channel.conf.
The channel I choose shows up and freezes for a short while (less than a second) after about a second and then it goes on for another 10 seconds as it should and then it dies or goes to the first channel.
softcam 0: switched to FTA softcam 0: setting new SID 1090, source c000, transponder 1da
DVB-T to DVB-S always works.
There is no problem with this if I use vdr-xine plugin instead. NO other changes.
I tried to remove plugins and saw that if I removed osdteletext and ttxtsubs the problem is gone. My family needs subtitle for moviechannels and animal planet, discovey. I really want to use my FF card instead of using softdevice because it is easier for me to use the computer while the other watch tv.
I am almost ready to give up and I have tried vdr 1.3.18-27 and 3 different hotplug firmwares under gentoo linux and kernel 2.6.10-12.
Today I learned a new thing and if I start a recording on an encrypted DVB-S channel before switching to a DVB-T channel it worked. :)
Both osdteletext and ttxtsubs uses teletext PID in some way I supose. Is this the problem together with FF card?
Please help!!
/Magnus
Magnus Andersson wrote:
When I switch from an encrypted channel from my DVB-S (Nexus-S rev. 2.1) to DVB-T Airstar2 vdr crashes almost every time but if I go from a free to air channel it is no problem.
This surely is a tricky bug. I too have a primary full-featured and a secondary budget card (not DVB-T though), and there are cases in which I switch from primary to secondary-transfermode, and I never had problems crashing. And yes, osdteletext is installed.
Try to generate a stack trace on crash. Some easy steps how to do this are on http://linux.bytesex.org/gdb.html This may give a hint why VDR crashes in that very special situation.
Cheers,
Udo
Thank you for the answer Udo but I do not understand a stacktrace.
I did not manage to get it crash with only osdteletext but it changed channel to the first one ten times in a row. After I used ttxtsub it crashed the first time.
gdb vdr core.12345
bt for stacktrace result:
Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5-20050130/libstdc++.so.5...done. Loaded symbols for /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5-20050130/libstdc++.so.5 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5-20050130/libgcc_s.so.1...done. Loaded symbols for /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5-20050130/libgcc_s.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/local/src/VDR/PLUGINS/lib/libvdr-sc.so.1.3.25...done. Loaded symbols for ./PLUGINS/lib/libvdr-sc.so.1.3.25 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libz.so.1...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /usr/lib/libcrypto.so.0.9.7...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.7 Reading symbols from /usr/local/src/VDR/PLUGINS/lib/libvdr-osdteletext.so.1.3.25...done. Loaded symbols for ./PLUGINS/lib/libvdr-osdteletext.so.1.3.25 Reading symbols from /usr/local/src/VDR/PLUGINS/lib/libvdr-ttxtsubs.so.1.3.25...done. Loaded symbols for ./PLUGINS/lib/libvdr-ttxtsubs.so.1.3.25 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 #0 0xb7cd63d1 in kill () from /lib/libc.so.6 (gdb) bt #0 0xb7cd63d1 in kill () from /lib/libc.so.6 #1 0xb7eb6091 in pthread_kill () from /lib/libpthread.so.0 #2 0xb7eb646b in raise () from /lib/libpthread.so.0 #3 0xb7cd6164 in raise () from /lib/libc.so.6 #4 0xb7cd763d in abort () from /lib/libc.so.6 #5 0xb7d11f40 in mallopt () from /lib/libc.so.6 #6 0xb7d10bc9 in mallopt () from /lib/libc.so.6 #7 0xb7d0f8bf in free () from /lib/libc.so.6 #8 0x080d1dd8 in ~cTS2PES (this=0x3a1a) at remux.c:488 #9 0x080d2f25 in ~cRemux (this=0x83962d0) at remux.c:868 #10 0x080f0b4c in ~cTransfer (this=0x837afd0) at transfer.c:33 #11 0x080f125f in ~cTransferControl (this=0x83804a8) at transfer.c:165 #12 0x080c7cdd in cControl::Launch (Control=0x0) at player.c:66 #13 0x0809155d in cDevice::SetChannel (this=0x836d620, Channel=0x81d37e0, LiveView=true) at channels.h:150 #14 0x0809120b in cDevice::SwitchChannel (this=0x836d620, Channel=0x81d37e0, LiveView=true) at device.c:516 #15 0xb7c96efb in cCam::Process (this=0x83a8db8, filter=0x83a4da0, data=0x2 <Address 0x2 out of bounds>, len=84) at cam.c:439 #16 0xb7c94de7 in cAction::Action (this=0x83a8db8) at filter.c:285 #17 0x080ea2be in cThread::StartThread (Thread=0x83a8db8) at thread.c:233 #18 0xb7eb316b in pthread_start_thread () from /lib/libpthread.so.0 #19 0xb7d62a6a in clone () from /lib/libc.so.6 (gdb) #0 0xb7cd63d1 in kill () from /lib/libc.so.6 #1 0xb7eb6091 in pthread_kill () from /lib/libpthread.so.0 #2 0xb7eb646b in raise () from /lib/libpthread.so.0 #3 0xb7cd6164 in raise () from /lib/libc.so.6 #4 0xb7cd763d in abort () from /lib/libc.so.6 #5 0xb7d11f40 in mallopt () from /lib/libc.so.6 #6 0xb7d10bc9 in mallopt () from /lib/libc.so.6 #7 0xb7d0f8bf in free () from /lib/libc.so.6 #8 0x080d1dd8 in ~cTS2PES (this=0x3a1a) at remux.c:488 #9 0x080d2f25 in ~cRemux (this=0x83962d0) at remux.c:868 #10 0x080f0b4c in ~cTransfer (this=0x837afd0) at transfer.c:33 #11 0x080f125f in ~cTransferControl (this=0x83804a8) at transfer.c:165 #12 0x080c7cdd in cControl::Launch (Control=0x0) at player.c:66 #13 0x0809155d in cDevice::SetChannel (this=0x836d620, Channel=0x81d37e0, LiveView=true) at channels.h:150 #14 0x0809120b in cDevice::SwitchChannel (this=0x836d620, Channel=0x81d37e0, LiveView=true) at device.c:516 #15 0xb7c96efb in cCam::Process (this=0x83a8db8, filter=0x83a4da0, data=0x2 <Address 0x2 out of bounds>, len=84) at cam.c:439 #16 0xb7c94de7 in cAction::Action (this=0x83a8db8) at filter.c:285 #17 0x080ea2be in cThread::StartThread (Thread=0x83a8db8) at thread.c:233 #18 0xb7eb316b in pthread_start_thread () from /lib/libpthread.so.0 #19 0xb7d62a6a in clone () from /lib/libc.so.6 (gdb) bt #0 0xb7cd63d1 in kill () from /lib/libc.so.6 #1 0xb7eb6091 in pthread_kill () from /lib/libpthread.so.0 #2 0xb7eb646b in raise () from /lib/libpthread.so.0 #3 0xb7cd6164 in raise () from /lib/libc.so.6 #4 0xb7cd763d in abort () from /lib/libc.so.6 #5 0xb7d11f40 in mallopt () from /lib/libc.so.6 #6 0xb7d10bc9 in mallopt () from /lib/libc.so.6 #7 0xb7d0f8bf in free () from /lib/libc.so.6 #8 0x080d1dd8 in ~cTS2PES (this=0x3a1a) at remux.c:488 #9 0x080d2f25 in ~cRemux (this=0x83962d0) at remux.c:868 #10 0x080f0b4c in ~cTransfer (this=0x837afd0) at transfer.c:33 #11 0x080f125f in ~cTransferControl (this=0x83804a8) at transfer.c:165 #12 0x080c7cdd in cControl::Launch (Control=0x0) at player.c:66 #13 0x0809155d in cDevice::SetChannel (this=0x836d620, Channel=0x81d37e0, LiveView=true) at channels.h:150 #14 0x0809120b in cDevice::SwitchChannel (this=0x836d620, Channel=0x81d37e0, LiveView=true) at device.c:516 #15 0xb7c96efb in cCam::Process (this=0x83a8db8, filter=0x83a4da0, data=0x2 <Address 0x2 out of bounds>, len=84) at cam.c:439 #16 0xb7c94de7 in cAction::Action (this=0x83a8db8) at filter.c:285 #17 0x080ea2be in cThread::StartThread (Thread=0x83a8db8) at thread.c:233 #18 0xb7eb316b in pthread_start_thread () from /lib/libpthread.so.0 #19 0xb7d62a6a in clone () from /lib/libc.so.6 (gdb) bt #0 0xb7cd63d1 in kill () from /lib/libc.so.6 #1 0xb7eb6091 in pthread_kill () from /lib/libpthread.so.0 #2 0xb7eb646b in raise () from /lib/libpthread.so.0 #3 0xb7cd6164 in raise () from /lib/libc.so.6 #4 0xb7cd763d in abort () from /lib/libc.so.6 #5 0xb7d11f40 in mallopt () from /lib/libc.so.6 #6 0xb7d10bc9 in mallopt () from /lib/libc.so.6 #7 0xb7d0f8bf in free () from /lib/libc.so.6 #8 0x080d1dd8 in ~cTS2PES (this=0x3a1a) at remux.c:488 #9 0x080d2f25 in ~cRemux (this=0x83962d0) at remux.c:868 #10 0x080f0b4c in ~cTransfer (this=0x837afd0) at transfer.c:33 #11 0x080f125f in ~cTransferControl (this=0x83804a8) at transfer.c:165 #12 0x080c7cdd in cControl::Launch (Control=0x0) at player.c:66 #13 0x0809155d in cDevice::SetChannel (this=0x836d620, Channel=0x81d37e0, LiveView=true) at channels.h:150 #14 0x0809120b in cDevice::SwitchChannel (this=0x836d620, Channel=0x81d37e0, LiveView=true) at device.c:516 #15 0xb7c96efb in cCam::Process (this=0x83a8db8, filter=0x83a4da0, data=0x2 <Address 0x2 out of bounds>, len=84) at cam.c:439 #16 0xb7c94de7 in cAction::Action (this=0x83a8db8) at filter.c:285 #17 0x080ea2be in cThread::StartThread (Thread=0x83a8db8) at thread.c:233 #18 0xb7eb316b in pthread_start_thread () from /lib/libpthread.so.0 #19 0xb7d62a6a in clone () from /lib/libc.so.6
Please take a look!
/Magnus
Magnus Andersson wrote:
When I switch from an encrypted channel from my DVB-S (Nexus-S rev. 2.1) to DVB-T Airstar2 vdr crashes almost every time but if I go from a free to air channel it is no problem.
This surely is a tricky bug. I too have a primary full-featured and a secondary budget card (not DVB-T though), and there are cases in which I switch from primary to secondary-transfermode, and I never had problems crashing. And yes, osdteletext is installed.
Try to generate a stack trace on crash. Some easy steps how to do this are on http://linux.bytesex.org/gdb.html This may give a hint why VDR crashes in that very special situation.
Cheers,
Udo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Magnus Andersson wrote:
Thank you for the answer Udo but I do not understand a stacktrace.
I did not manage to get it crash with only osdteletext but it changed channel to the first one ten times in a row. After I used ttxtsub it crashed the first time.
What VDR version did you use? Still the 1.3.18-27 you've mentioned? This sounds like some distri with LOTS of patches. And this:
#9 0x080d2f25 in ~cRemux (this=0x83962d0) at remux.c:868
... the original remux.c of 1.3.18 had only 641 lines...
To really understand the trace, we need the exact source code. If possible, try to update to a newer VDR version, as there were massive changes especially in remux.c where the crash seems to come from.
@All:
#7 0xb7d0f8bf in free () from /lib/libc.so.6 #8 0x080d1dd8 in ~cTS2PES (this=0x3a1a) at remux.c:488 #9 0x080d2f25 in ~cRemux (this=0x83962d0) at remux.c:868
this=0x3a1a looks rather short for a dynamic pointer, or? Maybe some pointer got corrupted in cRemux?
Cheers,
Udo
Magnus Andersson wrote:
Thank you for the answer Udo but I do not understand a stacktrace.
I did not manage to get it crash with only osdteletext but it changed channel to the first one ten times in a row. After I used ttxtsub it crashed the first time.
What VDR version did you use? Still the 1.3.18-27 you've mentioned? This sounds like some distri with LOTS of patches. And this:
#9 0x080d2f25 in ~cRemux (this=0x83962d0) at remux.c:868
... the original remux.c of 1.3.18 had only 641 lines...
Sorry I should have written 1.3.18 to 1.3.27 instead. There is a few patches applied to vdr and I reinstalled vdr with a minimum of patches that I need.
vdr-1.3.25 vdr-1.3.20-sc.diff subtitles-3.7-ttxtsub-0.0.5.diff ( changes remux.c )
To really understand the trace, we need the exact source code. If possible, try to update to a newer VDR version, as there were massive changes especially in remux.c where the crash seems to come from.
@All:
#7 0xb7d0f8bf in free () from /lib/libc.so.6 #8 0x080d1dd8 in ~cTS2PES (this=0x3a1a) at remux.c:488 #9 0x080d2f25 in ~cRemux (this=0x83962d0) at remux.c:868
this=0x3a1a looks rather short for a dynamic pointer, or? Maybe some pointer got corrupted in cRemux?
I think I found the problem but no solution. If I move my subscription card (DVB-S) from the cardserver and use it on localhost with a cardreader the problem is gone. The problem seems to be cardclient implemetation with sc plugin. Strange that it works with vdr-xine plugin. No problem with FF card without osdteletext and ttxtsubs. Most of the time it changes to an FTA channel and in that case I will not recieve a core dump. I am not an gdb expert and I don't know how to debug when it stays alive. When vdr is using encrypted channel on dvb-s and a scheduled recording on dvb-t starts it changes to first channle (FTA) and no recording is beeing made.
Thank you for your help Udo!
Cheers,
Udo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Magnus Andersson wrote:
Sorry I should have written 1.3.18 to 1.3.27 instead. There is a few patches applied to vdr and I reinstalled vdr with a minimum of patches that I need.
vdr-1.3.25 vdr-1.3.20-sc.diff subtitles-3.7-ttxtsub-0.0.5.diff ( changes remux.c )
Ok, now I have a source file that seems to match. And the subtitles-patch does modify some code around the area where the crash happens. cTS2PES (backtrace #8) and cRemux (backtrace #9) behave differently with this patch.
These are the two code fragments that appear in the backtrace:
cTS2PES::~cTS2PES() { if (tsErrors || ccErrors) dsyslog("cTS2PES got %d TS errors, %d TS continuity errors", tsErrors, ccErrors); --> free(buf); delete repacker; }
cRemux::~cRemux() { for (int t = 0; t < numTracks; t++) delete ts2pes[t]; delete resultBuffer; -->}
Try running without the subtitles-patch and check whether this has an influence or not.
Cheers,
Udo
vdr-1.3.25 vdr-1.3.20-sc.diff subtitles-3.7-ttxtsub-0.0.5.diff ( changes remux.c )
Ok, now I have a source file that seems to match. And the subtitles-patch does modify some code around the area where the crash happens. cTS2PES (backtrace #8) and cRemux (backtrace #9) behave differently with this patch.
These are the two code fragments that appear in the backtrace:
cTS2PES::~cTS2PES() { if (tsErrors || ccErrors) dsyslog("cTS2PES got %d TS errors, %d TS continuity errors", tsErrors, ccErrors); --> free(buf); delete repacker; }
cRemux::~cRemux() { for (int t = 0; t < numTracks; t++) delete ts2pes[t]; delete resultBuffer; -->}
I think you are right "TS continuity errors" it can explain why hardware encoder is more sensetive than vdr-xine. VDR should be more stable if there is a short stop in mpeg stream or channel keys. Sometimes when I use vdr-xine and switch to DVB-T channel FTA or pay channels after 1/10 sek No signal picture that comes whith vdr-xine show up for a short while and then it continues. If I do the sam thing with FF it can freeze for a short while instead of No signal picure and after about 10 sek.... crash or change channel to 1.
Here is a NEW crash with osdteletext only. I removed the ttxsubs patch but I had to patch with vdr-1.3.1-softcsa-0.0.8.diff also my family wanted to watch tv but it does not touch remux.c. :-)
I do not understand why it crashes because the new channel (DVB-T) start ok but after about 10 sek it crash or change to FTA channel one. As I said before if I connect DVB-S card locally it works which is strange because that data is not interesting any more except if I record a DVB-S channel. If I record a DVB-S it works without problems.
Core was generated by `./vdr -D 0 -D 1 -P sc -P osdteletext'. Program terminated with signal 6, Aborted.
warning: current_sos: Can't read pathname for load map: Input/output error
Reading symbols from /usr/lib/libjpeg.so.62...done. Loaded symbols for /usr/lib/libjpeg.so.62 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5-20050130/libstdc++.so.5...done. Loaded symbols for /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5-20050130/libstdc++.so.5 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5-20050130/libgcc_s.so.1...done. Loaded symbols for /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5-20050130/libgcc_s.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/local/src/VDR/PLUGINS/lib/libvdr-sc.so.1.3.25...done. Loaded symbols for ./PLUGINS/lib/libvdr-sc.so.1.3.25 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libz.so.1...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /usr/lib/libcrypto.so.0.9.7...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.7 Reading symbols from /usr/local/src/VDR/PLUGINS/lib/libvdr-osdteletext.so.1.3.25...done. Loaded symbols for ./PLUGINS/lib/libvdr-osdteletext.so.1.3.25 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 #0 0xb7d443d1 in kill () from /lib/libc.so.6 (gdb) bt #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 #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 #11 0xb7b89820 in cTxtStatus::CheckDeleteReceiver () from ./PLUGINS/lib/libvdr-osdteletext.so.1.3.25 #12 0xb7b894c8 in cTxtStatus::ChannelSwitch () from ./PLUGINS/lib/libvdr-osdteletext.so.1.3.25 #13 0x080e0763 in cStatus::MsgChannelSwitch (Device=0x8524338, ChannelNumber=0) at status.c:29 #14 0x0808fc49 in cDevice::SetChannel (this=0x8524338, Channel=0x81caec8, ---Type <return> to continue, or q <return> to quit--- LiveView=true) at device.c:576 #15 0x0808f95b in cDevice::SwitchChannel (this=0x8524338, Channel=0x81caec8, LiveView=true) at device.c:516 #16 0xb7cfbeb3 in cCam::Process (this=0x85313a0, filter=0x85315e0, data=0x2 <Address 0x2 out of bounds>, len=78) at cam.c:439 #17 0xb7cf9d9f in cAction::Action (this=0x85313a0) at filter.c:285 #18 0x080e5f46 in cThread::StartThread (Thread=0x85313a0) at thread.c:233 #19 0xb7f2116b in pthread_start_thread () from /lib/libpthread.so.0 #20 0xb7dd0a6a in clone () from /lib/libc.so.6
Try running without the subtitles-patch and check whether this has an influence or not.
See above!
Here is /var/log/messages
Jul 4 21:17:06 vdr vdr[9202]: switching to channel 18 Jul 4 21:17:06 vdr vdr[9867]: TS buffer on device 1 thread ended (pid=9867, tid =1851404) Jul 4 21:17:06 vdr vdr[9866]: buffer stats: 2256 (0%) used Jul 4 21:17:06 vdr vdr[9866]: receiver on device 1 thread ended (pid=9866, tid= 1835019) Jul 4 21:17:06 vdr vdr[9202]: buffer stats: 0 (0%) used Jul 4 21:17:07 vdr vdr[9872]: transfer thread started (pid=9872, tid=1933324) Jul 4 21:17:07 vdr vdr[9873]: receiver on device 2 thread started (pid=9873, ti d=1949709) Jul 4 21:17:07 vdr vdr[9875]: TS buffer on device 2 thread started (pid=9875, t id=1982480) Jul 4 21:17:08 vdr vdr[9872]: setting audio track to 1 Jul 4 21:17:22 vdr vdr[9766]: switching to channel 1 Jul 4 21:17:22 vdr vdr[9872]: transfer thread ended (pid=9872, tid=1933324) Jul 4 21:17:22 vdr vdr[9766]: buffer stats: 40984 (1%) used Jul 4 21:17:22 vdr vdr[9875]: TS buffer on device 2 thread ended (pid=9875, tid =1982480) Jul 4 21:17:22 vdr vdr[9873]: buffer stats: 37600 (1%) used Jul 4 21:17:22 vdr vdr[9873]: receiver on device 2 thread ended (pid=9873, tid= 1949709) Jul 4 21:17:22 vdr vdr[9202]: switching to channel 18 Jul 4 21:17:22 vdr vdr[9202]: buffer stats: 0 (0%) used Jul 4 21:17:22 vdr 0.7.0[7792]: removed client Jul 4 21:20:01 vdr cron[9885]: (root) CMD (test -x /usr/sbin/run-crons && /usr/ sbin/run-crons )
Thanks again!
/Magnus
Cheers,
Udo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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
-
Magnus Andersson -
Udo Richter