All Activity

@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

Howdy folks! I have become a Wrexham FC fan, much from the docuseries and I have been trying to find out where/wich channel in Europe/Sweden its available on IPTV, i have been mailing their HQ in Britain but no answers from them at all and im not that knowledgable when it comes to IP-TV in general and sportachannels in perticular. Sky Sports i read somewhere but havent been able to confirm. Any help would be much appreciated. N/

Thanks, found it, but found nothing about changes in the search feature; did I miss something?

Well, emby app just stoped working on my philips titan os tv. When i click on emby icon only emby logo is shown and nothing happens... and there is no cleare chace or uninstall option on app menu..

0.0.0.6 Bad bug fix, Emby changes ListItemEntryIds for every member when 1 member is added to the playlist. Plugin now handles.

/data/userplaylists and then I created a directory same name as the playlist and then the m3u modified in it:

Hey, Since the beginning of ages I remember Emby clients have difficulties remembering the scroll position when browsing general videos/pics. Imagine you have 1000 folders you are browsing, you enter some, then you go back and your scroll position is lost and you are back at the top.. annoying. How to reproduce on any client - library with general videos: enter folder with many subfolders - e.g. 100 at least navigate to some folder and play the video then stop the video and go to parent folder - scroll is 100% lost! - you go back to the top or in the parent folder scroll to the middle and delete some folder - scroll is 100% lost! - you go back to the top This does not happen with Jellyfin or Plex. Only with Emby on Android phone, Android TV, Web browser.. Please make it finally fixed across all clients. If you wanna delete most of the videos it is very obstructing to always be scrolled to the top. Thanks!

added a guid generation workflow event for plugin.cs

@Luke@NeminemThanks so much for pointing me in the right direction. I followed the instructions and deleted "library.db-shm" and "library.db-wal". Fingers crossed that fixed it!

UPDATE: Tested on Emby 4.9.5.0 and 4.10.0.23 (beta channel), in Docker, on Linux. It survived that version jump with settings intact and needed no changes. Other versions and platforms are untested — which is rather the point of a beta, but please mention your setup when reporting anything Emby performance note (separate issue) /Shows/Upcoming intermittently takes ~120s instead of ~0.1s. Investigated at length 25–26 July: not caused by plugins, TheTVDB, host resources, or Emby version (4.10.0.19 vs 4.10.0.20 — GetUpcomingEpisodes byte-identical). Emby's own log shows ~8,864 sequential TMDB HttpClient calls in a 6-minute window, each ~100ms apart, all "served from cache" — enough serialized latency to explain the stall. Root cause unconfirmed. Still present on 4.10.0.23 — reported to Emby (7 Aug 2026) Confirmed unchanged, and this time cleanly isolated: a single Emby container, request made directly to Emby on 8098with the plugin entirely out of the path, same ~120s failure. Two failures also seen through the listener at 121915ms and 120638ms. The 4.10.0.23 changelog contains nothing addressing it (search performance and a SQLite bump are the only performance-adjacent entries). Reported to the Emby team; awaiting a fix. This isolation is what the July investigation lacked — specific version, single instance, plugin excluded, reproducible timings. PDF information update Trakt-Air-Dates-Beta-Tester-Guide.pdf

was just a typing, it is 4.9.5.0, so there is no update

Hi Luke. With the latest beta is now working fine with some other errors, i attach the logs just in case. Thank you embyserver.txt

I released version 1.0.0.1 today https://github.com/encryptedcity/EmbyVision-Credits Feedback, testing, suggestions, and bug reports are very welcome!