All Activity

Just to clarify the request: I’m not asking Emby to change the default behavior for everyone — I’d just like the tuner handshake/retry policy to be user-configurable. Retries can be useful, but there are cases where they accomplish nothing. If all tuner capacity is already in use on my end, retrying the same tune every 60 seconds doesn’t help. Likewise, brief upstream stalls can be handled on my side without Emby repeatedly reacquiring the tuner. Ideally, users could set the retry count/delay, including 0/off, while leaving the current behavior as the default.

Okay good to know, that narrows it down... for now disable most watched... I will look into the issue.

Very cool. Thanks for sharing.

Update — 1.3.0: CarPlay, and capped quality is gapless on mobile data now Version 1.3.0 is out. Short recap for anyone new to the thread: Embeat is a native iOS music-only player for Emby — gapless FLAC/ALAC direct play, offline downloads, DLNA including Sonos, playlist management. €9.99/year, one month free, and it talks straight to your server with nothing of mine in between. Two things in this one. The first is what this thread has asked for most since I posted about the app; the second is me taking back something I announced in it. CarPlay Your library on the car screen: four tabs — Recent, New, Favourites and Playlists — with cover art, the queue, shuffle and repeat, and a now-playing screen driven from the wheel and from Siri. The design rule was every row plays with one tap, and it's the reason the tabs look shorter than you might expect. Tap an album and the album plays. Tap a playlist and the playlist plays. Tap a track and the list plays from there. Favourites covers albums and artists too, not just tracks, so tapping an artist plays the discography. Nothing drills down a level: picking track seven out of a list is a phone gesture, not a driving one. Worth knowing before you plug in: No search in the car yet. Four curated lists are enough to start something, not to find a specific record. It's the next iteration. No Downloads tab yet. Capped quality now streams MP3 on every network, and the HLS/AAC path is switched off When I announced Embeat here I listed "HLS/AAC on mobile data" as a feature. It isn't in the app any more, and I'd rather say that in this thread than let it quietly vanish from the store description. When you cap the streaming quality, the server now transcodes to MP3 and Embeat decodes it with its own engine — on Wi-Fi and on mobile data alike. The reason is gapless. Over HLS, iOS plays through AVPlayer, and AVPlayer does not chain one track into the next without a gap: on mobile data, every track change cost a pause you could count in seconds. On the progressive path the engine reads the MP3's encoder delay and trims it, which is what holds a live album or a continuous mix together. So capped quality is gapless now on any network. Over HLS it never was. On Android, since it gets asked here every time: the app is in review at Google Play right now, Android Auto included. I'm not giving an availability date — when it clears review isn't up to me, and I'd rather say nothing than say a week. It's the same shared Kotlin core underneath, and the car browse tree is literally the same code on both sides, which is why the two arrive close together. I'll post here when it's actually downloadable, not before.

exec $APP_DIR/system/EmbyServer \ -programdata $APP_DATA_DIR /Volume1/Emby \ -ffdetect $APP_DIR/bin/ffdetect \ -ffmpeg $APP_DIR/bin/ffmpeg \ -ffprobe $APP_DIR/bin/ffprobe \ -defaultdirectory /mnt/public \ -updatepackage 'emby_TOS5_APP_{version}_x86_64.tpk' Version 4.9.5.0.02 from tos store tos - 7.0.0804 Replacing the line doesn’t fix it for me.

Yes. I kept EmbyNewOverlay fully enabled and re-enabled Seerr library synchronization. The only thing I disabled was Most Watched. With Seerr library synchronization running and Most Watched disabled, CPU usage stays completely normal. So it looks like Most Watched is specifically triggering the high CPU usage during the Seerr library synchronization.

Hi, what do you mean by composers empty field? Can you please show a screenshot example? Thanks.

hi, you can always send it over PM. Thanks.

can you try it with most watched turned off?

Well this makes it hard to find the cause, if seerr is involved..... I don't even use seerr and i don't know what happens to the plugin during lib sync. I will try to look into it but not gonna promise this will be fixed .

It crashes before the transcoding can even start. The ffmpeg file gets created in the logs, however it just says "no items found" Edit: The file I sent was actually the wrong one, here's on with transcoding activity embyserver-63921916800.txt

Not exactly. Seerr itself doesn't cause the high CPU usage. The important part is the interaction with EmbyNewOverlay: Seerr stopped + EmbyNewOverlay enabled → normal CPU Seerr running + library sync disabled + EmbyNewOverlay enabled → normal CPU Seerr running + library sync enabled + EmbyNewOverlay enabled → ~100% CPU So the library synchronization in Seerr appears to trigger the issue, but I suspect something in EmbyNewOverlay is being executed excessively when Seerr scans the library. If I disable EmbyNewOverlay while keeping Seerr's library sync enabled, CPU usage also stays normal. So I don't think Seerr itself is the problem; rather, Seerr's library synchronization seems to trigger a problem in the overlay plugin.

Oh so it was seerr after all? glad you figured it out your self.

Hi, there is no transcoding activity happening in this log file. Are you saying it happens without using it?

The issue seems to be specifically triggered by the Seerr library synchronization. With EmbyNewOverlay enabled: Seerr stopped → CPU normal Seerr running, library sync disabled → CPU normal Seerr running, library sync enabled → EmbyServer CPU goes to ~100% So it looks like the large number of library/season/episode requests generated during Seerr's library synchronization triggers excessive processing in EmbyNewOverlay.

Well I suspected there is another issue causing your CPU to run at 100% because while testing it on my PC with no premiere date, I didn't have a CPU running at 100%. like @Neminemsaid can you dump the emby server log and your hardware info. And i have one question for you. Is the v 1.3.4.0 the first version you tried on? and maybe one thing to try..... Try switching off some master switches like most watched, studio logos and the like and test the results.

Would it be possible to create for each user a dedicated playlist (like spotify or deezer) when the user start listening random music for exemple, or a watching a collection. For each new connection, the playlist is load by default (continue playing). The playlist stay until the user decide to do a new action like watching a movie, listen an album, etc... This new action will erase the dedicated playlist and generate a new one. Don't hesitate to ask for details

@eMoOakI guess @Amanade3 would need your hardware info. And server logs with debug logging turned on.

Hi, I’ve just tested version 1.3.5.0 after your fix. Unfortunately, the CPU usage issue is still present. With EmbyNewOverlay enabled, the EmbyServer process goes to around 100% CPU continuously. As soon as I disable the plugin, CPU usage immediately returns to normal. I also confirmed that Emby is actually loading version 1.3.5.0. So it looks like the DateTime.MinValue / DateTimeOffset issue was fixed, but there is another issue causing the high CPU usage. There are no obvious exceptions in the Emby log while this is happening, which makes it a bit harder to identify. I’ve had to disable the plugin again for now because of the CPU usage.

This is not a bug, rather a priority issue. When a movie matches more than one rule at once, the plugin picks whichever rule has the highest priority, in this particular order Tag rules Folder rules Most watched Release date ( by the movie's premiere date) New Season And finally Date Added (by when it was added to the library) so in your case both movies may be added on the same day but the second movie also happens to fall within your Release Date window (i.e. it was actually released/premiered recently) so the plugin preferred to show the "new movie" banner instead.

Yesterday out of nowhere my hardware acceleration stopped working. I was watching something on my server and suddenly it started lagging, which is why I turned down the bitrate of the series I was watching. After this, the entire system started crashing as soon as I use hardware acceleration for transcoding. I did check the logs for any information on why this is happening. There seems to be an error which I can't really make out what it means right before the log stops (Logs attached). At first I thought it was an error that occured because of my reverse proxy setup, however the same thing happens when I stream through the local network. I did once have a similar issue that I could resolve by changing the transcoding settings to only use QuickSync instead of VA API and QuickSync. The driver for my GPU seems to be installed and loaded, however the output to the Command lspci -k | grep -A 2 VGA outputs no kernel driver in use: 00:02.0 VGA compatible controller: Intel Corporation Iris Plus Graphics 650 (rev 06) DeviceName: Onboard - Video Subsystem: Intel Corporation Iris Plus Graphics 650 Also of note: Running any glx commands in the console gives me the following error: Error: unable to open display I'm kind of at a loss here and don't know what to do. If anyone can help me with this would be nice, I have absolutely no clue how to make this work, especially since I don't really understand much about transcoding or hardware drivers. If I can add any more information to help solve this let me know! Thanks in advance! embyserver-63921916800.txt

Sorry my bad, on web browser it seems it was fixed - cannot replicate now on beta channel. However on Android phone app it is still bugged: Version 4.10.0.23 beta Preview attached. WhatsApp Video 2026-08-10 at 18.06.24.mp4

@GrimReaperI actually wanted to do a Netflix style badge too (like you asked) but got sidetracked. Should be in the next release.

This patch should fix it. but if you're still seeing high CPU after updating, let me know and I'll dig into what else might be causing it.

New Release V 1.3.5.0 Fix high CPU usage caused by an exception in badge cache-key generation for items with no premiere date. EmbyNewOverlay.dll