Expose track_id for use in Remote API

[lordchuffnel]

Could you please expose a unique track_id for use in the remote API as a substitute for filename.

I believe this would eliminate the need for url encode/decoding. Also make it much easier to create a url string.

Even if I had 2000000 songs,

&track_id=2000000
would be easier than
&filename=D:\this\that\and\the\other\thing\dont\accidentally\misspell\a\word\or\forget\any\character\of\the\filename.mp3

I noticed that as of now, there is no absolute unique identifier on each track saved in the database. Only table tracks2, which contains ALL tracks from all libraries, has an incremented track_id unique to each row.

perhaps this could be the id that gets exposed.

Also, if a track is loaded into the database and exists in multiple libary_x tables, perhaps it could be given a unique/immutable column that is the same across all tables, and unique to the filepath regardless of how the table decides to apply the _id and track_id? (assuming file path is the most fool proof way to detect duplicates).

thank you

 

[djsoft]

I believe this would eliminate the need for url encode/decoding. Also make it much easier to create a url string.

In any case, the URL string is created by a script, so it doesn't really matter how much work is performed. E.g. calling urlencode() in PHP is not a bug deal.

I noticed that as of now, there is no absolute unique identifier on each track saved in the database. Only table tracks2, which contains ALL tracks from all libraries, has an incremented track_id unique to each row.

While there's Track ID in the table, it's not guaranteed to be constant and may be changed by RadioBOSS for one reason or another. It shouldn't be used by user scripts.

Also, if a track is loaded into the database and exists in multiple libary_x tables, perhaps it could be given a unique/immutable column that is the same across all tables, and unique to the filepath regardless of how the table decides to apply the _id and track_id? (assuming file path is the most fool proof way to detect duplicates).

Libraries only contain Track ID and Filename fields, and those are used to connect tracks with the main "tracks" table. So in matter of library tables as well as general tracks table, track ID is what connects them.

Still, I don't understand how using Track ID instead of paths is better when used from API. urlencode() calls are cheap. Making request URL shorted doesn't make any sense as amount of data is low any way.

 

[lordchuffnel]

Still, I don't understand how using Track ID instead of paths is better when used from API. urlencode() calls are cheap. Making request URL shorted doesn't make any sense as amount of data is low any way.

I agree the urlencode() calls are cheap and the amount of data is low.

In the spirit of conversation, I would argue that shorter/simpler/static column in the database that is unique to each file, and that is returned as part of the API calls is merely an edge case of streamlining the process. The edge case being XML failing on parse of invalid characters in filenames and the encode/decode calls improperly working.

Also, one less step for the frontend/backend to make.

 

[djsoft]

I would argue that shorter/simpler/static column in the database that is unique to each file, and that is returned as part of the API calls is merely an edge case of streamlining the process

There's Track ID field, and if you're ready to work directly with the database using SQL queries, you can use that. Just don't store those Ids persistently (in your software) - as those may change.

Still, file name is unique and can de used to identify tracks.

The edge case being XML failing on parse of invalid characters in filenames and the encode/decode calls improperly working.

Any decent XML library doesn't have such problems. All characters are properly escaped/encoded, if that's not the case, I suggest changing XML library.

Also, one less step for the frontend/backend to make.

What are you building and what task needs to be solved? Probably we can add more commands or extend existing ones to make things easier.

 

[HMMMM]

Hi Lordchuffnel . The XML should be good I do preposes this. You need to ensure you have data that is valid before placing it in a SQL database. You also should check that. You can use PHP to extract your data from XML

$xml = simplexml_load_string($contents); $xml=simplexml_load_file("images/nowplaying.xml"); $title = implode($xml->xpath('//PLAYER/TRACK/@TITLE')); $artist = implode($xml->xpath('//PLAYER/TRACK/@ARTIST')); $album = implode($xml->xpath('//PLAYER/TRACK/@ALBUM')); $genre = implode($xml->xpath('//PLAYER/TRACK/@GENRE')); $comment = implode($xml->xpath('//PLAYER/TRACK/@COMMENT')); $bpm = implode($xml->xpath('//PLAYER/TRACK/@BPM')); $length = implode($xml->xpath('//PLAYER/TRACK/@DURATION')); $listeners =implode($xml->xpath('//PLAYER/TRACK/@LISTENERS')); $rating = implode($xml->xpath('//PLAYER/TRACK/@RATING')); $xml = null; // clear the used class XML.

You should clean your data, but the code is too long to post here. by cleaning I mean looking for some problem characters if you turn these into escaped codes in the database it will show them when recalled correctly on the website.

 

[lordchuffnel]

Hi Lordchuffnel . The XML should be good I do preposes this. You need to ensure you have data that is valid before placing it in a SQL database. You also should check that. You can use PHP to extract your data from XML

$xml = simplexml_load_string($contents); $xml=simplexml_load_file("images/nowplaying.xml"); $title = implode($xml->xpath('//PLAYER/TRACK/@TITLE')); $artist = implode($xml->xpath('//PLAYER/TRACK/@ARTIST')); $album = implode($xml->xpath('//PLAYER/TRACK/@ALBUM')); $genre = implode($xml->xpath('//PLAYER/TRACK/@GENRE')); $comment = implode($xml->xpath('//PLAYER/TRACK/@COMMENT')); $bpm = implode($xml->xpath('//PLAYER/TRACK/@BPM')); $length = implode($xml->xpath('//PLAYER/TRACK/@DURATION')); $listeners =implode($xml->xpath('//PLAYER/TRACK/@LISTENERS')); $rating = implode($xml->xpath('//PLAYER/TRACK/@RATING')); $xml = null; // clear the used class XML.

You should clean your data, but the code is too long to post here. by cleaning I mean looking for some problem characters if you turn these into escaped codes in the database it will show them when recalled correctly on the website.

Thank you very much.
Yes, I've had to clean all the filenames, titles, etc.

That's part of the reason I suggested using an immutable numerical id instead of the file path.

 

[djsoft]

That's part of the reason I suggested using an immutable numerical id instead of the file path.

If you want to prevent incorrect characters in SQL queries, using ids instead of file name is not a solution, you should use prepared statements instead, or other means of escaping such characters - in any case, if there would be ids, there are still other text fields like artist, title, comment that are also written to database. Preparing your queries solves all that.

You should never place any data, especially strings, directly into SQL queries - this will lead to all sorts of problems, including SQL injection attack.

 

[lordchuffnel]

If you want to prevent incorrect characters in SQL queries, using ids instead of file name is not a solution, you should use prepared statements instead, or other means of escaping such characters - in any case, if there would be ids, there are still other text fields like artist, title, comment that are also written to database. Preparing your queries solves all that.

You should never place any data, especially strings, directly into SQL queries - this will lead to all sorts of problems, including SQL injection attack.

Understood.
My solution is to use a noSQL database as middleware between RB and my frontend. On song change I use a simple JavaScript function to hash the filename, giving me a string value guaranteed not to have invalid characters. Then I use the new hash as the trackid to query rafioboss for the actual filename. Works great!


Thanks for all you suggestions, I really appreciate it.