Tvheadend

Hi Jaroslav,

thanks for considering this. My naive approach would be simple... during a given recording check every minute if any error counter during the last minute changed. If yes, increase the "faulty minute count" and update the % stats accordingly. Sounds simple. ;)

Thanks again
Dietmar.

I understand the requirement. I'll think about this more, but the absolute errors makes also sense if you get occasional dropouts. I had a complete time-log in my head to see which parts of recordings are broken.

Glad I searched before adding my own much-wordier request!

I would suggest that this would be highly useful for internal recording/re-recording management as well as for passing to post-processing. (That's probably obvious, but given how often I miss the obvious myself... ;) )

Again had some unusable recordings and noticed them too late. Thought it would be ok to ping this request again... although being flagged for 4.4. ;)
I would really appreciate the simple relative metric.

Cheers
Diddle.

In case it's useful for comparison, MythTV logs this at the end of a recording, and persists the xml to the DB for the client to use.

FinishedRecording(CHANNEL_YYYY-MM-DDTHH:MM:SSZ) damaged recq:

<RecordingQuality overall_score="0" key="<filename>" countinuity_error_count="3" packet_count="84856">                                                                          
   <Gap start="YYYY-MM-DDTHH:MM:SSZ" end="YYYY-MM-DDTHH:MM:SSZ" duration="6431" />                                                                                                                
   <Gap start="YYYY-MM-DDTHH:MM:SSZ" end="YYYY-MM-DDTHH:MM:SSZ" duration="999" />                                                                                                                 
</RecordingQuality>                                                                                                                                                                               

And another example for a different recording:

damaged recq:
<RecordingQuality overall_score="0.9" key="<filename>" countinuity_error_count="277" packet_count="2288569" />

I suspect the overall_score percentage (however it's calculated) is the useful stat for differentiating long recordings vs short ones, and the Gaps for determining the time log for how bad the problems were.

Of course, xml was last decade so we'd use json.

This was the MythTV (GPLv2+) commit that brought in its quality tracker (with a few bug fixes later) with the main logic in the recordingquality.cpp

[[https://github.com/MythTV/mythtv/commit/ca0419d8969b97bba80c590e5fed02f7c1d948c8]]

The "interesting" thing (according to the comments) is that the quality is weighted so if there are problems at the start/end of a programme they are given higher priority, on the assumption they contain important information such as "Who Shot J.R.?"

The quality score is degraded if the total number of continuity errors are >0.1% of the total recording, and set far lower if the errors are >1% of the total recording.

The score_gaps function seems to also modify the score based on the lengths of gaps (for example a five second gap is worse than a 0.1 second gap, but not as bad as a two minute gap). So, my #4747 where Tvheadend only recorded for one minute but had the recording marked as success, would be detected by this algorithm.

At a quality score of <0.95 the programme is automatically flagged as damaged and re-recorded.

MythTV also has a RecStatus::Failing so that it can schedule on the +1 timeshift channel if the current recording won't be good, but this seems to only be used for the initial tuner lock rather than checking quality during the recording. But I think an ongoing check is good since many programmes are an hour and with a padding it means they end after the +1 timeshift would've started (e.g., recording 9pm--10:02pm, but if it's a bad recording then it should re-record on the 10pm--11pm timeshift channel).

I don't know enough about the logic of either tvh streaming or mythtv to implement this one.

Another "bug" which should really be a "feature request".