All Activity

I provided a log, and it has zero downloads...

You could try setting the option in the ui instead of the config file.

Folder view shows physical folders. I want a symbolic link to an item so I can have a single item in multiple collections.

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

Yep apologies as I edited it I realized that but couldn't delete post

playback error only seems to be on h264 codec everything else plays fine, started on .64 update.

There may not have even been one submitted yet according to Luke's comment in the link below on Thursday. If one has been submitted then Google just got it and it will be some time.

I didn't make this thread (or the scripts) to "blame someone".

@stuartafix you permissions

@horstepipeShow us you compose file.

Hi all, I've just copied this to my Synology plugin location but on restart it doesn't seem to appear

Hi @Luke I moved to Emby for Docker. I can't reach the plugin catalogue, seeing this error: "Connection to https://www.mb3admin.com/admin/service/EmbyPackages.json timed out" So I changed the existing DisableOutgoingIPv6 setting in /config/config/system.xml from false to true while the container was stopped. This causes Emby to exit immediately. Log doesn't really help, I am seeing just three lines there: 2026-10-04 15:21:41.073 Info Main: Application path: /system/EmbyServer.dll 2026-10-04 15:21:41.120 Info NetworkManager: Adding event handler for NetworkChange.NetworkAddressChanged 2026-10-04 15:21:41.258 Info Main: Shutdown complete I moved back to my local instance on the same host and it is working fine there. I am using --network host parameter for docker. Everything else seems to work fine there. BR

If it at the very least makes a report system possible then i will be all smile.

## Environment - Caption stream metadata: `Codec: eia_608, IsTextSubtitleStream: true, SubtitleLocationType: VideoSideData`, index 100. It looks like AVPlayer's caption parsing for in-band 608 in a **progressive MPEG-2 TS** decodes the initial buffer and never processes subsequent caption data (in-band 608 handling is well supported for HLS/H.264 SEI; the progressive-MPEG-2-TS case appears unhandled or stalled). ## Finding 3 — no extraction fallback for live TV Every `live.m3u8` request in the session log (all clients, ~18k requests) negotiate `SubtitleMethod=VideoSideData&VideoSideDataSubs=100&ManifestSubtitles=vtt` — i.e. captions are only ever carried **in-band**, and the `ManifestSubtitles=vtt` request never yields a WebVTT rendition for live streams. The transcode commands carry `-sn`. Server user policies expose no burn-in option per user. So when the in-band carrier is lost (Finding 1) or the player can't decode it (Finding 2), there is no third path — **a 608 → WebVTT extraction option for live TV would resolve all of the above**. ## Workaround that works today Set the Apple TV app's player to **MVP** (the mpv-based player) and DirectStream the source (Max quality). mpv decodes the EIA-608 captions in software from the raw TS and renders them live: - Captions update continuously (verified minutes at a time) - Zero server transcode — the MPEG-2 stream is played as-is - Quirk: after starting a session, the caption track sometimes needs to be re-selected (CC off → CC1) before mpv begins decoding — first selection at stream start appears to bind before caption decoding attaches Android-family apps also expose a player choice; the same mpv route should fix captions there. ## Requests (in priority order) 1. **A53/CEA-608 caption injection for hardware H.264 encoders** in the transcode pipeline (VAAPI/QSV/NVENC), or transparent caption carry-over where the encoder supports user data — closes the silent caption loss for all HW-transcoding clients. 2. **Live TV subtitle extraction (608/708 → WebVTT)** as a server fallback when captions can't ride in-band — would rescue every affected client/player combination, including AVPlayer. 3. Investigate **in-band 608 decode stall in the Apple TV native player** on DirectStream of live MPEG-2 TS (Finding 2). 4. (Minor) AMD VAAPI intermittent `Access unit too large / Encode failed: -28` on live HLS transcodes, which surfaces the otherwise-unreachable software fallback. Happy to attach the full ffmpeg transcode logs and session log excerpts on request.

Extremely unpopular opinion, but upgrade your potato hardware. God. We've been dealing with this for decades now with fansubs and their fancy karaoke, and this is 100% a "you/we" problem in the fact that you/we the user made the choice to watch something with so much fancy scripting and fonts that it made the device we're watching it on gasp for breath and ask for mercy. I got sick and tired of my media devices not being able to render fancy subs and just decided to build media pc's for the areas where I watch my anime. This is not and has never been an Emby problem, this is a content problem. Even the Nvidia Shield falls to its knees on this content. If you want to blame someone, blame the media companies for making such weak devices for media playback, not Emby, or blame yourself for wanting to watch something that is so god dang awesome. This is sadly not the solution, it's just a band aid. We need far stronger media devices, or a means to make subtitle handling multi-threaded, as it's currently single thread only. FYI you'll run into the same problem if your device doesn't support PGS subs, as they are image based.

any chance there is another way? Thank you

I hadnt appreciated the user function was being disabled. thanks for for clarifying. Hopefully it will come back even stronger in the not too distant future

Yes but with great power comes great responsibility... We have to be very careful with this kind of thing but we are starting to build some things that will help us with that.

And the input data to train it. Without that, it never would have worked. The fact that the Internet came into being and we decided to digitize and make available most of human history there was a huge accelerator (completely ignoring the IP situation).

Hi, I do realize it has to be approved, but its been almost a month and a half since v5.3.55. This seemed like an unusually long time, so this would tell me there is an issue of some sort. However, i did find this on the Emby for Android changelog: "Important: The version in the store will generally be a few versions behind the downloadable APK's." So it seems this is expected behaviour. I missed that. Thanks.

No change after updating the server to 4.11.0.5. New log attached. It has to go through Google approvals first, which takes time. And no, nobody knows how much time. embyserver.txt

Hi all, I have a question unrelated to the Playback Error mentioned above. Does anyone know why new android tv app versions are not getting pushed to the play store ? The latest version i can download from the play store is 3.5.55 (In my region at least, central europe). This version does not include the many fixes/improvements that have been made for the spotlight feature, for example. Obviously i know i can manually install the APK, but this is not as feasable for non-techy users. Is it available in other regions? I'd apreciate any input. Thanks.

@AnsellI might have found the problem and fixed it. If you feel like testing it's the last beta version 5.61.0.3 in the catalog.

Hi Luke, thanks for looking at this. It's already solved on my side: renaming the PC to an ASCII-only name fixed it, hence the "fixed" tag. The exception (Request headers must contain only ASCII characters, thrown in GetReadySyncItems) comes from the client app log, and as far as I can tell the request is rejected locally before it is sent, so the server log shouldn't contain anything related. I mainly posted this as a heads-up for others with the same symptom. Suggestion: please consider encoding the device name in headers or showing a clear error message.

The plugin only reacts to what Emby tells it, having Emby first add it's image and then the plugin after that would be messy. I optimized some aggregation and image drawing more for speed in the version that you mentioned, i think i might have cause a problem for your system with that. The version uploaded here doesn't have those changes so should not cause the problem. Sadly hard to find out what is wrong without a log file, when you are done with the current tasks in Emby you can upload the log from that and i will look at it.