Hi there, I upgraded to 2.54 a few weeks ago after using 2.49 for the past 1.5 years, and I didn't notice this problem right away, but today I did -- and to confirm it I tried recreating it in a virtual machine using the same folder of MP3s and comparing the behavior between v2.49 and v2.54.
Here's what I did to recreate it:
Open a folder of MP3s in Mp3tag (and make sure the folder has at least enough files in it so that you have to scroll down to see them all (in my test my folder had ~100 files in it). Then sort by a column (I sorted DESC by the Modified column because I wanted to have the list sorted by newest to oldest files)... Then scroll down toward the middle or bottom of the list. Select a few files (1 or 5, it doesn't matter) and then perform an action on these files that will cause them to be removed from the list (such as Move To or Delete) [NOTE: i just tested again, and noticed that Remove does not cause this behavior, but Delete or Move does] .... Now here's the rub, in v2.49, the scroll position of the list does not change after deleting or moving the file(s), but in v2.54, the scroll position moves back to the top of the list, causing you to lose your place! Very annoying.
The whole reason I upgraded was to get the new Discogs API (because it stopped working in the last version) but now I'm considering downgrading back to 2.49 because this behavior is such a deal breaker for managing large lists of MP3s. Having to re-scroll back to where you were before is just so time consuming and distracting.
I thank you in advance for taking a look at this bug and fixing it!