It takes exactly the same time as before.
Which seems to be okay, as you claimed, that in the last version it took hours and never completed!
So that is back to normal then...! And is the main bug-fix to the v.31/v.32 versions! So that seems to be solved then?!
Rescanning of a folder based media lib involves scanning the hard disk folder and all sub-folders for all contained tracks. The time it takes is mainly limited by the speed of the hard disk.
In my tests here on my machines I achieve around 10.000 tracks in 45 sec.!
(that is e.g. on a standard laptop Win7-64bit, i5-CPU, 8GB RAM with a 7.200 rpm SATA III hard disc)
On the same system with an SSD drive I achieve around 10.000 within 30 sec.!
So when you say, that on your machine a rescan takes 45 min. for just 50.000 tracks (and if I understand you correctly, that it was always taking that time also in previous versions),
then I can only assume, that your I/O sub-system is the real limiting factor and your hard disk might be quite slow?
What I/O sub-system are you using, what type of hard drive, how is it connected etc.?
And what machine and OS are we talking about?
Further in MY tests I do can perform a search on a remote media lib which is currently being rescanned.
Of course that search is a bit slower (as the MLS and the I/O system on the server is utilized), but is does return quite timely, i.e. I experience a delay of around 1 or 2 sec. maybe!
And it does return valid tracks, which are matching the filter (which was the other bug you posted - so at least here in my tests this bug is also solved).
So it is a bit hard to say, why in your case resp. on your hardware the search would be so slow if the MLS is rescanning.
Maybe your I/O system is so much utilized, that it blocks everything?
At least I can not reproduce the issue on my systems.
When you open the Windows Performance Monitor what does it show for I/O and CPU?