livetv recording failed after 40secs

[Tau512 15]

embyserver-63864892800.txt

A recording was triggered at 2024-10-18 19:58:00.000, where the created recording works as expected but only for the first 40 seconds.

i assume the 40 second life has to do with with the following line indicating retries, followed by HttpException exceptions.

2024-10-18 19:58:31.799 Error SharedHttpPipelineSource: Give up retries copying live stream http://host8:8901/x_path5_x/x_path6_x/x_path7_x/x_path8_x No more retries allowed.
	*** Error Report ***
	Version: 4.8.10.0
	Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby -ffdetect /opt/emby-server/bin/ffdetect -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-deb_{version}_amd64.deb
	Operating system: Linux version 6.8.12-2-pve (build@proxmox) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-2
	Framework: .NET 6.0.31
	OS/Process: x64/x64
	Runtime: opt/emby-server/system/System.Private.CoreLib.dll
	Processor count: 2
	Data path: /var/lib/emby
	Application path: /opt/emby-server/system
	MediaBrowser.Model.Net.HttpException: MediaBrowser.Model.Net.HttpException: BadRequest
	   at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsyncInternal(HttpRequestOptions options, String httpMethod)
	   at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsync(HttpRequestOptions options, String httpMethod)
	   at Emby.LiveTV.TunerHosts.SharedHttpPipelineSource.OpenStream(IDisposable connectionContext, MediaSourceInfo mediaSource, String url, MediaProtocol protocol, CancellationToken cancellationToken, Int32 recursion)
	   at Emby.LiveTV.TunerHosts.SharedHttpPipelineSource.<>c__DisplayClass45_0.<<StartStreamingWithLegacyTsProcessor>b__0>d.MoveNext()
	Source: Emby.Server.Implementations
	TargetSite: Void MoveNext()

my first thought when the girlfriend told me of a failed recording was a failed tune as this has been a problem in the past. However the fact it connected to source for 40sec suggests i've got another issue somewhere.

the IPTV stream is Emby > threadfin > m3ufilter > provider.

does this log show anything specific at fault that would help me diagnose the problem?

Edited October 19, 2024 by Tau512

[Luke 42080]

HI, eventually the stream runs out of data, and then the server starts getting 400 bad request errors from the TV url. Can you found out why that response gets sent back?

[Tau512 15]

Thanks luke. i'll look into that more - i missed http 400 when i was looking through myself. it's something to work upon.

I've also found some hardware AND intermittent performance load issues on the server too so might all be related.

[Luke 42080]

Please let us know what you find. Thanks !

[Tau512 15]

found plenty of issues!

Failed disk in raid array which didn't appear to be causing perf issues, but has been replaced.

somehow the docker Threadfin was reporting it's internal docker IP to emby, which isnt routable. Not sure why this was being intermittent but the emby logs were clear on attempts to connect to that IP! I couldn't find a quick solution for the docker threadfin instance, so ended up moving threadfin into an LXC container with a real LAN IP. Very quick and easy process to move over.

also discovered that Nextcloud was causing abnormally high system load (5-20 Linux Load Average, on the quad core N100!!) during file syncs, which i suspect could have an knock on effect to the buffer of any media content that was ran on the same hardware.

so far it's been a week without the original problem occurring.

[Luke 42080]

Thanks for the update! Keep us posted.

[Luke 42080]

@Tau512how has this gone?

[Tau512 15]

seems solved with the update on 30th Oct. no further unexpected issues.

[iiiJoe 62]

1 hour ago, Tau512 said:

seems solved with the update on 30th Oct. no further unexpected issues.

Just wondering if you’ve had any failed recordings at all after the update? Also, looks like you’re using Linux, yes?

Edited December 11, 2024 by iiiJoe

[Tau512 15]

yes on the failed recordings, but all were my own fault (rebooting/changing stuff) during recording periods.

no unexpected failures though. Emby/threadfin has been reliable since fixing various IP/DNS/storage level issues

[iiiJoe 62]

3 minutes ago, Tau512 said:

no unexpected failures though. Emby/threadfin has been reliable since fixing various IP/DNS/storage level issues

That’s great! Just curious what made you decide to utilize “Emby/threadfin” as opposed to Emby by itself?

[Tau512 15]

cant quite remember, but i think it was IPTV source had so many channels that emby wasn't sanely useable. threadfin allows regex/search criteria to filter on.

[Nonnos 2]

On 30/10/2024 at 22:02, Tau512 said:

found plenty of issues!

Failed disk in raid array which didn't appear to be causing perf issues, but has been replaced.

somehow the docker Threadfin was reporting it's internal docker IP to emby, which isnt routable. Not sure why this was being intermittent but the emby logs were clear on attempts to connect to that IP! I couldn't find a quick solution for the docker threadfin instance, so ended up moving threadfin into an LXC container with a real LAN IP. Very quick and easy process to move over.

also discovered that Nextcloud was causing abnormally high system load (5-20 Linux Load Average, on the quad core N100!!) during file syncs, which i suspect could have an knock on effect to the buffer of any media content that was ran on the same hardware.

so far it's been a week without the original problem occurring.

Did you create the LXC container with threadfin manually or did you use e.g Proxmox VE + Helper-Scripts?