Displaying all tracks takes much longer with 1.4

[Tim]

Hello,
I noticed that when I choose to display all tracks by choosing by selecting the artist folder without picking a specific artist, it takes much longer to display all my tracks than it did in version 1.3. I have about 11,700 songs in Songs-DB. It whips through the first 5000 or so in about 20 seconds and then slows down dramatically taking over an hour to finish the second half of the tracks.
I use win98SE.
Oh, and I can't find the accessible tracks folder in playlists or anywhere else on Beta 4. Isn't it supposed to be in the playlists folder now?
Thanks,
Tim

[rusty]

Re. the first issue, I'll have to look into this. Has anyone else experienced this type of slowdown for large music collections with 1.4?

Re. the second issue, see http://www.songs-db.com/forum/viewtopic.php?t=412

[Peke]

Yap! me too, but as I see the problem of slowdowns iis resolt of scaning/displaying and sorting at the same time, slowdowns are bigger when collection of files that is needed to display is large ie. >2000 couse every new file that is needed to display first need to be sorted and than displayed. The solve as I see will be something like:
First collect info what files need to be displayed then display them and at the end sort them. Mathematicly looked it will save almost half of time needed for same procedure. Lets see how it looks from App. side:

This is done currently:

When Display all songs is selected do
Add file to list
sort list
add another file to list
sort list
add another file to list
sort list
........
all files are displayed.

This is why slowdowns are happeniing, as of progressive increase of time to sort list.


This is how it soposed to be faster:

When Display all songs is selected do
Add File to list
Add Another file to llist
Add Another file to llist
..........
Untill all the files are added.
Sortlist and display it.

Whith procedure like this there was no progressive slowdowns when there was need for displaying large amounts of files.

See what I mean

[jiri]

Peke is right with the reason for the slowdowns. I have actually already fixed it, but a bit different way - list is still sorted as items are added, but the time dedicated to sorting and to reading DB is better allocated. Now the procedure should work well for all cases and machines. Please try it in the next beta and let me know if there is any problem.

Thanks,
Jiri

[Peke]

Well, have you tried to show all file on library with >20000 files )) I am and it is sad, and I have little files compare to some of my friend that have more than 50000 even 80000 MP3 files, I have a friend that has 120Gb of MP3s.
1.4.519 has increase of speed in showing files but still much slower than 1.3.

[jiri]

Please try the next beta (isn't out yet), the fix I described will be there. I think that this way it will work well even for very large collections. However, if it doesn't, it is possible to add an option for disable sorting during adding tracks to the list - as Peke suggested.

Jiri

[rusty]

Fixed in beta5. Let me know if it solves the problem. thx.