All Activity

im on 4.10.0.23, accessing via app.emby.media, i have restarted. using the sdk demo file picker i get 2026-08-09 19:46:22.256 Debug SystemService-0HNNM8M840TKN:00000004: http/1.1 GET http://‌192.168.4.107‌:8096/emby/System/Info?X-Emby-Client=Emby Web&X-Emby-Device-Name=Google Chrome Windows&X-Emby-Device-Id=87adfbe1-b000-4414-a87a-ec2c2a1e4a62&X-Emby-Client-Version=26.0.1&X-Emby-Token=‌4ab31f545fea4b4fa5201883e5398447‌&X-Emby-Language=en-gb. Source Ip: ‌192.168.4.107‌, UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36 2026-08-09 19:46:22.256 Debug SystemService-0HNNM8M840TKN:00000004: http/1.1 Response 200 to ‌192.168.4.107‌. Time: 1ms. GET http://‌192.168.4.107‌:8096/emby/System/Info?X-Emby-Client=Emby Web&X-Emby-Device-Name=Google Chrome Windows&X-Emby-Device-Id=87adfbe1-b000-4414-a87a-ec2c2a1e4a62&X-Emby-Client-Version=26.0.1&X-Emby-Token=‌4ab31f545fea4b4fa5201883e5398447‌&X-Emby-Language=en-gb. 2026-08-09 19:46:22.509 Info EnvironmentService-0HNNM8M840TKN:00000005: http/1.1 POST http://‌192.168.4.107‌:8096/emby/Environment/DirectoryContents?X-Emby-Client=Emby Web&X-Emby-Device-Name=Google Chrome Windows&X-Emby-Device-Id=87adfbe1-b000-4414-a87a-ec2c2a1e4a62&X-Emby-Client-Version=26.0.1&X-Emby-Token=‌4ab31f545fea4b4fa5201883e5398447‌&X-Emby-Language=en-gb&reqformat=json. Source Ip: ‌192.168.4.107‌, UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36 2026-08-09 19:46:22.510 Debug EnvironmentService-0HNNM8M840TKM:00000004: http/1.1 GET http://‌192.168.4.107‌:8096/emby/Environment/ParentPath?path=D:\Placeholder.mkv&X-Emby-Client=Emby Web&X-Emby-Device-Name=Google Chrome Windows&X-Emby-Device-Id=87adfbe1-b000-4414-a87a-ec2c2a1e4a62&X-Emby-Client-Version=26.0.1&X-Emby-Token=‌4ab31f545fea4b4fa5201883e5398447‌&X-Emby-Language=en-gb. Source Ip: ‌192.168.4.107‌, UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Safari/537.36 2026-08-09 19:46:22.510 Debug EnvironmentService-0HNNM8M840TKM:00000004: http/1.1 Response 200 to ‌192.168.4.107‌. Time: 0ms. GET http://‌192.168.4.107‌:8096/emby/Environment/ParentPath?path=D:\Placeholder.mkv&X-Emby-Client=Emby Web&X-Emby-Device-Name=Google Chrome Windows&X-Emby-Device-Id=87adfbe1-b000-4414-a87a-ec2c2a1e4a62&X-Emby-Client-Version=26.0.1&X-Emby-Token=‌4ab31f545fea4b4fa5201883e5398447‌&X-Emby-Language=en-gb. 2026-08-09 19:46:22.536 Error EnvironmentService-0HNNM8M840TKN:00000005: Error processing request *** Error Report *** Version: 4.10.0.23 Command line: C:\Users\Nicholas Bird\AppData\Roaming\Emby-Server\system\EmbyServer.dll C:\Users\Nicholas Bird\AppData\Roaming\Emby-Server\system\EmbyServer.dll -noautorunwebapp Operating system: Microsoft Windows 10.0.26200 OS/Process: x64/x64 Framework: .NET 8.0.29 Runtime: C:/Users/Nicholas Bird/AppData/Roaming/Emby-Server/system/System.Private.CoreLib.dll Processor count: 16 Data path: C:\Users\Nicholas Bird\AppData\Roaming\Emby-Server\programdata Application path: C:\Users\Nicholas Bird\AppData\Roaming\Emby-Server\system System.IO.IOException: System.IO.IOException: The parameter is incorrect. : 'D:\Placeholder.mkv' at System.IO.Enumeration.FileSystemEnumerator`1.MoveNext() at System.Collections.Generic.LargeArrayBuilder`1.AddRange(IEnumerable`1 items) at System.Collections.Generic.EnumerableHelpers.ToArray[T](IEnumerable`1 source) at Emby.Server.Implementations.IO.ManagedFileSystem.EnumerateFileSystemInfos(DirectoryInfo dir, Boolean recursive) at Emby.Server.Implementations.IO.ManagedFileSystem.GetFileSystemEntries(String path, Boolean recursive, FileSystemCredentials credentials) at Emby.Api.EnvironmentService.GetFileSystemEntries(GetDirectoryContents request) at Emby.Api.EnvironmentService.Any(GetDirectoryContents request) at Emby.Server.Implementations.Services.ServiceController.Execute(HttpListenerHost appHost, Object requestDto, IRequest req, Type serviceType) at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost httpHost, IServerApplicationHost appHost, IRequest httpReq, IResponse httpRes, IStreamHelper streamHelper, RestPath restPath, String responseContentType, CancellationToken cancellationToken) at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IRequest httpReq, RestPath restPath, String urlString, String localPath, String contentTypeInPath, CancellationToken cancellationToken) Source: System.Private.CoreLib TargetSite: Boolean MoveNext() 2026-08-09 19:46:22.536 Info EnvironmentService-0HNNM8M840TKN:00000005: http/1.1 Response 500 to ‌192.168.4.107‌. Time: 27ms. POST http://‌192.168.4.107‌:8096/emby/Environment/DirectoryContents?X-Emby-Client=Emby Web&X-Emby-Device-Name=Google Chrome Windows&X-Emby-Device-Id=87adfbe1-b000-4414-a87a-ec2c2a1e4a62&X-Emby-Client-Version=26.0.1&X-Emby-Token=‌4ab31f545fea4b4fa5201883e5398447‌&X-Emby-Language=en-gb&reqformat=json. the exception is produced after the filepicker is already populated successfully and then i go back into it.

HI, you currently cannot assign a tuner per user, but you could use parental controls to hide content: How to Hide Specific TV Channels, Edit Parental Rating or Set Tags

Hi, what exactly do you mean by android auto fails to detect Emby ?

hi, are you still having this issue with our latest app updates?

HI, are you still seeing this with Emby for iOS 2.2.56?

HI, are you still seeing this with Emby for iOS 2.2.56?

But if you specify Open Emby, then are you sure it has to be the default music player of the device?

Hi, not yet, sorry, but it's certainly doable.

@Cotignachas this helped?

HI, we can look at improving it. Thanks.

Hi, are you still having an issue with this with new downloads?

Hi, not yet but this is something we are planning on implementing. Thanks.

The good news is that the other issues you ran into are fixed internally now - plus some new (small) features coming...

Hi @softworkz Thanks for confirming. I feel like i am on "the bleeding edge" on plugin development, exciting times...but good to know where i need to look now.

alucryd - I could give it a try if you think the additional stuff I just posted doesn't change the situation.

My emby server is a proxmox VM that has a nvidia card passed through to it (for transcoding). I have several NAS that I have NFS shares on that I mount to the emby server. I've had issues with the server not seeing the nas for various reasons and so I have a script - /usr/local/bin/check-nfs-before-emby.sh (seen in the systemctl status for the service below) that ensures the shares are mounted before emby server starts and emails me if there's a problem. It doesn't use LD_LIBRARY_PATH. That is first in the startup of the service. Next is a conf (90-nvenc.conf below) that sets up for ffmpeg. It was added as I couldn't get the NVIDIA card to transcode properly (wasn't finding the right ffmpeg files). I used a AI chatbot to come up with the following:: [Service] # Sets the library path so Emby's bundled FFmpeg can find its dependencies # and the necessary Intel (libmfx) and NVIDIA libraries. Environment="LD_LIBRARY_PATH=/opt/emby-server/lib:/opt/emby-server/extra/lib" # Add a short delay to ensure the NVIDIA device files are fully initialized # before Emby attempts its hardware detection. This can fix timing issues. ExecStartPre=/bin/sleep 5 The service (systemctl status emby-server): emby-server.service - Emby Server is a personal media server with apps on just about every device Loaded: loaded (/usr/lib/systemd/system/emby-server.service; enabled; preset: enabled) Drop-In: /etc/systemd/system/emby-server.service.d └─10-nfs-check.conf, 90-nvenc.conf Active: active (running) since Fri 2026-08-07 10:16:29 PDT; 2 days ago Invocation: 5cff728e33e24ec68f9e5ea4fa4d6877 Process: 881 ExecStartPre=/bin/sh -c sudo /usr/local/bin/check-nfs-before-emby.sh || { echo "NFS mount check failed - blocking Emby startup"; exit 1; } (code=exited, status=0/SUCCESS) Process: 1428 ExecStartPre=/bin/sleep 5 (code=exited, status=0/SUCCESS) Main PID: 1431 (EmbyServer) Tasks: 265:245m (limit: 9385) Memory: 3G (peak: 3.3G) CPU: 27min 57.497s CGroup: /system.slice/emby-server.service └─5:245m1431 /opt/emby-server/system/EmbyServer -programdata /var/lib/emby -ffdetect /opt/emby-server/bin/ffdetect -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage em> And the service file /usr/lib/systemd/system/emby-server.service: [Unit] Description=Emby Server is a personal media server with apps on just about every device After=network.target [Service] EnvironmentFile=/etc/emby-server.conf WorkingDirectory=/opt/emby-server ExecStart=/opt/emby-server/bin/emby-server RestartForceExitStatus=3 User=emby [Install] WantedBy=multi-user.target [Unit] Description=Emby Server is a personal media server with apps on just about every device After=network.target /etc/emby-server.conf has a single comment line and nothing else.

Hi, thx for the plugin It is possible to bind a premium account or watch without ads ? Quality is good, tested on ATV 4K best regards

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