All Activity

Sorry for delay. I mean every time I try to open the emby app. Tried reinstall the app, restart the iPad, close all the app and open again, everything dozens of times and on both my iPad air first edition. Nothing works.

It seems to be TerraMaster don't believe this needs to be fixed on their end and instead it is up to Emby devs to fix @Luke

The app has a new logging feature. can you please try this again and then provide an app log? Thanks.

Hi, we are still looking at it. Thanks.

I still don't see it in this log. This example here is direct play.

To go backwards from 4.9 to 4.8 you need to make a fresh start.

So in this example, what would you change it to?

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.