I just erased my library contents (included deleted items), and re-imported everything. About 51,000 tracks (some without cover art, all Audio, all JPEG, mostly 800x800 px). Very spiffy import, and completely clean data base.
Then I built the thumbnails database explicitly (from Tree & View options pane). At first, the progress was pretty fast (probably ~20 per second), and I let it run overnight. When I checked the progress this morning (about 10 hrs later), it was still at around 32,000 files and running at about 2 seconds per thumbnail, pegging a full CPU core (with a significant amount of time spent in the kernel). Quite puzzling. I canceled the thumbnail build, and restarted it (with 14000 to go). Similar behavior: very fast at first, mostly I/O bound. Less than 1/2 core used (10% of my i5). I'm am now at 5,000 out of 14,000, and the rate has dropped to about 5 per second, and the CPU is now at about 0.8 cores (20% of my i5). The memory footprint of MC remains small throughout (170 MB).
So there is something rather strange going on which makes the thumbnail build go more slowly within a single pass. Doing it in chunks behaves much better. Not a big issue, since this is not something done very often... But unexplained behavior is always worth taking a look at.
Note that I have no performance issue at all in normal use. MC is very fast except for this one thing, which is why it's puzzling.
Setup: i5-2405S (4 core single-threaded), 16 GB memory. MC library (database) on SSD, music tracks on HDD, all SATA-3. Windows 7 Pro, fully up to date; MC 20.0.49
Final side note: thanks for introducing Image Height/Width, I can now easily go through all my library and figure out which CD covers I need to scan... Online CD art is often not up to my standards :-)
Author
Topic: Build thumbnails runs slower and slower (Read 1956 times)