All Activity

I agree that this should be a fairly basic/standard function in this day in age. It should be brought down to the Emby Connect account level for that user to manage the sign-ins and not dependent upon the server owner having to remove devices from the server side.

HI, are you trying to connect to your own Emby Server, or someone else's server?

And this is why I said that people here were making a mountain out of a molehill, and yet they still thought they knew better..

Update — progress since the original post Quick update for anyone following along (and the folks who've already put their hand up — thanks!). Things have moved on a fair bit since I first posted: A web app is coming — so it won't be Android-only. This is the big one. The original post said Android-only with iOS "a much later maybe." That's changed: I'm building a browser-based web app (PWA) that'll run on iPhone, iPad, and desktop — anything with a browser. It works because the heavy lifting already lives in the backend; the app just asks it for playlists and streams audio straight from your Emby server. A couple of people mentioned they don't run Android phones, so this opens it up to everyone. It's early days, but it's actively in progress. Volume normalisation. One I didn't mention first time round: the app levels playback so a quiet track and a slammed modern master sit at a similar loudness (like Spotify/Tidal do), using loudness the backend measures during analysis. On by default, one toggle to turn off. On-device token encryption — done. I flagged this as a known rough edge last time. Your Emby session token on the phone is now encrypted at rest (Android Keystore), with a seamless migration so you stay logged in. Rolling into the next build. GPU acceleration for the analysis worker. If you've got an NVIDIA card, the worker can now use it (it logs device=cuda on startup) — a big help on a large library. How you enable it depends on the worker's OS: on Linux, the Docker CUDA worker (TORCH_VARIANT=cuda + --gpus all); on Windows, just run the worker natively with the CUDA PyTorch wheel (no Docker faff). Either way it auto-detects the card. CPU still works everywhere — it's just slower. Snappier + more polished. Faster library browsing (cached so reopening is instant and lighter on your server), the Sonic Adventure screen now scrolls as one smooth list, and various smaller fixes from real tester feedback. Marching toward a cleaner public release. Release-build hardening (smaller, optimised, properly signed APK) is now in place behind the scenes — groundwork for when this eventually goes public. Still looking for a few more testers — especially anyone with a GPU (I'd love more confirmation of the CUDA path on different cards) or a big library. Same deal as before: reply or DM with a rough picture of your setup (Emby host OS, GPU or not, library size) and I'll send you the files + repo access. Cheers — still very much a labour of love. It's a private GitHub project, so if you send me your GitHub username I can add you and send further info

The relevant difference is that for JF, an actual exploit existed for RCE, while for all others the severity level was evaluated as disruption of service at max and even that wasn't quite accurate - at least for Emby, because FFmpeg is always run out-of-process and when it would crash, it still doesn't tear down Emby Server.

Nice! Thank You.

Can you tell me which Font you used for these? They look great by the way. Thanks!

Hi, I would like to report an issue that I was able to reproduce with the TheIntroDB plugin on Emby Server 4.10.0.16 beta running on Synology DSM 7.2. At first, I thought the issue was related to Emby's Restart option or to the Synology package itself, because Emby remained stopped and did not start back up automatically. However, after more testing, I found the actual way to reproduce the problem. The issue happens when I add new content to a TV library, for example a new season or new episodes, and then Emby starts scanning/processing that content. At that point, TheIntroDB is automatically triggered for the new items through item_added / item_updated events. After that, Emby stops completely. It does not restart; the package remains stopped in Synology DSM and I have to start it manually from Package Center. In the log embyserver-63918344396.txt, the issue can be seen while new episodes from the series From are being scanned. For example: TheIntroDB: On-demand segment fetch completed (item_added) for El Corazón es un Cazador Solitario: 2 segments, markers applied TheIntroDB: On-demand segment fetch triggered (item_updated) for Los Mejores Planes (Episode) TheIntroDB: GetMediaSegmentsAsync called for ItemId=706fcf54-7b5f-b1e0-145d-8831a245ebe8 TheIntroDB: Episode: Name=Los Mejores Planes, Series=From, S4E7 TheIntroDB: Fetching from TheIntroDB API TheIntroDB: On-demand segment fetch triggered (item_added) for Los Mejores Planes (Episode) After that activity, Emby stopped. The next log, embyserver (1).txt, is already the next Emby startup at 15:39:56, after I manually started the package again. To confirm the cause, I uninstalled only TheIntroDB and repeated the same test: I added new content to the TV library and ran the scan. This time Emby did not shut down, and the content was added correctly. So I can confirm that, at least in my environment, the issue was related to TheIntroDB. There is also an earlier log where this error appears during Emby shutdown: System.Threading.SynchronizationLockException: The lock is being disposed while still being used at System.Threading.ReaderWriterLockSlim.Dispose(Boolean disposing) at TheIntroDB.Data.TheIntroDbSegmentRepository.Dispose() at TheIntroDB.EntryPoints.TheIntroDbChapterMarkerPersistenceEntryPoint.Dispose() at Emby.Server.Implementations.ApplicationHost.Dispose(Boolean dispose) Looking at the plugin code, this seems to match the behavior observed. TheIntroDbChapterMarkerPersistenceEntryPoint subscribes to ItemAdded and ItemUpdated, starts OnDemandFetchAsync, and during Dispose() it calls _segmentRepository.Dispose(). In turn, TheIntroDbSegmentRepository.Dispose() calls _lock.Dispose(). My impression is that when new content is added and TheIntroDB starts processing several episodes through on-demand operations, something may remain active using the lock or waiting for it. Then, when Emby tries to shut down or the process fails, the lock is disposed while it is still in use. Attached logs: embyserver-63918344396.txt: shows TheIntroDB processing the newly added episodes shortly before Emby stops. embyserver (1).txt: shows the later Emby startup after I manually started the package again. I can also attach the earlier log where the TheIntroDB SynchronizationLockException appears during shutdown. After uninstalling TheIntroDB, the issue disappeared in my tests. embyserver-63918344396.txt embyserver (1).txt embyserver-63918336666.txt embyserver.txt

Yeah, I like busting on the dev team . The Jellyfin team got notified about it back in May 24th and had a fix out by May 26th, 2 days. Just sayin'. Not sure why Emby was not notified back in May 26th with the rest of the major users. Kodi wasn't notified until June 7th and FFmpeg didn't have an official patched version until June 17th. The CVE was published on June 18th. I remember back at Meta when CVE's would be found and getting SEV 0 or 1 alerts on my phone. They would send them every 15 minutes until I acknowledged the event no matter what time of the night it was, even Christmas Eve. We usually had to resolved the problem within 24 hours or less. Good times.

Hey — thanks, would love to have you on the beta Your setup is honestly close to ideal for it. Music + audiobooks: both are covered. The sonic features (similar tracks, radio, "sonic adventures" that morph A→B, auto-mixes) run on your music library. Audiobooks live in their own Emby library and are deliberately kept out of the sonic analysis — so your wife's audiobooks still get full browse/playback/resume in the app, but spoken word never pollutes the music similarity. Best of both. That GPU is genuinely useful to me. The analysis is neural audio embedding (PANNs CNN14), and there's a CUDA worker that I've built but haven't been able to verify on real NVIDIA hardware yet — a 4090 would chew through a 70K library far faster than CPU. If you're up for it, confirming the worker actually picks up the card (it logs device=cuda on startup) would be a real help, and you'd get the fastest possible first scan out of it. Heads up that a 70K initial scan is a background marathon regardless — but it runs incrementally and new tracks get picked up automatically after. On pylrcget / timed lyrics: interesting project — I can see the appeal. It's adjacent in the "make your library richer" sense, but mechanically it's a different beast: emby-sonic analyses the audio itself (timbre, texture, sonic fingerprint) rather than anything in the lyrics/text. So not overlapping, but I like where your head's at. Can you send me your GitHub username and I'll DM you the onboarding bits — the Android app APK, the Emby plugin, and a quick-start for the coordinator + GPU worker. What Emby server version are you on, and is the 4090 box the one running Emby or a separate machine on the LAN?

Thanks for your efforts here. Nice app. Two questions: Do you plan to honor audio/music libraries? (ie have separate libraries) Will you allow users without passwords

Hi, on one of those libraries, can you try using the image editor to first delete the existing image. Then assign your new image. Then see if it happens again after that. Thanks.

Hi there, what exactly happens?

My friend "Riccardo" connect but not play movie, receive too error warnings.. Pls can you help me, i enclosed logs ? Thank Hispa embyserver.txt ffmpeg-transcode-e3b67745-6f5e-4cfa-bbe8-13e8a8d5425c_1.txt

Same for iPhone. It drives me nuts.

Hmm ok. So how do I install this?

Hi. Just for clarity, it wasn't brought to our attention until last week. We're working on the best path for the stable release. Thanks.

Additionally, if you using Emby Theater legacy version (not the Windows App Store version), you might want to update your mpv-1.dll as well. This is usually located: "AppData\Roaming\Emby-Theater\system\electronapp\libmpv\x64\mpv-1.dll" Here is where you can get the updated version with the latest FFmpeg. https://github.com/mitzsch/mpv-winbuild/releases?page=1

Have not found it so far. @GuderianCould you try a test for me with Process Monitor installed and running. I do not need a dmp file this time - just the embyclient.txt log and windows event viewer and zip of the PML file from procmon Procmon uses a lot of system resources - so we only need to run it for short time just before launching the Emby Windows app and stopping the capture once you get the dialogue box saying: Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item. Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item. So please download Process Monitor Unzip it Launch procmon.exe accept EULA and start with default capture filter Then launch emby windows client app When you get the error dialogue box, go back to the procmon session and stop the capture I have circled in green the icon for stopping / starting capture Once stopped, click File from the menu and then choose "Save .." and select the option to save as Native Procss Monitor formar (PML) and choose a path to save the PML file to Then please also save the full Windows Event Logs (Application and System) into evtx files - do not filter. Then zip the PML and the 2 evntx files and upload to the link i am going to send you. Please also include the embyclient.txt file Thanks

To clarify the scope of CVE-2026-8461, this vulnerability is in FFmpeg’s MagicYUV decoder. In practical terms, it is triggered by media files that cause FFmpeg to process video using the MagicYUV codec. If your media files are encoded with common codecs such as HEVC, AVC, H.265, H.264, x265, or x264, they should not be affected by this specific vulnerability. However, any movie or video content obtained from untrusted sources should be treated with caution, especially if it may be using or masquerading as MagicYUV. Tools such as MediaInfo, ffprobe, or FFmpeg itself can be used to verify the codec information. Manually replacing or patching the FFmpeg binaries bundled with Emby Server is generally not recommended, because Emby ships its own FFmpeg build and compatibility may depend on that specific build. That said, this should be addressed in the stable release branch as soon as possible. According to JFrog’s disclosure timeline, the issue was reported to the FFmpeg security team on May 13, 2026, and acknowledged on May 19, 2026.

In the end, it was the ISP. They had switched me back to CGNAT. I changed it back to a regular public IP, and now everything is working fine. 3/3 so far... Windows 11 pro , I had disabled everything in the antivirus (windows + real a/v software) for testing.

Alright yeah I need to take the time to install this thing then

if you are not directing the next command specifically at the [emby alexa|ear wax] skill "Alexa, Ask Ear Wax|MB Home, Next", then the response/outcome you got from "Alexa, next" might not be indicative of what the skill is and is not doing. (at least that is my experience)

Yes I recall seeing this on android. Will take a look. Thanks.