All Activity

## 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.

I believe the top priority is to immediately fix the logic issues and resolve the system crash. 1. Regarding images in the media library, the system should not generate graphics based on the currently opened image—as this slows down access speeds—but should instead display the original image first and then replace the images one by one. 2. Investigate why the plugin's scheduled task function is getting stuck.

I started the set up and had a password issue and a friend who already has emby and plex helped get it up and running.

Glad you like it.. Be sure to check out and enable the Halloween seasonal theme. I think it's my favorite.

It was precisely because the images went missing after the plugin update that I needed to scan the media library.I think this is crucial.

Quick Start

As you have noted, OPUS playback is inconsistent across LG models, and even on supported models playback isn't always reliable. This is why we disabled it for DirectPlay, and even your test by disabling "Allow audio transcoding to a compatible format, if necessary, during media playback" confirms this, which is the right way to test this. As to why it is starting part way through, that sounds like an issue with the transcoding process. I don't see anything of concern in the transcoding log from your earlier post. Does this occur with all Opus audio files, or just some? It could be an issue with the way the file has been encoded? You can send me a file via PM which I can test on a few of my devices to see if I can reproduce.

The database needs to have been scanned fully before the pre-draw posters works. Please report back if the rest works as it should, plus please try the version i posted here a few threads back if you encounter any problems. Thanks for answering and for your help!

That isn't always a good fix. Emby can run on a very lowpower server/NAS, as long as it doesn't need to transcode. And Emby supports a "hardcode when subtitles aren't supported". I don't think there is a good way to automate "hardcode subtitles when the tv CPU struggles with certain effects".

I’m new to this i require a server invite

Basically, the Emby Theater app for Android seems to download whatever it wants. This is how i downloaded the content: Open the episode directly. Select the "HD" version. Press the download button. I did this to specifically ensure that Emby is not just downloading the UHD version when i download the whole season or multiple at once. I have these different versions for very different purposes. One 4K for my HDR capable devices and one 1080p for compatibility, lower bandwidth and most importantly situations where i want to watch SDR content. However, this is what i end up with in the Android app: As you can see, the app downloaded the 4K version and saved it as "- HD" which is wrong. If it downloads the best quality or "generic" it should omit the suffix or at least use the correct filename. The "Split Versions Apart" button does nothing but load because there is no other Version merged into this container format, it has the exact same size as the UHD file on the server. I would need an option to download the version >I< want. I wanted the HD version specifically because watching HDR content on a train on a sunny day is just not fun as my Pixel 9a just is not bright enough so in dark scenes i am looking like i am inspecting my smartphone very very thoroughly. Kind Regards

Feel free to ask anything; I will do my best to accommodate you. The database scan isn't finished yet, so I'm not sure if everything is working correctly, but the pre-draw posters are still stuck at 0%.

So the latest 5.61.0.2 beta works as it should? Sorry for all the questions, i just want to be sure.

The issue started after the automatic upgrade to version 5.61.0.0; that update caused the media library to fail to load. I have since switched to version 5.61.0.2-beta and enabled the "Pre-draw posters" feature, and I am currently running the native Emby media library scan.