MLS Startup

[hdradio]

Thinking more about this I find that there is a very serious problem.
Suppose the scenario that some bad guy wants to break someones else's PF System it's very easy:
Create an mp3 file adding this text "</pf:comment>" to comment tag and send it to any PF users to play.

Bernd think of that !

Comment by MODERATOR:
WHAT THE AUTHOR OF THIS POST TRYS TO CLAIM HERE IS INCORRECT.
There is no way in breaking ProppFrexx in such way. You can add any tag data you want. There will be no issues or problems arise by this!

[hdradio]

Ok Bernd I stop here.
Will try v3.0.14.0

[hdradio]

I am really sorry for the confusion and MY misunderstanding for the previous posts.

Now about the real issue. Delay of MLS scanning.
I updated v3.0.14.0 and I see no improvement in MLS rescan performance. It takes exactly the same time as before.
It takes 45 minutes for my 50000 tracks library with both old and new version.
Again during MLS scanning the find dialog and Find expression builder does not return any tracks and searching forever (until I manually close or abort it). (in fact it returns only an existing track with title "...").
When MLS scan is complete the results are instant !

[hdradio]

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?!

Yes now it's the same like before but not better.

When you open the Windows Performance Monitor what does it show for I/O and CPU?

If I run it again I 'll take a screenshot to show you. Do you suggest any benchmark tool to try ?

[radio42]

I am about to post a new version today!
This should fix the long rescanning time - which is basically due to recalculating UNC paths...but that is an internal issue introduced by the bug-fix to your previous issue, that during a rescan the Find and Scripts result in incorrect tracks.
The other error you posted is basically because the rescanning resp. the search operation is still ongoing and running while you close PF and as such is absolutly non critical - but as already posted: this should also not happen and will also be fixed with the new version!

I further do not know, what notepad++ resp. the XML Tool plugin is trying to validate or finds incorrect with the XML file - as it is absolutely correct! There have never been any issues with the XML files and ProppFrexx reads them correctly! As such I can only disagree with you, that XML databases cause problems!

[radio42]

The Windows Performance tool will do its job quite good.

That it is not better seems to be depending on your machine or I/O already reaching its limit.
What about your machine data...any info available to my questions above...?

Also see here: That user had the exact same issue like you with the MLS and the Search, he says it is solved:
viewtopic.php?f=9&t=1116&view=unread#p4529

[radio42]

I just made another test with a slow external hard drive, an USB 2.0 drive with a 5.600rpm disk; same laptop as above.
A rescan of a folder with 60.000 tracks took 30 minutes.
(Note, that this does not include any TAG reading, as this is assumed to have happened with previous resp. initial rescan)

A parallel search was still possible, but took about 20 sec. to fully return (122 tracks from the 60.000 have been selected).

Do you have the ability to test the performance on a faster PC with a fast I/O sub-system?

[hdradio]

My pc:
AMD Athlon II X4 640 (quad core) 3.00GHz
Memory 4GB
Data disk: WD RED 3TB SATA III
https://www.dropbox.com/s/ajof6fk9ofrwr ... _18_40.jpg
This screenshot is without any scanning in background.

This is the fastest pc I have.
Also note that initial scan (tag reading) takes also 45 minutes.

[radio42]

Have you may be set the Force TAG reading option? So that the rescan would also force a total TAG reading of all tracks?

[hdradio]

http://pbrd.co/1iWP1UM