[mythtv-users] Just lost a recorded file due to mythtranscode "renaming error"

Jeffrey J. Kosowsky mythtv at kosowsky.org
Wed Jan 13 01:56:56 UTC 2010


Michael T. Dean wrote at about 14:30:56 -0500 on Tuesday, January 12, 2010:
 > On 01/12/2010 04:54 AM, Jeffrey J. Kosowsky wrote:
 > > mythbackend.log shows:
 > > 	2010-01-11 23:53:05.439 Transcoding /mnt/media/mythtv/mythtv-raw/2443_20091108103000.mpg done
 > > 	2010-01-11 23:53:05.494 mythtranscode: Error Renaming '/mnt/media/mythtv/mythtv-raw/2443_20091108103000.mpg.tmp' to '/mnt/media/mythtv/mythtv-raw/2443_20091108103000.nuv'
 > > 			eno: No such file or directory (2)
 > >
 > > Indeed the file is not there anymore though the entry is still fine in
 > > the mythconverg database.
 > >
 > > Admittedly I had started and stopped transcoding perhaps half a dozen
 > > times. Some in relatively rapid succession. I did this from 2
 > > different frontends (one is on the Linux backend server and the other
 > > is on a Windows laptop) and also from the mythweb interface. I also
 > > crashed the frontend a couple of times and restarted the mythbackend a
 > > couple of times during the transcoding interval -- but that is
 > > probably all a red herring.
 > 
 > If by, "red herring," you mean, "The type of unspecified procedure that 
 > results in a completely untested use case that /definitely/ caused the 
 > problem," I think you're exactly right.
 > 
 > There's no way to know from, "I did a bunch of things that weren't 
 > normal," exactly what went wrong.  My recommendation is to:

I know - I was just telling all in the name of full disclosure...

 > 
 > a) enable the mythtv-setup setting:
 > 
 > Save original files after transcoding (globally)
 > When set and the transcoder is active, the original files will be 
 > renamed to .old once the transcoding is complete.
 > 
 > b) make a backup copy of a recording (just in case)
 > 
 > c) do a transcode without all the circus tricks
 > 
 > and see if it works on your new system configuration.  If so, then 
 > unless you can find out which part of the procedure above caused the 
 > issue, it's probably not worth worrying about (because we can't fix an 
 > unidentified "bug").

It does work without the "circus tricks". Based on a couple of cases...

 > 
 > My best guess is that you experienced a problem caused by a race 
 > condition caused by running multiple transcodes on the same recording at 
 > the same time--as the transcode jobs don't die when you shut down 
 > mythbackend.  So, the one that had the good transcoded file finished and 
 > cleaned up stuff--including stuff used by one of the other 
 > transcodes--and you lost the file.  This is pure guesswork, though, as I 
 > haven't even looked at the code (and don't plan to do so without 
 > something a little more specific pointing to a confirmed bug  :).

Completely understandable given lack of repeatability and clarity to
the proximal cause. I was just giving the info in case others had
encountered similar situations.

That being said couldn't/shouldn't the scheduler implement locking and
ordering so that race conditions are not possible -- (I know it's not
as simple as I'm implying) since there is only one master scheduler it should
be able to prevent the possibility of race conditions. Even if mythbackend
crashes or is shut down and mythtranscodes continue, the files
would only be replaced by the scheduler itself and the rules for
replacing would be conservative to err on the side of avoiding data
loss.





More information about the mythtv-users mailing list