LinHES Forums http://forum.linhes.org/ |
|
Repeated problems with missing recording files http://forum.linhes.org/viewtopic.php?f=17&t=17912 |
Page 1 of 1 |
Author: | Grant_Edwards [ Sun Feb 17, 2008 8:43 pm ] |
Post subject: | Repeated problems with missing recording files |
Starting a few days ago, recordings on a particular channel stopped working. The recordings show up in the database as they should, but they can't be watched or deleted because the .nuv file isn't found. There aren't any problems with recordings on other channels. How do you prevent the backend from creating entries in the "recorded" table that don't have any .nuv files to go with them? This seems like a bug in the backend code to me... |
Author: | manicmike [ Mon Feb 18, 2008 1:37 pm ] |
Post subject: | Re: Repeated problems with missing recording files |
You didn't mention the version of KM you're using. I haven't seen the .nuv extension for quite a while (> a year). Mike Williams |
Author: | Grant_Edwards [ Mon Feb 18, 2008 4:00 pm ] |
Post subject: | Re: Repeated problems with missing recording files |
manicmike wrote: You didn't mention the version of KM you're using. I haven't
seen the .nuv extension for quite a while (> a year). I'm running R5F27. IIRC, when I upgraded to R5F27 this summer, the recording file names changed from .mpg to .nuv. Now I seem to have both. Perhaps transcoding changes the file type from one to the other? |
Author: | tscholl [ Mon Feb 18, 2008 4:32 pm ] |
Post subject: | |
Yes when you transcode a file it creates a file with a .nuv extension. |
Author: | Grant_Edwards [ Tue Feb 19, 2008 4:01 pm ] |
Post subject: | |
tscholl wrote: Yes when you transcode a file it creates a file with a .nuv
extension. That explains it. I never transcoded before the R5F27 upgrade. What I suspect is happening is that the signal strength from the one problematic channel has dropped and the tuner is unable to lock on to it. If that's the case, there's clearly a bug in the MythTv backend that is creating entries in the "recorded" table even though it was unable to record anything and didn't create an .mpg file. Has anybody else seen this problem? |
Author: | Kirk [ Tue Feb 19, 2008 5:10 pm ] |
Post subject: | |
Grant_Edwards wrote: What I suspect is happening is that the signal strength from
the one problematic channel has dropped and the tuner is unable to lock on to it. If that's the case, there's clearly a bug in the MythTv backend that is creating entries in the "recorded" table even though it was unable to record anything and didn't create an .mpg file. Has anybody else seen this problem? I usually get a zero byte file when that happens. There's a few scripts posted here that will clean up stale DB entries and the like. |
Author: | rollit12 [ Wed Feb 20, 2008 2:39 pm ] |
Post subject: | I have the same problem,I think. |
I have the same problem as Grant, I think. I don't have a zero-length file. What would be nice is to have the backend "retry" to re-establish the signal and start a new recording ASAP, kind of like what happens when the box gets rebooted and starts up when a recording is already in progress. I think the problem is not that the backend is deleting the file - the file is actually gone while the backend thinks it is still recording to it. I think the problem is that the backend can't tell if any data is actually going from the card to the file at all. |
Author: | slowtolearn [ Wed Feb 20, 2008 5:04 pm ] |
Post subject: | |
Have you guys seen http://svn.mythtv.org/trac/ticket/3872 ? |
Author: | Grant_Edwards [ Wed Feb 20, 2008 5:15 pm ] |
Post subject: | |
slowtolearn wrote: Have you guys seen http://svn.mythtv.org/trac/ticket/3872?
I have now. ![]() I don't have any 0-byte files, I have missing files. Then again, I'm using Ethernet instead of Firewire, so that may explain the differring behavior. |
Author: | rollit12 [ Thu Feb 21, 2008 9:25 am ] |
Post subject: | |
I've seen that ticket - it's not quite the same behavior, as Grant noted, we're not getting 0-byte sized files, we're getting *no file at all*. However, it does appear that it is probably stemming from a similar root problem - the mythbackend is unable to determine if the device, be it firewire, remote ethernet, or in my case, an AirStar Technisat HD-5000 is actually succesfully passing data through whatever code writes the file out. |
Page 1 of 1 | All times are UTC - 6 hours |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |