Code:
--------------------
/music/8763ea63/cover_50x50_p.png
...
/music/8763ea63/cover_300x300_p.png
--------------------
First of all I'd not use the .png. This way the server would return
whatever is most efficient. In many cases it doesn't make sense to convert
a jpeg to png (unless you need the transparency).
With the latest 7.8 code you should be able to run the following command:
artworkspec add 300x300_p.png extGUI4LMS
The first parameter is the resizing specification you'd be using (without
the underscore). The second parameter (extGUI4LMS) is an optional name or
description. It should help to clean up definitions once there are too
many of them registered. The web UI (settings/advanced/performance) does
list these additional specifications, and lets you remove them, should you
end up with obsolete specs. Keep in mind that larger artwork will require
a lot more disk space than smaller versions, and every cover is pre-cached
per track, not per album! A 300px image might easily require 100kB or
more. Times the number of tracks...
Unfortunately this registration would only work the next time you run a
full scan and the artwork was pre-cached. Which means that in most cases
the first time your client application is run, it's probably too late, and
you wouldn't see any improvement yet. I'll see whether we could introduce
a background artwork scan to be triggered upon such registrations. But for
now you'd have to run a scan manually.
--
Michael
_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix
