Playback Freezes

[Stabie 7]

Not a 100% the same situation, but maybe this will help you as well:

I’ve fought this for a while and finally pinned it down to mostly EAC3 (DD+) 2.0. What happens: during heavy skipping/fast-forward, the picture and audio freeze and I have to hard-restart.

Root cause (in my setup): with Auto detection, the Denon AVR sometimes treats DD+ as 5.1 instead of 2.0. That mismatch seems to trigger the lock-ups when seeking.

Workaround that fixes it every time:

• Leave the Denon on Auto normally.

• When the content is EAC3 2.0, press the MOVIE button on the remote and select a Dolby mode (Not atmos or anything else).

• After forcing the correct mode, I can skip/seek as much as I want without freezes.

Also:

I’ve seen this with the Samsung TV’s native app and with a different receiver before the Denon, so I don’t think it’s strictly a Denon bug. The fix is to make sure the AVR is interpreting the signal correctly (2.0 in, 2.0 out) and not engaging upmixers/post-processing that confuse the stream. Double-check the AVR’s Info screen: it should show Input: DD+ 2.0 and Output: 2.0 when you’re on affected titles.
 

PS: I used AI to help me write this.

[Stabie 7]

Seems to be the same problem I have and have and reported.

[Luke 43524]

@Stabie

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[Luke 43524]

@Stabie?

[Stabie 7]

Hello,

Been on vacation. I gave up on it hoenstly, I just use Tdarr or whatever to make one audio track AAC 2.0 if I am going to watch something.

[Luke 43524]

Can you please give it another try?

[Stabie 7]

Yes, sure. I'll give it a go with debug enable this weekend, should have some spare time then.

[Stabie 7]

Hello again,

Sorry for the silence – haven't had much time to debug lately, but I'm planning to dig deeper in December.

Update: I discovered that this issue is NOT exclusive to the EAC3 2.0 <-> 5.1 mismatch I previously described. It actually happens with standard EAC3 5.1 (Dolby Digital Plus) content as well, where the channel layout is correct.

It feels like a general issue with Audio Passthrough handling. My theory is that the bitstream sync/handshake with the receiver (Denon AVC-X3800H) is lost or fails to re-establish quickly enough when seeking/skipping. The video player seems to wait for an audio clock that never returns, causing the freeze.

I do notice that when skipping, the receiver goes from 5.1 --> 2.0 --> 5.1 when the handshake returns. I would imagine it goes to 2.0 when no stream because that's the "standard".
If it's possible, at all, to keep the audiostream alive during skipping that would solve it (I like to think so, but I have no idea).

[Luke 43524]

Quote

Sorry for the silence – haven't had much time to debug lately, but I'm planning to dig deeper in December.

OK that would be great. Thanks !

[Stabie 7]

Hello again - I will use AI to write this, because I used AI to figure out the reason. My fix over is wrong, but for some reason it's better in later versions of Emby, but the "slowness" is still there, but it won't require a restart of the box anymore.

Posting the findings here since you asked for data:

Setup now: Ugoos SK4 Pro (Amlogic S905X5M, Android 14), Emby for Android TV 2.5.05g, Emby Server 4.10.2.0, HDMI → Denon AVC-X3800H → Samsung Q60T. Direct play of UHD remuxes (HEVC, TrueHD Atmos / E-AC3 JOC passthrough).

What happens: every skip forward/back (5 s) gives ~1.5–2 s of silence and the video hangs ~1 s. The Android audio HAL log for one skip:
 

22:57:02.663 out_flush_new            io 181 out:0xe6484210
22:57:02.664 out_standby_new          io 181 streamType:RAW_DIRECT
22:57:02.665 adev_close_output_stream io 181 dev:OUT_HDMI flags:0x11 streamType:RAW_DIRECT
22:57:03.367 adev_open_output_stream  io 189 format:DOLBY_TRUEHD(0xe000000) flags:0x11 (DIRECT,COMPRESS_OFFLOAD)
22:57:03.989 aml_alsa_output_open_new

So on each seek the direct (passthrough) output is closed, a new one is created ~0.7 s later and ALSA is reopened ~1.3 s after the close. Only then can the Denon lock onto the bitstream again, which is the 5.1 → 2.0 → 5.1 flicker I saw on the receiver. This matches ExoPlayer's DefaultAudioSink releasing the AudioTrack on flush and creating a new one on the next write.

I have filed it upstream with Media3: https://github.com/androidx/media/issues/3522.

Two questions:

1. Is there anything on the app side that could keep the AudioTrack across a seek for passthrough, or a setting AI have missed?
2. Could the Emby team add weight to the upstream issue? Every Android TV user with an AVR and passthrough hits this.

 

Full logs available on request. The analysis was done with an AI assistant and this text was written by AI. All I wrote was the start text.

 

[ebr 17006]

14 hours ago, Stabie said:

Every Android TV user with an AVR and passthrough hits this.

But that's not really the case as most people don't have this issue.  So it is related to specific setups or settings.  Many AVRs have an input setting something like "white noise" or similar and it is defined as doing basically what you are asking - during brief interruptions, it keeps the bitstream active.

[Stabie 7]

Then I don't really know anymore dude, I've lived with this for years already. With different AVR's, different android-boxes and even TV into AVR.
I might've been to firm when I said every TV user got it, but I can't be that unique? Tell me then if possible what the setting is called on a Denon X3800H because I can't find it and that is not a "cheap" AVR.

[ebr 17006]

I just did some research and, unfortunately, Denon doesn't implement this.  I mis-remembered the name - it is called "Comfort Noise" on many devices and the Shield does actually have a setting for this.  Some AVRs call it "Keep Audio Alive" apparently but Denon does not seem to have it.

Check your Android device for something like the Shield setting.

[Stabie 7]

Yes, I found out that mostly it's players that has it and not AVR. Kodi already have it.
Any chance of getting something implemented in Emby? I don't want to change away from Emby if I can help it.
 

[Luke 43524]

Is that GitHub URL still valid?