Plugin: EmbyIcons release.

[yocker 2005]

EmbyIcons does not clear the cache on every reboot and only updates items in it's cache that are out of date.
Only out of date items will get cleared.
When updating the plugin it will also clear the cache for compatibility reasons.

Besides that i don't think i can help you sadly.
The plugin only reacts on what Emby gives it and it in your case tries to give EmbyIcons a poster on a path that doesn't exist. This is what causes the error in the log.

EmbyIcons isn't really that useful for strm files anyway as they in general don't have the information that EmbyIcons needs for adding icons to the posters like for example "4K" and "HDR".
You will just end up with posters that have no icons on them until Emby it self populates the video info.
From testing i have just made with adding strm files to Emby it's not possible (for me) to get any media info to show for them (thus EmbyIcons have nothing to do).

Sorry.  

Edited 11 hours ago by yocker

[Ansell 9]

2 minutes ago, yocker said:

EmbyIcons 并非每次重启时都会清除缓存，而是只更新其中已经过期的缓存数据。
只有过期的物品才会被清理掉。
在更新插件时，出于兼容性的考虑，系统也会清除相关的缓存数据。

除此之外，很遗憾，我似乎无法为您提供帮助。
这个插件只会对 Emby 提供的数据进行响应。在你的案例中，它试图在一个不存在的路径上添加 EmbyIcon 图标。这就是日志中出错的原因。

无论如何，EmbyIcons 对于 STRM 文件来说并没有太大的实用性，因为这类文件通常缺乏 EmbyIcons 所需要的那些用于向海报添加图标的信息，比如“4K”和“HDR”这些标识。
最终你会得到一些没有任何图标的海报，直到 Emby 自行填充了视频信息为止。
通过测试发现，当向 Emby 添加 STRM 文件时，无法获取任何与这些文件相关的媒体信息（因此 EmbyIcons 根本没有任何作用）。

抱歉。  

I haven't enabled those markers, and I have a plugin that extracts media info into NFO files, so that’s not the issue. My images and metadata are stored on the Emby server, not on a cloud server. The problem actually lies with the images.

[Ansell 9]

Just now, Ansell said:

我并没有启用那些标记功能，而且我有一个插件可以将媒体信息提取到 NFO 文件中，所以这并不是问题所在。我的图片和元数据存储在 Emby 服务器上，而不是云服务器上。实际上，问题出在图片本身上。

What I mean is, why not store it in a local folder instead of the cache? Storing it in the cache places immense pressure on my server; every load overwhelms the server, especially given the vast amount of media I have.

[Ansell 9]

8 minutes ago, yocker said:

EmbyIcons 并非每次重启时都会清除缓存，而是只更新其中已经过期的缓存数据。
只有过期的物品才会被清理掉。
在更新插件时，出于兼容性的考虑，系统也会清除相关的缓存数据。

除此之外，很遗憾，我似乎无法为您提供帮助。
这个插件只会对 Emby 提供的数据进行响应。在你的案例中，它试图在一个不存在的路径上添加 EmbyIcon 图标。这就是日志中出错的原因。

无论如何，EmbyIcons 对于 STRM 文件来说并没有太大的实用性，因为这类文件通常缺乏 EmbyIcons 所需要的那些用于向海报添加图标的信息，比如“4K”和“HDR”这些标识。
最终你会得到一些没有任何图标的海报，直到 Emby 自行填充了视频信息为止。
通过测试发现，当向 Emby 添加 STRM 文件时，无法获取任何与这些文件相关的媒体信息（因此 EmbyIcons 根本没有任何作用）。

抱歉。  

The problem is that there are too many media files on my server, causing timeouts every time it loads.

[Ansell 9]

13 minutes ago, yocker said:

EmbyIcons does not clear the cache on every reboot and only updates items in it's cache that are out of date.
Only out of date items will get cleared.
When updating the plugin it will also clear the cache for compatibility reasons.

Besides that i don't think i can help you sadly.
The plugin only reacts on what Emby gives it and it in your case tries to give EmbyIcons a poster on a path that doesn't exist. This is what causes the error in the log.

EmbyIcons isn't really that useful for strm files anyway as they in general don't have the information that EmbyIcons needs for adding icons to the posters like for example "4K" and "HDR".
You will just end up with posters that have no icons on them until Emby it self populates the video info.
From testing i have just made with adding strm files to Emby it's not possible (for me) to get any media info to show for them (thus EmbyIcons have nothing to do).

Sorry.  

Every load is a nuclear explosion.

[yocker 2005]

6 minutes ago, Ansell said:

The problem is that there are too many media files on my server, causing timeouts every time it loads.

I will look into adding a limit on how many posters it will work on at a time.
I don't think it will solve it but i would be very happy to be proven wrong!

Will write back when the the feature is ready.

Edited 11 hours ago by yocker

[Ansell 9]

1 minute ago, yocker said:

我会考虑添加一次同时处理多少张海报的限制。
我认为这并不能解决问题，不过如果能够被证明是错的，我会非常高兴的！

This is certainly not a concurrency issue; if left unhandled, the posters simply wouldn't display at all. I believe the correct approach is to store the processed images persistently and retrieve them directly when needed.

[Ansell 9]

2 minutes ago, yocker said:

我会考虑添加一次同时处理多少张海报的限制。
我认为这并不能解决问题，不过如果能够被证明是错的，我会非常高兴的！

Given the size of my media library, an in-memory solution won't work; I have to use local disk storage. Otherwise, the sheer number of entries would cause the server to crash, regardless of whether the files themselves are hosted on a cloud server.

[yocker 2005]

Emby already stores those images as you descripe (if i understand you correctly) in programdata/cache. Having EmbyIcons also do it would just double the amount of same rendered images.

If you mean the cache keys then the work for that is very small after a reboot, all it does is check them to see if they are up to date.

[Ansell 9]

4 minutes ago, yocker said:

根据您的描述（如果我理解正确的话），Emby 已经将这些图片存储在 programdata/cache 目录下。如果 EmbyIcons 也能做到这一点，那么相同类型的图片数量就会翻倍。

如果你指的是缓存键的话，那么重启后对这些缓存键的更新工作其实非常少。它所做的只是检查这些缓存键是否是最新的。

Doubling the amount of data stored on disk is acceptable, but the encroachment on memory and CPU resources is unacceptable.

[Ansell 9]

5 minutes ago, yocker said:

根据您的描述（如果我理解正确的话），Emby 已经将这些图片存储在 programdata/cache 目录下。如果 EmbyIcons 也能做到这一点，那么相同类型的图片数量就会翻倍。

如果你指的是缓存键的话，那么重启后对这些缓存键的更新工作其实非常少。它所做的只是检查这些缓存键是否是最新的。

But the issue I see is that my storage simply cannot hold the images from a petabyte-scale media library.

[Ansell 9]

7 minutes ago, yocker said:

根据您的描述（如果我理解正确的话），Emby 已经将这些图片存储在 programdata/cache 目录下。如果 EmbyIcons 也能做到这一点，那么相同类型的图片数量就会翻倍。

如果你指的是缓存键的话，那么重启后对这些缓存键的更新工作其实非常少。它所做的只是检查这些缓存键是否是最新的。

I checked and found that my memory has been offloaded to virtual memory; I allocated 64GB of RAM to Emby, but it was exhausted long ago, so I’ve had to temporarily remove the plugin.

[Ansell 9]

8 minutes ago, yocker said:

根据您的描述（如果我理解正确的话），Emby 已经将这些图片存储在 programdata/cache 目录下。如果 EmbyIcons 也能做到这一点，那么相同类型的图片数量就会翻倍。

如果你指的是缓存键的话，那么重启后对这些缓存键的更新工作其实非常少。它所做的只是检查这些缓存键是否是最新的。

When I delete that plugin, my media library loads in under a second.

[yocker 2005]

8 minutes ago, Ansell said:

I checked and found that my memory has been offloaded to virtual memory; I allocated 64GB of RAM to Emby, but it was exhausted long ago, so I’ve had to temporarily remove the plugin.

That's strange, i have put limits in on how big the cache can get.
And this is not a problem in the 5.60.0.1 you say? I havn't change anything really between the two that would change anything that much.

[Ansell 9]

9 hours ago, yocker said:

That's strange, i have put limits in on how big the cache can get.
And this is not a problem in the 5.60.0.1 you say? I havn't change anything really between the two that would change anything that much.

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.

[Ansell 9]

9 hours ago, yocker said:

That's strange, i have put limits in on how big the cache can get.
And this is not a problem in the 5.60.0.1 you say? I havn't change anything really between the two that would change anything that much.

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.

[yocker 2005]

1 minute ago, Ansell said:

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 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.

[Ansell 9]

14 minutes ago, yocker said:

我已经回滚了在最新版本 5.61.1.0 测试版中实施的某些更改。
另一个变化是，系统不再将图片加载到内存中，而是直接从磁盘中读取图片进行处理。

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

[Ansell 9]

16 minutes ago, yocker said:

我已经回滚了在最新版本 5.61.1.0 测试版中实施的某些更改。
另一个变化是，系统不再将图片加载到内存中，而是直接从磁盘中读取图片进行处理。

 

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

[yocker 2005]

1 minute ago, Ansell said:

 

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

Emby places the images in programdata/cache.

[Ansell 9]

9 minutes ago, yocker said:

Emby 将图片放置在了 programdata/cache 目录下。

Perfect

[Ansell 9]

10 minutes ago, yocker said:

Emby 将图片放置在了 programdata/cache 目录下。

However, it still takes some time to load.

[yocker 2005]

4 minutes ago, Ansell said:

However, it still takes some time to load.

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.

[Ansell 9]

2 minutes ago, yocker said:

你们确实有一个很大的处理库需要处理。  

不过，如果这就是你想要的评分方式，那么“Rating Poster Database”这个插件可能会更适合你。

它的运作方式不同，只专注于评分方面，因此对于你的图书馆来说可能会更快速。

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.

[yocker 2005]

2 minutes ago, Ansell said:

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.

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.