mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 00:05:55 +03:00
[GH-ISSUE #98] Metadata again.. #85
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#85
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @sashahilton00 on GitHub (Jan 29, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/98
Saturday Nov 25, 2017 at 04:03 GMT
Originally opened as https://github.com/plietar/librespot/issues/266
Metadata/tags has been sadly overlooked, as it is now every integration patches its own.
I suggest we address this by making metadata available in the audio_backend.
Ex. Pulseaudio has a more or less well defined API where it uses properties, Airplay supports its own tags, for the stdout backend we can continue to use stderr as the simple "Track loading" stuff does today but should be expanded with more tags. Currently metadata is not a part of the audio backend API at all as far as I can tell.
Also, all the basic tags should be available without having to lookup in Spotify again as that would push complexity into audio distribution (Pulseaudio, Snapcast). Adding a tag for Spotify reference would be nice to enable elaborate UI's (ex Kodi with a lot of track info) but basic info should be available without complexity.
Any ideas?
@sashahilton00 commented on GitHub (Jan 29, 2018):
Thursday Nov 30, 2017 at 07:16 GMT
Hmm, is this maintained at all anymore? Or moved somewhere else?
Anyone?
@sashahilton00 commented on GitHub (Jan 29, 2018):
Thursday Nov 30, 2017 at 07:37 GMT
See the readme here:
https://github.com/plietar/librespot#unmaintained
@sashahilton00 commented on GitHub (Jan 29, 2018):
Friday Dec 01, 2017 at 10:37 GMT
Ye, have any1 come forward to take ownership or do we all fragment it into our own special versions?
It's a brilliant piece of code and I'd hate to see it fragment :(
@sashahilton00 commented on GitHub (Jan 29, 2018):
Friday Dec 01, 2017 at 10:52 GMT
Sorry but another url again:
https://github.com/plietar/librespot/issues/263#issuecomment-348066472
Maybe you step forward? :)
@sashahilton00 commented on GitHub (Jan 29, 2018):
Saturday Dec 02, 2017 at 13:42 GMT
Tempting but my rust skills are more than rusty S
We are probably better off with someone who can evaluate pulls...
@sashahilton00 commented on GitHub (Jan 29, 2018):
Sunday Jan 28, 2018 at 23:58 GMT
@frafall see https://github.com/librespot-org/librespot the recent successor.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Monday Jan 29, 2018 at 07:54 GMT
This is good new indeed!
👍
@ComlOnline commented on GitHub (Jan 29, 2018):
Please see #7 for continued discussion.