All Activity

Hi, any time I try to use the identify option to match a show, it never works till the 3rd time I try to match it. The weird thing is that it always takes 3 tries and only 3 tries. If I try one or 2 times, I get an infinite busy symbol.

Hi, I don't know why you guys removed the option to show specials among the season episodes. This option is crucial in anime. To remove the option to toggle it on or off is totally dumb and serves no purpose except to disregard the people who need this option on. This is one of the only reasons I use emby and without this option, I might as well go with plex seeing as it's free. to take options away from paying customers is disconcerting.

Hi! Does it work on macOS?

very good question. first time I restarted the App only - that have to be enough to get new net config. This time I power-cycled TV to get three minutes complete power-off (cord is unplugged) but nothing changed.

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. If it happens again, i will upload another log.

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?