All Activity

I upgrade to the latest release and I see in the service startup: Aug 01 11:13:33 Emby sh[1632]: /bin/sh: /opt/emby-server/lib/libc.so.6: version `GLIBC_2.38' not found (required by /bin/sh) Aug 01 11:13:33 Emby sh[1632]: /bin/sh: /opt/emby-server/lib/libc.so.6: version `GLIBC_2.33' not found (required by /bin/sh) Aug 01 11:13:33 Emby sh[1632]: /bin/sh: /opt/emby-server/lib/libc.so.6: version `GLIBC_2.34' not found (required by /bin/sh) And of course the service fails to start. This is on Debian 6.12.94-1 (2026-06-20) x86_64 (not docker) I saw this trying to upgrade from 4.9.3.0 to 4.9.4.0 and to 4.9.5.0

How are your files named and organized?

Right now there are no plans to remove but the list of features that don’t work with it is likely to grow over time.

Hi, we might be able to add this to CarPlay but the lock screen is an Apple UI that we can’t control.

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

Something still isn't making sense. You imply if 'default' pref is off, then the device decides. But in my case the AC3 track is supported. Thanks for the info - I learned some things. I can't explain what happened and probably isn't worth chasing in this case. I'll have to monitor.

This: If you always want the "default" to play you would select that option. However, that could cause remuxing/transcoding when it isn't strictly necessary. In the above screenshot, the device probably doesn't directly support the audio codec of the first track so it selected the second one to direct play.

Exactly what happened when you tried that?

The output steam 1:1 is the subtitles. 8.464MB buffer. There are 3 subtitles muxing into this space from your log. If each takes up the maximum it would equal 12 which exceeds the buffer. Not sure if that is what this means the buffer size is for all the subtitles combined or just the 1. But the issue comes down to the subtitles sidedata being too large. If you remove some of those subtitles that will never get used it might make it easier to play that item. ffmpeg allows the flag -max_muxing_queue_size to change the queue size larger. But that is at the cost of memory leaking. The main reason that error comes up is to prevent memory leaks so ffmpeg crashes rather than continue out of bounds. This is happening for a reason. Maybe @softworkzknows best?

You mean this?

We already have the option to not record episodes that are already in the library.

FFmpeg log says "TranscodeReasons=SubtitleCodecNotSupported". What about the issue?

Hi, not yet sorry.

Hi, what is your question?

Hi, please attach the complete Emby server log without cutting it from any specific moment. Thanks.

Hi, what did the stats feature list as the transcoding reason?

How have you configured your Emby user audio settings?

Your Caddyfile is fine — that two-liner is really all Emby needs, so the problem is almost certainly setup, not config. A few things to check, roughly in order of likelihood: 1. This line in your logs is the biggest clue: ▎ server is listening only on the HTTPS port but has no TLS connection policies With a plain yourdomain.tld { ... } site block you shouldn't see that warning at all — it means Caddy isn't actually serving TLS for your hostname. If you're using an env placeholder like {$DOMAIN} in your Caddyfile, check that it's actually set inside the container (docker exec caddy env), or just hardcode the domain and restart Caddy. Could also be a stray typo in the site address. Maybe post your Caddyfile with the real structure (redact the domain itself), that would help. 2. How are you testing? If you're opening the domain from inside your own LAN, many routers fail at this (no NAT loopback / hairpin NAT). Try from your phone on mobile data — if it works there, that's your answer. For local access you'd then add a DNS override on your router or Pi-hole pointing the domain at the Pi's LAN IP. 3. Is port 80 forwarded too? Cert issuance can succeed over 443 alone, but if you type the domain without https://, the browser hits port 80 first — no forward there means a timeout that looks like "nothing works". 4. Do you have a real public IP? Compare the WAN IP your router shows with what whatismyip tells you. If they differ you're behind CGNAT and no port forwarding will ever work — you'd need a tunnel (Cloudflare Tunnel, Tailscale etc.) or ask your ISP for a public IP. 5. Docker port mapping: make sure your compose publishes 80:80 and 443:443 (plus 443:443/udp if you want HTTP/3). If none of that helps: what exactly happens when you try — timeout, connection refused, a Caddy error page, or an Emby error? And what does curl -v https://yourdomain from outside show? That narrows it down quickly.

So, as we all know, there are multiple ways to initiate downloads. There's the "down arrow" download option that immediately initiates downloads. We've tried that one, to no success. There is also the option of "download to..." where you can decide what device you want to download to, what bitrate you want it to download as, if you want to automatically download new material that is added, and for videos you get the option to ignore episodes already watched. We've tried that way as well. I have initiated the download to my device, I have initiated the download to my daughter's device. I have adjusted the bitrate down and up, I have toggled the option to automatically download new content. No of these options has worked. The next way you can download is if you initiate it from the server itself onto the external device. We have tried that method as well, with no success. Attached is a screenshot from how we try to download from the server itself, using the "download to..." option.

Hmm I found something peculiar in the Emby server log: /app/emby/bin/ffmpeg -loglevel +timing -y -print_graphs_file "/config/logs/ffmpeg-remux-06a47e9b-6f71-4de6-9ae5-e81904c920ab_1graph.txt" -copyts -start_at_zero -f matroska,webm -ss 01:13:00.000 -noaccurate_seek -c:v:0 h264 -noautorotate -i "/data/media/movies/X-Men Days of Future Past (2014)/X-Men Days of Future Past (2014) [imdb-tt1877832][Remux-1080p][DTS-HD MA 7.1].mkv" -map 0:0 -map 0:1 -sn -c:v:0 copy -bsf:v:0 h264_mp4toannexb -c:a:0 eac3 -ab:a:0 384000 -ac:a:0 6 -metadata:s:a:0 language=eng -disposition:a:0 default -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -map_chapters -1 -segment_format mpegts -segment_list "/transcode/transcoding-temp/61D6A6/61D6A6.m3u8" -segment_list_type m3u8 -segment_time 00:00:06.000 -segment_time_delta -01:13:00.000 -segment_start_number 730 -break_non_keyframes 1 -individual_header_trailer 0 -write_header_trailer 0 -segment_write_temp 1 "/transcode/transcoding-temp/61D6A6/61D6A6_%d.ts" This is the ATV app playing the movie. It seems that the Emby server is remuxing the audio, just like the universal android version. Could there be somehow a technical naming error in the UI in ATV? It shows direct-play for audio but in fact it is remuxing it. I am really confused now

I’m using a Vortex TV with VIDAA operating system, i cant find any Emby app. suitable for my Tv either on their app. store or on Emby website, and using the internet browser doesn’t allow me to scroll horizontally on my Tv, also using the Tv Mode from Emby online app. has similar issues and it hides the side menu .

Hmm. ATV is running on a Shield with 5.1 output. I guess my PC for web app has stereo. I don't see any pertinent audio settings in either app. This is a strange one because the 5.1 track normally is set by default. If I change the track in one app, will other apps inherit that change? Or does each app keep its own title settings?

Yes...

But does normal playback on an Android phone consume Premiere?

I ripped a DVD then encoded to HEVC in MP4 wrapper and included the subtitles. ATV (on my Shield) won't display the subtitles during play. Web app and std Android app does. When I do the same with recorded TV ATV will display the subtitles. Are subtitles from a DVD not working a known issue with ATV? I assume the reason Emby had to transcode is only because of the subtitles? Never would have I thought but I don't know much about subtitles. embyserver.txtffmpeg-transcode-73ee1824-23f8-44a4-b711-d92040c03d1b_1.txt