DJanGo wrote:
> AFAIK GDresizer does all the little artwork like eg. cover_96x96_p.png
Right, but I thought everything was pre-cached at scan time. Even if
some of the sizes aren't precached, if the same original images are
being handled later, you'd think GDresizer wouldn't have a problem with
OK, still have the same issue. Server crashes several times a day,
always with the last line in the server log looking like this:
[16-10-19 19:17:08.5208] Slim::Utils::Misc::msg (1244) Warning:
[19:17:08.5206] Perl interpreter failed at
gonk wrote:
> OK, still have the same issue. Server crashes several times a day,
> always with the last line in the server log looking like this:
>
> [16-10-19 19:17:08.5208] Slim::Utils::Misc::msg (1244) Warning:
> [19:17:08.5206] Perl interpreter failed at
>
JJZolx wrote:
> Hmm... My library has 43,600 flac files in 3600 albums.
> My library.db is 120MB,
> artwork.db is only 91MB.
> Every album has a cover.jpg per folder, with most of them 600x600 pixels
> in size, some older ones smaller.
>
> What would account for the large difference in library
mherger wrote:
> Now there's a twist to this which can have a massive influence on the
> artwork.db file cache: applications or plugins can register their own
> sizes to be pre-cached. Eg. iPeng does this. Therefore the size of your
>
> cache file depends on your use of 3rd party tools, too.
AFAIK GDresizer does all the little artwork like eg. cover_96x96_p.png
Right, but I thought everything was pre-cached at scan time. Even if
No, it's not: only sizes which are expected to be used often, very
likely, and lots at the same time are pre-cached. That's mostly the
smaller sizes
