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

[AndrewFG]

In some places, particularly in protocol handler plugins, LMS identifies browse tree branches and playable objects using "Dotted IDs" (e.g. 123.04.05), but in other cases, particularly when playing tracks, it identifies playable objects using "Track IDs" (e.g. 123456 for local tracks or -123456 for remote tracks).

If you are browsing the tree branches of a plugin, and you encounter a dotted Id item that has "isaudio:1", is there some way, (via the CLI), of converting its dotted Id to the respective track Id that this track would have when it is played?

Any vice-versa, is there a way of converting a (negative) track Id to the respective dotted Id of the item from which it descended?

And also is there a way of determing the name (actually the CLI verb) of the App that is responsible for handling a particular (negative) track Id?

[pippin]

I don't think there is any direct way to do this, definitely not for track-id to dotted-id.
I even filed a bug around this a few years ago but it only got worse with "onebrowser" in 7.6.0

If you just want to match them you might be able to do that through the "url" of the track but I'm not sure it always works (I was experimenting a bit with it for iPeng Party and got it to work, well, sometimes).

[mherger]

The dotted ID isn't a static id of any item, but rather the navigation
tree you've been coming from. The numbers between the dots are the numbers
of the menu items you chose.

--

Michael

[AndrewFG]

The dotted ID isn't a static id of any item, but rather the navigation
tree you've been coming from. The numbers between the dots are the numbers
of the menu items you chose.

Thanks for the info. At least that much is clear :-)

[AndrewFG]

I don't think there is any direct way to do this, definitely not for track-id to dotted-id.
I even filed a bug around this a few years ago but it only got worse with "onebrowser" in 7.6.0
If you just want to match them you might be able to do that through the "url" of the track but I'm not sure it always works (I was experimenting a bit with it for iPeng Party and got it to work, well, sometimes).

Thanks. The only way I could think of was through the player:

[player] [app] playlist play dotted_id
[player] status - 1 tags:t => returns a track_id

[pippin]

But doesn't songinfo work on dotted ids?

[AndrewFG]

But doesn't songinfo work on dotted ids?

Ah-Ha!

To be quite honest, I just assumed that it wouldn't work...

The help just says track_id shall be provided where "Track ID is as returned by other CLI commands". There are also inferences elsewhere in the help that a positive integer track_id indicates a track on the local file system, and a negative integer track_id indicates a remote stream. So somehow I had assumed that since a dotted id is neither a positive nor negative integer, it is therefore not a valid value for the query e.g. Spotify remote tracks have dotted ids like 123.4.5.6 which, (if you treated it like an IP address), appears to be more "positive" (local file system) than "negative" (remote stream) ?!?

But, you know what? I never actually tried songinfo with a dotted id: so I will give it a try and report back....

[pippin]

I'm not so sure it works anymore either.
I thought I used this to generate context menus when I was still using the XMLBrowser commands as defined in the CLI for access to services in iPeng but looking at my code it seems like back then I did not do that but just created a context menu myself and locally (just play/add/play next commands) so this would mean that at least creating a songinfo MENU from a dotted id doesn't work.

But I believe what _should_ work is to use URLs instead of track_ids and you can query a URL for a playable item using the want_url tag.

[Triode]

Bear in mind that there are essentially two separate internal sources of
data:

1) local tracks which are in the database following a scan - these will have
a trackid and there are a set of cli/json queries which work on them direct.

2) remote "radio" browse trees which are implemented by xmlbrowser - these
may have a negative trackid, but this is only valid for a temporary period
as they do not go into the database and hence are not persistent. You can't
use any queries related to trackids with these and expect to get persistent
data.

The dotted form is just the path to browse to something in xmlbrowser so its
very dependant on what the underlying source of data is to xmlbrowser what
it returns. There's also a lot of complexity around this to ensure
browsing down a tree results in a consistent menu structure (for instance
the what's new spotify list can change under you while browsing down it and
suddenly the 1st track in the third item is no longer what the user
expects). So I would avoid anything which retains the browse tree location
for more than a few minutes. As pippin says use want_url and then use the
urls which are returned.

Looking at the cli hander, the only 3 cli requests which are added for opml
based xmlbrowser items (spotify is one) are:

<name> items _index _quantify
<name> playlist _method
<name> _index _quantify

The json interface for this will be much richer.

-----Original Message-----
From: AndrewFG
Sent: Wednesday, July 04, 2012 3:21 PM
To: developers (AT) lists (DOT) slimdevices.com
Subject: Re: [Developers] CLI: Mapping of Plugin Dotted Item IDs TrackIDs
??


pippin wrote:
> But doesn't songinfo work on dotted ids?Ah-Ha!

To be quite honest, I just assumed that it wouldn't work...

The help just says track_id shall be provided where -"Track ID is as
returned by other CLI commands"-. There are also inferences elsewhere in
the help that a positive integer track_id indicates a track on the local
file system, and a negative integer track_id indicates a remote stream.
So somehow I had assumed that since a dotted id is neither a positive
nor negative integer, it is therefore not a valid value e.g. Spotify
remote tracks have dotted ids like 123.4.5.6 which, (if you treated it
like an IP address), appears to be more "positive" (local file system)
than "negative" (remote stream) ?!?

But, you know what? I never actually tried songinfo with a dotted id: so
I will give it a try and report back....


------------------------------------------------------------------------
AndrewFG's Profile: http://forums.slimdevices.com/member.php?userid=15838
View this thread: http://forums.slimdevices.com/showthread.php?t=95689

[AndrewFG]

Bear in mind that there are essentially two separate internal sources of data:

1) local tracks which are in the database following a scan - these will have a trackid and there are a set of cli/json queries which work on them direct.

2) remote "radio" browse trees which are implemented by xmlbrowser - these may have a negative trackid, but this is only valid for a temporary period as they do not go into the database and hence are not persistent. You can't use any queries related to trackids with these and expect to get persistent data.

The dotted form is just the path to browse to something in xmlbrowser so its very dependant on what the underlying source of data is to xmlbrowser what it returns. There's also a lot of complexity around this to ensure browsing down a tree results in a consistent menu structure (for instance the what's new spotify list can change under you while browsing down it and suddenly the 1st track in the third item is no longer what the user expects). So I would avoid anything which retains the browse tree location for more than a few minutes. As pippin says use want_url and then use the urls which are returned.

Looking at the cli hander, the only 3 cli requests which are added for opml based xmlbrowser items (spotify is one) are:

<name> items _index _quantify
<name> playlist _method
<name> _index _quantify

The json interface for this will be much richer.

Hi Triode,

Thanks for the very clear explanation. It helped me a lot. And it helps to address some of the issues I mentioned in my recent post on your Spotify thread over in the 3rd Party Software forum.

But I would still like to understand more about the mechanism whereby a plugin (like your Spotify) pulls in information from the remote server into the LMS cache.

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 ??

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...