4.11.0.5 beta: DVR recording fails with ArgumentNullException (consumerId) and leaks live stream buffers

[sittingmongoose 5]

Server: Emby Server 4.11.0.5 beta (Docker emby/embyserver:beta, Unraid 7.4, Linux 6.18). Same setup on 4.11.0.4 recorded fine. Tuner: M3U tuner pointing at Dispatcharr (http://<lan-ip>:9191/proxy/ts/stream/...) Transcode temp path: dedicated 239 GB SSD

What happens

Since upgrading to 4.11.0.5, every scheduled recording fails as soon as it starts:

 

 

 

 

 

 

 

 

 

 

 

 

Info SharedHttpPipelineSource: Live stream buffer limit is unlimited.

Info SharedHttpPipelineSource: Beginning SharedHttpPipelineSource stream to /Transcode/transcoding-temp/<id>/{0:0000000}.ts

Info SharedHttpPipelineSource: Done waiting for segments after 3500ms

Error LiveTV: Error in GetChannelStreamWithDirectStreamProvider

System.ArgumentNullException: Value cannot be null. (Parameter 'consumerId')

at Emby.LiveTV.TunerHosts.LiveStream.AddConsumer(String consumerId)

at Emby.LiveTV.EmbyTV.GetChannelStreamWithDirectStreamProvider(...)

at Emby.LiveTV.LiveTvManager.GetChannelStream(...)

at Emby.Server.Implementations.Library.MediaSourceManager.OpenLiveStreamInternal2(...)

Error MediaSourceManager: Error opening live stream

Error LiveTV: Error recording to ... S2026E276.ts

Info LiveTV: Retrying recording in 60 seconds.

 

The recording retries every 60 seconds for about 10 minutes. The problem is that each attempt's SharedHttpPipelineSource is never closed. The live stream keeps being copied into transcoding-temp/<id>/ with no buffer limit. After one 18:30 recording I had 11 orphaned buffers (one per retry), each about 22 GB, still writing 11 hours later. They only stopped when the transcode SSD hit 100% (No space left on device). No recording file was produced. In each log, "Beginning SharedHttpPipelineSource" appears about 20 times but only about 7 of those streams are closed.

Pattern across logs

Version	consumerId errors	Recordings
4.11.0.4	0	OK (Oct 1, Oct 2)
4.11.0.5	33 per recording attempt window	Failed (Oct 3, Oct 4)

It may matter that a Roku client was watching another channel from the same M3U tuner when the timer fired, so the recording may be trying to join an existing shared stream with a null consumer ID.

Two issues, really

1. Recording fails with the null consumerId (looks like a regression in 4.11.0.5).
2. When opening the stream fails, the already-started SharedHttpPipelineSource isn't disposed, so a failed recording can fill the transcode drive.

Possibly related: https://emby.media/community/topic/150062-bug-live-tv-recording-stopped-early-when-a-remote-viewer-stopped-watching-the-same-channel/ (a recording registered with an empty consumer id on 4.10.0.40) and https://emby.media/community/topic/150036-live-tv-can-consume-hidden-tunersconnections-due-to-duplicate-recording-consumers/ (recording consumers never released, so upstream connections stay open). In 4.11.0.5 the same consumer-id path seems to throw instead, and the stream it opened is leaked.

Workaround: pinned the container to emby/embyserver:4.11.0.4.

Log excerpt attached (one full cycle including the stack trace). Happy to provide more logs.

 

emby-4.11.0.5-recording-leak-log.txt

Edited 1 hour ago by sittingmongoose

[Neminem 1937]

Beta

Post here 

Emby Server Beta - Emby Community

More that 1 post about it.