All Activity

Awesome!

Thanks. I was able to install version 1.0.7.1 and test it. It is working correctly now, and Emby no longer shuts down when adding new content. Thank you very much for the quick fix.

@AngelSingoop my fault, forgot to push it from GitHub to the Emby library. V1.0.7.1 should be available now. Lmk if it works now!

Thanks for the advice, you are right. In this case, at first I did not know what was causing the issue and I also could not reproduce it. The failure happened unexpectedly, so the only log I had available was that large one. That is why I attached it, because if I restarted or cleared the logs, I could have lost the only evidence where the cause of the problem might appear. Later, almost by coincidence, I found a way to reproduce it: it happened when adding new content to a TV library while TheIntroDB was installed. For future testing, now that I know how to reproduce it, I will do exactly that: restart Emby, generate a clean log, reproduce the problem, and send the log right away.

Thanks. I’ll test it as soon as it becomes available. I just checked the plugin from Emby, but right now the latest version available to install is still 1.0.7.0, and 1.0.7.1 is not showing up yet.

Just a heads up. To help the developer in the best way possible it's usually a good thing to shut down Emby, start it back up (to reset logs and start a new one), reproduce the problem and then send the log right away. This lessens the amount of irrelevant stuff in the logs that the dev has to look through. 10MB of logs is A LOT to go through!

Thanks @AngelSingfor reporting this! Can you try v1.0.7.1 and see if it’s been fixed?

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.