not entirely correct.  cover art should be on-the-fly at all times, thumbnails
for browse_artwork are not (too many at once to handle live). Plus, the browse
artwork thumbnails is designed as a post-process (to allow variable filenaming),
so is not currently intended to be part of bmf, so this is an enhancement.

BMF is commonly billed as a means of library cataloging without requiring a 
rescan, so whether or not it was intended to pick up artwork, I'll stick to 
calling it a bug if it does less than a full rescan would.

What are the benefits of doing cover art on-the-fly (other than maybe relieving 
BMF from artwork duties)?  If the artwork path is in the db, wouldn't it be 
faster to use that data to render the web page rather than searching the file 
system for artwork?

if artwork is in the db, that's what is used.  it not found in db, it may look
for it in tags or file system. That's what some covers sometimes show in 'now
playing' or browse album, but not in browse artwork.

Not going to make it for 6.2.

*** Bug 2931 has been marked as a duplicate of this bug. ***

This should no longer be an issue as of current 6.5 builds. Artwork is grabbed and rendered on the fly, no longer requiring a post-scan process. Please reopen if there are issue.

this feature was reverted due to problems, so reopening for future review.

*** This bug has been marked as a duplicate of 4631 ***