MM3A7: Breaking up compilations while updating genre tags

[fvdpol]

After updating the genre for all tracks in a "Various Artists" album I discovered that MM3A7 decided to make every song's Album Artist equal to the track's Artist.... causing the the Compilation to be broken apart.

I suppose this has been going on for a while since I have this feeling I keep on re-tagging albums as compilations

Thanks,
Frank.

[jiri]

I can't reproduce it. Does it always happen? Any specific steps needed?

Jiri

[fvdpol]

Hi Jiri,

thanks for your reply. I can reproduce this quite easily; perhaps it's just me doing something stupid.

This is what I did
- select the album's tracks using 'Find more from the same album'
- the album node is selected and all the tracks are shown (eg. "Destination Goa 9 (Various)")
- if I now select all album's tracks (control-A) and change eg. the Genre or Date tag these fields will be updated and the album broken into pieces (each track gets an own entry in the album hiearchy, eg. "Destination Goa 9(Mino)", "Destination Goa 9(Mystica)" etc.)


Further investigation revealed that my initial analysis was not correct; sorry for sending you in the wrong direction. The symptom is still the same though.

After selecting the track (and before changing the properties) I observed:

a/ Album Artist (from Album properties) is set to Various
b/ Album Artist (from each of the track's properties) is equal to the track's Artist (ie. NOT Various).

Looking into the sqlite db I see:

in table Albums:
ID: 45513
Album: Destination Goa 9
Artist: Various
Year:
Tracks: 14

in table Songs where IdAblum=45513:
all the tracks where Artist and AlbumArtist have the same value


After changing the Genre tag for all tracks in the album (causing the breaking of the compilation) the Albums table in sqllite shows an entry for every track (ie. consistent with the breaking of the album in MM3); the Artist field set is set to the song's artist instead of Various.



Correcting the erratic situation:

1/ Maintain Library->Create Multi-Artist Albums
2/ select the 'Destination Goa 9 (Various)' album which is one of the proposed albums
3/ let it run et voila, the tracks are now back together in the colletion


Inspection of the Album properties: Artist = Various
Inspection of the individual tracks: Album Artist = Artist

Perhaps this the root cause of my problems?


Changing the Year property of all tracks (on the freshly recombined collection) causes it to break up again.

Going to the 'Files to Edit->Multiple Artist Albums' node shows the 'Destination Goa 9' album. Selecting the 'Change Album Artist'/Control-J menu option on the menu on the album node lets me change it to 'Various'.
The compilation is now re-combined; inspection of the individual tracks still shows an Album Artist equal to the Artist.


After updating tracks (and breaking the compilation) I launched MM2; the broken album was shown correctly (ie. broken) here (library was synchronised on startup monitoring the file system where the music is stored). I ran the Maintain Library/Create Multi-Artist abum, and hey: different result: now the track's Album Artists was set correctly to Various.

Hope this bug report is more usefull than my inital posting

regards,
Frank.



Note that I set MM to monitor any changes on the file system where my library resides, perhaps this makes a diffence?

[cmx]

This differential behavior between MM2 and MM3 is also occuring here.

Upon scan in MM3a7, SOME but not ALL compilation albums in MM3a7, that currently show "Various" as the album artist in MM2, now show album artist the same as artist....upon looking at the individual tracks and tags the majority seem to have been changed to the "album artist=artist" style.

SOME- still display as a single entry in the Tree Album Node with (Various)...this is the preferred way

SOME- display each individual song as an album AND the single (Various) entry

SOME- display only the individual songs as a seperate album no "(Various)"...this seems to be the way that people DO NOT LIKE.

SOME- (and this is the most curious) display the single album entry with the (various) connotation on it...BUT when it is selected then the Album node actually begins expanding, until it displays each song as an individual album....

I am unable to determine any reasons for this behavior.

There are also several other possibly associated issues with compilation type album...concerning ACC tagging and especially the album display functionality.

I have not attempted to use the "Create Multi-user Albums" because the documentation is a bit lacking and I'm concerned about creating more issues. The "files to edit "multiple Artist"" node does not seem accurate or complete as far as I can tell...so I'm not really confident in using this command.

This is a very big concern here as I have many, many compilations- and the organization and display is not at all consistent at this point....I am also unsure of exactly HOW to expect MM3 to behave concerning this functionality. I've posted in many previous discussions on this issue and requests for basic instruction/explanation in function.

Thanks for any help with this very important/critical aspect of MM.

All in all it is very confusing. If there is anything I can to to help work this out please let me know. Any further positive discussion very much appreciated.

[jiri]

I still can't reproduce it. Could you possibly try to find a way how to reproduce it with a newly empty DB (e.g. scan just that one album) and send me some screenshots of what you are doing? You could include also that small DB.

Thanks,
Jiri

[Guest]

Hi Jiri,
thanks for paying attention to this issue. I found an easy way to reproduce it:

1. I started out with a fresh, empty MM3A7 database by creating a new user account for testing
2. Launching MediaMonkey from that account shows (as expected) the empty database
3. Copy a few files into c:\MMTest\
   These test Files can be found at http://fvdpol.org/mm3/MMTest.zip
4. Setup MM file monitoring to c:\MMTest\ ("Monitor Selected Folders for Changes")
5. Populate the database using 'Add/Rescan tracks to library'
6. Library now contains the two albums from the MMTest directory:
   
7. select Maintain Library, create multi-artist albums:
   
8. The Destination Goa collection has now been properly grouped.
   Copy of the Sqlite db from this point in time can be found at http://fvdpol.org/mm3/MM.DB
   
   Inspecting the Album properties shows album artists = 'Various'.
   Inspecting the Track properties shows Album Artists == Artist.
   But no alarm bells ringing since MM3 still correctly groups the compilation's tracks:
   
9. Select all the tracks from the Destination Goa album; open the track properites dialog ('Edit Properties for Multiple Tracks'), and change the Date field to eg. 1800.
   Click OK and see what happens..... the Collection is broken into pieces:
   

I hope this step by step description will help to reproduce the erratic behaviour.

Regards,
Frank.

[fvdpol]

just tested the behaviour without enabling the monitoring on the file system, and found that it still breaks the compilation when updating track properties.

Frank

[pdemaio]

Just FYI, I'm seeing something similar when editing other metadata such as adding album art. (this is using 3.0.0.1057 with a 17589 song library which is nearly all lossless WMV. ).

[pdemaio]

By the way is this tag stored anyone in the actual music file or is this just in the MM db?
If it's just in the MM db and not the album I won't worry much about it.

[jiri]

Ok, thanks for the detailed description, the create multi-artist albums function really had some problems, it will be fixed in the next release.

Jiri

[fvdpol]

Ok, thanks for the detailed description, the create multi-artist albums function really had some problems, it will be fixed in the next release.

Jiri

Thanks a lot; glad to see my analysis was useful.

Since you mentioned that the problem was related to the create multi-artist function I'd like to point out that I've also been able to reproduce the issue by changing the album's artist (as album property).

Frank.

[fvdpol]

Did a quick spin with the MM3 A8 release (build 1066), and this issue seem still to exist in the new alpha.
Was it supposed to be resolved or is it still on the todo list?

Regards,
Frank.

[jiri]

Yes, this is supposed to be fixed and it works fine for me at this moment. Do you have any steps that cause the problem? Have you tried with an empty DB, just to be sure?

Jiri