Tvheadend

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.

Attached is a sample containing 20 errors from 3 minutes of 5 concurrent HD recordings.

https://ufile.io/0e6m1 the form upload wasn't working for me for some reason.

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.

What hardware are you using?
Please provide debug logs.

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.

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.

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).

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.

My guess, Lan card and tuner or hdd controller share same IRQ

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.

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.

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.