[mythtv] broken nuv file

[Eric Bosch]

I had similar problem a few days ago, and it was due to broken hotplug
in HAL. After a couple new revs of HAL, they at working again.  I don't
know what distribution you use, I use Gentoo.
Torbjörn Jansson wrote:
> Replying to myself, I think I've found the source of the problems and it's
> probably not mythtvs fault.
> 
> Its most likely nfs related as I'm getting:
> NFS: Server wrote zero bytes, expected 4096.
>>From the kernel.
> 
> Going to update kernel and see if that fixes the problem, existing fedora
> bug report suggests it may fix the problem.
> 
> Sorry for the noise, just replying in case someone else runs into this
> problem.
> 
>> -----Original Message-----
>> From: Torbjörn Jansson [mailto:torbjorn.jansson at mbox200.swipnet.se]
>> Sent: Friday, July 17, 2009 11:02 PM
>> To: 'mythtv-dev at mythtv.org'
>> 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 card.
>>
>> First thing I noticed was that when playing the recording on the frontend
>> seeking didn’t work.
>> Any kind of seeking resulted in playback stopping.
>>
>> After some analyzing of the resulting nuv file i think I've found out what
>> 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 not
> point
>> 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
> a
>> 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 the
>> seektable.
>>
>>
>> I'm no expert of the mythtv source so I have no idea where to begin
> looking
>> for the bug.
>> What I do know is that the setup I have have worked fine until recently
> and
>> 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 so
>> would be nice to avoid it :)
>>
>> So far I've only seen this once but i think the current one may have
> similar
>> problems, master backend crashed shortly after slave backend started the
>> recording.
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>