@
black_eagle quite a few things I want to discuss or comment oh here, could be a big post do try to keep track.
1) Add/remove boxed set facility
The db lockout you experienced brings up another point about how db access is done. The team is trying hard to improve the design to avoid UI (especially player) lock ups. It was easy in old xbox days, that automatically did the UI on a separate thread, so there are a lot of fundamental flaws in this area of design that are results of that history. Part of this means that db access must be done on a separate thread to the UI, so if for some reason (network issues, db locked by something else etc.) db access is delayed the user can still move the mouse and cancel what they started. There are still places that lock like that, but you will get jumped on if you accidentally add a new one. Context menu processing that includes a SQL update needs to be done on some other thread from the GUI. Such an update is normally almost instant so you don't think about it, but it has lockout potential.
I am still not keen on that add/remove boxed set feature (even done off the UI thread). I want ease of use for users, sure, but providing a quick UI route for one kind edit and not all the others (which may be equally vital to some other user) makes for yet more inconsitency rather than less. For example genre tagging can be a mess, and users so wish they could tweek that mis-spelled value rather than have to visit the tagging again, or that album that didn't get flagged as a compilation etc.
I know why looking at the diversity of the way sets could be tagged and how hard it is to untangle which are sets, you are attracted to this. It seems so simple... tidy up the mistakes via the context menu. But think big picture too, more items on the context menu is not an expandable approach to fixing album data - the properties can't have a menu item each. Even rating, the only other property set via GUI, is not a context menu item.
Editing album properties, if Kodi is going to do that, is better via something like the album info dialog - an approach that could be extended for more than just one property and that dialog already has the db reading on a separate thread.
Library updates that rescan an album will lose manual edits made to properties that can be derived from tag data. If the timestamp/size hash changes on any of the music files from an album that has been manually add/remove as a boxed set then that will get reset (unless you take steps to avoid it). The timestamp can be affected on some platforms by clock change, and some other media played edit the files/folder too, so library update can result in unnecessary and unexpected rescans.
2) Determining what is a boxed set
OK, so what comes out of Picard can be very diverse. Does this mean you want to abandon using tags to determine if something is a boxed set all together? Have "boxed set" as an arbitary custom property that users set via NFO or suitable GUI? You could still pick up DISCSUBTITLE from tagging, but nothing special is done with that other than store it like any other song property.
Or do we go with "is a boxed set" being something determined from tagging and leave it to the user to tag sufficiently to achieve the end results they want. Tagging with Picard may give the user a good start with that, but inevitably they may need to do some manual edits to tidy up the more messy Musicbrainz data entries.
My suggestion of using RELEASETYPE tag to
help determine a boxed set was not because Musicbrainz already have a "boxedset" entry (no they don't), but because it was a custom tag (not the ID3 standard) already added by Picard and used by Kodi. It is an easy place for a
user to edit this tag and add "boxedset" and then have Kodi use it intelligently. It is an easy way when the DISCSUBTITLE values are mixed, etc. for a user to set one tag and have Kodi take it as a boxed set regardless of other algorthims.
What I would like to avoid is yet another album property that is lost half-way between one approach and the other. We have a few of those already and they can cause issues later. For example year - set for both songs and album initially from the tag values, but album year can be edited via scraping album.nfo or JSON API and then differ from song year. What gets used for filtering? An "edit year" context menu would make matter much worse and end up with more users with inconsistent year data. But I digress.
At the moment my preference for "Boxed set" to be a fact about music files. That is to derive it from tags using a clear methodology but allowing for what Picard produces to be a nearish miss that is easy to edit, and get the user to set those tags according to the result they want.
You can make a case for it being a custom album property instead, but then I might suggest that you implement a generic custom property facility while you are there as well as a property editing UI.
I guess I find editing tags much easier than messing wth nfo files, and data that I may forget to export to save manual edits. Let's not get too bogged down in the imperfections of the Musicbrainz entries. We could even hope that if Kodi had better boxed set handling then some users would go back to MB and fix the more messy entries in their database. Flaws would be more obvious if the data was being used.
More seriously @
black_eagle can you see what I am getting at? I think what is needed is some clear vision if this feature is about organising songs based on music file tagging, or about selecting certain albums.
I will look at improving matching if I ever get once I get a working example that does the basics.
