Opened 14 years ago

Closed 10 years ago

#4130 closed patch (Won't Fix)

Extend mythcommflag to flag bad recordings

Reported by: Tony Lill <ajlill@…> Owned by: cpinkham
Priority: minor Milestone: unknown
Component: MythTV - Mythcommflag Version: head
Severity: medium Keywords:
Cc: Ticket locked: no


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

Attachments (1)

broken.patch.14764 (16.4 KB) - added by Tony Lill <ajlill@…> 14 years ago.

Download all attachments as: .zip

Change History (11)

Changed 14 years ago by Tony Lill <ajlill@…>

Attachment: broken.patch.14764 added

comment:1 Changed 13 years ago by cpinkham

Owner: changed from Isaac Richards to cpinkham
Status: newassigned

comment:2 Changed 13 years ago by danielk

Version: unknownhead

comment:3 Changed 13 years ago by cpinkham

Milestone: 0.210.22

comment:4 Changed 13 years ago by laga

Type: enhancementpatch

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.

comment:5 Changed 12 years ago by cpinkham

Milestone: 0.220.23

comment:6 Changed 12 years ago by sphery

See, also, #6899

comment:7 Changed 12 years ago by 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.

comment:8 Changed 12 years ago by stuartm

Component: mythtvMythTV - Mythcommflag

comment:9 Changed 11 years ago by cpinkham

Milestone: 0.23unknown

comment:10 Changed 10 years ago by stuartm

Resolution: Won't Fix
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.