Feature #4602
Hardcoded max error value will sort out "okayish" recordings
0%
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
Updated by Mark Clarkstone about 7 years ago
Roland A. wrote:
.. snip ..
Have you tried turning off "Full mux RX mode supported"?
Updated by Roland A. about 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?
Updated by Mark Clarkstone about 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) :).
Updated by Roland A. about 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.
Updated by Jaroslav Kysela about 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).
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