[F] Save tag in different ways

Mp3tag Versions 2.66 ... 2.70 Win 7 32bit

The 'Save tag' functionality is implemented twice (or can just be triggert
in different ways) with different outcome. A very minor problem.

Have a set of test records shown in the List View and the Tag Panel open
Mark some records for change

Line 2 normal Mouse Klick in it

Line 4 CTRL Mouse Klick in it
Line 6 SHIFT Mouse Klick in it

Line 8 CTRL Mouse Klick in it
Line 10 CTRL + SHIFT Mouse Klick in it

Line 12 CTRL Mouse Klick in it

Line 14 CTRL Mouse Klick in it

Mouse Klick in the Tag Panel field ALBUM (or any other) and change the text
Depress CTRL + S to trigger 'Tag save'

Repeat the line marking
Change the text in Album different, but NOT depress CTRL + S
Use CTRL + TAB to change focus to the List View and

depress any cursor movement key to trigger 'Tag save'
Mouse klick somewhere in the List View will trigger 'Tag save' as well

Line 2, 4, 5 and 6 do not update

Helmut

Mp3tag Versions 2.66 ... 2.70 Win 7 32bit

Since my description did not trigger any response, it must
be missing an important point about the problem. Let me try again.

The user forced 'Tag save' (CTRL+S) updates all selected tracks (records)

The automatic 'Tag save' (selection changed, WM_NOTIFY) does NOT update all selected

Helmut

Could you check your settings in
Tools>Options>Tags:Save Tags when navigating

If you do not tick this option then you have to press Ctrl-S or the toolbar button.
Yet, even when I had it ticked, Ctrl-Tab first moved to the filter window, then another Ctrl-Tab moved to the files list and only when I use a cursor button (to be sure that I do not hit a file in the current selection), all selected files get the modification...

In my configuration in "Tools/Options/Tags" the item "Save tags when using arrow keys/singe mouse click" is set to "on".
I followed your steps, but cannot repeat your result.
In my installed Mp3tag v2.70 on Win XP, all selected tracks have been changed to the new value at once, ... and the popup message box told me "Saved tag in 10 of 10 files."

DD.20150609.1313.CEST

I did another test with files within one folder only ...
and can confirm the misbehaviour now, ...
for example there were 6 from 9 files selected randomly in three steps as single file or group of files, ...
then prepared the new value into the ALBUM edit dialog within Tag-Panel, ...
then clicked into the listview ...
only 2 files have been updated.

DD.20150610.1800.CEST

Thank you both for taking a look on it.

Mp3tag Versions 2.58 + 2.70 Win XP 32bit
same behaviour on a different PC

Yes, the option is set to on, it has the expected working.

BTW. the CTRL+TAB function is a windows internal function to jump from active
window to active window within the client area, so it stops at the Filter only while open.

I did activate the 'message pop-up after save' option and it is telling me 5 out of 5 are saved. Expected is that 9 out of 9 are saved.
Line 2, 4, 5 and 6 in the ListView have NOT changed.

Let me point out:
CTRL+S works correctly independent of the place (FOCUS) from where it is depressed.

For the automatic update it is related to, that more then one block of lines are selected. In that case, the update includes ONLY the LAST block and afterwards selected SINGLE lines.

Helmut

You are right. I also observed this behaviour if you select the files from top to bottom.
The behaviour cannot be observed (that is: all files get changed) if you have selected the files from bottom to top in the list ... weird.

Oouch, as a Top Down worker, i would have not found that variation.

So it is now on Florian to place it in the 'as Specified List' or on
the list 'some time later to fix'.

Helmut

Thanks for the detailed explanations of all involved in describing this issue.

I've fixed it with the latest Development Build (v2.70a) and it would be great if you could give it a spin.

Kind regards
Florian

Thank you very much Florian, perfect.

In 2.70a the automatic update with strange multiple selections does now the same as the manual CTRL+S update.

No new problem seen while short testing with 3500 records (50 GByte data) in the table.

Helmut

Glad that it works now as intended. Many thanks for testing!

Kind regards
Florian

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.