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?
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?
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] Controller Performance Problem
Great stuff - have run the SQL on the squeeze center on my media PC and it works a treat. FYI - Have also been looking at ways to improve controller performance from my ReadyNAS. Have made some suggestions in a separate thread (below), which includes running equivalent logic to the sql during the initial scan. Have to wait and see if I get any traction http://forums.slimdevices.com/showthread.php?t=48617 -- cwinson cwinson's Profile: http://forums.slimdevices.com/member.php?userid=17447 View this thread: http://forums.slimdevices.com/showthread.php?t=45121 ___ 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
[slim] ReadyNAS cover art resampling
I've been looking at getting squeezecenter 7.x running on my ReadyNAS NV+ to feed a new duet setup. Initial attempts were disappointing due to cover art scaling, so I altered the performance options to resample the artwork as opposed to scaling only. Artwork now looks fine, but it takes an absolute age to resample each file. The logs are showing the resampling taking 30-40 seconds for each file: [08-06-06 19:41:41.8060] Slim::Schema::Track::coverArt (271) Retrieving artwork for: file:///MUSIC/FLAC/All%20Saints/All%20Saints/01%20-%20Never%20Ever.flac [08-06-06 19:41:41.8360] Slim::Schema::Track::coverArt (287) Found cached file: /MUSIC/FLAC/All Saints/All Saints/folder.jpg [08-06-06 19:41:41.8511] Slim::Web::Graphics::processCoverArtRequest (221) The variable $actualContentType, which attempts to understand what image type the original file is, is set to image/jpeg [08-06-06 19:41:41.8584] Slim::Web::Graphics::processCoverArtRequest (247) got cover art image image/jpeg of 57040 bytes [08-06-06 19:41:42.1032] Slim::Web::Graphics::processCoverArtRequest (366) resizing from 500x500 to 100 x 100 using pad [08-06-06 19:41:42.1124] Slim::Web::Graphics::processCoverArtRequest (438) This is a gif with transparency [08-06-06 19:41:42.1236] Slim::Web::Graphics::processCoverArtRequest (454) Resampling file for better quality [08-06-06 19:42:20.0966] Slim::Web::Graphics::processCoverArtRequest (500) outputting cover art image image/gif of 7744 bytes [08-06-06 19:42:20.1078] Slim::Web::Graphics::processCoverArtRequest (544) caching result key: 120-pad-100-100-0-.gif, orig=/MUSIC/FLAC/All Saints/All Saints/folder.jpg [08-06-06 19:42:20.2384] Slim::Web::Graphics::processCoverArtRequest (106) this is a transparent gif request [08-06-06 19:42:20.2454] Slim::Web::Graphics::processCoverArtRequest (160) artwork cache key: 133-pad-100-100-0-.gif [08-06-06 19:42:20.3303] Slim::Web::Graphics::processCoverArtRequest (211) Asking for trackid: 133 - cover at size 100x100 My stock artwork format is 500x500 jpg. Can anything be done to tune this? -- cwinson cwinson's Profile: http://forums.slimdevices.com/member.php?userid=17447 View this thread: http://forums.slimdevices.com/showthread.php?t=48595 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] ReadyNAS cover art resampling
Have thought of that but not tested. There are a few different thumbnail formats required for the duet, so some resampling will always be required. If resampling time is directly related to pixel count then resampling to 25x25 (small thumbnail) would take 25x longer with 500x500 than 100x100, so worth a try. Ultimately, it took me a long while to get good quality cover art for my collection. Squeezebox isn't the only front-end - I also use a media center, so don;t want to throw it all away. Would have though that even the processor in the ReadyNas could cope with this - it's not rocket science after all. What perl modules are being used? Can they be replaced? -- cwinson cwinson's Profile: http://forums.slimdevices.com/member.php?userid=17447 View this thread: http://forums.slimdevices.com/showthread.php?t=48595 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Remote streaming
Thanks for the replies guys. Have done a bit more research on the buffering and it seems that windows media player is particularly bad (if that's the right term) at buffering the mp3 stream. It effectively downloads as much as is can, which means you changing the stream (skipping songs for example) takes a long time to respons (minutes). Tried using winamp as a player and it doen't download quite as aggressively. Appears to only download/buffer 5 seconds ahead of the current position, so commands only take 5 seconds to take effect, which is manageable. Question is I guess whether the Pico downloads agressively like windows media player or behaves like winamp. Ideally, it would be configurable. -- cwinson cwinson's Profile: http://forums.slimdevices.com/member.php?userid=17447 View this thread: http://forums.slimdevices.com/showthread.php?t=47865 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
[slim] Remote streaming
Hi all - first post, so please be gentle. Have taken the plunge and ordered a duet. Awaiting delivery, but have got a squeeze center and softsqueeze setup up and running. Have been also trying to get remote streaming working via stream.mp3, but can't get any sound to come through. Other posts have suggested setting the secutity settings for the server, but I can't find them in squeeze center. Am I being stupid? Reason I'm testing this is I'd like to use a Rivo Pico Wi-Fi as an additional player for the kitchen. Has anyone tried one of these? I've read that Blik Radiostation works fine, so hoping this is the case for the Pico. Any help much appreciated Thanks Chris -- cwinson cwinson's Profile: http://forums.slimdevices.com/member.php?userid=17447 View this thread: http://forums.slimdevices.com/showthread.php?t=47865 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
Re: [slim] Remote streaming
Found a solution: http://forums.slimdevices.com/showthread.php?p=301978#post301978 Installed lame.exe and set the file type setting. Can now stream music to wmp. Next problem - I can play music files, but can't control them with any certainty from the web interface (and presumable from the duet controller when it arrives). Looks like the mp3 stream is getting heavily buffered at the client side, so if I skip tracks, it's too late as it's already been sent and queued Chris -- cwinson cwinson's Profile: http://forums.slimdevices.com/member.php?userid=17447 View this thread: http://forums.slimdevices.com/showthread.php?t=47865 ___ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
