Find track - Can't move back and forth

[hdradio]

I 've added a "year" and "rating" column on my Find Track window.
Also the settings "Force TAG reading for missing..." is disabled.
I search for an artist and this list of his songs appear.
But I need to find the latest songs and click the Year column.
Now I can not scroll the list and go to the bottom. The index always moves to the first item.
I have to wait for the tag reading to complete and if the list is long it takes some time.
Why this is happening as I have set to NOT force tag reading ?
And why tag reading if performed if I am using MLS ?
Isn't MLS supposed to handle all the tag reading ?

[hdradio]

Ok. it's not bug.

The "Force TAG reading for missing..." option means do NOT read TAGs during the find and search operation.

I 've enabled "Force TAG reading for missing..." and the result is the same.
Is there something wrong to my MLS settings ?

2014-12-18_111209.png (43.72 KiB) Viewed 5825 times

[hdradio]

Yes I can move by keyboard but not with mouse or scrollbar.
This is a problem for long lists because it takes too long to find a track especially if I am in a hurry in a live show.
But currently it seems I have no other option.

Also I don't understand why the Node tag reader is working if MLS is doing it's job.

[radio42]

That might happen BECAUSE you disabled the "Force TAG reading for missing..." option!
The "Force TAG reading for missing..." option means do NOT read TAGs during the find and search operation.

However TAGs are ALWAYS read in at least when a row becomes visible - see your general settings, section 'Meta Data/WaveForm'.
And this means, when you scroll
- a row becomes visible
- TAGs are being read in
- the 'year' value might change
- causing the row to be located somewhere else (as you sorted by that column)!

So the described behavior is exactly what might be expected.
No bug!

I do not know your MLS settings...
But yes, the MLS can handle the TAG reading, if enabled and transmitted to the client.

[radio42]

No. I guess all is normal !

Please try to scroll up/down by keyboard, e.g. using the "Page Up/Down" keys...
I guess in this case you can scroll up/down as you would expect this.

I believe what you experience is again a behavior of the UI lib I am using, which 'might be a bit odd', but is according to the UI lib vendor by design.
When you scroll within a list (and in the background you update some rows AND sorting on any column is enabled - no matter if that update really changes the sorting or not) the currectly focused row is always brought back into view.
This mean:
- when you scroll by mouse or using the scrollbar ... the old focused row is brought back into view
- when you scroll by keyboard you already changed the focused row accordingly and thus you do not experience the issue

IO have already filed a ticket to the UI lib vendor a year ago, but so far they did offer any way to change this behavior.

May be this is what you experience...

[radio42]

Maybe one additional comment:
ProppFrexx (resp. the Find window, the Playlist window etc.) always (re)read the TAG data (when the track becomes visible and the related general setting is enabled, which is the case by default).
This because the TAG data coming from a media lib might be old (no matter if a local or remote media lib is used).
E.g. a playlist based media lib might keep the meta data; but might have read them in months ago.
Same for folder based media libs, they might be rescanned a couple of days or hours ago - but the TAG data might have changed in between.

If you for example disable the general "Read TAG when Track becomes visible" option, no TAG data would be read in while scrolling and thus in case the list is sorted it wouldn't jump back to the currently focused row!
But if that option is disabled, you would always see the TAG data as is coming from the media libs; i.e. if that TAG data is out-dated you will not get the most recent TAG data displayed automatically.

I might even add more options, like "Only read TAG when Track becomes visible AND no sorting is enabled" - but I am afraid, that this would even add more confusion.
Or I might add an extra option for only the Find window: "No TAG reading if sorted"...?