mherger wrote: > > Thanks for releasing this, Michael. Iâm seeing artist picture scan > as 40 > > times as fast as the previous version and 4x as fast as the patch I > > wrote :) > > Well... unfortunately this joy didn't last long: turns out the new > method not only caused some issues, but it's not working as expected > with Material or iPeng. As they use both create the image URL based on > the raw data, they don't get the updated URLs. Which means they don't > take advantage of the pre-cached artwork and will continue to flood the > > cache file with copies of the images. I'll have to re-think how I handle > > artist artwork :-(.
:( Here is what I was thinking: Since many such clients use the artist id in paths like "imageproxy/mai/artist/artist_id/image.png" as well as elsewhere, I suspect that what we really want is for the artist id (which I presume is generated by LMS rather than MAI) to be stable. What if when LMS (not MAI) synthesizes an ID (assuming the source being scanned doesn't provide one), it uses the name or a hash of the name instead of just incrementing a count (which is what I'm guessing is done now)? If my speculation is correct, then the original MAI would work without changes, and I suspect there would probably be other benefits to having stable ids as well. I realize that was all very speculative about what is happening behind the scenes, but does that make sense? ------------------------------------------------------------------------ mps's Profile: http://forums.slimdevices.com/member.php?userid=36351 View this thread: http://forums.slimdevices.com/showthread.php?t=99537
_______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
