All Activity

Just to throw this out there, my current Emby install sits on a Netgear ReadyNAS but those systems are EOL'd and unsupported, so I wanted to migrate over to a more resilient setup. That said, the ReadyNAS still works fine, so I'm not in a rush. (Also, datacenter SAS storage isn't the cheapest thing right now so it will be a bit of time before I can migrate my whole library across...) Any advice you do have is greatly appreciated, I just want to prove the viability of this solution before I go broke on storage.

Do you use a reverse proxy?

I'm sure the features will get richer as time goes on. @softworkz This one is just a little trickier because you're in a different context.

embyserver.txt

I'm considering making an automatic resume if a failure happens.. Problem will be having it working well together with Embys time limit setting.

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

Hi there, please attach the Emby server log from when the problem occurred: How to Report a Problem Thanks!

Yes, here's the OS details: Edition Windows Server 2025 Standard Version 24H2 Installed on 8/13/2026 OS build 26100.33296 Experience Windows Feature Experience Pack 1000.26100.275.0 Also since this is a server OS, Desktop Experience is installed, as well as the DX runtimes. Plan was to use the nVidia Tesla A2 (Driver v610.88) for transcoding. (I originally planned to use Docker, but it seems on a Windows OS that's a bit of excessive overhead just for the convenience of containerization...but I admit I'm fairly new to the hosting side of Docker. That's why I'm just going to install direct.)

Yes — and it turns out that comparison is the answer. Your web client builds the same URL for the same endpoint: getAudioStreamUrl() in modules/emby-apiclient/apiclient.js hits Audio/{Id}/universal with the same parameter names I was using, and it fills TranscodingContainer from the Container of whichever transcoding profile was matched. The difference is which value ends up there. In modules/browserdeviceprofile.js the audio HLS transcoding profile declares Container "ts" on Chromium and "aac" everywhere else, Safari included — never "mp4". The video HLS profile in the same file does push m4s. So the web app never takes the audio fMP4 path at all, which is why nothing shows up there. Measured against the same track, the same server and the same session, changing only that one parameter: TranscodingContainer=ts playlist 200, segment 0 -> 200, 91,556 bytes TranscodingContainer=aac playlist 200, segment 0 -> 200, 91,556 bytes TranscodingContainer=mp4 playlist 200, init.mp4 -> 500, every segment -> 500 The two values your own web app uses both work. Only mp4 fails, with the null reference at TranscodingCommandBuilder.HlsGetCommandLineArguments and no ffmpeg process ever started. I'm asking for mp4 because I want fMP4 audio segments for Apple's native player, the same way the video path already offers m4s. Happy to test a build whenever you have one.

I will try and uninstall and reinstall official release .54 and see if it fixes

No those were created by Emby.

That's strange. There is nothing that should stop it then other than some settings in Emby. This is the schedule task in Emby. See if the time limit is set as that will stop it. Edit: I mean if it is set incorrectly. Also are these enabled in the plugin?

Following up on my own 4.10.0.30 post: I found why the tail still hangs, and this time I can show it with your own app. The last segments are the same file. Byte for byte. On the 21-minute episode from the top of this thread: my own tvOS app, 6-second segments Emby for Apple TV 2.0.9, 3-second segments md5(segment 220) = d57aadc9... md5(segment 440) = d57aadc9... md5(segment 221) = d57aadc9... md5(segment 441) = d57aadc9... md5(segment 442) = d57aadc9... 2 identical, 2,646,476 B each 3 identical, 2,646,476 B each Both go through the same path — HLS with .ts and the video copied — and both stop in the same place. Every one of those requests returns 200, so from the server's side nothing looks wrong. Why it happens, from your own command lines. You restart ffmpeg per segment and seek to the nominal segment boundary, with the video copied: -ss 00:22:00.000 -f segment -c:v copy -> segment 220 -ss 00:22:06.000 -f segment -c:v copy -> segment 221 With -c:v copy ffmpeg cannot start anywhere except a keyframe. In this episode the last keyframe is at 1319.693 s and there is none after it, so every run whose -ss lands past it rewinds to that same keyframe and emits the same frames. That also predicts the count, and the prediction holds: the number of duplicated tail segments is the number of segment boundaries that fall after the last keyframe. With 6-second segments there are two (1320.000, 1326.000) and I get two identical segments; with 3-second segments there are three (1320.000, 1323.000, 1326.000) and I get three. I isolated the condition with four synthetic files that share the exact same arithmetic — 1326.336 s declared, 222 segments at 6 s, the last starting at 1326.000 — and differ only in where the last keyframe falls: last keyframe segment 220 vs 221 playback 1324.000 different (528,092 / 138,180 plays to the end 1320.000 different (907,664 / 351,372 plays to the end 1319.720 IDENTICAL, 366,788 B hangs at the end 1319.693 (real) IDENTICAL, 2,646,476 B hangs at the end 280 milliseconds of keyframe placement is the whole difference. If the last keyframe sits exactly on a segment boundary, or if there is another keyframe after it, the tail is fine. The synthetic that reproduces it, if you would rather build your own than take mine: ffmpeg -f lavfi -i "testsrc=size=1920x1080:rate=25" -frames:v 33150 \ -c:v libx264 -preset ultrafast -crf 32 -pix_fmt yuv420p -profile:v high \ -force_key_frames "expr:gte(t,9.693+n_forced*10)" -sc_threshold 0 video.mkv ffmpeg -f lavfi -i "sine=frequency=440:sample_rate=48000" -ac 2 -t 1326.336 \ -c:a ac3 -b:a 192k audio.mka ffmpeg -i video.mkv -i audio.mka -map 0:v:0 -map 1:a:0 -c copy sample.mkv That puts the last keyframe at 1319.720 with none after it. Play it, seek to about 20:00, and let it run out. It reproduces on both apps, and the segment md5s match the same way. One thing worth knowing, because it explains why this is hard to reproduce on demand: Emby Web on Safari swallows the duplicate and ends cleanly. So "it works for me" and "it hangs every time" can both be true on the same build, the same file and the same server. If the restart seeked to the keyframe that actually precedes the requested segment, and a segment were dropped when it cannot advance past the previous one, I believe this tail would end. Happy to run anything against this setup, I have it ready.

I guess compare to a web app url for that endpoint?

I am using the new Windows client. This problem started a couple months ago. When tuning in a TV station (tuner channel), the audio does not play properly - cutting in and out for approximately 30 seconds. Eventually it rights itself and sounds fine. This does not happen when I play a recorded TV show, for example. I am bitstreaming / passing through all audio through hdmi to a receiver. Audio being bitstreamed is typically dolby digital 5.0.

no, that's not enabled.

If it's on both sides yes.

Where exactly do they get this? can you please show a screenshot?

.54 is publicly released but I don't know why it would be any different in regards to this.

Okay here is where I am if I leave the port blank on the app I can connect to the server, most likely since the port is already set up on in the tunnel. Now when selecting a user and trying to log in receive the error access token is invalid or expired.

OK thanks that is how I understand it, but they could access emby if they had tailscale installed?

Yes

OK I looked at tailscale, only question I have is will everyone that uses my emby need to have tailscale installed on there device?

I'm still seeing this issue - the skip forward icon is missing. It renders a small white box which I assume to be the missing icon indicator. All other icons render as expected Emby App v1.0.51 (08/26/2026) LG webOS TV OLED65B8PUA (software v05.50.70) Emby Server v4.9.5.0