Comment 5 for bug 500535

This issue still exists in 1.04, so I've written a patch that actually fixes it, whereas the last few were debatably effective and efficient. The patch uses a hashmap(path:{files}) to speed things up and actually works on top of it.

The definition of the issue(and the way I saw things) was that if a m3u file is in a directory and pointing to some files, then those files should not be duplicated, which is what the patch does. I've tested it on m3u files outside the directory and in differing situations with supported file-types; with no problems.

I'm not sure about the performance of the previous solutions, but I did a speed check on straight 1.04 and after the patch and it sped things up in every situation by a factor of about 1.1. As below:

Time test to drag and drop a folder into dap

Method:
20 samples of the execution time to perform getTracks() before and after the changes in the patch were applied to ../src/media/__init__.py. Basically I was just dragging and dropping my entire music folder into the playlist. Done in Ubuntu 10.04 on a asus-u80v.

Input Data:
2,091 files (mostly mp3 or m4a, but does include 27 m3u files)
71 base-level folders and 571 sub folders
totalling 12.2 GB in size

Testing Before changes
>
> sample
 [1] 5.91 5.92 5.91 5.95 5.92 5.92 5.94 5.92 5.93 5.93 5.93 5.97 5.95 5.94 5.95
[16] 5.94 5.93 5.94 5.95 6.03
> mean(sample)
[1] 5.939
> var(sample)
[1] 0.0006936842
> sd(sample)
[1] 0.02633789

Testing After changes
>
> sample
 [1] 5.34 5.35 5.34 5.33 5.33 5.33 5.33 5.33 5.42 5.33 5.33 5.34 5.37 5.37 5.42
[16] 5.40 5.42 5.53 5.41 5.42
> mean(sample)
[1] 5.372
> var(sample)
[1] 0.002753684
> sd(sample)
[1] 0.05247556
>

It shows a decrease in mean processing time to about 9/10 of the 1.04 processing time for getTracks(). This is performing the same functions as before and removing same dir duplicates.