All Activity
- Past hour
-
Masaoc joined the community -
Roorey joined the community -
Dharm z. joined the community -
Ashok_9780 joined the community -
Mandal joined the community -
Anu01 joined the community -
lulu503 joined the community -
cambo35111 joined the community -
raluvscats joined the community -
Jaisingh joined the community -
Emby Theme: Retro Navy & Gold (W/ Seasonal Themes)
szymonSamsung replied to Aleas's topic in Web App CSS
@Aleas are you planning to rollout some updates any time soon ? Or the project is finished -
Latest Emby Update - RAM usage creep - Anyone else seen it ? Docker/Linux.
vaise replied to vaise's topic in Linux
It used all the ram again - and it is not linear, as it seemed to do it before the 5 minute growth check - [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. [2026-10-05 20:20:02] MEMORY WARNING: Emby is currently drawing 16GiB of system RAM. And then my other script saw it busted, so restarted it : [2026-10-05 20:20:11] ALERT: Emby URL failed health check (Status Code: 000). Restarting container. Just 7 direct play shows. Just normal playing progress in the hour run up to this failure, no scans or anything strange. No errors or anything - 2026-10-05 20:18:44.798 Info PlaystateService-0HNP0B058PKJA:00000012: http/1.1 Response 204 to host87. Time: 28ms. POST http://emby_remote_ip/emby/Sessions/Playing/Progress?X-Emby-Client=Emby for Android&X-Emby-Device-Name=Family room TV&X-Emby-Device-Id=61b83ac49a1b16d9&X-Emby-Client-Version=3.5.55&X-Emby-Token=x_secret57_x&X-Emby-Language=en-au&reqformat=json. 2026-10-05 20:18:44.967 Info PlaystateService-0HNP0B058PKJA:00000013: http/1.1 POST http://emby_remote_ip/emby/Sessions/Playing/Progress?X-Emby-Client=Emby Xbox&X-Emby-Device-Name=DOPYDRAGONXBOX&X-Emby-Device-Id=yNjZdXKrZtaCiJjgbfeEYW8CZGJJ57utGWXx9rZis&X-Emby-Client-Version=2.317.70.0&X-Emby-Token=x_secret61_x&X-Emby-Language=en-gb&reqformat=json. Source Ip: host94, UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36 Edg/150.0.0.0 2026-10-05 20:18:44.975 Info PlaystateService-0HNP0B058PKJA:00000013: http/1.1 Response 204 to host94. Time: 8ms. POST http://emby_remote_ip/emby/Sessions/Playing/Progress?X-Emby-Client=Emby Xbox&X-Emby-Device-Name=DOPYDRAGONXBOX&X-Emby-Device-Id=yNjZdXKrZtaCiJjgbfeEYW8CZGJJ57utGWXx9rZis&X-Emby-Client-Version=2.317.70.0&X-Emby-Token=x_secret61_x&X-Emby-Language=en-gb&reqformat=json. 2026-10-05 20:18:45.277 Info PlaystateService-0HNP0B058PKJA:00000014: http/1.1 POST http://emby_remote_ip/emby/Sessions/Playing/Progress?X-Emby-Client=Emby for Android&X-Emby-Device-Name=Smart TV Pro&X-Emby-Device-Id=2b464082bda8a69b&X-Emby-Client-Version=3.5.55&X-Emby-Token=x_secret2_x&X-Emby-Language=en-au&reqformat=json. Source Ip: host2, UserAgent: Mozilla/5.0 (Linux; Android 11; Smart TV Pro Build/RP1A.200622.001; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/153.0.8010.36 Mobile Safari/537.36 2026-10-05 20:18:45.281 Info PlaystateService-0HNP0B058PKJA:00000014: http/1.1 Response 204 to host2. Time: 4ms. POST http://emby_remote_ip/emby/Sessions/Playing/Progress?X-Emby-Client=Emby for Android&X-Emby-Device-Name=Smart TV Pro&X-Emby-Device-Id=2b464082bda8a69b&X-Emby-Client-Version=3.5.55&X-Emby-Token=x_secret2_x&X-Emby-Language=en-au&reqformat=json. Anything I can do here ? Seems like the out of memory issue takes longer to happen now, but it still does it. - Today
-
Hi, with last version I cannot make any recording of live tv. embyserver.txt
-
BUG Live TV recording stopped early when a remote viewer stopped watching the same channel
nargg posted a topic in Live TV
Synopsis generated by AI. Raw logs attached. Setup - Emby Server 4.10.0.40, Ubuntu 24.04 (kernel 6.8), Hyper-V guest, Quadro P2000 (NVENC/NVDEC) - Tuner: HDHomeRun (native HDHomeRun tuner type, stream sharing automatic) - Recording: "NFL Football - Denver Broncos at San Francisco 49ers", channel 862 KCNC-TV, timer 12b26b50ce49aad1077546b3d18c9c95 - Remote viewer: user "Chuck", Emby for Samsung 2.3.6, watching the same channel live (transcoding, low bitrate cap) Summary - 14:00:58 viewer opens KCNC-TV live -> "consumerId added: d635760f..." -> consumer count 1. - 14:23:01 recording timer fires and attaches to the SAME shared stream ("Will record ... for 246.98 minutes"). NOTE: logged as "LiveStream consumerId added: " with an EMPTY consumer id -> consumer count 2. - 14:26 - 15:17 viewer stops/starts repeatedly (failed transcodes on the client side). Every new viewer session logs "consumerId added: <PlaySessionId>" / "count is now 2"; every stop logs "consumerId removed" / "now 1". - 15:17:34 viewer session bb9fc8fb removed -> consumer count 1 (only the recording remains). - 15:18:04 viewer starts NEW session 0581f67e (PlaybackInfo, AutoOpenLiveStream=true) on the same stream. NO "consumerId added" and NO "consumer count is now 2" is logged for this session. - 16:44:59 viewer stops 0581f67e -> "LiveStream consumerId removed: 0581f67e..." -> "consumer count is now 0" -> live stream closed -> "Recording stopped" (~2h22m into a 246.98-minute recording). - No timer delete/cancel request was made. The recording was terminated only because the shared stream was closed. Anomalies 1. The recording registers as a consumer with an empty consumer id. 2. A consumer id that was never added (0581f67e) is "removed" and the count is decremented, reaching 0 while the recording is still active, which closes the stream out from under the recording. Expected: a viewer stopping playback must not close a live stream that an active recording is still consuming. emby-livetv-consumer-count-bug.txt -
Rendering the image isn't difficult; the challenge lies in having to redraw it every time—though that issue seems to have been resolved. Now, all that's needed for perfection is to reduce memory consumption. The need to redraw it every time was the biggest problem, but it appears that issue has already been solved.
-
In reality, relying on disk I/O is indeed the best approach, given that Emby's memory management and its use of SQLite are notorious issues. Since Luke has consistently been reluctant to switch to PostgreSQL and Redis, other plugins really shouldn't consume memory; otherwise, the risk of a system crash becomes extremely high.
-
Sony Bravia TV with EMBY for Andoid TV fails to play
Orionas21 replied to Orionas21's topic in Android TV / Fire TV
Any update why EMBY for Android TV is not working in Sony Bravia after 2.1.48g? -
After a reboot it will have to rebuild the cache, this will be fast though and no redrawing of posters will happen. There is one last thing i thinking of adding back to the plugin but i'm a bit hesitant about it as it might have been part of the problem on your system. In short, it shortens the amount of time between each poster being drawn on. It could gain a little performance.
-
Version 5.61.1.0 seems great so far; I wonder how it will behave after restarting the Emby server.
-
It always did that, Emby hands EmbyIcons a poster and tells it to enhance it, EmbyIcons after that hands it back to Emby that then placed it in cache and used it for libraries. I believe the problem was that i had it load x amount of posters into memory for processing but something would go wrong. Either the limit didn't work as it should or the memory didn't get released. I will have to look into that at some point.
-
Storing images locally for reuse is already an excellent solution; the app no longer crashes when opening the media library.
-
I don't think there's much performance left to squeeze out of it. The main two things that takes a lot of work is the series aggregation as it needs to check all episodes in a series when not using "lite" mode (available in the settings) and the drawing it self. I can't really change the drawing much as it is done by SkiaSharp and not my own. Best thing to speed up the plugin is to use "lite" mode for TV shows and collections. This will not change much for you though since you only use ratings. I am looking into some more options to increase performance but options are getting thin.
-
Android downloads fail with 404 because the Emby sync file is missing
OUARZA replied to OUARZA's topic in Android
In fact, it downloads on a loop.I have already uninstalled the application. -
Your plugin library consolidates images in a way that is visually appealing and aesthetically pleasing—I really like it. The performance issues are concerning, but I feel there must be a way to resolve them.
-
You DO have a big library to process. That said, if those ratings are all you want then maybe the plugin "Rating Poster Database" would work better for you. It works in a different way and focuses only on ratings so might be faster for your library.
-
However, it still takes some time to load.
-
Perfect
-
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.
-
Android downloads fail with 404 because the Emby sync file is missing
OUARZA replied to OUARZA's topic in Android
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.
