When adding tracks, the title, artist & album fields show the last track/artist/album name and not the sign, in case of multiple entries
I don't understand.
I just selected several files from several albums and the tag panel behaved like it used to.
- Start by just opening mp3tag without adding any file (blank fields)
- Go to a folder with several tracks (preferably with different artists, albums, titles)
- Press right click and add the folder to mp3tag
- The fields are showing like there is only one artist, one album & one title - the last ones in the folder
- The fields are correctly populated but the tracks/artist/titles seem the same as the last one
- If you run through the tracks and then and only then you "select all" everything is normal - so the bug only appears during the first selection/adding to mp3tag
PS This bug leads to another: If you change the artist/album name and save before going through the tracks (with up/down arrow or the mouse) to return things to normal, all the tracks inherit the same title (of the last title in folder) and that's an even more serious bug
- mp3tag opens blank as expected
- All files display in the list pane with correct tags, none are selected and the tag panel is blank, as it should be.
- Populated where for you? With no tracks still selected, the tag panel remains blank.
- As I select individual tracks, all of the tag elements in the panel change to match correctly each file. Select All further shows all tags in the panel that are 100% match, the rest show the option to ‘<keep’> by default. Again, as expected.
I can’t replicate what you have described, and have tried the same process with several different folders.
- the folder I'm going to add, as seen in explorer
- adding the folder to mp3tag
what do you see? although everything is selected the title is the same (the last track in the folder)
- going down with the arrow
the track 02. has now the correct title, different than before where the title was the last track's title
- select all
now the titles are marked "keep" because they are different (which is the right thing)
In this particular example I use a single artist's name and a single album. If I used n folder with different artists or/and different album names things would be the same: one title (last title in folder), one artist (artist of the last track in folder) and one album (last album in folder). So far so good. If I choose to modify something i.e. in artist's name and save before going up/down through the titles all track titles are stored as the same one (the last tile in folder)
Let’s see if anyone else can replicate. What you get in step 2, I don’t.
mp3tag 3.11 stable re-installed (the same would happen with 3.11a)
and now repeating the steps
- the same folder
- adding the folder
as you can see the tracks are different (marked as keep)
Just look at the two different images with 3.11b (posted before) and now with 3.11
Remark: the versions are showing in the posted images, so there is no mistake
There is no point in forwarding to the other steps I described, since now everything is in order
I’m at 3.11b without any issues
Here no issue too.
But maybe we should also consider the OS version as responsible for different behaviors.
Here: Windows 10 Pro, 64 Bit, Version 21H1 (Build 19043.1288)
My version: Windows 10 home, 64 bit, OS built 19043.1288
It's a very long shot but I'm trying at this very moment installing an optional WIN10 update. I'll report back.
My updated built: 19043.1320
Nothing ... the same results. When using 3.11b and add a folder (via explorer right mouse button click) I have a tag field showing like all the tracks have the same title, the last track title of the folder. In fact - as I described in my posts - that's not true. All tracks are loaded correctly but only the last one is showing like there is one title. If I move through the tracks I can see all title tracks correctly and if then "select all", everything goes back to normal.
In the end I re-installed 3.11 and I have no problem, so I'm skipping this release.
Can you try this internal build (it's still v3.11b but the file version is 188.8.131.52):
Everything is fine with this release. Problem solved! There was something wrong after all.
Excellent! Thanks for reporting this issue — it was due to a workaround for a recent crash, which in turn resulted in a timing issue (which you were able to observe).
Fixed in Mp3tag v3.11c.