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...

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

_________________
*********************
LinHES 7.4
Australian Dragon
*********************

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?

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?

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.

_________________
MBE/FE ~ R5F27 ~ Asus A8N-VM-CSM ~ AMD64 3500+ ~ 1GB RAM ~ 1.5TB Storage ~ Nova-T-500 ~ SH-S183A DVDRW ~ LC20M Case ~ iMON-Pad Remote
FE ~ Diskless ~ Asus M2NPV-VM ~ AMD X2 BE-2350 (45w) ~ 1GB RAM ~ TT Lanbox Lite ~ iMON-Pad Remote

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.

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.

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.