All Activity

I surmise that once the disk-based image storage took effect, all images had to be regenerated; the resulting media library was so massive that the server became overwhelmed, causing all images to fail to load. The correct approach would have been to display the images first and then replace them one by one as a slow background process.

This is what I had explained in a recent conversation: As you had noticed yourself already, this is not properly implemented, and never been looked at it. It even turned out to be a potential security risk, that's why we have disabled it until we have safe and a fully working implementation for it. Thanks

I noticed an problem related to Music Assistant. When I set “ValidateImageTags” to “true,” Music Assistant can no longer load the images correctly. WARNING (MainThread) [music_assistant.helpers.images] Failed to fetch image from http://xxx.xxx.xxx.xxx:8096 When I set “ValidateImageTags” back to “false,” the images load correctly again. Maybe hatharry could take a look at this? I think he’s the maintainer of the Music Assistant Emby integration. @hatharry

If you continue to see issues - try the guidance provided in this thread, there have been changes to database settings:

I can't send you the logs because I've already rolled back the version; switching versions again would cause the media library to blow up.

As I said, it's controlled by Feature Access, so either disable this: Or remove this from your Home Sections:

@seanbuffhere r some screen shots. first one shows my permissions (web), 2nd are the options I have (no live tv option), 3rd same no option in drop down menu, 4th is the Home Screen on Apple TV app. Its showing live tv section but I want to remove it.

Possible for me to get you to send me a log?

Versions 5.61.0.0, 5.61.0.1-beta, and 5.61.0.2-beta all fail to load the media library home screen; reverting to version 5.60.0.1 restores normal functionality. I hope this is fixed soon. The exact cause is unclear, but in the problematic versions mentioned, the "Pre-draw posters" process remains stuck at 0% progress.

Yeah, I saw... There is a 4.10.1.0 available. I'm gonna upgrade to that first, and see what happens. This usually uses about 4-5 GB of RAM, and it has slowly increased to over 17 GB which is why I even noticed. I just wanted to capture the logs for the issue in case it's a bigger thing. TheAudioDB is kinda important to my metadata. I'll try that as a last resort... Thanks!

It looks like the plugin AudioDB is failing. I would remove that, and see if that helps you move forward. Error in TheAudioDB *** Error Report *** Version: 4.10.0.40 Command line: /system/EmbyServer.dll -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3 Operating system: Linux version 6.18.38-Unraid (root@Develop) (gcc (GCC) 15.3.0, GNU ld version 2.46.1-slack151) #1 SMP PREEMPT_DYNAMIC Mon Jul 6 15:22:03 PDT 2026 OS/Process: x64/x64 Framework: .NET 8.0.28 Runtime: system/System.Private.CoreLib.dll Processor count: 12 Data path: /config Application path: /system MediaBrowser.Model.Net.HttpException: MediaBrowser.Model.Net.HttpException: NotFound at Emby.Server.Implementations.HttpClientManager.CoreHttpClientManager.SendAsyncInternal(HttpRequestOptions options, String httpMethod) at Emby.Server.Implementations.HttpClientManager.BaseHttpClientManager.SendAsync(HttpRequestOptions options, String httpMethod) at AudioDb.AudioDbAlbumProvider.EnsureInfo(String musicBrainzReleaseGroupId, IDirectoryService directoryService, CancellationToken cancellationToken) at AudioDb.AudioDbAlbumProvider.GetMetadata(RemoteMetadataFetchOptions`1 options, CancellationToken cancellationToken) at Emby.Providers.Manager.MetadataService`2.ExecuteRemoteProviders(MetadataResult`1 temp, LibraryOptions libraryOptions, String logName, TIdType id, IRemoteMetadataProvider`2[] providers, MetadataRefreshOptions options, CancellationToken cancellationToken) Source: Emby.Server.Implementations TargetSite: Void MoveNext() And Emby can't finde the webpage at AudioDB Http response 404 from https://www.theaudiodb.com/api/v1/json/2139078587215309723505/artist-mb.php?i=4580d83b-093e-4241-91fb-2dd71f5f1f3f after 205ms Not sure if this is a AudioDB web-server issue or if they have changed paging format.

Good evening, I am about to do the update that is available to see if it fixes this, but I wanted to capture the logs in case it doesn't and report it... Two servers running in UnRAID Docker Containers have started consuming RAM. The logs show repeated errors, as if something is stuck in a loop. They both have frozen progress for "Scanning Media Library". Everything seems to be working, no signs of failure, except for the RAM usage slowly being eaten. embyserver.txt

I noticed starting with 3.5.64 there were some changes to the connection dialogue at startup, not seeing it on my phone anymore but I did see it when in airplane mode. My server connections are fast, maybe I would see it on my shield but I haven't plugged it in yet as I'm traveling so just don't have a point of comparison yet. Yes subtitles can be turned off now, working again.

I restarted that LG TV and now it seems to play SRT (SubRip) subtitles just fine. So updating Emby app on LG solved this.

Resolved in 3.5.65. Thanks guys.

3.5.65 Support automatic subtitles after skip back (requires Emby Server 4.11.0.5+) Core UI Changes from 26.0.31 to 26.0.32 Fix regression with turning off subtitles not being remembered

Emby for Android 3.5.65 Released Download Emby for Android Changes 3.5.65 Support automatic subtitles after skip back (requires Emby Server 4.11.0.5+) Fix regression with turning off subtitles not being remembered

Hardware transcodes still failing... ffmpeg-transcode-151095e3-24a1-4c4f-9b26-bcba69a67a5d_1.txt

New beta version up in the catalog (v2.9.1.5). Added: 1) Option to have the plugin wait with detections if any playback sessions are running. 2) Post-credit detection. Added a setting to enable the detection of Post-credit detections. The plugin runs past the first positive detection to check if there is any other positive detections, threats them as post-credits and adds the credit mark there instead. If the Emby team adds "CreditEnd" to the chapter type in the future this can be made to work with that. Please note: This is experimental for now as it will require a good amount of testing to be sure it's precise enough for every-day use.

Hi, no, the trakt plugin isn't built for that. it's built to map one trakt user to one emby user.

Is it possible to run two or more different Trakt accounts off a single Emby account?

I just used the reg fix for Server2025 and emby installed. Thanks

Nice theme, looks and works great. I appreciate the efforts. A different blue and yellow/gold and I could have told my wife it was a University of Michigan theme, lol.

Emby can show one active recording while multiple upstream tuner/provider connections remain actively in use. I caught this live tonight and was able to verify both Emby’s internal consumer state and the actual network traffic while it was happening. Environment: Emby Server 4.10.0.40 on macOS using an M3U tuner. At the recording boundary, the server log showed three recording timers firing for the same program on three different channels: 19:00:00.104 Recording timer fired ... [PROGRAM] (3 times) 19:00:00.111 Getting media sources ... [CHANNEL A] 19:00:00.111 Getting media sources ... [CHANNEL B] 19:00:00.112 Getting media sources ... [CHANNEL C] Those recording jobs attached to existing shared streams, bringing each stream to two consumers. When the previous recordings ended, Emby removed those consumers, but the three affected streams only dropped back to one consumer each, so all three remained open: Live stream [A] consumer count is now 1 Live stream [B] consumer count is now 1 Live stream [C] consumer count is now 1 A separate stream behaved normally: Live stream [D] consumer count is now 0 Closing live stream [D] I also verified the three remaining connections at the TCP level. They were ESTABLISHED and actively transferring MPEG-TS data, so these were not stale sockets. The shared-stream/tuner logic itself appears to be behaving correctly: Emby still believed each stream had an active consumer. The issue therefore appears to be higher up in the recording/timer state rather than in tuner release itself. The practical concern is that the UI showed one active recording while three provider/tuner connections were actually in use. This matters for IPTV users with concurrent-stream limits. If a provider allows two connections, for example, a hidden consumer can occupy one of those slots and cause another recording or Live TV session to fail even though Emby appears to show available capacity. Main question: why were multiple recording consumers created for one logical airing while the UI represented only one active recording?

OK we are looking into it. Thanks.