]]>
Dubious wrote:
> ...and then reboot the PC and
> re-load Silverjuke - that even then my album
> covers are still quick and responsive.
That is indeed the caching to disk you see. And yes, you could use my script just once to make sure you have cached all art.
But the effect the script was intended for was to make sure at _every_ start of SJ (and not PC boot) that SJ has RAM-cached the disk-cached images.
Some figures for my old Athlon-1200 (I think) PC with MP3's stored on a fast USB drive, showing 8 covers per page:
1) Without any cache a new page shows its album art in 0.25-1.0 seconds
2) With diskcache a new page shows in about 0.25 seconds. Fast, but you can still clearly see the order in which the 8 covers are drawn.
3) With RAM cache at 256Mb and after scrolling once through the entire collection (or let my script do that, no difference) all pages are drawn (nearly) instantly, I can not see anymore in which order they are drawn.
Using disk-cache or not the end result is the same, but the initial loading of any page takes 0.25-1.0 (without) versus under 0.25 (with).
So especially as in Dubious' case where the initial load can be even 3 seconds per 8 covers, the added value of the RAM caching is not that great compared to that of disk-caching. But for me it is just that last added icing on the snappy-cake, especially for a dedicated jukebox. And if you have a dedicated machine which you just turn on once a day my script will have the RAM cache filled up for you without any effort from the user.
Regards,
SilverEagle
Statistics: Posted by SilverEagle — 14. Nov 08, 07:52
]]>
I hope this helps other people who have their music stored on a remote server (especially across a high-latency connection like mine).
Statistics: Posted by Dubious — 14. Nov 08, 04:41
]]>
Regards,
SilverEagle
Statistics: Posted by SilverEagle — 13. Nov 08, 23:44
]]>
The cache setting extracts album art from the MP3's and puts it by default in "c:\documents and settings\<yourname>\Local Settings\SilverJuke".
They are not removed upon exit, and reused for the next session, and there is no limit on filecount. So if you ever have seen an album it will stay cached (forever as far a I know - I did not wait for that to happen
). FYI: I have 11Mb 354 *.bmp files in the imagecache, one for each albumcover for about 5000 songs.Just scroll once though your collection using the basic skin, then switch over to your touchskin.
Alternatively you could even scroll on the fast machine with local database, then copy the imagechache, but probably you'd need to map the music collection to the same path as explained previously. But that is just theoretical, I did not try that.
What you'll still see are two cache effects:
1) windows file cache
You could help this a little with all sorts of "read and discard" tricks before program start, but it will probably not fit all images, depens on your physical RAM and a lot of other stuff beyond real control.
2) SJ album RAM cache
You could increase this to the max if it makes sense related to your physical memory, and make sure it could hold all your images. (I have 256Mb with 3% for 354 images here, so that fits a lot)
I'll see what I can do about loading them once on startup to make sure they are in the SJ RAM cache, either as a standalone script (which I'll post here) or as a startup option in the touchskin you have (which will become available at 1/12
) And if you put them first in the imagecache, that might make for a reasonable SJ boottime.Cheers,
SilverEagle
Statistics: Posted by SilverEagle — 13. Nov 08, 11:35
]]>
Are there any settings that will automatically cache the album art without having to manually scroll through all of the available albums first?
Statistics: Posted by Dubious — 13. Nov 08, 02:59
]]>
What I am finding is that I can greatly improve the performance of SJ if I load the application, then scroll through all of the album art. When I have already displayed all of the album covers once then they display much more quickly each subsequent time. Its apparently that SJ is performing some sort of caching without my intervention. And this is a good thing. But I would like to maximize this performance without having to scroll through 800 albums first.
I'm looking in the Settings --> Advanced --> Further Options
I read the online manual for these options but it isn't exactly clear what the "real world" results would be for each of these.
I'm slightly confused as to what these settings do in some cases. Can I get some clarification on the following:
- Image cache: RAM cache
- I'm guessing that this will allocate xxx MB of RAM to cache album art. The default is only 2MB. If I set this to 64MB, and my average album art file is 100KB in size, then I should be able to cache about 640 album art images in memory. But I would guess that it has to load the album art once in order to add it to the cache. So do I have to still scroll through all of my albums to get them added to the cache?
- Image cache: Use temporary directory
- Does using a temporary directory actually save a copy of the album art file in a temp directory for fast access? Having the album art files saved on the local HD would be much faster than having to load them across the network. But would I still have to scroll through all of my album art once to get SJ to store those files temporarily?
- Index file: RAM cache
- This option is not documented in the online manual. I assume that this allocates RAM to cache the database. But how much RAM is needed? I added about half of my music collection to SJ and my mymusic.db file is 6270KB in size. If I set this setting to about 16MB then I would be able to cache the entire database in RAM for fastest performance?
In summary, I would like to set up the options so that I do not have to scroll through 800 albums once in order to add the album art to a cache. I would much rather wait 30-60 seconds at SJ startup to have the images cached automatically. Or even better, the cache should be created when the music collection is first indexed by SJ. The cache would only change when music is added or deleted from the collection, and the user would have to re-index the database at that time anyway.
Perhaps I am missing some obvious settings which would help me?
Statistics: Posted by Dubious — 12. Nov 08, 00:10
]]>