JJZolx wrote:
I'm not positive, but I believe that it does increase both the work done
by the server when pre-caching resized artwork during a scan, plus the
amount of storage required for the cached images.
It doesn't increase storage size - the size of the cached image is the
same, no
Roland0 wrote:
It doesn't increase storage size - the size of the cached image is the
same, no matter what the source.
It doesn't take additional effort for this, as LMS has to check each
file for artwork in any case, since it's possible to have different
artwork for tracks from the same
JJZolx wrote:
How can the cache check use the path, since the path for different audio
files will always be unique? Have you looked at the code?
see Artwork.pm:
Code:
# Find all tracks with un-cached artwork:
# * All distinct cover values where cover isn't 0
Another way too answer your question:
I store embedded and folder.jpg for all music (mainly flac and mp3). I
tend to try to find the highest resolution artwork I can (typically in
the 800x800 to 1500x1500 range unless it's obscure). It doesn't cause
me any performance issues AFAIK.
What is
Embedding artwork into every track rather than storing one single
cover.jpg must increase the storage size required for your library?
Granted they are not big files but over time and many CDs I would have
thought that they would add up to a relatively significant amount of HDD
space.
2 x Duet,
flimflam wrote:
Thanks. So when scanning the library, LMS cross-checks the embedded art
for each track and if it is a repeat of another track, they share the
same cached files?
only if they are from the same album
And therefore once scanning is complete, there is no difference in
Thank you everyone, especially Roland0 for your brilliant answer - v
helpful, really.
flimflam's Profile: http://forums.slimdevices.com/member.php?userid=56891
View this thread:
HeadBanger wrote:
Embedding artwork into every track rather than storing one single
cover.jpg must increase the storage size required for your library?
Granted they are not big files but over time and many CDs I would have
thought that they would add up to a relatively significant amount of
flimflam wrote:
Given I use lossless encoding, and the average length of a track - it
would be about 1% of my library with 'hi-res' artwork, which I think
isn't too bad of a hit.
I am contemplating this approach for reasons outside of Squeezebox. For
example, in iTunes on my Mac I can't
flimflam wrote:
Possibly a dumb question, but if I embed folder.jpg into each file of,
for example, a 10 track album (to make life easier outside of
Squeezebox), does this cause ten times the work for LMS artwork resizing
and caching (and use up ten times the cache storage)?
I'm not
Roland0 wrote:
It will be processed / stored only once if it's the same picture for all
the tracks.
Thanks. So when scanning the library, LMS cross-checks the embedded art
for each track and if it is a repeat of another track, they share the
same cached files? And therefore once scanning is
I can't recall all sizes used , touch uses 3 different sizes so does
radio and ,controller wants 2 sizes and the web UI has several sizes to
.
But all are not pre cached , some are converted on the fly and stored
temporarily .
In the later LMs version the artwork is stored in the artwork.dB
Possibly a dumb question, but if I embed folder.jpg into each file of,
for example, a 10 track album (to make life easier outside of
Squeezebox), does this cause ten times the work for LMS artwork resizing
and caching (and use up ten times the cache storage)?
Thanks. (I use iPeng, if this makes
flimflam wrote:
Possibly a dumb question, but if I embed folder.jpg into each file of,
for example, a 10 track album (to make life easier outside of
Squeezebox), does this cause ten times the work for LMS artwork resizing
and caching (and use up ten times the cache storage)?
It will be
14 matches
Mail list logo
