Zero-byte recordings should not exist

[xris]

If there is a recording error (like a broken firewire connection), MythTV shouldn't keep the zero-byte file around as if the recording was a success, but should log an error, delete whatever recorded/oldrecorded table entries there are and re-schedule the specific recording as if it was never recorded in the first place (since it wasn't).

[anonymous]

I see this happen once a week or so and in my case there is always a standard def version of the same show available on a different card so it would be really nice if the generation of a zero byte file would trigger an immediate attempt to record the same show on a different input rather than waiting for another airing as there may not be one. I would accept the missing couple of minutes at the start of a "rescued" show. If no input is available, try to record it later.

[xris]

Better than that, the firewire-tester app can flush the bus enough that the backend can often continue recording once it restarts (see [3995] for some crash-related info). It should be easy enough for the backend to detect that the file isn't growing, flush ala firewire_tester, flush with whatever the backend itself does upon restart, and then try the recording again. If it's still failing at this point, best to log an error and just give up to try the recording at a later time instead.

[xris]

make that #3995

[danielk]

(In [14956]) Refs #3872. Do a firewire bus reset when required in the LinuxFirewireDevice?.

This is the default behaviour with the DarwinFirewireDevice?, but due to concerns about buggy Linux drivers this requires changing a line of code and recompiling in Linux to enable. But since there are many bug reports which are really do to this not being enabled, this changeset enables the reset and adds an option to mythtv-setup+general|miscellaneous to disable it.

The problem drivers were for an external firewire harddrive, they have been fixed in the Linux kernel for over a year. Resets can also cause a small glitch in recordings currently in progress if you have multiple Motorolla STBs connected to the same firewire bus, but a this is preferable to most people over zero-byte recordings.

[xris]

Didn't seem to help much. Still got a zero-byte recording. When I tried to delete it the backend crashes (see #3995), and I still get a zero-byte recording when I start it up again. However, if I run firewire_tester (firewire_tester -B -P 0 -n 3), the recording starts getting data.

[xris]

See also #4425

[stuartm]

If no-one else gets to it first, I'll take a look at this when I get time. The issue of firewire failures is clouding the issue slightly, there are all sorts of reasons a recording might fail from temporary aerial disconnections to driver bugs.

The desired behaviour should be as Xris states - that the error is logged to the database (viewable from the frontend), that we re-schedule the recording and the zero-byte (or even non zero byte) file and recorded table entry are deleted.

To go further, we should maybe even attempt to retry the recording a couple of times with increasing intervals, up to 120 seconds after the first failure, before giving up. Losing the first two minutes is better than losing the entire recording because of a temporary glitch.

Neither of the above is especially hard to implement.

[xris]

I might have created another ticket for the retry stuff (it was a long time ago). But yes, I think it would be a good idea to retry (with or without a signal reset of some sort). I often find that when there is trouble viewing LiveTV, things will work fine if I just escape out and retry.

The scheduler will already ignore recorded zero-byte recordings (I think I snuck that patch in a few months ago), but it's still annoying to have to manually go in and delete them.

[skerit@…]

I would like MythTV to retry failed recordings.

Every once in a while a recording would fail because of some decoding hiccup, the only thing MythTV needs to do is give it a millisecond and try again.

0 byte recordings are, indeed, very annoying. I like the idea that people would be able to see when a recording has failed (in stead of it just disappearing), otherwise most people would be stuck with some serious question marks. Will this also be viewable from MythWeb?

[chris@…]

This is not just a firewire issue. I see the same thing happen with my HD Homerun, when weather or other problems causes a show not to be coming in.

Even if the firewire problem is fixable, a general ability to notice 0-byte files and remove/reschedule would be a good idea.

[paulcull]

I agree - I get this error if one of the kids knocks out the arial cable. There are many root causes of this error, some not resolvable just with defensive code. The correct behaviour should be to report an error, may have to be lacking some detail and re-schedule.

[Dibblah]

Trac is not a discussion forum. The bug (along with almost 600 others) remains open. A developer has already stated that he will look at this bug. It will be resolved at some time.

[ScottNorris]

Sounds like this is being worked on, but I just wanted to post that I'm also getting zero-byte recordings on my pcHDTV-5500, so it's not specific to firewire setups. Unfortunately, I'm also experiencing the issues reported in the (now closed) bug #5507 -- i.e., after this happens once, all future recordings will be zero bytes until a reboot occurs.

Now, I understand that you can't do anything about fixing hardware issues, but where could/should I post about this? Googling "file for this recording can not be found" suggests that lots of people, on a variety of cards, are all ending up with frozen recorders after encountering this bug, so it seems something, somewhere, is wrong on a very fundamental level. Any ideas?

[ScottNorris]

Not trying to pester, but just had another thought. Could the fact that this problem seems to knock out the hardware until a reboot possibly be a driver/kernel bug? If so, where should the issue be raised elsewhere (I'm going to make a note in the ​Ubuntu but)? While this may not be a Myth problem, it's still a pretty major one -- losing a week's worth of shows every so often is enough to make one question whether an unreliable DVR is worse than no DVR at all.

[stuartm]

This ticket isn't about fixing hardware or recorder failures - most of which are outside our control, it is merely about what we do after the failure. Preventing you losing a week of recorders because of an ongoing card/driver failure is not only outside the scope of the ticket, it's also outside the scope of MythTV, so yes talk to the driver developers at linuxtv.org instead.

[danielk]

Not an enhancement ticket, since no ticket is attached. Not critical priority since it does not cause a deadlock.

[gigem]

(In [25383]) When updating the recorded table after a recording has ended, don't set duplicate=1 if the recording ended abnormally, eg. rsFailed. This let's the scheduler attempt ro re-record the program if the rule type allows it.

Refs #3872. I'm not closing this since there might still be issues with deleting zero-length files that this change doesn't try to address.

[gigem]

(In [25384]) Backport of [25383] to release-0.23-fixes.

When updating the recorded table after a recording has ended, don't set duplicate=1 if the recording ended abnormally, eg. rsFailed. This let's the scheduler attempt ro re-record the program if the rule type allows it. Refs #3872. I'm not closing this since there might still be issues with deleting zero-length files that this change doesn't try to address.

[robertm]

Calling it fixed. She had a good run.

[stuartm]

Calling it 'won't fix' instead since the problem remains, but as much as it pains me, no-one is interested enough in working on a fix.