Kodi Community Forum

Full Version: Musicplayer art vs player art?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I am wondering what best practice is for skins to show art?

1.  MusicPlayer.Cover vs Player.Art(album.thumb)
2.  MusicPlayer.Property(Fanart_Image) vs Player.Art(artist.fanart)

scott s.
.
(2018-12-19, 01:01)scott967 Wrote: [ -> ]I am wondering what best practice is for skins to show art?

1.  MusicPlayer.Cover vs Player.Art(album.thumb)
2.  MusicPlayer.Property(Fanart_Image) vs Player.Art(artist.fanart)

scott s.
.
I'd go with Player.Art, I think its the most recent info label..?
Someone with some more gui/skinning knowledge could chime in.. but I think they do the same thing at the mo.
Thanks, I've been refactoring musicvisualisation window xml code and it would be the time to make the change, if there is some specific advantage (other than searching in files for player.art would be more complete).  I was kind of wondering if processing for "musicplayer" takes Kodi down a different path compared to just "player".

scott s.
.
Yup, Player.Art is the ideal way, and allows you to access all other music artwork that is available in Kodi 18 Leia, like "Player.Art(artist.clearlogo)" and "Player.Art(album.discart)". As soon as possible they return the expected item from the Art map, so they don't do anything different. I'd like to remove the incomplete duplication someday.
Thanks.  I kind of assumed that was the way to go, but I just don't understand how the thumbloader / artwork management works, and maybe just me, but the wiki documentation and also doxy for art infolabels I have trouble understanding just what's available as well as how to use json rpc to get / put art.

scott s.
.
Yes use  Player.Art(album.thumb) and Player.Art(artist.fanart) etc.
MusicPlayer.Cover  and MusicPlayer.Property(Fanart_Image) have been deprecated and will at some point (v19?) be removed completely.

The wiki and infolabel doxy are in need of updates, and yes all art handling including doing it via JSON could do with documenting clearly. @rmrector  any chance you find time to have a go at that? I am terrible at documentation from a clean sheet, but great at editing/correcting
I'll take a stab at it. The video library wiki has a good frame to build on.
I see now a significant difference.  MusicPlayer.cover has the possibility of using the form MusicPlayer.offset(n).Cover or MusicPlayer.Position(n).Cover but I don't think that works for Player.Art() if so can't make the change.  I use the "offest" in a custom next tracks window for music visualisation and home.

scott s.
.
Yes "offset" and "position" forms are  only available to MusicPlayer.

But the image info labels do seem a jumble that it would be nice to rationalise, obviously evolved over time but coming to it with fresh eyes it is confusing. Thoughts on extending "offset" and "position" forms to Player?
I need to do some more thinking, but in general there is a desire / need in skinning to reference items in a media container to absolute position/offset, to relative (to what's displayed on screen) position/offset, and to relative to selected or focused position/offset.  The interesting case is the "now-playing" containers, which exist even when the container isn't visible in a window (I think logically I would add PVR EPG as a type of "now-playing" playlist along with picture slideshow).  If skin has access to the "now-playing" containers outside of the context of any single window then the same infobools/labels/art could be used as in media windows.

scott s.
.
Scott you gave me an idea, and it half-works already. There is a VFS path called playlistmusic:// that can be fed to a list control (as "<content>") which can be displayed directly, or it is possible to use Container(controlID).ListItem.Art(album.thumb) to get just an InfoLabel. "Half-works" because the "offset" option follows the focus of the container, not the playing item, so it is less useful. A solution there could be to add an option for skinners to add to containers like "focus follows playback" for this. I've wanted such a thing for the main list on the playlist window; maybe it's not a bad idea in general.

playlistvideo:// is also available, and looking at the code, pvr:// has a few paths in it. I don't have a PVR so I can't really explore that one to see what's available, but it is possible to show the VFS path of many windows' container with the Container.FolderPath InfoLabel.


On a different note, I've been working on some wiki documentation for artwork, and one new page I'm working on might interest you, Artwork/Accessing with skins and JSON-RPC. It's still in progress so I would appreciate any feedback.
(2018-12-19, 01:01)scott967 Wrote: [ -> ]I am wondering what best practice is for skins to show art?
=11pt meilleur taux
1.  MusicPlayer.Cover vs Player.Art(album.thumb)
2.  MusicPlayer.Property(Fanart_Image) vs Player.Art(artist.fanart)

scott s.
.
Player.Art without doubt
(2019-01-19, 23:58)rmrector Wrote: [ -> ]Scott you gave me an idea, and it half-works already. There is a VFS path called playlistmusic:// that can be fed to a list control (as "<content>") which can be displayed directly, or it is possible to use Container(controlID).ListItem.Art(album.thumb) to get just an InfoLabel. "Half-works" because the "offset" option follows the focus of the container, not the playing item, so it is less useful. A solution there could be to add an option for skinners to add to containers like "focus follows playback" for this. I've wanted such a thing for the main list on the playlist window; maybe it's not a bad idea in general.

playlistvideo:// is also available, and looking at the code, pvr:// has a few paths in it. I don't have a PVR so I can't really explore that one to see what's available, but it is possible to show the VFS path of many windows' container with the Container.FolderPath InfoLabel.


On a different note, I've been working on some wiki documentation for artwork, and one new page I'm working on might interest you, Artwork/Accessing with skins and JSON-RPC. It's still in progress so I would appreciate any feedback.

WRT "focus follows playback", that would be nice.  Then position relative to focus should be straight-foward.

scott s.
.
(2019-01-19, 23:58)rmrector Wrote: [ -> ]Scott you gave me an idea, and it half-works already. There is a VFS path called playlistmusic:// that can be fed to a list control (as "<content>") which can be displayed directly, or it is possible to use Container(controlID).ListItem.Art(album.thumb) to get just an InfoLabel. "Half-works" because the "offset" option follows the focus of the container, not the playing item, so it is less useful. A solution there could be to add an option for skinners to add to containers like "focus follows playback" for this. I've wanted such a thing for the main list on the playlist window; maybe it's not a bad idea in general.

playlistvideo:// is also available, and looking at the code, pvr:// has a few paths in it. I don't have a PVR so I can't really explore that one to see what's available, but it is possible to show the VFS path of many windows' container with the Container.FolderPath InfoLabel.


On a different note, I've been working on some wiki documentation for artwork, and one new page I'm working on might interest you, Artwork/Accessing with skins and JSON-RPC. It's still in progress so I would appreciate any feedback.

hi did this ever come about? I'd like to treat my visualisation like a container so I can have some animations trigger between songs and it sounds like with this proposal I could use Container.OnNext to trigger animations when the song would change