Project

General

Profile

Feature #4602

Hardcoded max error value will sort out "okayish" recordings

Added by Roland A. over 7 years ago. Updated almost 4 years ago.

Status:
New
Priority:
Normal
Assignee:
Adam Sutton
Category:
PVR / DVR
Target version:
4.6
Start date:
2017-09-17
Due date:
% Done:

0%

Estimated time:

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 over 7 years ago

Roland A. wrote:

.. snip ..

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

#2

Updated by Roland A. over 7 years 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 over 7 years 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. over 7 years 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 over 7 years 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).

#6

Updated by Richard Farnsworth over 5 years ago

Note that errors above 1000 per recordings mean that something is really broken

Not really.
When I'm recording from SkyDE and the CS server gets unreachable, then I see >1 million data errors in a single minute.

So,
+1 to have this configurable
+2 to have this configurable per duration

BTW, in the recording profile we can ocnfigure a threshold for re-scheduling. Maybe we could simply integrate that here...

Cheers
Rich

#7

Updated by Flole Systems almost 4 years ago

  • Target version changed from 4.4 to 4.6

Also available in: Atom PDF