On Jun 20, 2010, at 2:24 PM, MrSinatra wrote: > > andyg;555001 Wrote: >> If a cover image is in the cache it shouldn't be going to the source >> file at all, I thought I had already fixed that but will make a note to >> take another look. Certainly there is more work to be done here, for >> example cover.jpg changes on the disk aren't picked up the same way as >> audio file changes are by the auto-rescanner. > > Andy, > > In addition to that concern, (cache/source), which is one i share, i > also think it would make sense to streamline and even make user > configurable what is cached and used. > > if you look at the art in the cache, one is 40 pixels, another is 41 > pixels. i would suggest that designing things in this way [as to > necessitate two images of one pixel difference] is not good design. > can't things be redone so only the bare minimum of various sizes are > made?
Yes the 40 vs 41 issue was caused by the UI designer not taking into account how we deal with resized artwork, it's unfortunate. > and can't the user be empowered to tell SBS what versions * not * to > create if they don't have gear that uses those sizes? Maybe, but what if you then buy something that needs those sizes, and your new device doesn't show any artwork because it's being created very slowly? _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/beta
