Bugzilla – Bug 14921
Give database some room to breathe
Last modified: 2011-01-14 19:15:40 UTC
Moonbase discovered that simple edits to text files will dramatically decrease the amount of time needed to do a scan. however, each persons hardware is different and most users do not feel comfortable or want to go under the hood. so the solution being proposed, which was phil m's idea that AndyG supported, was for the installer to run a "check" on system specs, and figure out the best values to use in the text files based on the system specs. personally i don't know what specs need to be known. surely some idea of CPU speed and RAM size, but maybe also HD speed? thruputs? RAM speed? more? but guidelines/data need to be developed so the installer knows what to do based on what hardware it finds at the time of install. the database, scanner, and installer are all involved then. the other alternative is to have the installer actually run live tests and work out the values based on those results, rather than apply less precise guidelines based on sporadic user feedback of similar found hardware. (even an infrant can have different ram sizes installed, all hardware should have basically unique optimums) the best solution would be for some kind of automatic (but optional) feedback be included, so that scantimes, fileinfo, system specs, and DB text values were reported back to logitech, and over time it could become more obvious as to how to fine tune and reach optimum values, so that on each new install it got better until it was perfect.
Andy will keep track of this bug, waiting for information to implement feature.
James, the bug was assigned to me, surely a mistake, i can program a VCR, thats it. :) "in andy, we trust"
It is assigned to you because you guys need to work out what to do in the forum thread first.
My results: System: Windows 2008 R2 (x64), 4GB, Pentium Dual-Core E5200@2.50Ghz, 99% .flac, 2 drives in RAID0 (Intel ICH8R/ICH9R/ICH10R/DO SATA RAID Controller) Total Tracks: 35,792 Total Albums: 3,445 Total Artists: 1,033 Total Genres: 151 Total Playing Time: 2767:39:29 Music Scan Details (Before) Directory Scan (35792 of 35792) Complete 00:35:37 Playlist Scan ( of ) Complete 00:00:00 MusicIP Import (35321 of 35321) Complete 00:24:03 Merge Various Artists (3309 of 3309) Complete 00:01:27 Artwork Scan (3445 of 3445) Complete 00:24:36 The server has finished scanning your music collection. Total Time: 01:25:43 (Monday, 26 October 2009 / 19:24) Music Scan Details (After) Directory Scan (35792 of 35792) Complete 00:33:56 Playlist Scan ( of ) Complete 00:00:00 MusicIP Import (35321 of 35321) Complete 00:13:57 Merge Various Artists (3309 of 3309) Complete 00:01:26 Artwork Scan (3445 of 3445) Complete 00:24:34 The server has finished scanning your music collection. Total Time: 01:13:53 (Monday, 26 October 2009 / 20:56)
Andy, so far all the results seem to indicate that even the sheevaplug improves with moonbases file. everyone has gotten better scores, and probably could get even better scores with more tweaking. i do not know, but would guess the infrant nv type stuff wouldn't however. so except for only the lowest power hardware, it seems safe to make his file the new default. so here are my questions: 1. can u assign differing my.tt files for different distributions? 2. how are we to optimize the my.tt values automatically for each hardware setup? is there a sql program during install/setup or a plugin that we [users] could use to figure out what the best values are/would be? 3. if we make a plugin that allows us to update the values, can a log be made so as to track whether or not the improvement helped or hurt the scan times? all, please add your results to this tread rather than the bug: http://forums.slimdevices.com/showthread.php?t=70371
Changing priorities due to management guidance.
Moving P3 and lower bugs to next release target
Honestly I fail to see the reason of the delay for this specific improvement. It brings benefits to pretty much all platforms...
We're going to move to SQLite before we get to fix this bug. Users should feel free to tweak their settings however they like, however.
i just saw this bug was closed, and if you all want to "re-close" it, feel free, but i wanted to say this first as reason not to: my understanding is that BOTH sqlite AND mysql will be supported going forward. if thats the case, then this bug helps those choosing to continue to use mysql. the consensus seems to be that no one is hurt by these mysql tweaks. i think they should be implemented right now. the only thing i don't know, but i bet you all do know, is if you can or need to not apply them to sparc hardware, or similar. but other than that small caveat, i see no reason not to implement this. and going forward, some kind of "mysql" optimizer plugin would really be sweet.
I'm ok with adding a simple select box to the Performance page with maybe 2 options for MySQL configs: Default 1+ GB memory If you can define exactly what the settings should be for the 1 GB (or whatever other number you think is the right one here), I will do this.
on that same page, an option/checkbox could be there, that is only automatically filled in if a plugin "Auto Tuner" is ever made/run. (a plugin that benchmarks your hardware to get optimum sql settings) https://launchpad.net/mysql-tuning-primer some other related threads: http://forums.slimdevices.com/showthread.php?p=573700 http://forums.slimdevices.com/showthread.php?t=81137
This is done.
big thx to you and moonbase! it has an effect on sqlite installs too, right?