We just pushed changes to the node-roon-api and node-roon-api-transport libraries to update them to work with version 2 of the transport API service.
Version 2 adds these capabilities:
Support for subscribing to the play queue for a specific zone
Support for playing from specific points in the play queue for that zone
An optimization to not send a full zone update every time the seek position changes
Existing extensions that use versions less than 1.1 of the node-roon-api-transport library should continue to work without any changes. Using version 1.1 will mean that the event callback provided to subscribe_zones will also need to handle Changed messages with a msg.zones_seek_changed which is an array of objects like this:
{
zone_id: zone_id_as_string
seek_position: optional number representing new seek position in seconds
queue_time_remaining: optional number representing new remaining queue time in seconds
}
Right now, my advice for end users is to mostly ignore this update. If you have extensions that you are using, and they work now, just don’t touch them until you hear something from the extension authors. New extension installs should generally work as well, but it might be possible for things to be broken somehow there.
Good to see that the Roon API hasn’t been forgotten!
Considering the jump to version 2 and the breaking change it introduces (the seek position optimization), I want to suggest to add version tags to the 1.0 and 1.1 version of the transport library. This will make it easier for an extension developer to force the use of a specific library version by appending the version in the dependencies section of the package.json file:
You might also consider the semantic versioning scheme as suggested by npm. This could add the flexibility to use the latest compatible version of an API.
Is there something else I need to do to specify that version correctly?
I could be convinced that the new transport library should be version 2.0 instead of 1.1, mirroring the Roon core side API version number sounds reasonable to me.
As I understood it, the version specified in the package.json file can only be used in a dependency specification if the package is published (i.e. can be found in the npm registry).
I believe I understand now, I made these changes to the github repo. We will make a best-effort attempt to match semantic versioning, although I can’t quite promise we will always get it right.
Let me know if this looks correct to you know, I am quite far from an npm/github expert.
Thanks @ben! Once I get home from dealing with a family situation, I will start playing with this. These changes should let me optimize a LOT of code on the Web Controller extension!
I ran into an issue with the queue_time_remaining field that got added in version 2 of the transport API. If an internet radio stream is playing then there is no clear indication that the remaining time is unknown/infinite:
The remaining time is the seek position with a minus sign in front. It is also possible that both values are 0 if the radio stream has just been started.
This issue isn’t limited to the Roon API, also Roon itself reports negative remaining times of the queue when internet radio is playing:
Would it be possible to define a constant for an unknown/infinite remaing time (e.g. -1)?
Looking forward to further functionality from the API. Am I missing the roadmap somewhere, or are we just posting change/feature requests here in the forum?
Things I think would make the API more fun/functional:
√ Add current UI theme (light/dark) to zone.settings.
√ Expose the user’s LastFM auth token.
√ Send audio channel frequencies in transport api. (I.E. low, mid, high range frequencies).
Hmmm - you could add an extension then to control lighting like Philips hue or even a DMX based club systems (I still have old lighting systems form my DJing days)
Any news on what’s coming next to the API?
Perhaps plans to allow us to interface with Swim/Radio feeds (Vote up/down, start new swim feed, image_key for upcoming artist/track, etc)?
