No subject

Wed Jun 24 15:02:31 UTC 2009

Going to update kernel and see if that fixes the problem, existing =
bug report suggests it may fix the problem.

Sorry for the noise, just replying in case someone else runs into this

> -----Original Message-----
> From: Torbj=F6rn Jansson [mailto:torbjorn.jansson at]
> Sent: Friday, July 17, 2009 11:02 PM
> To: 'mythtv-dev at'
> Subject: broken nuv file
> Hello all.
> I've run into something odd with one of my recordings.
> This is on 0.21-fixes branch and a recording done on an old analog =
> First thing I noticed was that when playing the recording on the =
> seeking didn=92t work.
> Any kind of seeking resulted in playback stopping.
> After some analyzing of the resulting nuv file i think I've found out =
> have happened to the file or atleast part of it.
> First problem:
> The offset to the seektable stored at the beginning of the file does =
> to the right place (offset should be larger by about 68705 bytes)
> This in itself is bad.
> After some more analyzing of the file I found the cause.
> 2 extra video frames (or packets, header + data) have sneaked in and =
it is
> repeat of the 2 previous video frame/packet.
> There is also some repeated audio frames in there.
> The amount of extra data matches exactly the error in the offset to =
> seektable.
> I'm no expert of the mythtv source so I have no idea where to begin
> for the bug.
> What I do know is that the setup I have have worked fine until =
> the only difference now is that the backend have a little more load
because of
> other software including disk io.
> (same for the nfs server where the recordings get saved to)
> Any idea what caused that extra data to sneak in?
> I had to manually fix this file and it's a little complicated to do it =
> would be nice to avoid it :)
> So far I've only seen this once but i think the current one may have
> problems, master backend crashed shortly after slave backend started =
> recording.

More information about the mythtv-dev mailing list