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
Currently this issue is tracked in librespot-org/librespot#7, but most requests/suggestions involve us providing metadata through various methods (pipes, sockets, websockets, etc.) which is something that should be implemented in librespotd rather than librespot. Related to this is event notifications, which are not really implemented in librespot. We should give some thought as to how to notify connected clients (local ones, not other Spotify clients), about the various events, from play/pause, all the way up to shuffle.
My first thoughts are that we probably want to approach this in a similar fashion to the sink implementation, as there may be use cases where the user wishes to use pipes and websockets to receive metadata, for example. In addition to this, programs will need to be able to request data from the server, in the event that they start receiving metadata at a different time to when librespot is started.
Hence, my thinking is that a hub and spoke type architecture for sending/requesting metadata is probably optimal; implement metadata retrieval and event logic once, then create adapters for the various different outlets. This would be greatly simplified if we agree on a format (JSON, etc.) for distributing metadata, as we could then handle generation of that once, and simply implement encoding/decoding for sending/receiving on each of the respective metadata outlets.
The text was updated successfully, but these errors were encountered:
Currently this issue is tracked in librespot-org/librespot#7, but most requests/suggestions involve us providing metadata through various methods (pipes, sockets, websockets, etc.) which is something that should be implemented in librespotd rather than librespot. Related to this is event notifications, which are not really implemented in librespot. We should give some thought as to how to notify connected clients (local ones, not other Spotify clients), about the various events, from play/pause, all the way up to shuffle.
My first thoughts are that we probably want to approach this in a similar fashion to the sink implementation, as there may be use cases where the user wishes to use pipes and websockets to receive metadata, for example. In addition to this, programs will need to be able to request data from the server, in the event that they start receiving metadata at a different time to when librespot is started.
Hence, my thinking is that a hub and spoke type architecture for sending/requesting metadata is probably optimal; implement metadata retrieval and event logic once, then create adapters for the various different outlets. This would be greatly simplified if we agree on a format (JSON, etc.) for distributing metadata, as we could then handle generation of that once, and simply implement encoding/decoding for sending/receiving on each of the respective metadata outlets.
The text was updated successfully, but these errors were encountered: