All Activity

there should be an option to include all specials

here you go embyserver (1).txt

This is correct though...

Should per user weekly watch time limits be working for web client for 1.5.8.0? I set a 2h limit for one user, Watching Eye shows "Weekly: 3/2h", but I can still start watching new episodes with that user on Emby web client. I also tried setting a time out and that doesn't work either. On Android the both the limit and the timeouts are working.

Bump?

Ok worth a try

Hi, it does support strm. All Emby apps support strm.

Hi, there is currently no way to control this in the windows app, but more options are possible for future updates. Thanks.

HI there, can you please provide a specific example? How to Report a Problem Thanks !

But this example does not have any critical to story tagged specials. Compared to my Bleach example So only items that contain this "critical to story" tag gets positioning data from TVDB.

Would need specific example and enabled library metadata order.

Well they dont show up for me and they are movies that are critical. They don't show up in mu up next section or in the seasons. The show im watching right now is inuyasha and the movies dont show up anywhere except in the specials section

+1 for banners! with "coming soon" banners, release in <x> days, released <x> days ago, etc.

It wasn't really removed it was changed to only get specials "critical to story" positioning data from TVDB. So all other specials require manually applying positioning data.

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 xx.xx.xxx.xxx. 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 xx.xx.xxx.xxx. 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. Sorry for not being clearer about this. 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?