All Activity

26.0.3 Add cancellation support to directory picker Fix multi-select episodes not showing delete option on some screens Fix on now video tab not loading Update header style during video playback Improve new folder view style Update header style during video playback Fix new folder view style on apple devices Improve folder icon in folder views Various fixes related to submitted crash and error reports Support cancellation of initial connection process Add new spotlight home screen section option (requires Emby Server 4.10+)

Emby Web App Update: Version The Emby Web app has been updated to version Go and try out: https://app.emby.media/ Changes 26.0.3 Add cancellation support to directory picker Fix multi-select episodes not showing delete option on some screens

In this example, I’d change it from 60 seconds to 0/off — no automatic retry. My code is already holding or recovering the session, so another tuner handshake from Emby isn’t needed. The current 60-second behavior can stay as the default — I’d just like the option to disable it, choose a different interval, and ideally limit the retry count to 2 or 3 instead of 11.

@ginjaninja Awesome, seems like read my mind! Looking forward to hear from you

In the 2nd line, remove the space between "$APP_DATA_DIR" and "/Volume1/Emby" The line should look like this -programdata $APP_DATA_DIR/Volume1/Emby \

and if you disable hardware transcoding in server transcoding settings, does it happen then?

What version number of the app do you have now?

It crashes before the transcoding can even start. The ffmpeg file gets created in the logs, however it just says "no items found" I recreated the error cause I was confused which logs contained any transcoding activity, this one should. embyserver-63921990415.txt

OK we'll take a look at it. Thanks.

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?