Bugzilla – Bug 13157
TrackInfo returns different menus when called with ID vs. URL for remote tracks.
Last modified: 2011-04-08 00:04:09 UTC
When I call TrackInfo for a remote track with a url I get a different menu as when called with the track_id. The latter one (id) is wrong. Is this probably because the remote ids are negative values? They were not in 7.3.3.
Remote track IDs are now negative. What is the bug here? I would suggest always using URL for trackinfo when dealing with remote tracks.
You said it's a bug, not me. It was supposed to be a bug that there are different results. MY request was to know how I identify a remote track. I understand there's a "remote" tag, yet what about local tracks that are identified through a URL, e.g. from a plugin.
I'm going to give this one to Alan.
Returning different stuff with id and URL must be wrong. I would recommend using the URL if you have it available. But to answer the more general question, there is no reliable way to tell if a track is remote. The code in SC generally treats anything that is not actually a local track, for example line-in on a Boom, as 'remote'. It is something of a mess. For the moment, the 'remote' flag is your best information. The hack of using negative ids for remote tracks is just that - a temporary hack. I intend to replace all integer IDs with some other form of identifier - a URL of some sort.
Joerg, can you clarify for me please. You say that your are calling Trackinfo. Do you mean that you are calling the CLI 'songinfo' command? Also, when you say that the results for track_id are wrong, do you actually get any results? How big is your library and what is a sample track_id value?
Joerg - what OS did you produce this on? Do you know what size pointers and integers are, respectively?
No, I'm calling trackinfo through cometd, there's just no category in Bugzilla for that. I should say that currently I don't see the issue anymore, maybe it was related to the SQLite builds (I saw it when using an SQLite build). I did get a menu when I call using the trackid for remote tracks but it was wrong. My library is small, some 9000 tracks or so. OS for the server is Ubuntu, 32 bit version, no idea about pointer and integer sizes, wouldn't it be 32 bits then? Or do you mean the client? That's iPhoneOS and has 32 bit integers and pointers AFAIK. Here's an example of what I send: { channel => "/slim/request", data => { request => [ "00:04:20:12:3b:42", [ "trackinfo", "items", 0, 100, "menu:menu", "context:playlist", "track_id:-200829160", ], ], response => "/1b03611c/slim/request", }, id => 31, },
As an expediency, I would say that always using the URL should be fine, regardless of whether the track is local or remote. I'll continue to investigate to see if I can understand why it sometimes fails.
Alan, it may be that the url always works! It was track_id that sometimes returned the wrong information. And, as I said, I haven't seen this on the MySQL builds recently, only on the SQLite builds, maybe that's a hint to what causes it.
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.