You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If this API is going to be the glue between music players and libraries, then it needs to let you retrieve and filter by path info.
I'm working on a music web app and would love to speak this API and be compatible with multiple things. But without the path in the track info, there is no way for me to add any tracks to the playback queue! And without track querying by path, there is no way to show the "now playing" area based on the currently playing file reported by the player.
The text was updated successfully, but these errors were encountered:
I'm for it. This is a good idea for an optional extension, of course—not every client will want access to filesystem details, and exposing paths might not even make sense for some use cases (e.g., multi-user 100%-remote setups). But that's the idea behind designing an extensible API!
If this API is going to be the glue between music players and libraries, then it needs to let you retrieve and filter by path info.
I'm working on a music web app and would love to speak this API and be compatible with multiple things. But without the path in the track info, there is no way for me to add any tracks to the playback queue! And without track querying by path, there is no way to show the "now playing" area based on the currently playing file reported by the player.
The text was updated successfully, but these errors were encountered: