Extend mythcommflag to flag bad recordings

[Tony Lill <ajlill@…>]

This patch piggybacks on the video processing that mythcommflag already does to check for bad recordings. Recordings with excessive blank frames or not enough frames to fill it's scheduled run time are marked for re-recording. This requires Ticket #3917 to provide the re-recording functionality.

If anyone has any pointers to getting audio into mythcommflag, I'll add a check to no sound (every once in a while, I'll get a no-sound recording from my stb).

[laga]

This is almost a duplicate of #3872.

Tony, could you please add your concern as a comment to #3872? It seems we need to extend our definition of "failed recording" to those cases where a file has been created which contains bogus data.

[mdean]

See, also, #6899

[ajlill@…]

I tried commenting on #3872, but it was locked.

These tickets are duplicates in only the sense that mythtv thinks it's done it's job, but you still wind up downloading the show off the net!

The are two basic causes of why a recording fails, hardware failure and signal failure. Hardware failure is usually permanent (requires a manual reboot or reset), while signal failure is transitory, where simply retrying after some delay usually works.

Ticket #3872 is about early detection of hardware failure. The resolution requires that you detect an obviously bogus file during recording, abort the recording, disable or de-prioritize the borked video source, and do a reschedule in time to record the same showing on a different source. You should also let the user know that mythtv suspects one of the video sources is boned.

This ticket (and #6899) are about signal failure, where you record a perfectly valid file, but the contents are unwatchable because it's blank, has no sound, the STB froze or was reset, etc. Detecting this requires more signal processing that you probably want to do in the recorder, although some might be easy to do, like what I think #6899 does. Also, you generally want a long retry, especially if it's weather related.

My patch works in the comflagger by re-analysing the blank frame data, then removing any probably bad recordings from duplicate detection and rescheduling. It works great in Canada 'cause cable and satellite pad their lineups with stations from every timezone, but would be less effective if you only had one shot at recording a show.

That being said, my patch also detects a zero byte file, but since it simply causes it to be re-recorded at a later time, doesn't solve all of the other tickets concerns, especially avoiding the jammed hardware.

[stuartm]

I think we have to call it a day on this patch, if it hasn't drawn sufficient interest in 4 years then it's simply not going to get committed any time soon. The patch will be still here if anyone wants to dig it up in the future but I'm closing the ticket.