[black_eagle]

@dm21912   Having taken on board @DaveBlake 's comments regarding the albumreleasetype, I have re-visited this area and made some changes.
So, if you add 'boxset' (no quotes) to that tag with Picard, Kodi will automatically turn it into a boxset.  It will create disc names for any discs that do

First of all, I can't find a reference from @DaveBlake talking about a tag called "albumreleasetype". Can you point me there, please?

There is no tag content "boxset" in use at musicbrainz, and also there is no tag "albumreleasetype". You can check what's used where if you try editing any boxset at their website. Musicbrainz uses "MUSICBRAINZ_ALBUMTYPE" (in the field secondary album type under releasegroup) and so-called boxsets are tagged as "Compilation" there. Only in conjunction with the existence of "DISCSUBTITLE" do we, the users, deduct that it is a boxset and evaluating both sets of tags would probably the way to go programatically as well.

A general request just in case: Please do not make up or require new tags. Many users don't even use Picard but use plug-ins for their favorite software, like foobar2000. Kodi needs to work with existing tags and not force the user to create new ones. Thanks!    

What Dave was referring to was a tag name that is internal to Kodi's core code and is derived from "MUSICBRAINZ ALBUM TYPE" which has an MB defined value of "album", "single", "ep", "broadcast", or "other". Those are the only tags MB uses as the primary type of a release. There are also secondary tags, which are "compilation", "soundtrack", "spoken word", "interview", "audiobook", "audio drama", "live", "remix", "dj-mix" and "mixtape/street".

IF you edit that tag to include 'boxset' (and it can be anywhere in the tag, so "album ; boxset ; compilation" is valid, as is "boxset ; album") then Kodi will make that album into a box set, automatically producing disc names if some or all of them aren't present in the tags. If you don't edit that tag, Kodi will apply the rules of "Each disc named, at least three discs and not marked as a compilation" and make box sets of any albums you have that fit that criteria.

To be totally clear, no-one is adding any tags to anything, merely adding a value to an already existing tag (if you use MB & picard).  It is up to the user whether or not they add that value (as it's not set at the MB end). Yes, Kodi may well find some box sets in your music if your tags are up to date, but there is absolutely no requirement to open that node and navigate them in this way and I have made completely sure that adding this functionality to Kodi does not in any way alter or impair the way it already works. Anything I have added builds upon what is already there, without detracting from any current functionality.

Further, if Kodi doesn't automatically identify any box sets in your collection and that value hasn't been added to the tags of any albums, the node won't show in the list and all will look as it looks now.

Besides all that, there is absolutely no guarantee that any of the work I've done will actually make it into Kodi and be available for general use, although I hope that that doesn't prove to be the case.

[HeresJohnny]

Thanks for explaining, that's how I understood it as well. In my book, the term "tag" includes both tag names and tag values. Again, I plead that neither new tag names nor new tag values are created that don't adhere to common use... and by common use I mean those tag names and values pre-defined by musicbrainz in their API / editor. I feel this is a case where Secondory Album Type "boxset" should be added directly at musicbrainz API level and not go over their head.

EDIT: Sorry, I just noted there were more replies than just BlackEagle's so I have to amend:

My counter proposition is to use just the presence of
DISCSUBTITLE = [anything]

for something to be recognized as a boxset for now. That would include all the cases mentioned before, but also some multi-disc releases like "The Wall - Immersion Box set". I think we can all agree that we want to exclude simple multi-disc releases, i.e. The Beatles' Blue Album disc 1 and disc 2.

Also I feel that the music support section is meant to describe ideas whereas technical discussion about database structure and such is best held in the developer section. Not all of us are programmers and as such might not always use correct technical terms.

[DaveBlake]

Well expressing your opinion is fine @HeresJohnny, but that doesn't mean it will be adhered too. As we have already discussed at great length using just DISCSUBTITLE to detect boxed sets is too broad a criteria, so Kodi will be doing more than that.

As for not discussing technical things on this forum, in the beginning of my work on Kodi I tried to use the developer section for such things and got absolutely no response from anyone else. In time I asked for the creation of a section specifically for music library discusision, and that has become a far more vibrant place for both the most basic user support and discussion at a much more technical level. Long may it continue that way!

Kodi was created by enthusast users with varying degrees of technical expertise. It may now have millions of users, some of whom struggle to do more than press play on the remote, but the life blood of the project is still the input from those kinds of orginal technical enthusiasts. I hope to encourage those people to contribute in whatever way they can (from chatting about ideas and testing things all the way to doing what black_eagle is doing), and I will continue to use this subforum to do it because that is the most likely place that the right kind of people will see the conversation. Others may see it too, but there is no harm in that, they might even learn something unexpectedly.

As for terminology, I try to explain if people ask and I ask if I don't understand what others are saying. How does it go - "first seek to understand then to be understood". I may vary in my successfulness, but that is the principle  I try to apply.

[black_eagle]

Thanks for explaining, that's how I understood it as well. In my book, the term "tag" includes both tag names and tag values. Again, I plead that neither new tag names nor new tag values are created that don't adhere to common use... and by common use I mean those tag names and values pre-defined by musicbrainz in their API / editor. I feel this is a case where Secondory Album Type "boxset" should be added directly at musicbrainz API level and not go over their head.

EDIT: Sorry, I just noted there were more replies than just BlackEagle's so I have to amend:

My counter proposition is to use just the presence of
DISCSUBTITLE = [anything]

for something to be recognized as a boxset for now. That would include all the cases mentioned before, but also some multi-disc releases like "The Wall - Immersion Box set". I think we can all agree that we want to exclude simple multi-disc releases, i.e. The Beatles' Blue Album disc 1 and disc 2.

Also I feel that the music support section is meant to describe ideas whereas technical discussion about database structure and such is best held in the developer section. Not all of us are programmers and as such might not always use correct technical terms.

Well, using 'boxset' will never become common use if people don't start using it.  You don't change things or advance them forwards by always staying the same.  Sure, MB provide a rich set of tags for us to use but if those tags don't supply the information that a user requires, then I see absolutely nothing wrong with that user altering or amending a tag or tags to suit their own individual needs.  And if enough people start doing that and complaining at MB that this piece of data is missing for them then perhaps MB will start adding it at their end and then it becomes 'common use'.

Besides, its not a requirement that you use it, its entirely optional.  Finally, it makes absolutely no difference to MB, or to you, if a user chooses (or not) to edit the tags in their files.  If it enhances functionality (which it does) without breaking or changing anything else (it doesn't make ANY difference to any other part of the music library or how it currently works) then I can't see an issue.  Who, exactly, says I can't put different values in my tags to what MB supplies if I want to, especially if by doing so I can improve my user experience when those tags are read ??

[black_eagle]

So, just for @DaveBlake 's eyes at the moment, I have a URL to github [url redacted for now]  Not that I'm particularly difficult to find on there should others so desire but I don't really want to leave the url available for scraping by bots etc, or have anyone purloining my work !!

Dave, the first commit will show massive diffs I'm afraid, as the copy of Kodi I was writing on was from 28/07 so I had to rebase against current master and there appears to have been a lot of code tidying going on in the last month which seems to be included in that commit.  No idea if I can do anything about that.  I also had to add a commit to move from 'pItem->setIconImage' to 'pItem->SetArt' but that was only a small change although I also removed an unused function at the same time (forgot to commit them separately - sorry !!).

Anyway, criticism is most welcome, both good and bad.  I know Kodi's codebase is pretty strict so if I've done anything wrong in that regard, please tell me.

Cheers, BE

[DaveBlake]

@black_eagle well done for getting this far
Some of the large the diff issue seems to be because your editor kindly cleaned-up the trailing while spaces. They shouldn't be there, but it does make seeing the real changes over cosmetic much harder. I'm sure there is a git option to avoid that but darned if I can remember what it is right now!

I won't have chance until tomorrow at best to start looking seriously, but I should be able to do detailed feedback via Github rather than forum. [EDIT: can you create a PR against your own master (not xbmc/master), seems that I can't comment on a branch only a pull request. Then we can bat it back and forth without pinging the entire team!]
I'm not big on code standard nit-picking, so no worries there. In fact I'm far worse, I nit-pick design

[dm21912]

My counter proposition is to use just the presence of
DISCSUBTITLE = [anything]

for something to be recognized as a boxset for now.

unfortunately that would very quickly fall down. Some examples:

[black_eagle]

@black_eagle well done for getting this far
Some of the large the diff issue seems to be because your editor kindly cleaned-up the trailing while spaces. They shouldn't be there, but it does make seeing the real changes over cosmetic much harder. I'm sure there is a git option to avoid that but darned if I can remember what it is right now!

I won't have chance until tomorrow at best to start looking seriously, but I should be able to do detailed feedback via Github rather than forum.
I'm not big on code standard nit-picking, so no worries there. In fact I'm far worse, I nit-pick design

Sorry about that, it's a setting in my IDE that cleans up trailing spaces and tabs (amongst other things) when it saves files.

Pick away !!  I'm always keen to learn new things and improve my skills and that won't happen without people pointing out flaws and where I can improve.  I need to look now at how this JSON stuff works and add support to it for box sets so that addons and remotes can access the same info as the gui.  Hmmm, still lots to do

@dm21912 If you add 'boxset' to the musicbrainz release type tag, then Kodi will automatically create disc names (Disc 1, Disc 2, Disc 3 etc etc) for those albums and then add them to the boxset node, which is easier than adding titles for all the discs.  Either approach will work though.

[DaveBlake]

it's a setting in my IDE that cleans up trailing spaces and tabs (amongst other things) when it saves files.

The whitespace/tab thing is driving me slightly nuts, and you will need to fix it for a Kodi PR, sorry.
I can hide it in diffs with ?w=1 on the URL, but seem to lose the ability to comment.
Diff without whitespace changes may also help you spot the leftover edits you don't need any more.

Meanwhile if you also raise a PR against your own master (not the xbmc one, or everyone gets hit with every post) then it may be easier for me to comment and us to discuss.

[dm21912]

@black_eagle well done for getting this far
Some of the large the diff issue seems to be because your editor kindly cleaned-up the trailing while spaces. They shouldn't be there, but it does make seeing the real changes over cosmetic much harder. I'm sure there is a git option to avoid that but darned if I can remember what it is right now!

I won't have chance until tomorrow at best to start looking seriously, but I should be able to do detailed feedback via Github rather than forum.
I'm not big on code standard nit-picking, so no worries there. In fact I'm far worse, I nit-pick design

@dm21912 If you add 'boxset' to the musicbrainz release type tag, then Kodi will automatically create disc names (Disc 1, Disc 2, Disc 3 etc etc) for those albums and then add them to the boxset node, which is easier than adding titles for all the discs.  Either approach will work though.  

oh indeed, most definitely.

my post was purely in response to the suggestion that "DISCSUBTITLE = [anything]" would be enough on its own to identify a box set




just thinking out loud (and putting the cart waaaay in front of the horse, i presume that "album / boxset" would be equally as effective as "album;boxset" as you previously wrote (for those who like to keep their tagging consistent - i use " / " as the seperator generally)

[black_eagle]

oh indeed, most definitely.

my post was purely in response to the suggestion that "DISCSUBTITLE = [anything]" would be enough on its own to identify a box set




just thinking out loud (and putting the cart waaaay in front of the horse, i presume that "album / boxset" would be equally as effective as "album;boxset" as you previously wrote (for those who like to keep their tagging consistent - i use " / " as the seperator generally) 

 Ah, that's a good question !! MB & Picard use ";" as their separator whilst Kodi uses " / " unless you override that in advancedsettings.xml. If I edit that tag with picard, it automatically uses ';'



Bit difficult to see that, but basically I right clicked on the tag value, picked 'edit tag' from the pop-up menu, clicked 'add value' in the box that appears and typed in 'boxset'. Picard automatically adds in the separator. I don't know if you can change that. However, it should still work I think if you can.

[DaveBlake]

Separators - what you see in Picard when using it isn't necessarily what is actually in the tag.

Multi-frame tag formats e.g. ID3v2.4 for Vorbis/FLAC can hold each value separately, hence you get a popup menu to add a value etc. Picard then displays the values in a single string with ";" between values but the tag can be read by Taglib as separate values without any splitting using separators.

The separator gets used for single frame formats e.g. ID3v2.3, then the tag is just a single string. However you can also set what actual separator to us in Picard for that under Options>Metadata>tags>"Join Multiple ID3v2.3 tags with".

When it comes to reading that tag Kodi will need to allow for the use of "/", " / " and ";" as a separator, and for even multi-frame formats having all the values in one entry with a separator. Users do odd things when they manually edit, and not all use Picard.

[black_eagle]

I didn't change any of the tag reading, so I presume that it can already handle different separators.  I just added a check to look for 'boxset' in the value(s) returned from that tag inside CTagLoaderTagLib::SetReleaseType by which time all the parsing etc has already been done.  It checks against a single value and against multiple values that have been joined using m_musicItemSeparator.  If it finds it, it then checks to see if the disc subtitle is empty and if so, generates a dummy title which is then processed later.  If the disc title is not empty then we keep it.  In either case, we set the boxset flag with tag.SetBoxset(true) as the presence of 'boxset' in the tag indicates the user wants this album to be processed as a set.  If the tag doesn't have that value it is processed as before.

[dm21912]

Separators - what you see in Picard when using it isn't necessarily what is actually in the tag.

When it comes to reading that tag Kodi will need to allow for the use of "/", " / " and ";" as a separator, and for even multi-frame formats having all the values in one entry with a separator. Users do odd things when they manually edit, and not all use Picard.

ah....

I have picard set to use " / " as the separator as I was under the impression that that is all Kodi recognised when it came to genres



(Note for those wondering, the genre separator is on a separate setting confusingly)

im not gonna retag my entire collection to ";" though

[DaveBlake]

I have picard set to use " / " as the separator as I was under the impression that that is all Kodi recognised when it came to genres

Yes for genre the item separator, and only the item separator applies. It is " / " by default (a solution suggested by ID3 for v2.3 and earlier formats that didn't support multi-frame) but can be set to something else. Although I do have a plan to extend that sometime, afterall ";" does make more sense as a separator.

What I was trying to explain is that the ";" you sometimes see displayed in Picard are not always there.