[mythtv] Frontend dying on aspect ratio change
christianh at edmi.com.au
Thu Apr 8 08:34:09 EDT 2004
I played it at least 5 times in a row on my machine with no issues
whatsoever. I just fudged an entry in my DB and created an appropriately
fudged filename. This is what I saw in my logs:
Input #0, mpeg, from
Stream #0.0: Video: mpeg2video, 704x576, 25.00 fps
Stream #0.1: Audio: mp2, 48000 Hz, stereo, 192 kb/s
2004-04-08 22:28:36 Opening OSS audio device '/dev/dsp'.
2004-04-08 22:28:36 Audio fragment size: 4096
2004-04-08 22:28:36 Using XV port 103
2004-04-08 22:28:36 Changing from None to WatchingPreRecorded
2004-04-08 22:28:49 prebuffering pause
2004-04-08 22:28:49 GetNextFreeFrame() served a busy frame. Dropping.
[mpeg2video @ 0x406a45b4]ac-tex damaged at 28 3
[mpeg2video @ 0x406a45b4]concealing errors
[mpeg2video @ 0x406a45b4]Warning MVs not available
The "Unknown conversion ... GetNextFreeFrame" bit occurs during the blank
between the channel promo and the show i.e. when the aspect ratio changes.
The last 3 corruption lines appear to be just due to you cutting up the
For the record, I am running CVS from about Apr 4 17:50 (GMT+10). I
exclusively use DVB-T but we don't have aspect ratio changes at all here in
Australia. They just broadcast 4:3 recorded programs inside a 16:9 frame
forcing me to use the zoom function, which is no problem in reality.
It played over and over in the preview screen with no problems.
It also played using the Windows filters with no problems.
What else could I do to break it?
----- Original Message -----
From: "Ed Wildgoose" <lists at wildgooses.com>
To: "Development of mythtv" <mythtv-dev at mythtv.org>
Sent: Thursday, April 08, 2004 9:38 PM
Subject: Re: [mythtv] Frontend dying on aspect ratio change
> Could someone please at least download the file and let me know if they
> can get a good backtrace from it?
> I updated my threads library to NPTL and rebuild a few things, but I'm
> still having problems getting a bt. At least now it does segfault every
> time though...
> I think this is also related to the problem reported on 17/3/03 by Jon
> Whitear, titled "Mythfrontend dies" - the link below does at least have
> a file which reliably reproduces the problem
> Ed W
> > The following snippet from one of my recordings *usually* kills the
> > frontend at the point the aspect ratio changes from 16:9 to 4:3 (just
> > as Friends starts)
> > http://www.wildgooses.com/downloads/duff.nuv (around 7Mb and FWIW:
> > it came from a dvb-t device)
> > I'm having difficulty debugging it though. It doesn't *always* die
> > for starters (but > 50% of the time it does). Also, gdb is acting
> > rather wierd for me, "thread apply all bt full" is just doing nothing
> > (although "bt full" still seems to do something) - I have tried
> > updating to gdb 6 and a newer 2.6.5 kernel, but no change..? I also
> > can't see how to get gdb to stop just before the app dies, and so I
> > can't see how to find out which line it is actually excuting on?
> > (It's not dying like a segfault would) Finally, whats with all the
> > Sig32 signals in the most recent cvs version? Is "handle SIG32 nostop"
> > the way everyone else supresses them?
> > As near as I can tell though, it's probably related to the "unknown
> > conversion" error messages coming back (which seem to be in the OSD
> > code), and the "GetNextFreeFrame() served a busy frame" messages.
> > However, these don't reliably turn up every time. Could it in fact be
> > a chunk of code which isn't handling SIG32 signals though (hence the
> > reason it doesn't happen everytime, bit of a race condition)?
> > Any help appreciated
> > Ed W
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
More information about the mythtv-dev