UI Track Count, Non UI Related Performance Issue

Should the number in the lower right …
40%20AM

… equal the number of tracks in the upper left?

These are the only tracks loaded. All unclustered, nothing on the Right.
As I delete tracks from the Left, that number in the lower right stays what it started as.


I know. “Picard”, “Lots of Files” :slight_smile: and “It’s not for” … but sometimes there may be a greater amount of tracks loaded that are all part of a compilation … and they’ll need to be whacked at some point when one is done with whatever they’re doing.

So, deleting a lot of tracks from either list … isn’t exactly fast. Most of the time is faster to quit / force quit and relaunch. Might there be a better way of purging these items from memory instead of sending Picard (on OSX) into Spinning Disk of No Response Hell?

Most of the time it comes out of it in 20-30 seconds at the most, but sometimes … it seems like “never”.

Though it does appear that closing the exposure triangle makes a difference, or even clustering when able and removing them a cluster at a time…

i would drag or select 1000 songs MAX to picard then when thay are loaded add some more

Indeed, the counters seem no to get updated when items are removed, only when items get added. I files a ticket:

Yes, we have a ticket about reporting exactly this. Seems like something is really slowing things down when the items are visible. But I have not yet investigated this deeper.

2 Likes

More voodoo logic, but, what if the cluster title is selected, collapse that cluster, then pitch it from the display? Since the cluster would obviously being going away. That would take eliminate some of the instances of delay.

Collapsing a cluster with only some selected items, on the other hand, would still need some attention…