mherger wrote:
> > 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).
>
Good point, I've changed it. I noted that the LMS Web UI uses /cover.png
for the full-size cover pop-up - should one in this case use the .png,
or would /cover be preferred?
mherger wrote:
>
> 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.
>
This doesn't work for me:
artworkspec add 300x300_p.png extGUI4LMS
since Slim::Web::Graphics->parseSpec accepts this spec, but gdresize
itself doesn't like the .png part ("Invalid spec")
This does:
artworkspec add 300x300_p extGUI4LMS
mherger wrote:
>
> 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...
>
Actually, it seems I have the issue mentioned in another thread that the
db only grows, it's ~5GB (even before adding the new size).
Although I don't have any performance issues from that, what's the best
way to shrink it? Delete & complete scan?
mherger wrote:
>
> 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.
>
Actually, as you noted in another post, it starts the pre-caching as
soon as I added the new size, which is great.
One question: it seems the _p and _m format are actually identical (and
are treated like this in GDResizer). Adding both, however, results in
two pre-cache runs/entries.
What's the purpose of having these two formats?
(There's a good probability that the same format gets pre-cached twice,
if I look at the default formats, it's already inconsistent (64x64_m,
but 75x75_p), so I'm unsure which one is the preferred)
Thanks,
Roland
------------------------------------------------------------------------
Roland0's Profile: http://forums.slimdevices.com/member.php?userid=56808
View this thread: http://forums.slimdevices.com/showthread.php?t=98156
_______________________________________________
unix mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/unix
