All Activity

By the way, it would be a nice feature to add a banner like that with custom tags!

This is what I do with an overlay on posters: It could be an idea, because having tons of icons on posters makes them look like christmas trees

Environment: Emby Server 4.9.3.0 (Linux, Ubuntu) Emby Windows App 2.234.2.0 (device: GAMING_X3D) Remote access via DDNS (subdomain.ddns.net:8096) User: meeko, isInLocalNetwork: False Setup: I have a custom HLS proxy service running on the Emby server at localhost:5081. My .strm files contain URLs like: http://localhost:5081/play/jujutsu-kaisen/3/7 The proxy resolves the actual stream source, fetches the HLS master playlist (m3u8), rewrites segment URLs to route through the proxy, and serves the rewritten HLS stream. This works perfectly in web browsers (hls.js handles it fine). The Problem: The Emby Windows desktop app cannot play these STRM files. It enters a rapid start/stop cycle and eventually shows an error or gives up. Observed Behavior (from server logs): 1. Emby tries DirectPlay first via original.hls - receives the m3u8 but fails: GET /emby/videos/143265/original.hls?...&PlaySessionId=8fe172fabe404d2cb072c0c60796c2cf HttpClient: GET http://localhost:5081/play/jujutsu-kaisen/3/7 HttpClient: Http response 200 from http://localhost:5081/play/jujutsu-kaisen/3/7 after 153ms Response 206 to 62.40.208.236. Time: 154ms. Content-Type=application/octet-stream, Content-Length=3467 The server fetches the m3u8 from the proxy successfully (3467 bytes), serves it to the client as application/octet-stream with a 206 response. But then immediately: Playback stopped - Position: 0 ms. PlaySessionId: 8fe172fabe404d2cb072c0c60796c2cf 2. App falls back to transcoding with TranscodeReasons=DirectPlayError: GET /emby/videos/143265/master.m3u8?...&EnableDirectPlay=false&EnableDirectStream=false &MaxStreamingBitrate=7000000&TranscodeReasons=DirectPlayError 3. Emby starts ffmpeg transcoding (DirectStream copy) from the proxy URL: ffmpeg -i "http://localhost:5081/play/jujutsu-kaisen/3/7" -c:v:0 copy -c:a:0 copy -f segment -segment_format mpegts -segment_time 00:00:03.000 ... 4. First segment takes ~10 seconds, then segments flow normally: GET /emby/videos/143265/hls1/main/0.ts - Response 200. Time: 9686ms (first segment!) GET /emby/videos/143265/hls1/main/1.ts - Response completed after client disconnected. Time: 19ms GET /emby/videos/143265/hls1/main/2.ts - Response 200. Time: 2ms GET /emby/videos/143265/hls1/main/3.ts - Response 200. Time: 755ms ...segments 4-15 flow normally... 5. But the app has already given up - it stops and retries the whole cycle: Playback stopped - Position: 8500 ms (barely started) Then immediately starts a NEW session, repeating steps 1-4. This loop continues multiple times. 6. ffprobe calls are slow (blocking PlaybackInfo responses): ffprobe -i "http://localhost:5081/play/jujutsu-kaisen/3/5" ... PlaybackInfo Response Time: 10686ms (blocked by ffprobe!) 7. Client disconnects during segment delivery: Response completed after client disconnected to 62.40.208.236. Time: 19ms. GET .../hls1/main/1.ts 8. One session briefly worked locally before remote retry killed it: When accessed from LAN (192.168.178.87, isInLocalNetwork: True), the transcoding actually started and delivered segments. But the app switched to remote mode and killed the session: # LAN session - segments flowing: Playback stopped - Position: 59999 ms (played ~60 seconds!) # Remote session - instant death: Playback stopped - Position: 0 ms Key Observations: The original.hls endpoint serves the m3u8 as Content-Type: application/octet-stream - should this be application/vnd.apple.mpegurl? The Windows app's native player seems to not understand the proxied m3u8 served as octet-stream ffprobe takes 7-10 seconds per STRM URL (it has to fetch the HLS stream to probe it), which blocks PlaybackInfo responses MaxStreamingBitrate=7000000 (7 Mbps) is the remote limit, but the first transcoded segment takes ~10s, causing the app to time out When accessed locally (isInLocalNetwork: True), the stream actually played for 60 seconds before being killed The app enters a rapid retry loop: DirectPlay attempt → fail → transcode attempt → first segment slow → app gives up → repeat Questions: When Emby serves a .strm file via the original.hls endpoint, does the Windows app expect a specific Content-Type? The server returns application/octet-stream for what is actually an m3u8 playlist. Is there a timeout for the first HLS segment in the Windows app? The 10-second wait for 0.ts (while ffmpeg fetches the source and starts segmenting) seems to cause the app to abort. Is there a way to set MinSegments higher so the app waits for more segments before starting playback? Why does the app work briefly when isInLocalNetwork: True (played 60s) but instantly fail when isInLocalNetwork: False for the same content? TV Apps Samsung, Android, Linux work perfectly!! Any guidance would be appreciated. Happy to provide ffmpeg logs or additional server logs.

Thanks, for teaching me how emby works Just wanted to say: I am sure my network is ok.

After making the changes to your proxy, Did you restart the TV?

X-Emby-Client=Emby for Samsung&X-Emby-Device-Name=Samsung Smart TV (LT27H390)&X-Emby-Device-Id=a492ee24-d43e-4ff1-9cef-f314366461e3&X-Emby-Client-Version=2.2.5

What app and version?

Hi. Sorry, we do not have that capability. We are designed for your personal media.

Hi. I doubt it very much because that TV is in the same network as other TV and server itself. where can I found client log to check it?

I think I am too Now what's you question?

Hi. No other streaming service is accessing content on your network and your server...

Hi. That would indicate that the TV is being blocked from reaching our server.

Genial

@Lukethx, please keep us updated. @js28194SURE i know it has an 1GBE connection. Sorry for not beeing clear. With an notebook and iperf i get full 2,5GBE over 3x 2,5 GBE switches. With the shield i get full 1GBE while not saturating my switches switching capacity. And as stated above, NO other streaming service has issues at all on the shield (and i am streaming also 4k DV HDR..., where the issue in emby occured on 1080p material).

Sorry to hear that, but can't help you with that. As I have never encountered your issue, and only know from what I have learned, from other issue like this on the forum.

can't find log shipping option on the client =(

proxied those two URL and still nothing (except new "readme.txt" file inside Logs folder. funny enought) digged to the logs - no errors. mb3admin got "200 OK" embydata.com the same it's only one TV with that issue. The server itself has a "Gold coin". what esle should I check?

@GrimReaper That site is awesome, been PRO on there for a while now But good looking out tho, thanx!

This all depends on your plugin choices Each plugin uses different sources. But start looking at your logs and proxy those adresses that fail, but only if you need than

Check here.

thanks. this is my country Is there a complete list of resources for Emby to work with somewhere so I can proxy them all?

Howdy! In my quest for awesome posters for my awesome media library i have found it hard to get my hands on decent collection posters, some are on TMDB, some on Fanart, so on my travelings on the world wide webb i have collected some collection posters so i thought i would share some here. The filesize is 3000 x 1500 and the format is PNG, each collection ranges from like 20-ish to just over a hundred each and attch some thumbs as samples. The collections are: Blade Trilogy Indiana Jones Hellboy Arnold Schwartzenegger Underworld Lord Of The Rings The Hobbit Middle Eart (LOTR +Hobbit) Alfred Hitchcock Evil Dead Batman TRON Totalfilesize is 670MB so i have added a link to Google Drive. https://drive.google.com/drive/folders/10CEnIEJpyXgLPVMPI9xGqwYmrep0yV0-?usp=sharing Enjoy Folks!

Luke; This is still an issue and I have been following the discussion with hamah and I see there has been no updates since December 20, 2025. I have been carefully monitoring to see if the cause might be due to too many concurrent connections, but I have no evidence this is the cause. I am reluctant to say that if I am paying for Premier but cannot use the most essential feature (recording) reliably, I will need to cancel my subscription. I would like to support your efforts, but I cannot afford to pay for something that costs me almost $7CAD/mnth. Let me know if there is anything else we can do before I cancel tomorrow.

sorry, no news

Yor also have issues connecting to fanart.tv. Connection to https://assets.fanart.tv/fanart/world-war-z-5227bffd7a8bc.jpg timed out