All Activity

Hi ebr, Thank you for the follow-up and for clarifying that no one was trying to target me. I appreciate that. I wanted to add a few important technical details that were not fully covered in my previous reply, because they directly explain both the similarities people noticed and why the two plugins should never be installed at the same time. **On the original development path** When I started this work, my goal was to create improved detection engines (particularly better OCR and proper AV1 support) that could plug into Yocker’s existing EmbyCredits plugin. That is why some of the high-level concepts, terminology, and even a few UI patterns ended up looking familiar — I was deliberately trying to stay compatible at first. As development progressed, two things became clear: 1. Yocker’s plugin was not handling my large AV1 library reliably, and 2. The architectural changes I needed (especially around frame extraction, parallel processing, and the OCR microservices) were substantial enough that it made more sense to build a complete, independent plugin. That is how EmbyVisionCredits came to exist as a separate project rather than just a set of engines for EmbyCredits. **What is actually original work** - The CPU and GPU OCR microservices were written from scratch (they are separate GitHub repositories). - The detection pipeline was largely rewritten to handle AV1 correctly and to support the performance characteristics I needed. - The plugin’s internal state handling, event registration, scheduled tasks, and overall architecture are my own. There is inevitable functional overlap because both plugins solve the same problem (detecting end credits and writing the markers Emby understands). Functional similarity does not equal the same implementation. **Why the two plugins must not be installed together** Even with unique GUIDs (which I have already changed), the plugins still conflict at a deeper level: - Both register for the same Emby events (`ItemAdded` / `ItemUpdated`). - Both maintain pending-episode queues and state. - Both extract frames and write the same chapter/segment markers that Emby uses for “Skip Credits”. - When both are active they can overwrite each other’s markers, fight over temporary files, and produce unpredictable results. This is visible in server logs when both are present — both start their own “Credits Detection Service” and both load the same pending episodes. It is a classic case of two plugins claiming ownership of the same subsystem. Users should choose one or the other, never both. I have already updated my documentation and releases to state this clearly. I remain fully respectful of the MIT license under which EmbyCredits was released, and of Yocker’s original work. Multiple independent implementations of a credits detector can and should exist, just as multiple implementations of other media tools exist. My intention has never been to diminish or claim credit for the foundational work Yocker did. Thank you again for taking the time to look at this carefully. I’m happy to provide any further technical clarification if needed. Best regards, EncryptedCity

Afer some deeper assessment, the answer has become more clear: For the time being, html/js is the only option for user settings.

Updated release notes for version 5.0.0.0 Trakt Air Dates Release Notes Version 5.0.0.0 Changes 5.0.0.0 Fifth ground-up rewrite — no longer depends on TheMovieDb provider's cache files, so provider updates can't break it Corrects already-downloaded episodes directly in the library, with automatic re-correction if a later metadata refresh overwrites them Corrects the Upcoming view for every client via a built-in listener — the only mechanism that can reach not-yet-downloaded episodes Upcoming responses now cached in memory and refreshed in the background — typically under a millisecond instead of waiting on Emby Upcoming no longer fails when Emby's own endpoint stalls: falls back after 15 seconds and completes the full list in the background Listener now retries automatically if its port is busy, and rebinds itself if it stops — a port conflict no longer requires a restart or leaves the server unreachable Settings page now reports retry attempts instead of appearing dead Emby's reported server address now corrected in both formats, so clients on Emby 4.10 don't drift onto the wrong port WebSocket connections relayed to Emby, so live updates and remote control work through the listener Plugin scripts can now be injected into the web client without writing to Emby's own web files — see below Diagnostic logging reduced, and credentials redacted from logs Plugin version now reported correctly in the plugin list and server log Renamed from Air Date Fixer to Trakt Air Dates, with a new plugin icon Web script injection Plugins that add behaviour to Emby's web client normally have to write into Emby's own dashboard-ui folder — which every Emby update wipes, and which Docker often blocks without a root chown. Trakt Air Dates can now serve those scripts itself and insert them into the page as it passes through, so Emby's files are never touched. Any plugin dropping a .js into plugins/webinject/ is picked up automatically. TV Show Status 2.5.12.0 uses this — with both plugins installed, its badge survives Emby updates with no chown and nothing to redeploy. Notes Tested on Emby 4.9.5.0 and 4.10.0.23 (beta), Docker on Linux. Survived that version jump with settings intact Upcoming corrections require moving Emby's own HTTP port — see the setup guide HTTPS and remote/WAN traffic bypass the listener and are not corrected The Android app may revert to Emby's real port after a restart; re-enter the address manually if Upcoming dates look wrong TraktAirDates.dll

The suggestion was to create an integration with HA. That has no "physically present" requirement and no automation that you could create in that regard would.

Thanks for the clarification. I haven't blocked you or intentionally disabled private messages, and as far as I can tell my messaging settings aren't preventing you from contacting me. I also haven't received a private message in several years, so I'm not sure what is happening with the forum messaging system. Regarding the plugin GUID, I have already changed it to a new, unique GUID, so there should be no possibility of my plugin being identified by Emby as the same plugin or interfering with Yocker's plugin because of the GUID. I also think there is some important context regarding the similarities between the projects. When I originally started working on this, my intention was actually to develop my own detection engines that could be used with Yocker's plugin. I wanted to maintain compatibility to some extent so that people could use the new engines without necessarily having to abandon the existing plugin. That is one of the reasons some of the features and terminology are similar. As development continued, I eventually decided to build my own plugin around the work I was doing. Part of the reason was that Yocker's implementation wasn't working well for my particular library. I have a very large AV1 library, and I needed the detection logic to properly handle AV1 content. A significant amount of my detection and processing logic has therefore been rewritten around that requirement. I've also built my own OCR microservices from scratch, including the CPU and GPU Docker implementations, which are available as separate projects on GitHub. Those services weren't simply taken from Yocker's plugin. They were developed as part of my own architecture so the plugin could communicate with dedicated OCR engines. The vast majority of the current project is my own development. There are certainly similarities in functionality because we're solving the same underlying problem, and there are a few areas of the UI that may look familiar. But similar functionality doesn't mean it is the same implementation. The underlying code, detection logic, OCR architecture, AV1 support, GPU/CPU handling, and microservices have been substantially developed in my own direction. And ultimately, credit detection itself isn't something that anyone owns as a concept. There can obviously be multiple implementations of a credits detector, just as there can be multiple implementations of other media-processing tools. I also want to be clear that I'm not trying to take credit for Yocker's original work. The original project was released under the MIT license, and Yocker stated that he was fine with me taking the project and doing what I wanted with it. I've respected those licensing terms and have been open about where the project started. This isn't intended to escalate anything. I simply wanted to explain why the projects have some similarities and how the project evolved from initially developing compatible engines into what is now a separate plugin with its own architecture and development. I appreciate you pointing out the GUID issue. That has already been addressed, and I hope this provides some of the context that may have been missing from the earlier discussion.

@ginjaninja - Can you retry with the latest web app (app.emby.media)? If it still fails, please restart Emby Server, reproduce again and post the server log. Thanks

I'd assume because "The Last House" has Release Date within 60 days (default) window. Edit: @Amanade3Could you pls add "Top Center" and "Bottom Center" positions for Badge (rounded pill) style selected, so it doesn't clash with/overlays with other treatments? Thanks.

TV Show Status Release Notes Version 2.5.12.0 Changes 2.5.12.0 Web badge now survives Emby updates — no longer wiped from Emby's web files (requires Trakt Air Dates listener) Web badge no longer needs a root chown on Docker installs Badge script now deployed to plugins/webinject/ as well as dashboard-ui Removed diagnostic logging that wrote a log line for every image request Plugin version now reported correctly in the plugin list and server log Fixed unreachable-code warning in the image enhancer Notes Running without Trakt Air Dates is unchanged — dashboard-ui is still used, and may need re-applying after an Emby update "Prepend status to show description" edits real library metadata, and remains off by default EmbyTVShowStatus.dll TV-Show-Status-Web-Badge-Instructions.pdf

Now I have downgraded to 4.8.10, which is equivalent to re-sweeping the library and modifying the metadata. See the attachment for the previous log. By the way, how to migrate the existing library and metadata when replacing the docker embyserver version? embyserver-63921649964.txt embyserver-63921800847.txt embyserver-63921695587.txt embyserver-63921694662.txt embyserver-63921669393.txt embyserver-63921669318.txt embyserver-63921665676.txt

If the only way to log in to the Shield is to be physically present, and the only way to log in to the UGOOS is to be physically present, and they're in the same room, there's no change in security if I get the logins synced.

Hi, I've been using Emby on a Apple TV 4K (2nd generation) for several months. Sporadically, I experience crashes when starting a stream whether it be from stored content or Live TV content. I cannot determine any pattern to when the app crash will happen - only that it happens at the start of the streaming session. The Emby app completely closes and then I can go in and start the same movie or live TV channel again and it will work fine. I'm currently running the latest Apple TV client and the latest server beta, but it also occurs on the latest stable server release. I'm happy to help get to the bottom of this. Below is the server log for a live TV stream as the client crashed. My guess is that it isn't very helpful other than indicating that the server lost communication with the client. Very much appreciate any help. 2026-08-09 11:05:24.638 Info PlaystateService-0HNNLNV55GBC2:00000006: http/1.1 POST http://host1:8096/emby/Sessions/Playing?X-Emby-Client=Emby for Apple TV&X-Emby-Device-Name=Apple TV&X-Emby-Device-Id=0B2265F9-14D4-4C09-ACD4-7E56068C0F71&X-Emby-Client-Version=2.0.7 (1)&X-Emby-Token=x_secret8_x&reqformat=json. Source Ip: host5, UserAgent: Emby/1 CFNetwork/3860.700.1 Darwin/25.6.0 2026-08-09 11:05:24.640 Info SessionManager: Playback start reported by app Emby for Apple TV 2.0.7 (1) on Apple TV playing ESPNU. Position: 0 ms. PlaySessionId: df77545def4943ef9a4926a21c7eb2d0. IsPaused: False 2026-08-09 11:05:24.641 Info PlaystateService-0HNNLNV55GBC2:00000006: http/1.1 Response 204 to host5. Time: 3ms. POST http://host1:8096/emby/Sessions/Playing?X-Emby-Client=Emby for Apple TV&X-Emby-Device-Name=Apple TV&X-Emby-Device-Id=0B2265F9-14D4-4C09-ACD4-7E56068C0F71&X-Emby-Client-Version=2.0.7 (1)&X-Emby-Token=x_secret8_x&reqformat=json. 2026-08-09 11:05:24.645 Info PlaystateService-0HNNLNV55GBCB:00000001: http/1.1 POST http://host1:8096/emby/Sessions/Playing/Progress?X-Emby-Client=Emby for Apple TV&X-Emby-Device-Name=Apple TV&X-Emby-Device-Id=0B2265F9-14D4-4C09-ACD4-7E56068C0F71&X-Emby-Client-Version=2.0.7 (1)&X-Emby-Token=x_secret8_x&reqformat=json. Source Ip: host5, UserAgent: Emby/1 CFNetwork/3860.700.1 Darwin/25.6.0 2026-08-09 11:05:24.646 Info PlaystateService-0HNNLNV55GBCB:00000001: http/1.1 Response 204 to host5. Time: 2ms. POST http://host1:8096/emby/Sessions/Playing/Progress?X-Emby-Client=Emby for Apple TV&X-Emby-Device-Name=Apple TV&X-Emby-Device-Id=0B2265F9-14D4-4C09-ACD4-7E56068C0F71&X-Emby-Client-Version=2.0.7 (1)&X-Emby-Token=x_secret8_x&reqformat=json. 2026-08-09 11:05:24.729 Info VideoService-0HNNLNV55GBC9:00000001: http/1.1 Response completed after client disconnected to host5. Time: 2887ms. GET http://host1:8096/emby/videos/80653399/original.mpegts?DeviceId=0B2265F9-14D4-4C09-ACD4-7E56068C0F71&MediaSourceId=xtream_live_1826_2c8d8ff1d88548899d8d2a234471098f&PlaySessionId=df77545def4943ef9a4926a21c7eb2d0&api_key=x_secret8_x&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_xtream_live_1826_2c8d8ff1d88548899d8d2a234471098f. Headers: Connection=close, Content-Type=video/mp2t, Date=Sun, 09 Aug 2026 15:05:23 GMT, Server=UPnP/1.0 DLNADOC/1.50, Transfer-Encoding=chunked, Cross-Origin-Resource-Policy=cross-origin, Private-Network-Access-Name=K Media, Private-Network-Access-Id=ae879ea1032e468a8c897afa1c2d5ae6 2026-08-09 11:06:24.645 Info SessionManager: PlaySession df77545def4943ef9a4926a21c7eb2d0 has gone idle while playing 2026-08-09 11:06:24.645 Info SessionManager: Playback stopped reported by app Emby for Apple TV 2.0.7 (1) on Apple TV playing ESPNU. Position: 58999 ms. PlaySessionId: df77545def4943ef9a4926a21c7eb2d0. IsPaused: False 2026-08-09 11:06:24.646 Info MediaSourceManager: Closing live stream 06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_xtream_live_1826_2c8d8ff1d88548899d8d2a234471098f 2026-08-09 11:06:24.646 Info MediaSourceManager: Live stream 06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_xtream_live_1826_2c8d8ff1d88548899d8d2a234471098f closed successfully 2026-08-09 11:06:24.646 Info SessionManager: Removed playSession df77545def4943ef9a4926a21c7eb2d0 from session f5a2397d7f582e0d2b96d2d4f96fcfc9

Yes - when GenericUI was created there didn't even exist any possibility for a plugin to provide "per-user settings pages". Everything is designed in a way to make operations and UI single-instance, so that long-running operations - like a TV tuner channel scan - do not get lost when you accidentally close the dialog - or the browser tab. Or when another admin would log in, they are supposed to see those operations, so they won't get to perform any conflicting operations. To serve user settings, a number of changes are required. The AI suggestion is not suitable - each user's view needs to be backed by a separate server-side instance.

@EncryptedCitymaking sure you saw this because it is very important. You clearly copied Yocker's plugin to start with but I'm not really sure why you took such offense when that was asked about because he said from the get-go that was fine. I don't think anyone was intending to target you. Carry on...

Also happens sometimes on latest beta.

The left bar on the dashboard page has been blank for sometimes. emby 2.2.56 ipados 26.6

I noticed separate users were seeing the same page instance on my user facing plugin even without using UIViewInfoChanged. Does any one have an example repository with good patterns for user pages with generic ui please? Hopefully not ai slop but claudes suggestion was below, basically suggested the need of "abandoning the GenericEdit/generic-UI-page framework for those [userfacing] pages" Summary: GenericUI command routing limitation (Emby 4.10.0.22) Component: Emby.Web.GenericUI (server-side C#) + modules/genericui/genericui.js (dashboard client) The limitation: Two separate but compounding issues make it impossible for a plugin using IPluginUIView/IPluginPageView (the GenericEdit-driven page framework) to reliably identify the calling user on a per-command basis. Server-side: no per-command user identity reaches the view. IPluginUIView.RunCommand(string itemId, string commandId, string data) — the interface every plugin page implements — has no user parameter at all. The host class that dispatches to it, PageControllerHostBase.RunCommand(requestItemId, requestCommandId, requestData, UserDto user), does receive the real authenticated caller from the API layer, but never assigns it to the view's User property before invoking RunCommand. IPluginUIView.User is only ever refreshed on GetUIView (initial page load / tab switch) — never on a postback. So inside RunCommand, a plugin has no reliable way to know who actually issued the command. Client-side: no way to route around it. genericui.js's runUiCommand() hardcodes every command from every plugin's generic UI page to a single fixed endpoint, POST UI/Command, regardless of which button or command fired. There is no per-button/per-command hook, override, or extension point for a plugin to direct specific actions to its own authenticated API endpoint instead. The command dispatch is entirely generic and not plugin-customizable at the transport level. Combined effect: Because UI/Command is a single shared endpoint whose server-side handler (PageControllerHostBase) also has one controller instance shared across all users of the server (keyed only by pageId, not by user/session — UIPagesManager.controllers is ConcurrentDictionary<string, PageControllerHostBase>), a plugin author has no supported way to build a multi-user-facing page (as opposed to a single shared admin config page) where each command execution can be confidently attributed to the correct calling user. The only available workaround is having the view privately track identity through data it stamps and asks the client to echo back on the next request — which works for legitimate use, but isn't something the SDK provides or guarantees, and could be spoofed by a malicious client since it isn't real authentication. Suggested fix for the SDK maintainers: either (a) have PageControllerHostBase.RunCommand assign CurrentUIView.User = user before calling RunCommand, using the already-available authenticated caller, or (b) add a UserDto parameter to IPluginUIView.RunCommand itself so plugin authors don't have to reconstruct identity by hand. https://github.com/ginjaninja1/recommendme Claude suggested a hot fix which seems to work outlined below applied to recommendme ## Emby generic UI pages are singleton, server-wide, per pageId — not per-user/session `UIPagesManager.controllers` is `ConcurrentDictionary<string, PageControllerHostBase>`, keyed ONLY by pageId. One instance of your `IPluginUIView` serves every user on the server. Anything stored directly on that view's `ContentData`/fields (search results, form state, etc.) is visible/overwritten by every other user — confirmed root cause of "user sees another user's search results" bugs. Worse: `IPluginUIView.User` (and `IUIView.User`) is ONLY refreshed by the framework on `GetUIView` (page load / tab switch) — `PageControllerHostBase.RunCommand` receives the real authenticated `UserDto` from Emby's API layer but never assigns it to `CurrentUIView.User` before invoking `RunCommand`. So `this.User` inside a page's `RunCommand` is not "who clicked this" — it's "whoever most recently loaded this page anywhere on the server." Do not use `this.User` for identity/authorization inside `RunCommand`. **Working fix pattern** (no adversarial/security requirement — trusted single-tenant use only): - Add an `OwnerUserId` field to the ContentData/view-model class, `[Browsable(false)]`. - Stamp it with `value.Id` in the view's `User` property setter (this only fires on `GetUIView`, which is trustworthy). - Because `PageControllerHostBase.RunCommand` deserializes the client's posted `data` string fresh on every call (this string is per-request, not shared), and the client always round-trips the full ContentData object back on postback, `OwnerUserId` survives the trip. - In `RunCommand`, deserialize `data` FIRST, pull `OwnerUserId` from it, and resolve the calling user (`IUserManager.GetUserById`) from that — never from `this.User`. - Keep per-user state in a `ConcurrentDictionary<string, TViewModel>` keyed by that same id, looked up in both the `User` setter and `RunCommand`. - `UserDto.Id` is a `string` (not Guid/long) — matches the `GetUserById(string)` overload. - No eviction is built into this pattern — the dictionary grows for the process lifetime. Fine for low user counts; needs `ISessionManager.SessionEnded`-driven cleanup at scale. My other plugin doesnt have the suggested fix, i mention it in case an example of a default case is needed. (to help explain what i might be dsoing wrong please) I asked the ai to consume the sdk and use the patterns in sdk demo to build the pages. Maybe there is a proper approach to user pages my ai isnt seeing? https://github.com/ginjaninja1/ManageComingSoon

Hi. I cannot reproduce this in the Android TV app. Used a mixed content library with 109 top level items and folder view. Came right back to where I was. Also unable to reproduce in the web app so may need more specifics like an app log from when this happens.

Hi. Not sure what new function you are looking for but the Android TV app has always scoped the search to the library you are in.

OK

Bit odd that Emby is allowing mp4+eac3 (& it plays correctly) but forces audio transcode with mkv+eac3! Let me know if you need any further logs or testing. I would be very happy to help get this fixed. I’m attaching a screenshot of what the iPhone is reporting as supported via Dolby’s test site. iOS is correctly reporting E-AC-3 support via the HTML canPlayType() API Thanks again

Small update (v2.9.6.7) Added ability to use locally installed Tesseract instead of being Docker only. Tesseract can be found at: https://github.com/tesseract-ocr/tesseract

Log 4.10.0.23 embyserver.txt

Hello, I have installed the latest version of the plugin on Emby 4.10.0.23. However, after adding two movies, I noticed that one appears under “Recently Added”, while the other appears under “New Movies”. Could you please explain why the two movies are displayed in different categories even though they were added at the same time? Thank you in advance for your help.

Thanks for reply! Okay... and I just wanted to know if the problem is on my end. It also seems that the plugin only finds the files where the chapters are integrated. With files where Emby itself inserts the chapters – for example, every 5 minutes – it doesn't find any intros, etc.

EmbyVision Credits – GPU Edition Resource Usage I wanted to post a quick look at what the GPU edition of EmbyVision Credits looks like while it is actually running. The video shows the Docker container logs while PaddleOCR is processing the video using CUDA. You can see the OCR service running and processing the frames instead of having to guess what it is doing in the background. For this test I was using an RTX 4060 8GB for the OCR container. The GPU usage was pretty reasonable. The OCR container was using roughly 400–600 MB of VRAM during the run, with GPU utilization going up and down depending on what it was processing. GPU temperature was around the low-to-mid 50°C range. The important part for me is that the OCR service isn't sitting there eating several GB of VRAM just to run. It leaves plenty of the GPU available for other things. The setup was: RTX 4060 8GB Ryzen 9 5950X 64GB RAM PaddleOCR CUDA GPU acceleration EmbyVision OCR running in Docker Emby running separately The OCR container is also separate from the Emby plugin itself. EmbyVision Credits sends the video/frame processing work to the OCR service, and the GPU container handles the actual OCR processing. This is the GPU edition I'm currently working on. I'm also working on making the GPU handling better for people who only have one NVIDIA GPU, since that's going to be a much more common setup than having a dedicated GPU sitting around just for OCR. I've included the video so you can see the actual logs and resource usage rather than just taking my word for it. Under the hood, EmbyVision uses several powerful detection engines working together rather than relying on a single detection method. Each engine has its own job, allowing the plugin to combine the results and make much more accurate credit detection decisions. GPU Edition users should have Emby Premiere if they want to use Emby's hardware-accelerated video processing. The EmbyVision OCR engine itself runs separately through the CUDA-enabled OCR service. EmbyVision Credits – OCR Edition EncryptedCity GitHub: https://github.com/encryptedcity/EmbyVision-Credits Latest released version 1.0.0.1 Video - GPU - logs.mp4 Video - EmbyVision OCR Credits V1.0.0.1.mp4