Kodi Community Forum

(2019-11-16, 12:37)DaveBlake Wrote: [ -> ]@black_eagle has raised a PR https://github.com/xbmc/xbmc/pull/16915 to get this new feature into v19, yay! Test builds are available on the mirrors for those that would like to give it a go. For Win64 that is KodiSetup-20191115-a35dd75e-PR16915 with builds for OSX and Android in approriate folder.

Question. Do you know if there are plans for Kodi 19 to have during test phase a different application id (specifically on android) so it can be installed alongside 18 as currently the test builds upgrade 18.

With the python 3 thing likely to have such wide ranging implications being able to run the test build alongside Leia is gonna be kinda critical.

(I would start testing 19 but the test builds arent on linux yet, and i dont want to upgrade my k18 installs on android for obvious reasons )

(2019-11-20, 20:08)dm21912 Wrote: [ -> ]Question. Do you know if there are plans for Kodi 19 to have during test phase a different application id (specifically on android) so it can be installed alongside 18 as currently the test builds upgrade 18.

I don't know if we run a beta channel on Playstore once v19 is in beta, that is some (unknown) way off anyway. For other platforms it is about running in portable mode, that way you can have many versions of Kodi installed simultaneously. Once in beta no new features are added or major adjustments made, so too late for all but disaster feedback. Testing features as early as possible is what we devs need.

Stick Kodi on a spare device perhaps, different from the one you use normally. This work isn't platform sensitive, so any flavour will do, just as long as it can see your music files.

New test builds will be available for the updated version of this boxset/multi-disc feature very soon.

(2019-11-20, 20:08)dm21912 Wrote: [ -> ](I would start testing 19 but the test builds arent on linux yet

If you can build stuff on Linux yourself, then I can point you to my branch on github for you to clone and build yourself.  You can run in portable mode on Linux too so no need to interfere with a system-wide install from PPA.

(2019-11-20, 21:08)black_eagle Wrote: [ -> ]

(2019-11-20, 20:08)dm21912 Wrote: [ -> ](I would start testing 19 but the test builds arent on linux yet

If you can build stuff on Linux yourself, then I can point you to my branch on github for you to clone and build yourself.  You can run in portable mode on Linux too so no need to interfere with a system-wide install from PPA.  

Ive just dug an old gen 2 firestick out of the draw and installed on that.

Ive only added Dylan to my library for testing (but I have everything hes ever done). Going to add Beatles and McCartney/Wings in a bit as they are my other two big box set collections./

It picked up everything bar one item. But, I had pre-tagged a lot of things with a box set tag.

The only thing it didnt consider a box set was the 14 disc edition of the Rolling Thunder Review. Granted, this had no disc titles (something I have now corrected on MusicBrainz - now just wait for a mod on MB asking if these are the official titles as per the release)

Maybe there should be a trigger at which point it becomes a box set regardless of disc titles or tags, lol... 

But joking aside, looks good. Personally, the splitting of discs within album view is enough for me, so good to be able to just queue 2 of 14 discs

New test builds are available on the mirrors for those that would like to give it a go. For Win64 that is KodiSetup-20191115-060ef868-PR16915 with builds for OSX and Android in approriate folders on http://mirrors.kodi.tv/test-builds/.

Linux users I hope can build for themselves (for their flavour of Linux) from git https://github.com/xbmc/xbmc/pull/16915

The new test build did identify my Wagner album as a boxed set.  I played around a little with Estuary and got the wall view more to my liking, but IMHO needs more work to make full use of the disctitles.

scott s.
.

Thanks @scott967 , if you would like to submit changes to Estuary then that would be useful, even just the minimal basics. I think we need to get this lib PR merged, then easier to see what skin adjustments are needed or if something more is needed from core.

I really need some way to determine that the container in view is albums or disks that I can use as a visibility condition.  I tried different ways but can't figure out any that work.  The closest I came was trying string.contains(Container.ListItemAbsolute(1).Label,*disks) but that doesn't seem to work for some reason.  But even if it did, it only shows if the music setting "show all items" is enabled.  Also if infolabel Container.SortMethod would return "diskorder" rather than "name" which seems to be the only allowed sortmethod (and disks aren't shown in name order anyway).

scott s.
.

(2019-11-22, 02:41)scott967 Wrote: [ -> ]seems to be the only allowed sortmethod

There is no allowed sort method for discs.  They are presented in (numerical) disc order.  This is mainly because most of the sort order options make no sense for discs.  The only ones that do make any sort of sense are playcount and lastplayed (and possibly ratings).

(2019-11-22, 02:41)scott967 Wrote: [ -> ]I really need some way to determine that the container in view is albums or disks that I can use as a visibility condition. 

I'm really intrigued as to what you are wanting to display ?  I tend to not look at things from a skinners point of view because I don't know enough about skinning to be able to do that so I don't know what's either missing or needed.  I can manage to mod skins a little though and my infowall view for Estuary currently looks like this.



So that shows AlbumTitle ~ DiscTitle which is enough for me, but if you have better ideas, please share them. I don't know what you need to get Kodi to display what you want unless I'm told.  Mock-up pics would also help immensely.

Here is the main problem I see on estuary:



It shows the sort as "name".  This is from Estuary include TopBar

It looks like GUIViewStateMusic.cpp is setting SetSortMethod to be SortByNone  and that results in localized string 551 "name" being returned in the Container.SortMethod infolabel.  Could GUIViewStateMusic be modified so that SortByNone sets a new localized string "disk order" or something similar for disks? 

The Estuary sublabel could be changed IF there was a way to know that there were disks in the container, but all that can be said is that container.content is albums, so I assume there are instances in album node where SortByNone being displayed as "Name" is correct.

scott s.
.

BTW did something change with art? I use $INFO[Player.Art(album.discart1)] to show art for disc 1 in the regular nightlies but it isn't returning anything in boxset tester.

scott s.
.

Yes, something did change with disc art to support all art types at a disc level (not that I can think of anyother types of art for a disc but who knows) - album.discartN should be working, but will need to check that handling having one disc has not upset "disc1".

Re sortorder

Quote:It looks like GUIViewStateMusic.cpp is setting SetSortMethod to be SortByNone  and that results in localized string 551 "name" being returned in the Container.SortMethod infolabel.  Could GUIViewStateMusic be modified so that SortByNone sets a new localized string "disk order" or something similar for disks? 

...so I assume there are instances in album node where SortByNone being displayed as "Name" is correct.

I think SortByNone should not be giving the label "name", but should be empty as SortByNone will be different phyiscal orders depending on the situation. Albums are always sorted by something.

But yes, this sort label needs fixing in core.

Was the sort label the reason for wanting to know content was discs separate from albums? I'm just really aware of the impact on all skins of adding a new content type for what seems like no gain, so would prefer to avoid that.

(2019-11-23, 07:32)scott967 Wrote: [ -> ]$INFO[Player.Art(album.discart1)

You don't need the number.  $INFO[Player.Art(album.discart)] or $INFO[Player.Art(discart)] will show the right art for the currently playing disc.  Works fine for single discs that aren't named discartN, they need to be just discart .

Is this how you want it to look ?  That's returning localized string 427 for NODE_TYPE_DISC



***EDIT***

I played with String.IsEqual(Container.SortMethod,$LOCALIZE[427] and managed to achieve this



Hopefully that's the sort of thing @scott967 is after. PR has been updated with the change if @DaveBlake would like to trigger a test build.

Test build of that for windows available here.

Estuary looks good to go.

I have a navigation problem on one of my Aeon MQ5 windows, but it may be my fault.  I have a "multi-container" view, and when my content type is "albums" I have a second list container with dynamic content set by
where Container(71) is the list of albums.

Prior, this second list was a track listing of the album, and the onclick action for any of the content items was "play".

Now, this second list is a list of discs which is nice, but the onclick action opens a new music window with content songs listing the tracks.  That's good but the problem is that if I try to backtrack by clicking the ".." entry in this song list navigation gets screwed up.  It takes 2 clicks of ".."  I can get back to the album but then I can't navigate properly.  Looking at ListItem.FolderPath, when I first enter the albums node I have eg
for one of the albums.  After moving focus to the secondary list (of disks) and clicking one I get the new song node for the disk.  Clicking ".." twice I get back to the albums node, but now ListItem.Folderpath is

I still have the problem where I can get $INFO[Player.art(album.discart)] if it is in the database, but not $INFO[Player.art(album.discart1)], $INFO[Player.art(album.discart2)] etc.  (the discart1, discart2  show up in the musicdb art table as expected.)  The intent is that discart1 is the art for the first disc of the set etc. 

scott s.
.