[ronie]

i think i recently saw you mention wanting to dive into the kodi source-code...
well... here's your first warning, things can get pretty messy in there ;-)

[User 224999]

i think i recently saw you mention wanting to dive into the kodi source-code...
well... here's your first warning, things can get pretty messy in there ;-)

hahaha, noted. For now I'll work around the issue in my code and this might be something I'll look into first when having the source figured out ;-)

[ronie]

it's probably a little early for requests, but if you want to make things more consistent...
i'm utterly annoyed that json returns a 'runtime' field for videos, but uses 'duration' for audio. ;-)

[User 224999]

it's probably a little early for requests, but if you want to make things more consistent...
i'm utterly annoyed that json returns a 'runtime' field for videos, but uses 'duration' for audio. ;-)

haha, me too

[scott967]

that's the album type as far as i can tell.
it's not related to media type.

Hmmm, but why do all other json endpoints return the mediatype as the type property except for the album one ?
It doesn't seem very consistent to me but maybe I'm missing something very obvious :-)

Since PR#10573 the music database now will store a string as "strType" for album "Type", intended to be pulled from song tag Musicbrainz ReleaseType if present. There is also a separate strReleaseType that's really a boolean album/single and can work as a fallback if strType is null. I suppose JSON api maybe should be tweaked?

scott s.
.

[ilovethakush]

the thing is: there is no infodialog for seasons.
At the moment core just makes it open the infodialog of the corresponding tvshow, so listitem.dbtype probably returns "tvshow", and that´s why it doesnt work. I can understand why skinners want to make the infodialog for seasons look different, but atm core just doesnt allow that in a sane way, so if you want to workaround these core limitations you have to use hacks.

Any word on when or if ever info dialog for seasons will be available? Why can't it be done?

[ronie]

Any word on when or if ever info dialog for seasons will be available? Why can't it be done?

i'm sure it can be done... we just haven't found anyone who's interested enough to write the needed code.
are you volunteering?

[ilovethakush]

Any word on when or if ever info dialog for seasons will be available? Why can't it be done?

i'm sure it can be done... we just haven't found anyone who's interested enough to write the needed code.
are you volunteering?

That's exactly why I'm asking why can't it be done? Or more specifically now, why hasn't it be done?

I haven't looked at the source code but it seems all too simple to me unless I'm just missing something.

If the code is written to pull the season poster and display it on screen when hovering over a season, then I feel like it can easily pull the season poster and the season info when looking at the info dialogs. As of right now, when skinning, and you tell it to pull the poster, it displays the tv show poster and not the season poster for info dialogs. But when displaying the poster on the screen, it pulls the correct one.

Actually interestingly enough. ListItem.Property(TotalEpisodes) is the only one that works for seasons, it pulls the number of episodes per season for season info dialogs, and number of episodes in total for tv show info dialogs. Literally everything else corresponds to the tv show value regardless if it's season info or not.

Which is exactly what phil65 said.

the thing is: there is no infodialog for seasons.
At the moment core just makes it open the infodialog of the corresponding tvshow, so listitem.dbtype probably returns "tvshow", and that´s why it doesnt work. I can understand why skinners want to make the infodialog for seasons look different, but atm core just doesnt allow that in a sane way, so if you want to workaround these core limitations you have to use hacks.

But he also mentions that core doesn't allow it in a sane way and that you have to use hacks. Hinting that my "all too easy" fix wouldn't work.

So I asked why.

[ronie]

That's exactly why I'm asking why can't it be done? Or more specifically now, why hasn't it be done?

and that's exactly the question i answered ;-)
it can be done. but someone needs to write the code for it.

i've been waiting for over 7 years for someone to step up to this taks :-)
http://forum.kodi.tv/showthread.php?tid=58154

[User 224999]

Since PR#10573 the music database now will store a string as "strType" for album "Type", intended to be pulled from song tag Musicbrainz ReleaseType if present. There is also a separate strReleaseType that's really a boolean album/single and can work as a fallback if strType is null. I suppose JSON api maybe should be tweaked?

Yeah, that's what I was discussing with ronie. The json api should have a separated album type attribute (and keep type for the mediatype as for the other content) or the other way around. Anyway, I worked around it for now by simply implying all results are albums and will look at it when I have some more time and experience with the kodi code.

[User 224999]

If the code is written to pull the season poster and display it on screen when hovering over a season, then I feel like it can easily pull the season poster and the season info when looking at the info dialogs. As of right now, when skinning, and you tell it to pull the poster, it displays the tv show poster and not the season poster for info dialogs. But when displaying the poster on the screen, it pulls the correct one.

There is no season metadata at all in the core, not even in the database so that's the reason why.
It can be added but it would be a lot more work than simply adding some infolabels. I guess that's why it did not yet happen until someone volunteers

[DaveBlake]

Since PR#10573 the music database now will store a string as "strType" for album "Type", intended to be pulled from song tag Musicbrainz ReleaseType if present. There is also a separate strReleaseType that's really a boolean album/single and can work as a fallback if strType is null. I suppose JSON api maybe should be tweaked?

Yeah, that's what I was discussing with ronie. The json api should have a separated album type attribute (and keep type for the mediatype as for the other content) or the other way around. Anyway, I worked around it for now by simply implying all results are albums and will look at it when I have some more time and experience with the kodi code.

Just to clarify: the change of PR10573 was to populate strType field of album table from music file tag data, before that PR it was only set via scraping of album.NFO files (<type>) and would often be empty. It contain arbitrary text, although now it is initially populated from tags it is more likely to have things like "album", "album/live", "Album / Compliation", "EP", "Soundtrack" in it if the music was tagged using Picard.

JSON API GetAlbums has always returned this arbitrary value string as "type". The for v15 the detection of singles was cleaned up by adding a codifed "album"/"single" field that GetAlbums returns as "releasetype".

Any API naming inconsistecy with other content is made worse by the fact that Picard calls the ALBUM_TYPE tag "Release Type". If you are looking to rename this and makes things consistent etc. please ping me. I would like consistent naming from API to database and NFO tags, so I'm not sure using "type" alone for either is a good idea.

[DjCisco]

Container Content Episodes is missing isnt it?

[smitchell6879]

Container Content Episodes is missing isnt it?

I haven't read all of this thread but I still use container.content episodes ..
So is it going to be missing in v18

[jurialmunkey]

Container Content Episodes is missing isnt it?

I haven't read all of this thread but I still use container.content episodes ..
So is it going to be missing in v18

No he means in the OP it's missing from the quoted list of content types. Episodes is definitely an available content type.

The first post needs to be amended to include episodes is all.