Re: [slim] Embed art vs folder.jpg?

[Roland0]

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
> storage or workload compared to a single folder.jpg with no embedded
> artwork?
> 
In practice, there shouldn't be.

> 
> I looked long and hard for some basic info in layman's terms about this
> but couldn't find much. I think LMS when scanning the library makes one
> small and one large pre-cached image (potentially up to two cached
> images per track if they were all embedded with different images) - is
> that right? And these are ready-made for the thumbnail and Now Playing
> views in Players? I was wondering then what exact resolution are these
> images and where/in what form does the server store them? 
> 
Well, it's not really a topic the average user cares much about, I'd
guess.

Pre-generated sizes are:

Code:
--------------------
    
  "100x100_o", # Web UI large thumbnails
  '75x75_p',  # iPeng
  '64x64_m',  # Fab4 10'-UI Album list
  '50x50_o',  # Web UI small thumbnails
  '41x41_m',  # Jive/Baby Album list
  '40x40_m',  # Fab4 Album list
  
--------------------

Recent versions of LMS 7.8 allow 3rd party extensions to register
additional sizes, see the thread "Registering custom resizing
specifications to be pre-cached" in the Developer's forum.
Additionally, if another size is requested by an application (e.g.
SqueezePlay uses 240x240px, the web GUI 96x96px), it will be generated
on-the-fly and cached as well. 

As mentioned, the images are stored in a database (artwork.db), which
can grow to a large size (see  'this'
(http://forums.slimdevices.com/showthread.php?98776-Registering-custom-resizing-specificiations-to-be-pre-cached&p=749287&viewfull=1#post749287)
and subsequent posts for a detailed analysis an why this is happening).

Short version: Due to an issue in LMS, full-sized pictures will also be
cached. Additionally, if the image isn't perfectly square (e.g. 801x800
instead of 800x800), it will be (under certain circumstances) cached as
a png, no matter what the original format is (see above linked thread
for details), effectively doubling the size. This happens both for
embedded and standalone artwork.

That being said, the size of the database shouldn't really affect
performance (my artwork.db at one point was 5.3 GB, and I never noticed
any issues). What is noticeable for large full-size covers, though, is
the increase in network transmission time, as a 1.5mb jpg gets converted
to a 12mb  png, which is then sent from the LMS server to your browser.



[ extGUI4LMS - an alternative web interface: 'forum'
(http://forums.slimdevices.com/showthread.php?98186-Announce-Alternative-Web-Interface-(beta))
/ 'homepage' (http://code.google.com/p/extgui4lms/) ]
------------------------------------------------------------------------
Roland0's Profile: http://forums.slimdevices.com/member.php?userid=56808
View this thread: http://forums.slimdevices.com/showthread.php?t=98996

_______________________________________________
discuss mailing list
discuss@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/discuss