Author Topic: "id" of things  (Read 7938 times)

bazinga

  • Guest
Is there any way to get an id of songs, albums etc etc?
I'm trying to write a DACP plugin, and as far as I can tell DACP needs Id of things (such as "play the track you told me was this Id".

Any way of getting that? Or I have to cache everything in my plugin???

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
the musicbee api uses the file url as the identifier in the API calls.
If you need to use a numeric id in your plugin, you might use the StringComparer.OrdinalIgnoreCase.GetHashCode() function on the url to convert it to a number. Of course there is a very tiny chance you get a clash where 2 url's generate the same hash, but if you can use a 64 bit integer then the first 32 bits could use the hash value for the folder path and the last 32 bits the hash value for the filename only.
If you needed to translate that number back to a file url, you would need your own in memory dictionary to look up the mapping from hash value to url and could probably just use your own sequential numbering rather than hash values - i dont think that would need to saved

boroda

  • Sr. Member
  • ****
  • Posts: 4595
Also you can assign GUIDs to each track using Library_SetDevicePersistentId/Library_CommitTagsToFile

bazinga

  • Guest
Also you can assign GUIDs to each track using Library_SetDevicePersistentId/Library_CommitTagsToFile

DACP uses albumsId and artistId too; so track id would not be enough (BTW how does Library_SetDevicePersistentId work?)

Since I'm going to cache everything in the plugin, it would be nice to be notified that something with the library has changed... such as file added, libary changed...

boroda

  • Sr. Member
  • ****
  • Posts: 4595
DACP uses albumsId and artistId too; so track id would not be enough (BTW how does Library_SetDevicePersistentId work?)
You can assign several uids to 1 track.
As for Library_SetDevicePersistentId:

1st parameter is track url.

2nd parameter is a type of uid.
You need to extend DeviceIdType enum, but please don't use 1,2,3,4 which are reserved by my plugins.

3d parameter is uid (actually any string)

You can read uid using Library_GetDevicePersistentId:

1st parameter is track url

2nd parameter is a uid type.

Also you can search tracks for uids using Library_FindDevicePersistentId:

1st parameter is an id type

2nd parameter is an array of ids.

3d parameter is a result of query with array of urls.

bazinga

  • Guest
are these Ids written to the files or in mb metadata?
Somehow I don't see a big improvement over having all info in memory (a simple tree would permit queries without the complex MB api calls...). Am I wrong?

BTW: is there any way of getting notified of library changes (change library, add/remove files...)? Otherwise, no matter the implementation, I might have either stale data (if using the cache) or not-yet-IDed tracks (if going with persistentid)

 
 

Steven

  • Administrator
  • Sr. Member
  • *****
  • Posts: 34312
although it is a valid request to have a permanent id at least for a track assigned and maintained by MB, i wont have time to do that for quite a while.
You could apply the hashcode function i suggested above to the artist name and to the album name.
If you are going to use Library_SetDevicePersistentId then let me know so i can allocate an id type for your plugin

bazinga

  • Guest
As I said, I don't see the added value: I would have to re-scan all tracks at startup to check that everyone has its id assigned.
I can't use any hashing function, as I have to be able to go back from (say) albumid to album track list.
But that's not a problem. I cached all metadata info in my plugin, and it looks fast enough.

The problem I'm having now is the cache expiration (isn't it the only problem in programming? :) ).
I can't find any info on library changes.
It's not a big deal at the moment. I don't expect people to mess with their library and then use their phone to control mb right away.
So for the moment the cache is built when needed (first call) and kept as long as mb is running. I might add a "flush" later in the config panel I guess. This, obviously, until an event that says "something (it doesn't have to be specific) has changed in MB library" is implemented.