To give NeomaD a point, on Windows you could check for each drive what type it is, and Windows could tell you its a removable drive. But then, that’s only Windows, and to finally take that point away again, what about CDs you had in the drive only once etc. 😉
A general idea for speeding up such rescans would be to not remove songs from the database, but flag them, in a new boolean field (“filexists” or something), as N/A. Any functions processing the database should then ignore entries where this is set (a simple additional parameter to the queries). This way, on a rescan it would only have to remove the N/A flag instead of parsing the same file again.
That combined with a “lastseen” database column could allow to only remove entries finally from the DB after time X, e.g. when the songs haven’t been seen for a week or two, making accidental short outages of an external or network drive less time-consuming on the rescan.
As Ron said: if you feel this is important, feel free to provide a patch for that 😀
PS: My song database is not even half that big, for more files. Are SQLite2 databases three times as big?
PPS: One occasion where its normal that such a large number of files “disappear”: if you retag your files and change your directory and/or filename structure, for example.
For a server application, “asking the user” about decisions is always bad (unless its when the user aka admin actively is configuring the server), since who knows if he’ll access the user interface the next day or three months from now? I can go for weeks without looking at Firefly, and if it wouldn’t find new files I moved to its network drive, I would think something is wrong actually, while it just sits there and waits for me to give it an answer what it should do about those missing files…
Hmmm. One way to combine the last situation with my example above: when > 50% of all files are not found, 1. set the N/A flag, 2. set a global flag that would, if you access the web interface, show you the “problem” and allow you to remove those entries with one click (contrary to the “after time X” described above).