Hi,
we*) notice a seqfault of cutting Thread on "Low disk space!", if OSD used during cutting process.
i think, reason is a call of a OSD function from background cutting thread.
I tested only on 1.3.32, but 1.3.37 should also affected
(gdb) thread 5 [Switching to thread 5 (process 4733)]#0 0xb7e68114 in ioctl () from /lib/tls/libc.so.6 (gdb) bt #0 0xb7e68114 in ioctl () from /lib/tls/libc.so.6 #1 0x080aa202 in cDvbOsd::Cmd (this=0x8c9e710, cmd=OSD_Clear, color=0, x0=0, y0=0, x1=0, y1=0, data=0x0) at dvbosd.c:110 #2 0x080a9c13 in cDvbOsd (this=0x8c9e710, Left=54, Top=504, OsdDev=5) at dvbosd.c:63 #3 0x080aa816 in cDvbOsdProvider::CreateOsd (this=0x8c81930, Left=54, Top=504) at dvbosd.c:183 #4 0x080e4854 in cOsdProvider::NewOsd (Left=54, Top=504) at osd.c:738 #5 0x08110911 in cSkinSTTNGDisplayMessage (this=0x8c95570) at skinsttng.c:1052 #6 0x08111100 in cSkinSTTNG::DisplayMessage (this=0x8c819f0) at skinsttng.c:1117 #7 0x0810509e in cSkins::Message (this=0x81f73e4, Type=mtWarning, s=0x8143f3f "Platte beinahe voll!", Seconds=30) at skins.c:179 #8 0x080bb3d4 in cInterface::Confirm (this=0x8c818c0, s=0x8143f3f "Platte beinahe voll!", Seconds=30, WaitForTimeout=false) at interface.c:71 #9 0x080ece45 in AssertFreeDiskSpace (Priority=-1) at recording.c:147 #10 0x0809d62f in cCuttingThread::Action (this=0x8c92528) at cutter.c:86 #11 0x0811b716 in cThread::StartThread (Thread=0x8c92528) at thread.c:234 #12 0xb7fb8b63 in start_thread () from /lib/tls/libpthread.so.0 #13 0xb7e6f18a in clone () from /lib/tls/libc.so.6
Here a possibly solution :
--- recording.c.org 2005-09-11 17:52:31.000000000 +0200 +++ recording.c 2005-12-07 21:33:18.000000000 +0100 @@ -144,7 +144,7 @@ } // Unable to free disk space, but there's nothing we can do about that... isyslog("...no old recording found, giving up"); - Interface->Confirm(tr("Low disk space!"), 30); + Skins.QueueMessage(mtWarning, tr("Low disk space!"), 30); } LastFreeDiskCheck = time(NULL); }
*) I'm not the original bug reporter, but i could this seqfault reproduce http://www.vdr-portal.de/board/thread.php?threadid=42375&sid=
Cu, Andreas
Andreas Brachold wrote:
Hi,
we*) notice a seqfault of cutting Thread on "Low disk space!", if OSD used during cutting process.
i think, reason is a call of a OSD function from background cutting thread.
I tested only on 1.3.32, but 1.3.37 should also affected
(gdb) thread 5 ...
Here a possibly solution :
--- recording.c.org 2005-09-11 17:52:31.000000000 +0200 +++ recording.c 2005-12-07 21:33:18.000000000 +0100 @@ -144,7 +144,7 @@ } // Unable to free disk space, but there's nothing we can do about that... isyslog("...no old recording found, giving up");
Interface->Confirm(tr("Low disk space!"), 30);
Skins.QueueMessage(mtWarning, tr("Low disk space!"), 30); } LastFreeDiskCheck = time(NULL); }
You're absolutely right - calling Interface->Confirm() from a thread is a no-no. Silly me, telling others not to do this, while doing it myself...
Thanks for the fix.
*) I'm not the original bug reporter, but i could this seqfault reproduce http://www.vdr-portal.de/board/thread.php?threadid=42375&sid=
Cu, Andreas
But I take it that you have suggested this fix, right? If not, please tell the one who did to come forward so that he can be given credit in the VDR/CONTRIBUTORS file.
Klaus
Hallo Klaus,
ich glaube einen Bug gefunden zu haben, ich habe eine kanallliste von ca. 550 Einträgen. Wenn ich einen Kanal markiere (an pos 489) und dann sehr schnell zum Anfang blättere bleibt der vdr stehen und verbraucht 100% cpu. Leider treten keine Einträge im Log auf.
cu xpix
On Donnerstag 08 Dezember 2005 13:38, Frank Herrmann wrote:
ich habe eine kanallliste von ca. 550 Einträgen. Wenn ich einen Kanal markiere (an pos 489) und dann sehr schnell zum Anfang blättere bleibt der vdr stehen und verbraucht 100% cpu.
passiert das nur dann, wenn Du gerade ZDF oder Pro7 oder Sat1 empfängst? Mit anderen Worten wenn der Transfer modus aktiv ist?
Dann würde ich eine aktuelle Firmware versuchen.
On Thu, Dec 08, 2005 at 03:54:07PM +0100, Thomas Rausch wrote:
Wolfgang Rohdewald schrieb:
Dann würde ich eine aktuelle Firmware versuchen.
Hatte das Problem auch. Die FW-2622 war die Lösung. Kein Transfermodus mehr notwendig (und schnelles OSD). :-)
Nevertheless ... IMHO the bug exist even with new firmware and ... maybe for parallel recordings ... it should be fixed :)
Werner
Dr. Werner Fink schrieb:
On Thu, Dec 08, 2005 at 03:54:07PM +0100, Thomas Rausch wrote:
Wolfgang Rohdewald schrieb:
Dann würde ich eine aktuelle Firmware versuchen.
Hatte das Problem auch. Die FW-2622 war die Lösung. Kein Transfermodus mehr notwendig (und schnelles OSD). :-)
Nevertheless ... IMHO the bug exist even with new firmware and ... maybe for parallel recordings ... it should be fixed :)
Ok, but I has no more problems. I draw Sat.1, ZDF and a radiosender on (3 different transponders at the same time). I switch then to Pro7 and let me the channel list indicate. Then I mark a channel and leaf then as wild from beginning to end and back and so on (1965 transmitters). No crash. :)
Hello and sorry for my mistake!
I have read a mail from Klaus and push button 'Reply' ;) I forget, this is a mail from the mailinglist.
Ok, i recreate the Question in english and in a new thread.
--------------
I have a channellist with more as 500 entrys, If i mark a channel at position and then jump from page to page very fast with the right or left button. Then vdr is freeze with more as 95% cpu and i must restart my vdr.
Wolfgang Rohdewald wrote:
passiert das nur dann, wenn Du gerade ZDF oder Pro7 oder Sat1 empfängst? Mit anderen Worten wenn der Transfer modus aktiv ist?
No, i looked in this moment the Phoenix channel.