Bug #5446
closed
Continuity errors while recording
Added by Lewis Juggins over 6 years ago. Updated over 6 years ago.
0%
Description
Hi,
While viewing 5 HD streams from the same mux I can stream for hours without a single continuity error, however, when recording 5 HD streams from the same mux after a few minutes I start to get continuity errors intermittently. I also see a CPU spike when the errors happen.
Would a trace be useful for diagnosing this?
Files
Updated by Lewis Juggins over 6 years ago
I should also mention that this is using a quad HDHomerun DVB-T tuner.
The reason I mention 5 concurrent streams/recordings is that a single recording takes much longer to experience the same issue, and will encounter less continuity errors during its recording.
I thought this may be an issue related to flushing the recordings to disk, but the RAM usage seems to continue to climb during the continuity errors.
Updated by Lewis Juggins over 6 years ago
Attached is a sample containing 20 errors from 3 minutes of 5 concurrent HD recordings.
Updated by Lewis Juggins over 6 years ago
https://ufile.io/0e6m1 the form upload wasn't working for me for some reason.
Updated by Lewis Juggins over 6 years ago
I've also noticed that with multiple recording streams active and an epgdata stream on the same mux I see the continuity error counter building on all streams other than the epgdata.
Even with single streams of ~1h I'm seeing >500 errors for a recording. I'm really struggling to work out how to fix this now.
Updated by Joe User over 6 years ago
What hardware are you using?
Please provide debug logs.
Updated by Lewis Juggins over 6 years ago
I'm using an Intel i5-5250U running Debian.
Attached are logs of a variety of scenarios (many and single recordings/streams)
Interestingly the errors appear almost predictably frequently at 2 seconds past the minute (see 'The Secret Life of the Zoo at...' recording).
Dec 21 09:15:10 is an example of 15 minutes of 5 concurrent HD streams with no errors.
Dec 21 10:53:12 is a single recording which experienced errors almost predictably.
Dec 21 11:17:22 is an example of a single stream (not recording) that experienced no errors for 30 mins.
This looks to me like an issue with the recording pipeline, but I'm only speculating based on my observations.
I hope this is helpful.
Updated by Mark Clarkstone over 6 years ago
Lewis Juggins wrote:
I'm using an Intel i5-5250U running Debian.
Attached are logs of a variety of scenarios (many and single recordings/streams)
Interestingly the errors appear almost predictably frequently at 2 seconds past the minute (see 'The Secret Life of the Zoo at...' recording).
Dec 21 09:15:10 is an example of 15 minutes of 5 concurrent HD streams with no errors.
Dec 21 10:53:12 is a single recording which experienced errors almost predictably.
Dec 21 11:17:22 is an example of a single stream (not recording) that experienced no errors for 30 mins.
This looks to me like an issue with the recording pipeline, but I'm only speculating based on my observations.
I hope this is helpful.
It could be the home run causing issues. This might be a long shot but have you tried connecting directly to the homerun without anything in between [router/switch etc]? You could also give changing "DSCP/TOS for streaming" in tvh a go too.
Updated by Lewis Juggins over 6 years ago
Mark Clarkstone wrote:
It could be the home run causing issues. This might be a long shot but have you tried connecting directly to the homerun without anything in between [router/switch etc]? You could also give changing "DSCP/TOS for streaming" in tvh a go too.
Does tvh do something differently with recordings than it does if it's just passing the stream onto the client? Because I don't have any communication issues with the latter. I don't use any QoS, and the two devices are on the same switch so they're only a single hop from each other.
Updated by Jaroslav Kysela over 6 years ago
It appears like that the UDP stack or the ethernet card or a network equipment on the path is dropping some UDP packets. You need to check the whole ethernet setup and try to determine the packet loss. TVH uses UDP data transfers for HDHomeRun.
You may also use HTTP (TCP) streaming from HDHomeRun (use the HTTP links in the channel list from HDHomerun webui).
Updated by Lewis Juggins over 6 years ago
Jaroslav Kysela wrote:
It appears like that the UDP stack or the ethernet card or a network equipment on the path is dropping some UDP packets. You need to check the whole ethernet setup and try to determine the packet loss. TVH uses UDP data transfers for HDHomeRun.
You may also use HTTP (TCP) streaming from HDHomeRun (use the HTTP links in the channel list from HDHomerun webui).
Is there a reason why this only seems to manifest for recordings? I'm looking into connectivity issues now.
Updated by saen acro over 6 years ago
My guess, Lan card and tuner or hdd controller share same IRQ 
Updated by Lewis Juggins over 6 years ago
Had to restart the box to check BIOS settings (unfortunately I can't configure IRQ), also switched the ethernet cable out while there, I've just run the same test again and I'm not seeing any errors. Not sure what's caused a sudden change, but it appears to be working for now, I'll continue to monitor, thanks all for the help.
Updated by saen acro over 6 years ago
Disable all unused devices in BIOS
COM Port, Printer Port, Sound card /hdmi port have own audio processor/
Also sometime driver problem can make some problems.
Use POWERTOP to see with device make most CPU wakeups and optimise it.
Updated by Luis Alves over 6 years ago
saen acro wrote:
My guess, Lan card and tuner or hdd controller share same IRQ
IRQ sharing is normal and doesn't cause any issues (unless the OS is bugged).
In fact everything would work fine with 1 IRQ only. Usually more that one interrupt exist so that they can be prioritized in hardware (which can also be done in software with just one interrupt).
Not sure which machine we're talking about here (x86?) but at most you want to set a higher IRQ priority.