[angelblue05]

@DaveBlake 

I have an unexpected artwork issue when trying to play music in Kodi, where the music is served over http. I was wondering if you knew about it.

When I play via the interface, no problem, the artwork shows up.
When I play via party mode, artwork is missing.
When I play via context menu on artist or album, artwork is missing.

The artwork is set up in the database. Does it not look at it when playing via those scenarios? Is it a limitation of using http (similar to the limitation for chapter images for content that is not served over network)?

Thanks for your help!

[sualfred]

It's not http that is causing the problem or how the path looks like in the DB. I guess the problem is based on the real file path that is passed to the player. But for some reasons the library windows are handling it differently by starting a playback via artist -> album -> song (which works without issues).
For example you can also create a "track4.strm" to E:\mymusic\artist\album" that points to a http stream and you will have the same problem. As soon as the track itself is not a local .mp3 or whatever it's going to break for widgets, partymode, *.m3u or PlayMedia(file).
All other listitem labels will be solved correctly (artist,album,etc)

[DaveBlake]

@angelblue05 which artwork, all types or just some? What skin are you using? Is only art accessd over http the problem? Is this new in v18 or have you had the same issue in v17?

All those routes to playback attempt to load art, but do so at different points in the processing. A better design would be one consistent way to do that, and it is something I would lke to untangle. The "reason" for this separate handling is just history as best I can tell.  However that diversity not something that has changed, so if this issue is new with v18 then something else is a contributing factor.

Leia has additional network security and it is possible, if this is a v18 specififc issue, that change is part of the problem. A debug log could help to show that.

[sualfred]

@DaveBlake 
All artworks and not related to the skin. Player.Art(info) + MusicPlayer.Cover is not filled at all. In partymode ListItem.Art(info) is missing too.
I'll provide you a debug log for Krypton + Leia within the next hour.

[sualfred]

Leia:
-> Debug Log: https://paste.kodi.tv/cifotonofi.kodi
-> Widget playback (which calles PlayMedia(file)) -> No Player.Art(info) + MusicPlayer.Cover
-> Partmode playlist -> No ListItem.Art(info)

Krypton:
-> Debug log: https://paste.kodi.tv/curajukedi.kodi
-> Widget playback (which calles PlayMedia(file)) -> No Player.Art(info) + MusicPlayer.Cover
-> Partmode playlist -> ListItem.Art(info) is filled correctly

As soon as the file is a real .mp3 and locally stored it works for all scenarios. With our Emby addon we point to stream.mp3 of the Emby server (https://xx.xx.xx/emby/Audio/77268/stream.mp3).

If you want I can provide you a manipulated leia musicdb and test album with 1 .strm file that points to my emby server and 1 real mp3. You just have to call the song directly via widget or PlayMedia(file.strm)
You also can do it on your own, but this requires a direct manipulation of the musicdb after the scan to the DB, because Kodi ignores .strm files during a scan.

[DaveBlake]

So @sualfred  same issue with art for music over HTTP server or .strm file in v17?

BTW I have never been clear that .strm support existed in the music library, if it works it could  be more accident than design. Cuesheet and .m3u support yes, but not .strm. While the player can unpack and play the contents, getting data from the library for the unpacked thing is a separate matter.

[DaveBlake]

Cross posted, thanks for logs.
So widget playback of remote music art is missing in both v17 and v18, but party mode art missing in v18 is new.

As soon as the file is a real .mp3 and locally stored it works for all scenarios. With our Emby addon we point to stream.mp3 of the Emby server (https://xx.xx.xx/emby/Audio/77268/stream.mp3).

If you want I can provide you a manipulated leia musicdb and test album with 1 .strm file that points to my emby server and 1 real mp3. You just have to call the song directly via widget or PlayMedia(file.strm)

Yes that would be useful, PM me with details, I don't have any served music to test with.

You also can do it on your own, but this requires a direct manipulation of the musicdb after the scan to the DB, because Kodi ignores .strm files during a scan.

As I said I don't think the music library is designed to support .strm files

[sualfred]

Same issue with .strm and HTTP. 
I know that .strm isn't supported officially. I've just tested this case to see if it's a problem in how our path is stored in the musicdb or if the path is a http:// protocol. But it won't work for both of them.

Emby database construct:
path table: https://xx.xx.xx./emby/audio/72268/
song file: stream.mp3

Manipulated structure:
path table: %local path% as usual
song file track.strm

Btw: .strm works well for single file playback even if it's by accident

[sualfred]

pm sent

[DaveBlake]

Thanks @sualfred playing music from your server now

It is the HTTP access that interests me most rather than the .strm accident, and that art behaviour for remote music in party mode change since v17 (I have touched that). I can reproduce the lack of art, or rather the art only being visible when playback is started from the song node. Playback started from album node for example does not show art.

The widgets use a script call, and that takes yet another route though the code to start playback, it does not surprize me if that route does not include loading art but I need to check.

So doing some digging....

[sualfred]

@DaveBlake 

AFAIK widgets just use PlayMedia() in general. That's also the reason why video items, that are started from a widget, will be added to the playlistid 0 (which is the musicplaylist). But that's another bug ^^

I have no idea how this complete stuff is handled but maybe it tries to probe the file and looks for the integrated id tags before the setArt stuff is processed. And since the stream.mp3 or the test .strm file has no information stored it raises an exception and skips that part?  Anyway, I'm sure you will dig enough to find the root of the issue. Thanks!

[DaveBlake]

Not related to this issue but @sualfred any idea how so many of your song.iTimesplayed fields in the db ended up as Null? Kodi creates the records with iTimesplayed = 0, so I don't know how that happens. An addon? Anyway the consequence of the null value is that play count never gets incremented

[sualfred]

@DaveBlake 
It's mostly related to the intial sync process I guess. @angelblue05 please correct me if I'm wrong and if not we should adjust it.

[DaveBlake]

It looks to be like the art is missing sometimes for music located on a server because the background loader CMusicInfoLoader::LoadItemCached looks at dynpath which starts "HTTP" and therefore the items are taken as internet streams and no art is loaded.

I'll do some more testing, see if anything else is contributing, but I'm sure that is the main issue.

[sualfred]

Player.IsInternetStream is returning true, yes. I already thought it could be related to it I just was confused because all other listitems get filled correctly and that playing from a song node is handling everything correctly.

Edit:
Btw, don't know if that information is helpful, but if the filename has a argument included like xx.xx.xx/stream.mp3?static=true all listitems won't get filled,too. We just dropped that argument, because it's not really required.