CLI: Mapping of Plugin Dotted Item IDs <=> Track IDs ??

[Triode]

These are both features of the way my plugin works rather than things which should be generalised as to how LMS works... The plugin has to work around some of the features of LMS to work as much as it does as LMS was not specifically designed for all the things it does.

For example the command "spotify items 0 1 id=<whats new folder>" returns "count:1" whereas "spotify items 999 1 id:<whats new folder>" returns "count:500" (!!) -- I suppose it is because in the first case, it has already pulled in one track from Spotify's What's New into the LMS cache and it (wrongly) thinks that cache contains all there is to be got; whereas in the second case it forces all the What's New tracks to be freshly pulled into cache. Or ??

In this case it is because what's new is a search results and the plugin has a setting for "max search results" which defaults to 500 - this is to avoid the search results being very long on non paging interfaces (such as the players). Change this setting to be larger than 999 and I think this will work...

Another example is if you do "[player] playlist play <spotify url>" immediately followed by "[player] status ..." then the response shows the track in the playlist, but it does not show all the track attributes and meta data. Whereas if you wait a few more seconds until the track is fully playing and then do another "[player] status ..." query, then the full set of track attributes and meta data are returned. -- I suppose the "[player] status ..." query responds with data from the cache, so the first request returns very little, whereas the subsequent request returns more attributes since they have been pulled into LMS cache by the player. This is different from the behaviour you get when playing a local track: in that case, even the immediate "[player] status ..." query returns all of the track attributes and meta data...

This is down to how the spotify plugin fetches the track data for playing tracks. The plugin will put as much information as it knows into the temporary database entry for the remote track when you try to play a stream. If a track is played from one of the menus in the plugin then this will normally include the title and probably the icon url, but if you start playback via cli with just the url then at this point the track database will only know the url. It will also trigger a request to the spotify helper to get the rest of the metadata at the point when you start to play a track. However it doesn't block and so playback can start before the response is received and the temporary track database updated with the rest of the metadata. There is also a queuing mechanisms to avoid overloading the helper app with requests so this means that they may be a delay in getting all the information into the track object. This is normally not a problem as the normal interfaces seem to to refresh their requests and get the updated metadata. However as you have seen it means you are getting less data the first time round.

[AndrewFG]

Thanks Triode. All very clear.