[angelblue05]

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

I will correct that. Thank you!

[angelblue05]

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.

So like, chapter images. But it’s odd it only applies in certain scenarios?

[DaveBlake]

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.

 

So like, chapter images. But it’s odd it only applies in certain scenarios?

As I said almost every different way of starting playback takes a totally different route through the code (bonkers, but how it is at the moment). Playing from songs node the GUI list of items is passed to the current playlist and already has all the art loaded (from db and cache). Playing from something that does not have all the songs on display e.g. partymode or say an album, the art is loaded as part of populating the curent playlist (or rather isn't because each item is seen as a stream).
 

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.

IsInternetStream is triggered by the "http" at the start, but yes I could see why arguments at the end could upset it too.

What is needed is a common and consistent way of filling the playlist items with both art and additional artist and album information regardless of how playback is initiated. Maybe for v19, eh? Meanwhile I am not sure I can fix this particular seeing-items-as- stream issue (or some of it) for v18.X because of the fragile nature of the code - fix this break something else - but I will have a look.

[sualfred]

Yeah, we are mostly too late to the party. 

A plaster solution to check the dynpath for being in the database and set the art in this case isn't a good idea I guess?

[DaveBlake]

A plaster solution to check the dynpath for being in the database and set the art in this case isn't a good idea I guess?

Tweeking that check is the most I could hope to do for v18, but we need to take care. I can probably tell from path that an item is in the library, dynpath gets set to the actual location (at some point in the process) and so can not be used for that.

[angelblue05]

If it can be patched for 18 it would be great. However I’d understand if it had to wait until 19. Thanks a lot for looking into it.

Maybe related question, but when playback ends and it tries to move on to the next track, are we facing a similar situation? I think some kind of file probing happens then, is this correct? Is it a similar situation to what we are facing now? Or it’s an actual file probe?

[DaveBlake]

Maybe related question, but when playback ends and it tries to move on to the next track, are we facing a similar situation? I think some kind of file probing happens then, is this correct? Is it a similar situation to what we are facing now? Or it’s an actual file probe?

IsInternetStream being positive will effect what processing happens on flow to next track, so yes similar. The player does scan the tags of the file it is playing even with library items because not all tag data is held in the library e.g. replay gain, if that is what you mean by "probing". But there is also a progress dialog that gets displayed when music window update is slow, this says something like "Loading media information from files..." by default even though it may be something else that is actually happening. That could make you think the file is being scanned when it isn't.

[angelblue05]

Yes I think the file tags is what I am referring to. It seems, if it fails to do this, it will skip the next track. Is this correct? If so, is there a way around this behavior, a way to turn it off? Just being curious really

[DaveBlake]

If tracks are being skipped then that is something else, probably the player unable to access the file at all or does not see it as music.

[DaveBlake]

OK @sualfred @angelblue05  would you like to see if this win64 test build solves some, if not all, the art loading issues with library music files on a server.

I have not looked at the widget play media problem.

[sualfred]

@DaveBlake 

Artworks are back for partymode playlists. The other things are unchanged. Only playback via songs node is setting the artwork correctly.

[DaveBlake]

The other things are unchanged. Only playback via songs node is setting the artwork correctly.

Odd, I'm seeing art when I start playback from artist or album too. Takes a while to load but appears.

[sualfred]

How do you start them? 
Because via context menu on a album/artist "queue", "play", "play next" they won't get filled.

Edit:
Playback started via albums node + context menu + play + debug overlay with player.art(info) items. The fanart comes from the artist slideshow addon.

[DaveBlake]

Hit <p> on keyboard.... Do we have more code routes here? I'll check.

[sualfred]

Makes no difference on my end. "p" doesn't fill them, too.

Edit:
Just in case -> You test it in Estuary, aren't you? Because for Embuary I've added a Python fallback solution to query the DB on the onPlay() notification.