Marko Mäkelä schrieb: > I got another hang today. I don't know the circumstances, since I was not > there when the hang occurred. But I think it was caused by a decoding > error or by suspending and resuming vdr (using my patch), as the log > ended with this: > > [dfb] (re)configured 0x00200806 > [dfb] (re)configuring Videolayer to 720 x 576 (720x576) > [dfb] creating new surface (stretchBlit) > [surface capabilities] videoSurface: videoonly interlaced PixelFormat = > 0x00200806 > [dfb] (re)configured 0x00200806 > [dfb] (re)configuring Videolayer to 704 x 576 (704x576) > [dfb] creating new surface (stretchBlit) > [surface capabilities] videoSurface: videoonly interlaced PixelFormat = > 0x00200806 > [dfb] (re)configured 0x00200806 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 17 20 > [mpeg2video @ 0xa7af58a8]00 motion_type at 4 18 > [mpeg2video @ 0xa7af58a8]invalid mb type in P Frame at 13 19 > [mpeg2video @ 0xa7af58a8]00 motion_type at 1 20 > [mpeg2video @ 0xa7af58a8]00 motion_type at 5 21 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 3 22 > [mpeg2video @ 0xa7af58a8]invalid cbp at 25 23 > [mpeg2video @ 0xa7af58a8]00 motion_type at 7 24 > [mpeg2video @ 0xa7af58a8]00 motion_type at 3 25 > [mpeg2video @ 0xa7af58a8]00 motion_type at 1 26 > [mpeg2video @ 0xa7af58a8]00 motion_type at 1 27 > [mpeg2video @ 0xa7af58a8]00 motion_type at 14 29 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 29 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 30 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 31 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 32 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 33 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 34 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 35 > [mpeg2video @ 0xa7af58a8]Warning MVs not available > [mpeg2video @ 0xa7af58a8]concealing 792 DC, 792 AC, 792 MV errors > +++[mpeg2video @ 0xa7af58a8]ac-tex damaged at 39 15 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 1 15 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 16 > [mpeg2video @ 0xa7af58a8]invalid mb type in I Frame at 0 17 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 18 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 19 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 20 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 21 > [mpeg2video @ 0xa7af58a8]invalid mb type in I Frame at 0 22 > [mpeg2video @ 0xa7af58a8]skipped MB in I frame at 1 23 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 24 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 25 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 26 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 27 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 1 28 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 29 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 30 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 31 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 32 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 33 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 34 > [mpeg2video @ 0xa7af58a8]ac-tex damaged at 0 35 > [mpeg2video @ 0xa7af58a8]Warning MVs not available > [mpeg2video @ 0xa7af58a8]concealing 924 DC, 924 AC, 924 MV errors > *hang* > > By the way, it could be useful to have timestamps in the log entries, > or to log via syslog. > > Attached are the full stack traces of the two running vdr processes. > The gdb-637 stack trace looks perfectly normal. The video decoder thread waits for displaying a picture, the audio decoder thread is in some alsa routine waiting to put more sound data into the alsa buffer. That means both audio and video data are available, which means that both threads are running. If one of them would have been deadlocked, the other one would continue to consume data until the buffers are full because the other thread doesn't consume any data. Then the not locked thread would have starved... But maybe that argumentation is wrong. Sorry I didn't get new ideas from that backtrace...
The other backtrace is a vdr which is stuck somewhere during the initialization, probably because the it could not open the alsa device. The only strange thing is why it didn't die... Maybe there is something wrong with alsa or the softdevice -> alsa communication? > Software: > > vdr 1.4.2 > ffmpeg CVS from months ago > DirectFB CVS from weeks ago > softdevice CVS from 2006-09-22, plus dfb-blbar-clear-03.patch and the I assume this contains the fixes by Stefan on 09-22? And the dfb-blbar-clear-03.patch is the one without osdMutex, okay. Laz, how do you suspend your vdr? Do you use Marko's patch or the softdevice suspend method? Bye, Martin _______________________________________________ Softdevice-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/softdevice-devel
