All Activity

Emby places the images in programdata/cache.

Wow, it's incredibly fast—that's great.In which directory were the processed images placed?

I'm testing it right now; give me half an hour to run the test.

Hi @Luke, I'm sorry, it does the same.

My Emby Server recently updated to 4.10.x.x and I noticed the Thumbnails are now shrunk and pasted onto a "Folder" when viewed in Folder View mode. I reverted back to 4.9.5.0 and locked the server from updating automatically in order to keep the old Folder View without the Folder Outline. Is there a way to force the old Folder View on 4.10+? I didn't like the new look.

I have rolled back some changes in the latest 5.61.1.0 beta. One of the changes is also that it no longer load the images to memory but instead work on them directly from disk.

Even if your cache is large enough to hold these images, they will be processed again the next time you load them—which is a waste of resources.

My point is that you have to limit the cache size regardless; whenever you open a media library containing tens of thousands of files, the system attempts to load them into memory. I have 64GB of RAM, but the image collection itself might be as large as 80GB, so local disk storage is the only viable option. Even if I *did* have enough RAM to hold all the images, opening the library would still trigger a reload. Furthermore, I have 14 such libraries—there is simply no way to fit them all into memory. If I didn't use local storage to process the images beforehand and instead tried to load them on demand, I would run into serious performance issues.

I bought 3rd Gen Fire TV Sticks for every TV in my house, 7 total back in 2020. I don't have any plans on buying anything new from Amazon going forward. If you still have any "Pre-Vega" Amazon devices, I'd suggest you turn off Auto-Updating and deny any future Updates on them. Amazon has resorted to sleezebag tactics of updating old devices with bloatware in order to slow them down and frustrate you into buying their newer devices. Don't fall for it, hold on to your older devices

It happens on Amazon too. I brought it up in the transcoding post yesterday since I think it's related to transcoding for me; direct play seems fine, but it stutters or freezes when I pause and resume transcoded content, leaving just the audio until I restart the stream. My logs are too big to download on my phone, so I'll rotate them tonight and try to recreate the issue so I can grab the data for you.

The fix should be included in the next Music Assistant update. Image paths are persisted with library items and a rescan merges rather than replaces them, so existing installs keep their tagless URLs until the item is re-added

Hi, I’d like to help improve the Japanese translation for Emby. I audited the Japanese localization files included with Emby Server 4.11.0.5 Beta and tested the updated strings on a running server. The audit covers the server/web UI localization files and includes fixes for untranslated strings, mistranslations, inconsistent terminology, and some invisible formatting characters. I also verified several changes directly in the Web UI, for example: Home Screen → ホーム画面 Identify → 作品を識別 Stats for Nerds → 再生の詳細情報 Exit menu → 終了メニュー Side navigation menu → サイドメニュー Conversions → 変換 “Last ran {0}, taking {1}.” → 最終実行: {0}（所要時間: {1}） I have attached an audit package containing the updated Japanese JSON files and verification data. The package is intended as review/reference material rather than a request to bypass the official translation workflow. I understand that the official contribution path is translate.emby.media. Could you let me know the best way to submit these Japanese corrections there, or whether translator access needs to be granted first? One additional finding: some strings in the iOS app appear to use a separate localization resource from the server/web client. For example, after changing StatsForNerds on the server, the Web UI correctly shows 「再生の詳細情報」, while the iOS app still shows the older translation 「専門家のための統計情報」. Thanks! emby-ja-forum-4.11.0.5.zip

Not sure I spoke too soon, Its risen to over 10GB as of today. Just three direct play sessions, no library scans. I guess I am not changing this back to 8GB. [2026-10-05 10:55:02] MEMORY WARNING: Emby is currently drawing 6.58GiB of system RAM. [2026-10-05 11:00:02] MEMORY WARNING: Emby is currently drawing 6.753GiB of system RAM. [2026-10-05 11:05:02] MEMORY WARNING: Emby is currently drawing 7.104GiB of system RAM. [2026-10-05 11:10:02] MEMORY WARNING: Emby is currently drawing 7.2GiB of system RAM. [2026-10-05 11:15:02] MEMORY WARNING: Emby is currently drawing 7.25GiB of system RAM. [2026-10-05 11:20:02] MEMORY WARNING: Emby is currently drawing 7.266GiB of system RAM. [2026-10-05 11:25:02] MEMORY WARNING: Emby is currently drawing 7.336GiB of system RAM. [2026-10-05 11:30:02] MEMORY WARNING: Emby is currently drawing 7.438GiB of system RAM. [2026-10-05 11:35:02] MEMORY WARNING: Emby is currently drawing 7.471GiB of system RAM. [2026-10-05 11:40:02] MEMORY WARNING: Emby is currently drawing 7.678GiB of system RAM. [2026-10-05 11:45:02] MEMORY WARNING: Emby is currently drawing 7.555GiB of system RAM. [2026-10-05 11:50:02] MEMORY WARNING: Emby is currently drawing 7.515GiB of system RAM. [2026-10-05 11:55:02] MEMORY WARNING: Emby is currently drawing 7.52GiB of system RAM. [2026-10-05 12:00:02] MEMORY WARNING: Emby is currently drawing 7.588GiB of system RAM. [2026-10-05 13:50:04] MEMORY WARNING: Emby is currently drawing 7.629GiB of system RAM. [2026-10-05 14:45:03] MEMORY WARNING: Emby is currently drawing 7.566GiB of system RAM. [2026-10-05 14:50:03] MEMORY WARNING: Emby is currently drawing 8.334GiB of system RAM. [2026-10-05 14:55:02] MEMORY WARNING: Emby is currently drawing 8.874GiB of system RAM. [2026-10-05 15:00:02] MEMORY WARNING: Emby is currently drawing 9.3GiB of system RAM. [2026-10-05 15:05:02] MEMORY WARNING: Emby is currently drawing 9.814GiB of system RAM. [2026-10-05 15:10:02] MEMORY WARNING: Emby is currently drawing 9.933GiB of system RAM. [2026-10-05 15:15:02] MEMORY WARNING: Emby is currently drawing 10.04GiB of system RAM. [2026-10-05 15:20:02] MEMORY WARNING: Emby is currently drawing 10.05GiB of system RAM. [2026-10-05 15:25:03] MEMORY WARNING: Emby is currently drawing 10.06GiB of system RAM. [2026-10-05 15:30:02] MEMORY WARNING: Emby is currently drawing 10.04GiB of system RAM.

@sa2000

In the Emby guide data, channels 26.1 to 26.5 are missing. I mean I see them on the guide, but I can not map those channels because the are not in the list.

The app delegates it to the system, so you have to install an app that can play cbr and that can receive intents from other apps.

Logs. ffmpeg-transcode-f09a8bba-1e9d-45ec-8dc0-ff78330490f8_1.txt ffmpeg-transcode-cbc4cc07-cba5-4818-a3f7-39a68c52b914_1.txt ffmpeg-transcode-92c2afb5-97d0-4eff-a555-3e16ae316f77_1.txt ffmpeg-transcode-8fdfd1c5-c441-42f6-8b93-144196d848ad_1.txt ffmpeg-transcode-3f2de129-de14-4e3c-9cbc-37aad14a094f_1.txt ffmpeg-transcode-1b9bce19-26d5-4a4f-ac3e-2e58ddad6f67_1.txt ffmpeg-transcode-12f09438-af02-4dfc-a02f-6567ffa32a65_1.txt ffmpeg-transcode-058ccb33-06f9-4de9-9c37-d9a87da322b9_1.txt ffmpeg-directstream-b071340c-beab-4dea-864f-a4f39a3a167e_1.txt embyserver.txt

No all good. Thank you.

I am glad you could get it worked out. Do you still need me to try .64 and or .65 as well?

Hi, I think we had to change which element in the view layer had a background color applied.

I just tried 3.5.66, which was the latest build on github. It looks good! I tested a few videos that had problems and they all played with proper black bars on HDR content that is letterboxed. Thank you! Can I ask what was done to make that happen?

Right we are not currently looking at iso_3166_1 for images, so that needs to get added. But there are also changes to the server required, so I can't just push an update the moviedb plugin to resolve it. The fix will be on the server beta channel for the next build. Thanks.

I think, I have a start of an explanation. The first request for the movie "Warrior - (2011)" is : https://api.themoviedb.org/3/movie/59440?api_key=xxxxxxxxxxxxxxx&append_to_response=alternative_titles,reviews,casts,releases,images,keywords,trailers&language=fr-FR&include_image_language=fr-FR,null The content is in the first file "request_fr-FR" There is a second request without the language restriction : https://api.themoviedb.org/3/movie/59440?api_key=xxxxxxxxxxxx&append_to_response=alternative_titles,reviews,casts,releases,images,keywords,trailers The content is in the file "request_base" The difference is in the answer, in the content : images / logos : with the fr-FR restriction there is no logo image received, but, without the language restriction, there is 11 logos received. But no logo with "iso_3166_1" key at "FR", but one with "CA" and the "iso_639_1" key with the "fr" value (array index 8). I think, this can be part of my problem. Am I close ? What is your opinion on that ? Thanks request_fr-FR.txt request_base.txt

Hi @quickmicMinor request. Before you took over E4K and AngelBlue was the keeper of all things E4K, there was an option under the Other category in the Kodi settings to open the E4K config settings. Is there any chance you would consider adding that option back? It's not a huge deal, as you can easily access the E4K settings through the Kodi settings under Add-on browser. But it would be a few less clicks to get there if there was a direct link under Other.

I also tried with the 4.11.0.5 (beta), but same behavior...