Feature #4602

Hardcoded max error value will sort out "okayish" recordings

Added by Roland A. 3 months ago. Updated 3 months ago.

Status:NewStart date:2017-09-17
Priority:NormalDue date:
Assignee:Adam Sutton% Done:

0%

Category:PVR / DVR
Target version:4.4

Description

Please read this topic to get into the problem: https://tvheadend.org/boards/5/topics/22608?r=28512

We define DVR_MAX_DATA_ERRORS to 10000 in src/dvr/dvr.h.

This will, at least for me, always sort out long recordings of HD 720p streams (german FTA "Das Erste HD"). The error count is at ~13000 for 3h30 of recording time.
I was fighting with myself if I should create this ticket as a bug or a feature. For my personally, it is a too strict default value and my TVheadend regularly sorts out long HD recordings (happens every now and then). If I play them, the error rate seems to be "okayish".

I propose 2 changes:
Idea is to not only make this user configurable, but also not a static value without references. We should make a limit relative to a timeframe, e.g. "Avg 5000 errors per hour". An example - if a recording takes 3h30, the individual "sort out threshold" would be 17500. On a 30 minute recording, it is 2500.

Currently the system will sort out longer recordings with a higher probability because of this.
Also, and this makes it worse, the button "Move to finished" in the "Failed recordings"-tab is not doing anything. (I will file a bug for this).

I'm using HTS Tvheadend 4.2.3-33~ga255d82 from the source "http://dl.bintray.com/mpmc/deb raspbianjessie stable-4.2" on a Raspberry Pi 2 connected to a 4way SAT>IP server Kathrein EXIP414/E. The local path for recordings is a NFS mount from FreeNAS 11. Perhaps this situation, with the Pi as the TVH server, provokes the situation as described as the NIC is limited on that device.

History

#1 Updated by Mark Clarkstone 3 months ago

Roland A. wrote:

.. snip ..

Have you tried turning off "Full mux RX mode supported"?

#2 Updated by Roland A. 3 months ago

Mark Clarkstone wrote:

Have you tried turning off "Full mux RX mode supported"?

No, not yet - but I just did. As two recordings are running right now, I can see that there is at least no direct change in the error rate of the subscriptions. Do I need to restart something after changing the checkbox?

#3 Updated by Mark Clarkstone 3 months ago

Roland A. wrote:

Mark Clarkstone wrote:

Have you tried turning off "Full mux RX mode supported"?

No, not yet - but I just did. As two recordings are running right now, I can see that there is at least no direct change in the error rate of the subscriptions. Do I need to restart something after changing the checkbox?

I shouldn't think so, next thing you could try is limit the PIDs. I honestly use the Pi for testing & building tvh.

You did however remind me to check if I'd built 4.2.3-39 for Jessie & pushed it to bintray (I hadn't). You should be getting 4.2.3-39 now (after an apt update) :).

#4 Updated by Roland A. 3 months ago

Mark Clarkstone wrote:

Do I need to restart something after changing the checkbox?

I shouldn't think so, next thing you could try is limit the PIDs. I honestly use the Pi for testing & building tvh.

I tried to change a different setting and it had immediate impact on the next subscription. So I guess disabling "Full mux RX mode" does not help in my case. When you say "limiting PIDs", is this reducing the "Maximum PIDs" on SAT>IP server level that is currently set to 32?

You did however remind me to check if I'd built 4.2.3-39 for Jessie & pushed it to bintray (I hadn't). You should be getting 4.2.3-39 now (after an apt update) :).

Ah cool, will update in 20mins. :)

#5 Updated by Jaroslav Kysela 3 months ago

  • Target version set to 4.4

Note that errors above 1000 per recordings mean that something is really broken. But I basically agree that the decision threshold should be configurable by user (probably in the DVR configuration).

Also available in: Atom PDF