lordchuffnel
New member
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
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