Replies: 41 comments
-
|
Hi @frafall I agree, I'm doing some research on it now. This is a good read as you know. More for reference this is the web API track object. I feel this may be easier to use if there is an easy way to authenticate with the API (So far I've found it a pain) As in the above issue I would also say that writing to file may be the best way as it is somewhat easy to get information from. Of course other ways could be added but I would say that write to file should be the first focus. |
Beta Was this translation helpful? Give feedback.
-
|
Some issues with file writes, u never know if the data is current or some leftover from earlier runs, it's localized inside a docker image or VM (unless exported explicitly) and pushing new data is a hassle as u either have to add new data at end or re-write file and leave it to the client to poll this. I like push options. My ideal solution would be opening a socket to libreelec where it pushed data, kinda similar to listening to stderr or a pipe if you have control of the process. I kinda dislike pipes due to the locality (single machine) and single reader things. But, for now I've been happy reading the stdout output, rather that than a file. |
Beta Was this translation helpful? Give feedback.
-
|
I see where you're coming from with writing to file, however its sometimes the only way to feed from other programs the information. Usually by polling said file, containing only now playing metadata. (I don't like it either). I think like you some sort of push service were other devices listen would be best, but I feel that should be as a secondary objective. Also not everyone will want metadata so I think it should be an option, views? I think stout should be a priority as it would be one of the easiest get a proof as concept. |
Beta Was this translation helpful? Give feedback.
-
|
stdout support would provide file writing support "for free" because of the lovely concept of pipes (which work on both UNIX-likes and Windows cmd, AFAIK). I'd advocate implementing this for stdout first, making sure to move any current stdout prints during normal operation into stderr so the stream is free of non-metadata noise. This feature would enable me to use librespot where I can't use it currently. |
Beta Was this translation helpful? Give feedback.
-
|
I did implement a (dodgy) websockets server a little while back in an earlier version of librespot that pumped out metadata to clients on various changes, though it wasn't merged as Paul wanted to keep librespot relatively minimal. With regards to metadata format, do we think JSON would be suitable? I only suggest that so that those who choose to interact with the Web API as well don't have to think about multiple data formats. Also, I agree that the metadata output should be optional, some people just dont need it if they integrate with librespot directly. Perhaps a compile time flag if people want metadata output? |
Beta Was this translation helpful? Give feedback.
-
|
I would prefer a meta-data pipe. That would be compatible with forked-daapd. |
Beta Was this translation helpful? Give feedback.
-
|
See here: owntone/owntone-server#278 |
Beta Was this translation helpful? Give feedback.
-
|
Well, maybe it's just because I'm curmudgeonly, but I'd prefer not to have to write any code in Rust. What I'd like is for the example Spotify Connect daemon that comes with librespot to offer a metadata to stdout flag. You could implement similar backends for other protocols too, even HTTP. With the new librespot-org we don't have to worry about if Paul wants to keep the thing minimal if the current maintainers don't feel that way ;) Since librespot has PulseAudio output, you can kinda see where I'm going with my design if you look at what Tribblify can do... Keeping in mind that all sinks have a source named As far as data format, any of the following would work for my purposes:
What probably wouldn't work is having the format be |
Beta Was this translation helpful? Give feedback.
-
|
I get where you're coming from, I'm not a huge fan of rust either. However, in the interests of maintainability, I do think he was right not to allow things like a websockets server to be baked in to librespot with no way to turn it off. However, compile-time feature flags are our friend here, to a certain extent, in that any pipe/websocket/etc. solution can be selectively enabled at compile time. I.e. those who don't want a bigger executable can just build without the features they don't need. I do agree with you though, in that whilst librespot is technically a library, I get the feeling that most people are using it as a daemon/standalone program, thus not having metadata easily available in daemon mode is a pain. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps a separate GH project entirely for the daemon that's actually featureful? That would be amazing! :) It could go under librespot-org, too... |
Beta Was this translation helpful? Give feedback.
-
|
I think that was Paul's intention, that all the websocket server, piped metadata, etc. go in a separate project, and librespot is simply for core functionality. |
Beta Was this translation helpful? Give feedback.
-
|
The only reason I get a little nervous about compile-time flags is that, if actually compiling the thing is a nightmare (which could happen if we keep super up to date with the latest Rust stuff and you're running, say, Ubuntu 16.04 with 2 year old Rust), and binaries happen to be conveniently available from distro packages or a PPA, then we'd want to make sure that distros ship with all possible options enabled at compile-time, and just have them be runtime flags. I agree with you that having a web server enabled by default is way overkill, but I think all the possible features of the daemon should be there in a default compile, and encourage anyone packaging binaries, whether it be Ubuntu or a PPA maintainer or some other distro, to enable all options. Everything that's a compile-time flag should also be disabled by default in the daemon if you just run it with only the minimum required arguments to establish a Spotify connection; to get extra features like metadata, it's fine to expect the user to have to pass a command-line argument. I don't think code size is an issue even on a Raspberry Pi, because the storage capacity of MicroSD cards is ridiculous these days. Compiling in Rust code for a web server may add a megabyte to the code; it may add five megabytes... I can't bring myself to care at all on any platforms that would have the cycles to run librespot in the first place. |
Beta Was this translation helpful? Give feedback.
-
|
Fair enough. To be honest, compiling librespot is really not very difficult. One simply installs rustup, installs the latest rust version, makes sure portaudio is installed and runs cargo build. I would rather keep librespot fairly vanilla, and have the various features such as dns-sd over mdns, etc. that frankly most users are not going to care about as compile time flags, then have a separate project as you suggested which is the bells and whistles daemon. That way, the daemon repo can handle which features it wants when compiling librespot, and the daemon/standalone binary can have all of the metadata/webserver/etc stuff built in and toggleable by runtime flags. The daemon/standalone project could then be binary that gets distributed via PPAs and such, whilst librespot is kept thin for people using it as a library. |
Beta Was this translation helpful? Give feedback.
-
Yeah, that sounds like a great plan. |
Beta Was this translation helpful? Give feedback.
-
|
I like this a lot, so just to check?
|
Beta Was this translation helpful? Give feedback.
-
|
If he opens a PR and then once it's reviewed, sure. |
Beta Was this translation helpful? Give feedback.
-
|
#214 PR created. |
Beta Was this translation helpful? Give feedback.
-
|
This is brilliant. I'll give your repo a clone while we wait for the daemon. Thanks @billsq ! |
Beta Was this translation helpful? Give feedback.
-
|
So I cloned the rep to get this fix. Compiling was successful and the client runs. |
Beta Was this translation helpful? Give feedback.
-
|
@chimpy Does your pipe.metadata have the same permission as your pipe file? Did you run librespot with the arguments I mentioned above? Did you restart your forked-daapd? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @billsq ! Thanks for the reply. Details below:
I have restarted forked-daapd before using your fork, no change. If I do a Ah, this gets mentioned in forked-daapd's log: OK, so I realised that maybe |
Beta Was this translation helpful? Give feedback.
-
|
Try restarting librespot. spotify.metadata |
Beta Was this translation helpful? Give feedback.
-
|
Hey bill, not sure if you saw my edited comment, but I did that. I did mkfifo spotify.metadata. When I restart librespot it hangs after authenticating my user but before showing the country code. |
Beta Was this translation helpful? Give feedback.
-
|
It happens to me with stock librespot sometimes. Just try to restart it. I don’t think it has anything to do with the pipe code. |
Beta Was this translation helpful? Give feedback.
-
|
I had to insist a bit but it works perfectly. Thank you!
_edit_
Using @billsq 's fix with forked-daapd is so so good now. Any volume changes in any Spotify client are instantaneously reflected in forked-daapd. And the elegant web interface and Remote allow easy choosing of multiple Airplay speakers. Fantastic!!
Thanks to forked-daapd and librespot!
|
Beta Was this translation helpful? Give feedback.
-
|
@billsq Everything still working for you? The problem above has back for me with a vengeance. After a about 40 start/stops, it's still hanging before getting the country code. |
Beta Was this translation helpful? Give feedback.
-
|
It is working as usual. |
Beta Was this translation helpful? Give feedback.
-
|
Has this been merged? Using |
Beta Was this translation helpful? Give feedback.
-
|
IIRC they closed the pull request citing it as out of scope/feature creep. :’(
… On 29 Jan 2019, at 09:07, Menso Heus ***@***.***> wrote:
Has this been merged? Using --mixer pipe --metadata-pipe /srv/music/spotify.metadata gives me error: Unrecognized option: 'metadata-pipe' on what I built from source yesterday
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Beta Was this translation helpful? Give feedback.
-
|
@chimpy Finally found the root cause or your issue. It is due to forked-daapd doesn't open metadata pipe by default. Now should be working fine. |
Beta Was this translation helpful? Give feedback.
-
Damn nice initiative 👍
One area we would need to look at is metadata, a lot of forks is due to the need to integrate this and we should put down some standard way to do it.
This includes two parts, what tags to use (ex Vorbis) and how to deliver it to the rest of the world as in encoding (json, xml, ...) and transport (stderr/stdout, pipe, tcp, ucp...)
This could/would also imply changes to the audio adapter API, ex to have metadata available for pulseaudio properties.
Beta Was this translation helpful? Give feedback.
All reactions