High CPU usage when using "Find Track" window

[franksiegers]

Hi Bernd,

When I use "find track" and drag a search result to a playlist, PFOA CPU usage goes to 60% on all 4 cores and the program becomes unresponsive for several minutes. I had only selected 5 libraries with a total number of around 150 tracks.

Also, sometimes the first result of a second search is not properly updated and shows the search result from the first search.

On a side note, not sure if this is related: In earlier versions the directory explorer worked instantly. A few versions ago, this suddenly got a bit sluggish as well.

[radio42]

A few questions - pls try to answer them all:
What exact version and license are you using?
What columns do you show in your Find Window and are they maybe also sorted?
What are your settings regarding 'Force TAG reading' (in the general settings, as well as in the Find Window options).
Where are your media lib tracks located (local disk or network drive)?
And what media libs are they (playlist, folder or remote libs)?
And is the CPU usage high during the search or only when dragging the search result to a playlist?

When I do a search here as a test, the result is almost instant. So it must be some specific setting or environment dependency what is causing it in your setup.

[franksiegers]

What exact version and license are you using?
v4.2.2.0 64-bit PFOA Professional Edition on Windows 7 64-bit

What columns do you show in your Find Window and are they maybe also sorted?
Track and duration. No sorting that I'm aware of.

What are your settings regarding 'Force TAG reading' (in the general settings, as well as in the Find Window options).
General settings:

Find Window options:

Where are your media lib tracks located (local disk or network drive)?
On a Synology NAS with a mapped drive letter

And what media libs are they (playlist, folder or remote libs)?
Those are folder based libs

And is the CPU usage high during the search or only when dragging the search result to a playlist?
I have not been able to reproduce it today, but I have made a short mp4 of weird search behaviour where old results are mixed in with new. It's 330 MB so I cannot attach it here. Can I send it to you by DM?

[radio42]

Can you disable both 'Force TAG reading...' options in the general settings and the Find window and see, what that changes - as both options are not the default and will definitly force the TAG reading for ALL entries before being displayed - which might simply be slow on a slowly connected NAS device.
The mixing of the results might simply because of the async. operations and the slow TAG reading. I.e. while the initial search continues, you cancelled it and fired a new one...

[franksiegers]

Thanks Bernd, disabling both options made PFOA a lot more responsive, including the directory explorer!

[franksiegers]

I've just now started working with the Trackboard. The trackboard shows Music as Type for each track, even though I've set Bed, Sweeper etcetera. WhenI open the Tag, the Type is updated in the trackboard (no need to save anything). Is this perhaps due to disabling Force Tag Reading?

This is too bad, because now when I add a track from trackboard to playlist, it doesn't get properly formatted based on the Media Type Color rules.

[radio42]

I can unfortunately not reproduce that. Here it displays all just fine!

Could it be, that you have changed the menu type ‚only‘ within a playlist, but have not explicitly saved that meta data to the audio TAG data? But then dragged the audio file from the (windows) explorer to the Track Board?
In that case, the entry type would only exists in the playlist, ie. when you drag the track from that playlist the media type would be shown.
But when you dead the file from the explorer it accesses the physical file in which the media type is not stored and that defaults to ‘Music’.