Re: [slim] Artwork resizing - could it be managed better?
[08-12-23 00:15:52.8045] Slim::Web::Graphics::processCoverArtRequest (618) caching result key: plugins/cache/icons/radioio_25x25_f.png, orig= [08-12-23 00:15:53.1488] Slim::Web::Graphics::processCoverArtRequest (114) this is a transparent png request [08-12-23 00:15:53.1648] Slim::Web::Graphics::processCoverArtRequest (197) cached image not usable because 'orig' undef [08-12-23 00:15:53.1744] Slim::Web::Graphics::processCoverArtRequest (222) Asking for trackid: notCoverArt - radioproviders at size 25x25 [08-12-23 00:15:53.1813] Slim::Web::Graphics::processCoverArtRequest (316) got cover art image image/png of 26165 bytes [08-12-23 00:15:53.5125] Slim::Web::Graphics::processCoverArtRequest (433) resizing from 336x336 to 25 x 25 using fitstretch [08-12-23 00:15:53.5201] Slim::Web::Graphics::processCoverArtRequest (499) Set alpha for transparent png [08-12-23 00:15:53.5274] Slim::Web::Graphics::processCoverArtRequest (521) Resampling file for better quality [08-12-23 00:16:21.3728] Slim::Web::Graphics::processCoverArtRequest (567) outputting cover art image image/png of 1163 bytes [08-12-23 00:16:21.4716] Slim::Web::Graphics::processCoverArtRequest (618) caching result key: plugins/cache/icons/radioproviders_25x25_f.png, orig= [08-12-23 00:16:22.5571] Slim::Web::Graphics::processCoverArtRequest (114) this is a transparent png request [08-12-23 00:16:22.5830] Slim::Web::Graphics::processCoverArtRequest (191) returning cached artwork image, image/png (729 byte) Now with version 7.3.1, every time the webUI is loaded, most of the 25x25 icons are re-generated instead of being retrieved from pre-cached artwork. This causes the webUI to be very slow on each startup. From the debug above you can see that this is due to: cached image not usable because 'orig' undef -- Fishbones Fishbones's Profile: http://forums.slimdevices.com/member.php?userid=20670 View this thread: http://forums.slimdevices.com/showthread.php?t=48617 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
Hi guys, This might be a stupid question, and I apologise if it is, but could we not have the option of resizing/resampling album artwork offline on a proper PC? I have a ReadyNAS and a Controller, and it would be really nice to just let your (hopefully much more powerfull) PC perform all of the hard work, and dump the results into the ReadyNAS's cache file. The Moog -- The Moog The Moog's Profile: http://forums.slimdevices.com/member.php?userid=5192 View this thread: http://forums.slimdevices.com/showthread.php?t=48617 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
Looking into the artwork cache directories I see that a scan generates and caches */*/cover_100x100_p images. When the webUI requests covers for the Albums menu squeezecenter generates and caches ANOTHER file */*/cover_100x100_o. So we have */*/cover_100x100_p AND */*/cover_100x100_o in cache. Why doesn't the webUI use */*/cover_100x100_p that was generated by the scan? -- Fishbones Fishbones's Profile: http://forums.slimdevices.com/member.php?userid=20670 View this thread: http://forums.slimdevices.com/showthread.php?t=48617 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
Looking into the artwork cache directories I see that a scan generates and caches */*/cover_100x100_p images. When the webUI requests covers for the Albums menu squeezecenter generates and caches ANOTHER file */*/cover_100x100_o. Good catch! We originally used the _p covers in the web UI, but later switched to using _o. Alas, we forgot to adapt the pre-caching... This should be fixed in 7.3 r23698. Thanks a lot! -- Michael ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
Got it. (I was looking *.jpg files in cache :-| I have been following bug9757 and it would be great if something like that could be done via the webUI. For now I'm going to try and apply the patch. erm ... after finding out to apply a patch to *.pm file that is... Cheers -- Fishbones Fishbones's Profile: http://forums.slimdevices.com/member.php?userid=20670 View this thread: http://forums.slimdevices.com/showthread.php?t=48617 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
i think a user, and esp a nas user, should be able to optionally run scans with settings they choose. imagine an artwork only scan. imagine a music only scan. sure, this may mean your music and art are somewhat out of sync at times, but the user should have the option. (other options in a scanner would be what to look for, so you could turn off looking for embedded artwork, or certain tags you don't need or care about, and as i've mentioned elsewhere, the ability to turn off automated logics like VA and GH) -- MrSinatra www.LION-Radio.org Using: Squeezebox2 (primary) / SBR (secondary) / SBC - w/SC 7.3b - Win XP Pro SP3 - 3.2ghz / 2gig ram - D-Link DIR-655 MrSinatra's Profile: http://forums.slimdevices.com/member.php?userid=2336 View this thread: http://forums.slimdevices.com/showthread.php?t=48617 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
AH! No go for ReadyNAS and artwork on demand resampling then. But what does it do for 13 hours then? As I said it lacks support for floating point operations in the CPU. Thus resizing one artwork might take 20 secs. vs. 2 secs in resize mode. It must be resampling and caching the resampled images somewhere. What size are they and where are they being cached to? They're the size as used on the Controller (50, 56) plus what you've defined as the thumb artwork size in the web UI (100 by default). I turned on debug for artwork and noticed that SlimPronto requests 64x64 images to display a coverart collage. Squeezecenter then resizes from the original folder.fpg of 500x500 to 64x64. Now if these 64x64 images were already cached then there would be no need for this on demand resize. Images would just be retrieved from cache. So we could have resampling enabled and the only downside would be the long scan time. There's already an enhancement request for additional formats. You might want to add your voice. http://bugs.slimdevices.com/show_bug.cgi?id=9757 I also noticed that the web interface requests 100x100 and those also get resized and resampled on demand. They should be pre-cached. -- Michael ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
Could someone please point out to me where the images are pre-cached on the server. Cheers. -- Fishbones Fishbones's Profile: http://forums.slimdevices.com/member.php?userid=20670 View this thread: http://forums.slimdevices.com/showthread.php?t=48617 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
Could someone please point out to me where the images are pre-cached on the server. In the cache folder you'll find in Settings/Status. -- Michael ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
I'm running SqueezeCenter 7.2.1 on a ReadyNAS Duo and have noticed that when a scan is done with Resample Artwork set in the performance settings, viewing album art in the web interface and consequently also on a Philips Pronto with the SlimPronto module, is very slow to non functional. When a scan is done with Resize Artwork, cover art loads in seconds. A scan with Resample Artwork set takes +-13 hours. A scan with Resize Artwork set takes +-1 hours. So what is happening here? Does album art, either resampled or resized, get cached on the server? If it's not cached, why does it take 13 hours to resample artwork? TIA. -- Fishbones Fishbones's Profile: http://forums.slimdevices.com/member.php?userid=20670 View this thread: http://forums.slimdevices.com/showthread.php?t=48617 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
When a scan is done with Resize Artwork, cover art loads in seconds. There's one reason that option exists at all: ReadyNAS. We only introduced it because the ReadyNAS isn't able to resample the artwork in a reasonable amount of time. why does it take 13 hours to resample artwork? AFAIK because the ReadyNAS doesn't have a floating point unit. -- Michael ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
Been a while since I looked at this. In truth, this issue turned into a showstopper for me and I've ended up using itunes and the iphone/ipod remnote app instead. As I'm using softsqueeze, this works fine for me. From memory, the problem you are having is that the ReadyNas CPU is particularly poor at running the resampling code This is compounded by the fact that the initial scan only creates caches for some of the artwork sizes used in the controller and the web interface - the rest has to happen on the fly, which kill the user experience. Don't know whether any of my suggestions above were taken into account in later releases, but to be honest, I don't really care at this stage. The slim duo is packed up along with other redundant kit. I would peddle it in ebay if it wasn't for the fact that it's got scratches all over the back from where the controller was actually taken out of the cradle. Nice idea - bad implementation -- cwinson cwinson's Profile: http://forums.slimdevices.com/member.php?userid=17447 View this thread: http://forums.slimdevices.com/showthread.php?t=48617 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
cwinson wrote: Been a while since I looked at this. In truth, this issue turned into a showstopper for me and I've ended up using itunes and the iphone/ipod remnote app instead. As I'm using softsqueeze, this works fine for me. From memory, the problem you are having is that the ReadyNas CPU is particularly poor at running the resampling code This is compounded by the fact that the initial scan only creates caches for some of the artwork sizes used in the controller and the web interface - the rest has to happen on the fly, which kill the user experience. Don't know whether any of my suggestions above were taken into account in later releases, but to be honest, I don't really care at this stage. The slim duo is packed up along with other redundant kit. I would peddle it in ebay if it wasn't for the fact that it's got scratches all over the back from where the controller was actually taken out of the cradle. Nice idea - bad implementation Using a NAS for a media server is a bad idea indeed. X. ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
I'm not sure that's the case - most of the NAS boxes out there are stripped down Linux boxes which should be perfectly capable of running a media server. Of course it depends on what the media server is trying to do. The issue for me around this whole episode was that ReadyNAS was purported to be capable of running the software. It wasn't immediately apparent that this came with big caveats. The option to run with resized artwork was not workable for me - the artwork looked awful. I should note that I also ran for a period of time with the software running on a full PC. I still found the performance and responsiveness of the controller disappointing - I guess I have high expectations... Of course, that was when it was able to get a wireless signal.. -- cwinson cwinson's Profile: http://forums.slimdevices.com/member.php?userid=17447 View this thread: http://forums.slimdevices.com/showthread.php?t=48617 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
mherger;352408 Wrote: When a scan is done with Resize Artwork, cover art loads in seconds. There's one reason that option exists at all: ReadyNAS. We only introduced it because the ReadyNAS isn't able to resample the artwork in a reasonable amount of time. why does it take 13 hours to resample artwork? AFAIK because the ReadyNAS doesn't have a floating point unit. -- Michael AH! No go for ReadyNAS and artwork on demand resampling then. But what does it do for 13 hours then? It must be resampling and caching the resampled images somewhere. What size are they and where are they being cached to? I turned on debug for artwork and noticed that SlimPronto requests 64x64 images to display a coverart collage. Squeezecenter then resizes from the original folder.fpg of 500x500 to 64x64. Now if these 64x64 images were already cached then there would be no need for this on demand resize. Images would just be retrieved from cache. So we could have resampling enabled and the only downside would be the long scan time. I also noticed that the web interface requests 100x100 and those also get resized and resampled on demand. -- Fishbones Fishbones's Profile: http://forums.slimdevices.com/member.php?userid=20670 View this thread: http://forums.slimdevices.com/showthread.php?t=48617 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
Thanks for the responses Michael. To answer the question around what I mean by 'more could/should be done during the initial scan', I would propose the following: 1) Provide a set of options which configures the resampling and caching of the various artwork sizes during the initial scan. Knowing my RadyNAS struggles with the resizing, I would pre-scan the 56x56, 154x154, 186x186 and 240x240 images which are used by the controller - plus possbily the web ones as well so I can access the settings page within a reasonable timescale. The initial scan would take a long time, but this could be scheduled overnight 2) Resize and cache the standard icons (e.g. no album cover, favourites etc.) during the initial scan. At the moment, I'm not sure if they're even cached on first use. 3) Run the logic to determine artwork location for each track (embedded tag vs. folder.jpg etc.) during the initial scan. This would also fix the issue reported by EliteAV in the following thread where this per-track check causes delays in browsing albums. http://forums.slimdevices.com/showthread.php?t=45121 Add to this the ability to share cached artwork across tracks so the resizing doesnt have to occur multiple times (as per the bug you mention) and I think the overall responsiveness of the controller would be far better. For me, it would make the readynas solution workable without having to use the degraded artwork option. Chris -- cwinson cwinson's Profile: http://forums.slimdevices.com/member.php?userid=17447 View this thread: http://forums.slimdevices.com/showthread.php?t=48617 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Artwork resizing - could it be managed better?
1) The initial scan doesn't do much to help the controller interface in terms of resizing and caching artwork. Only the 56x56 image is used by the controller Nope. Now Playing and screensaver use the other sizes. 2) There is no sharing of cached cover art for different songs in the same album. This issue is being tracked in a bug report (don't remember its number) 3) More could/should be done during the initial scan to help out those Please define more? Overall, I think there a lots of things that can be done around the management of artwork which would make the interfaces run much better. The problem here is dev cost vs. use case. ReadyNAS is by far the slowest device out there regarding this issue. ReadyNAS users are a small bunch. And most of them seem to be happy with the current compromise. It's particularly bad with ReadyNas, but would help across the board. That's especially true for 2. which we're addressing. -- Michael ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Artwork resizing - could it be managed better?
Bit of a long one this I'm afraid I've been doing some investigation into artwork resizing and caching in 7.01, prompted by the fact that it takes 30 secs to resample a 500x500 image on my RadyNAS NV+ to each required size, which means teh interface runs like a dog Note: I have tried reducing the size of my standard artwork files to see if it helps - it does reduce the resample time (to 15 secs), but it's still not manageable Having turned on logging in the server, I've seen the following: 1) Artwork is cached on a per song basis, rather than a per-album basis 2) The initial scan creates and caches some artwork sizes (see below) but only for the first song in the album 3) There are 7 different representations of artwork that I've seen: 50x50 (pad) - Created and cached for each album during initial scan. Used for web interface album thumbnails 100x100 (pad) - Created and cached for each album during initial scan. Used for web interface 'now playing' thumbnails 56x56 (original) - Created and cached for each album during initial scan. Used in controller interface for album thumbnail 96x96 (pad) - Not created during initial scan. Used for 'now playing' thumbnail in web interface. Gets created and cached when a song is first played via controller, causing delay in now playing artwork to appear 154x154 (original) - Not created during initial scan. Used for smaller 'now playing' thumbnail in controller. Gets created and cached when a song is first played via controller, causing delay in now playing artwork to appear 186x186 (original) - Not created during initial scan. Used for larger 'now playing' thumbnail in controller. Gets created and cached when a song is first played via controller, causing delay in now playing artwork to appear 240x240 (original) - Not created during initial scan. Used for 'show artwork' screen in controller. Gets created and cached on first request, causing delay in artwork to appear 25x25 - Not created during initial scan. Used for small non-artwork thumbnails in the web interface. Gets created and cached on first request, causing delay in the web interface to work first time 3) Most of the standard icons which sit alongside the cover art (e.g. 'no cover art' logo, favourites logo, genre logo etc.) come in a standard jpg size (336x336) and have to be resampled on first use in the interfaces (web and/or controller). This causes delays in first use of either interface - particularly when using readyNas server Some observations: 1) The initial scan doesn't do much to help the controller interface in terms of resizing and caching artwork. Only the 56x56 image is used by the controller 2) There is no sharing of cached cover art for different songs in the same album. I understand that some people may have embedded artwork which can vary by song, but if folder.jpg is used, the cached versions should be re-used where possible 3) More could/should be done during the initial scan to help out those of us who predominantly use the controller interface as opposed to the web interface. Perhaps this could be made configurable so that I could get all resizing and caching requirements done up front as opposed to on first use. 4) If nothing can be done around point 2 (different songs, same album), getting the initial scan to create artwork for all of the songs would be useful - at least as an option 5) The standard logos used in the interfaces should be pre-prepared and cached to meet requirements rather than on first use. Overall, I think there a lots of things that can be done around the management of artwork which would make the interfaces run much better. It's particularly bad with ReadyNas, but would help across the board. It may take some more programming and/or config options, but I think it's worthwhile. If all I had was my readynas nv+ to run the server, I would have given up on the duet and returned it. At the moment, I'm using another machine to run the server and it's useable - but has other issues. Ideally I would migrate back to readynas as it's the only always-on machine in the house. -- cwinson cwinson's Profile: http://forums.slimdevices.com/member.php?userid=17447 View this thread: http://forums.slimdevices.com/showthread.php?t=48617 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
