Spotify Connect

[snizzleorg]

Would be awesome if spotify-connect could be supported so that one could stream from spotify to forked-daapd and then to all the speakers in the house:

https://github.com/plietar/librespot

It's probably possible to do this even now via pipe (the same was as mentioned here: https://github.com/ejurgensen/forked-daapd/issues/278)

See also this discussion: https://github.com/plietar/librespot/issues/88

[ejurgensen]

Certainly would be an interesting feature.

It would mean that a user like me, which has both local music (+ radio) and Spotify, would need to use two clients. Personally, I prefer having all my music controllable from one client per device (mostly Remote on my phone). So what I am going for (and hoping for) is still proper integration. This is hard to do right now because of the lack of replacement for libspotify. So right now, Spotify support in forked-daapd is lackluster. The plan on my part (and @chme, I believe) is to see if Spotify delivers on their promise to make a replacement for libspotify. The announcement says before the end of this year.

Anyone who feels like writing them to encourage this should probably do so!

[snizzleorg]

Yeah one would have to use two clients. (My use case is identical to yours). Not ideal But much better than only having the playlists as we have now. I kinda don't really expect the spotify API to be released anytime soon...

[ejurgensen]

Yes, they may well disappoint. I actually have begun working on a little something that will give you all your Spotify music in forked-daapd. Basically by mixing libspotify with the web api. So I hope they will at least not cripple libspotify any more.

[snizzleorg]

Cool. Let me know if I can help testing. However still think that forked-daapd besides iTunes being the only piece of software able to stream to multiple airplay speakers synchronised would be good to accept input from spotify directly via spotify-connect. also forked-daapd as a airplay target would be nice to distribute audio from e.g. an iPhone to multiple speakers.

[snizzleorg]

Sounds interesting. Let me know if you need someone to test it out...

Sent from my phone.

On 26 Oct 2016, at 20:43, ejurgensen notifications@github.com wrote:

Yes, they may well disappoint. I actually have begun working on a little something that will give you all your Spotify music in forked-daapd. Basically by mixing libspotify with the web api. So I hope they will at least not cripple libspotify any more.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ejurgensen]

I agree, it’s just that adding direct support for librespot and libshairport/libshairplay in forked-daapd (and maintaining the support) is a bit more work than I can take on.

I hope that the pipe (+ metadata pipe) can serve the purpose for now. Maybe a good thing to add to the current pipe implementation would be to make forked-daapd automatically start playing a watched pipe, if there is audio being written to it. That would mean you could start playback without interacting with forked-daapd.

[snizzleorg]

So for the interested: I got https://github.com/plietar/librespot to work on the same raspberrypi that runs forked-daapd.

I created a named pipe:

mkfifo ~/music/spotify

and then run librespot like this:

/home/pi/librespot --backend pipe --device /home/pi/music/spotify -n spotifyConnect --cache /tmp > /dev/null 2>&1

then I can "play" Spotify in forked-daapd and select SpotifyConnect in the Spotify App - The output then goes to which-ever speakers selected in forked-daapd.

Not exactly elegant but it works nicely to stream Spotify from the app to all airplay speakers.

[1liminal1]

This is very cool.

https://bbs.nextthing.co/t/howto-chip-or-chip-pro-as-spotify-connect-radio/17621

I found this guide, is this what you did or?

Thanks

[snizzleorg]

I went for step 2B from your link. I downloaded the binary.

the point however is starting it so that it outputs the audio to a named pipe, which is then read by forked-daapd

This is done as I wrote above.

[1liminal1]

Ive found a place with the install, but no idea how to install this to a headless Pi Zero

https://github.com/herrernst/librespot/releases

Any guides, im Googling, but im struggling.

[1liminal1]

Right, hope this helps someone in the future :)

Create the directory first, cd into that and then;

wget` https://github.com/herrernst/librespot/releases/download/v20170717-910974e/librespot-linux-armhf-raspberry_pi.zip

unzip librespot-linux-armhf-raspberry_pi.zip

[1liminal1]

So if I run it this way, it works, but obviously goes no where; (I have set up the pipe, same as above)

./librespot --name "AirPlay" --username "Username" --password "Password"

If I try running it like this;

./librespot --name "AirPlay" --username "Username" --password "Password" --backend pipe --device /home/pi/music/spotify -n spotifyConnect --cache /tmp > /dev/null 2>&1

It seems to just crash, any ideas?

[1liminal1]

Ok, so its running now, but the pipe doesnt work;

I can see a device called "AirPlay" I can play to it.

I cant see it in the remote and I can see this in the logs

laudio: Error initializing Pulseaudio: Connection refused

Im also using the native spotify "client" the one that just shows you the playlists in the remote. But I would assume if it was picking up the pipe correctly, it would show both?

[snizzleorg]

Did you create the pipe?

mkfifo /home/pi/music/spotify

and of course this needs to be inside the library folder of forked-daapd

so the above assumes that /home/pi/music/ is the library folder of forked-daapd.

[snizzleorg]

This option in /etc/forked-daapd.conf is also helpful

...
    # Watch named pipes in the library for data and autostart playback when
    # there is data to be read. To exclude specific pipes from watching,
    # consider using the above _ignore options.
    pipe_autostart = true
...

This makes forked-daapd automatically start if it detects data in the pipe. So you do not have to select the pipe file, forked-daapd will automatically do that if it detects that librespot is putting data into it.

[1liminal1]

so the above assumes that /home/pi/music/ is the library folder of forked-daapd.

Thats what it was, I had the default in the conf file. Thanks so much, would never have got that.

But its all working, and working well, crashes a bit though :( How are you finding stability? Also is there a way to make this run on start up?

Thanks again for your help with this :)

[snizzleorg]

stability is so-so. It is crashing on me always. mostly I suppose it's forked-daapd crashing. not sure why though and I haven't had time to go into debugging.

For running it as a service I use systemd

/etc/systemd/system/spotify-connect.service

pretty crude but it works.

[Unit]
Description=Spotify Connect
After=network-online.target
[Service]
Type=idle
User=pi
ExecStart=/home/pi/librespot --backend pipe --device /home/pi/music/spotify -n spotifyConnect --cache /tmp > /dev/null 2>&1
Restart=always
RestartSec=10
StartLimitInterval=30
StartLimitBurst=20
[Install]
WantedBy=multi-user.target

I can then use sudo service spotify-connect start

[ejurgensen]

Don't like to hear about forked-daapd instability, so now I have also setup librespot with a pipe to test it the next few days...

Would be nice if librespot would support metadata pipes like shairport does. That could also help remove some of the volume control lag.

[1liminal1]

@snizzleorg sorry, been away, thanks for that.

Have you guys seen this?

https://github.com/dtcooper/raspotify/issues/15#issuecomment-329002310

Its a client that's easy to install and has a conf file for settings, like piping as you can see from this issue.

[chimpy]

@1liminal1 @snizzleorg is the one that explained it to me :P

[chimpy]

@ejurgensen Just wanted to say thanks for an awesome piece of software. The setup detailed in this thread took me about an hour, which was a lot quicker than I expected. Mostly thanks to your slick software. Getting rid of volume control lag would be brilliant!

[1liminal1]

@chimpy Nice! and thanks for your help on that other thread :)

I also second how awesome forked-daapd is and just a general thanks for how helpful everyone is in getting stuff setup.

[ejurgensen]

Yes, I'm hoping librespot will implement metadata pipe or file, so forked-daapd can pickup volume changes instantly. However, so far there has been no response in the thread, so might require that someone steps up and makes a PR.

I've been running the setup a few days, and so far no crashes. If there are specific circumstances that produce a crash I hope you will share.

[snizzleorg]

thanks for testing. I have not had time to dig to the root of this. Not sure what the crashes are and who is to blame. It's not so easy to debug and doesn't follow a pattern so that I can recognise so far.

However if I find a little more time I will do some more thorough testing. Maybe I can find some specific circumstances.

[1liminal1]

I have mine working now as well so ill test over the next few days and let you guys know about stability.

So the meta-pipe causes the slow response, is there any workaround for that, or nothing we can do?

[Condorello]

Take a look here, seems to be more Active mantained than librespot for now:

https://github.com/Spotifyd/spotifyd

[ejurgensen]

Thanks for the hint. But isn't it built on top of librespot? Or am I not understanding it properly?

It also looks like it only can output to alsa and Pulseaudio, which won't do for forked-daapd. It will need to provide raw audio so that forked-daapd can send to any output (Airplay, Chromecast, alsa etc.).

[Condorello]

Seems to be build around librespot Yes and currently support pipe. It's like raspotify but works also in x86. Anyway: https://developer.spotify.com/web-api/web-api-connect-endpoint-reference/

[ejurgensen]

Yes, the connect api is interesting. The web connect api + librespot could replace libspotify, it seems. However, librespot is written in Rust, and forked-daapd is C. It is possible to call Rust libraries from C, but looking at it I think it would require a wrapper, and I have never done any Rust.

[mivida]

Sorry if I made some stupid mistake, just trying to get to know all this and get it all to work.

The forked-daapd server is up and running perfectly. (Only trying to figure out how to get a simple playlist, but not for now)

What I did so far was:

wget https://github.com/herrernst/librespot/releases/download/v20170717-910974e/librespot-linux-armhf-raspberry_pi.zip

unzip librespot-linux-armhf-raspberry_pi.zip`

mkfifo /data/Music/Spotify

(This is a sub dir of my forked-daapd library)

And in /etc/forked-daapd.conf I unhashed

pipe_autostart = true

If I run the command below, librespot starts, stays open at the cml, shows info (like loading song etc) and I can see it from my Spotify app. The songs plays, and of course I don't hear anything (I need the pipe)

./librespot --name "AirPlay" --username "username" --password "password"

But if I run the command below, it returns directly to the cmd, and I don't see anything in the Spotify app. I don't know where to find the log of librespot so I can't debug. What am I doing wrong?

./librespot --name "AirPlay" --username "username" --password "password" --backend pipe --device /data/Music/Spotify -n spotifyConnect --cache /tmp > /dev/null 2>&1

[ejurgensen]

I'm not sure, perhaps the question should be made to librespot? Well first you can check that the pipe part is working. Make a wav file if you don't have one already, you can do that with 'ffmpeg -i yourfile.mp3 testfile.wav'. Then run 'cat testfile.wav > /data/Music/Spotify'. This should start playback and you should hear the song. If that part works, then librespot is not writing to the pipe.

BTW, while you test, remove the '> /dev/null 2>&1' part. That means that you don't see errors produced by librespot. Maybe it is actually trying to tell you what is wrong :-)

[mivida]

Thanks for the tip to remove > /dev/null 2>&1 Still learning :) And thanks for forked-daapd. It's great!

The error was that the name was set 2 times --name and -n Then an other issue came up. Errors with writing permission in the pipe. Solved now. So finally this commando worked for me:

./librespot --name "AirPlay" --username "username" --password "password" --backend pipe --device /data/Music/Spotify --cache /tmp

I have an other question. Is it only the possibility to stream my Spotify music from my smartphone to librespot->forked-daapd to let forked-daapd stream it to my Apple TV? Because I can do this directly. I was hoping that (like with a Playstation4) the Spotify app would become a remote for librespot. So when you close the app the music keeps playing and can be done by multiple people. Is this possible? Or could this be done in any way?

[ejurgensen]

I'm not that into librespot/Spotify Connect, but I thought it did actually stream straight from the backend, so not from your phone? Isn't that working for you?

Personally, I use Spotify a lot with forked-daapd, but I do it as described here: http://ejurgensen.github.io/forked-daapd/#spotify

With this setup it works like you say: Music keeps playing independently of the phone, and it can be controlled by multiple people/devices via Remote. However, the drawback is that you cannot control music via the Spotify app.

[1liminal1]

I can say it does work, you can use librespot (ie create a Spotify Connect device on your phone) to pipe music to forked-daapd that you can then control with the remote to connect to Airplay endpoints.

https://github.com/dtcooper/raspotify

I actually started using this one, its the easiest to install and config.

You might want to check your music group permissions for the pipe. And also the config files.

You can get it working, just keep at it!!!

[mivida]

@ejurgensen & @1liminal1 I'll look into both.

Strange that librespot should work like that but doesn't for me. Any idea what I maybe doing wrong or where I can search for? You do use Spotify as remote app or the Apple Remote app?

In the meantime I got the suggestion of @ejurgensen working. Is there a way to just have all the playlist items and don't have albums/songs show up in my albums list? (Apple Remote app)

[thorium232]

Hi all,

I have recently set up forked-daapd and librespot with a pipe as shown above. It works but the delay between play is pressed in the Spotify App and music starts is huge (about 15 secs). This happens also whenever a new song starts and sometimes forked-daapd seems to give up and music stops. Not sure if its forked-daapd or the Airport.

any clues on this?

Thanks in advance and thanks for the great work.

Osvaldo.

[ejurgensen]

If you set the log level to debug you should be able to get detailed info about what forked-daapd is doing, incl. timestamps. That should reveal if the lag is before or after the audio gets to forked-daapd. Librespot probably also has logging abilities?

[thorium232]

Pasted syslog below. There are only a couple of lines of librespot. I tried to figure it out myself but I could not. It seems forked-daapd first disconnect from Airport Express and then reconnects but I'm not sure.

Jan 1 19:01:43 ornl-pi02 librespot[24288]: INFO:librespot_playback::player: Loading track "Cheap Sunglasses" with Spotify URI "spotify:track:0FvWTzmlU7kp2f15zn7mqd" Jan 1 19:01:46 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: keep_alive: Sending OPTIONS to 'ORNL_AE01' Jan 1 19:01:47 ornl-pi02 forked-daapd[22548]: [ LOG] player: Source is not providing sufficient data, temporarily suspending playback (deficit=188) Jan 1 19:01:47 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: flush: Sending FLUSH to 'ORNL_AE01' Jan 1 19:01:47 ornl-pi02 forked-daapd[22548]: [DEBUG] mpd: Asynchronous listener callback called with event type 1. Jan 1 19:01:47 ornl-pi02 forked-daapd[22548]: [DEBUG] mpd: Notify clients waiting for idle results: 1 Jan 1 19:01:47 ornl-pi02 forked-daapd[22548]: [DEBUG] player: Callback from AirPlay to device_command_cb Jan 1 19:01:53 ornl-pi02 librespot[24288]: INFO:librespot_playback::player: Track "Cheap Sunglasses" loaded Jan 1 19:01:57 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: Flush timer expired; tearing down RAOP sessions Jan 1 19:01:57 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: device_stop: Sending TEARDOWN to 'ORNL_AE01' Jan 1 19:01:57 ornl-pi02 forked-daapd[22548]: [DEBUG] player: Callback from AirPlay to device_streaming_cb Jan 1 19:01:57 ornl-pi02 forked-daapd[22548]: [ INFO] player: The AirPlay device 'ORNL_AE01' stopped Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] player: Resume playback of '/home/pi/Music/Spotify Stream' (id=625, item-id=319) Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [ WARN] player: Input start called, but playback already running Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] player: Action is metadata_get Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] main: Got worker execute request Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] db: Running query 'BEGIN TRANSACTION;' Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] db: Starting enum 'SELECT FROM queue f WHERE id = 319 ORDER BY pos;' Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] db: Running query 'END TRANSACTION;' Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] db: Running query 'BEGIN TRANSACTION;' Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] db: Starting enum 'SELECT FROM queue f WHERE id = 319 ORDER BY pos;' Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] db: Running query 'END TRANSACTION;' Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: device_start: Sending OPTIONS to 'ORNL_AE01' Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [ INFO] player: Using selected AirPlay device 'ORNL_AE01' Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] artwork: Artwork request for item 625 Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] db: Running query 'SELECT COUNT() FROM files f WHERE f.disabled = 0 AND id = 625;' Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] db: Starting query 'SELECT f. FROM files f WHERE f.disabled = 0 AND id = 625 ;' Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: startup_options: Sending ANNOUNCE to 'ORNL_AE01' Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: Local address: 10.0.250.15 (LL: no) port 37660 Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [ INFO] raop: Setting up AirPlay session 3720417141 (10.0.250.15 -> 10.0.250.10) Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] cache: Running query 'SELECT a.format, a.data FROM artwork a WHERE a.type = 0 AND a.persistentid = 5024056800311776848 AND a.max_w = 600 AND a.max_h = 600;' Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] cache: Cache hit: SELECT a.format, a.data FROM artwork a WHERE a.type = 0 AND a.persistentid = 5024056800311776848 AND a.max_w = 600 AND a.max_h = 600; Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] artwork: Source 'cache' stopped search for artwork for group 5024056800311776848 Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [DEBUG] artwork: No artwork found for item 625 Jan 1 19:01:59 ornl-pi02 forked-daapd[22548]: [ INFO] raop: Failed to retrieve artwork for file id 319; no artwork will be sent Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: startup_announce: Sending SETUP to 'ORNL_AE01' Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: token: unicast Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: token: mode Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: token: record Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: token: server_port Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: token: control_port Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: token: timing_port Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: Negotiated AirTunes v2 UDP streaming session 1; ports s=6000 c=6001 t=6002 Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: startup_setup: Sending RECORD to 'ORNL_AE01' Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: RAOP audio latency is 15409 Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] raop: volume_internal: Sending SET_PARAMETER to 'ORNL_AE01' Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] player: Callback from AirPlay to device_restart_cb Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] main: Command has 0 pending events Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] mpd: Asynchronous listener callback called with event type 1. Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] mpd: Notify clients waiting for idle results: 1 Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] mpd: Asynchronous listener callback called with event type 1. Jan 1 19:02:00 ornl-pi02 forked-daapd[22548]: [DEBUG] mpd: Notify clients waiting for idle results: 1 Jan 1 19:02:05 ornl-pi02 forked-daapd[22548]: [DEBUG] player: Input buffer has 354432 bytes Jan 1 19:02:15 ornl-pi02 forked-daapd[22548]: [DEBUG] player: Input buffer has 355584 bytes

[snizzleorg]

The Problem is that librespot does not support meta data pipe. (Yet). This would take care of the huge annoying lack especially when changing volume...

[ejurgensen]

Yes, meta data pipe would help on volume change, but not with this. In this case it looks like the data is just arriving too slowly during start-up:

19:01:43 Playback starts 19:01:47 forked-daapd runs out of audio (underrun) -> pauses playback 19:01:59 forked-daapd restarts (because the buffer now has 2 sec audio)

So librespot probably writes a bit of data in the beginning, but then delivers data at low rate so forked-daapd has nothing to play at 19:01:47. It will then wait until it has 2 seconds worth of audio before restarting, but this doesn't happen until 19:01:59.

To confirm this, you could try stopping forked-daapd and then reading straight from the pipe to see at what rate data arrives. A simple way of doing that: Open two terminals, in the first run cat "/home/pi/Music/Spotify Stream" > out.wav and in the other watch the size of out.wav.

[ejurgensen]

I made some timings on my rig. I didn't get any underruns, and for me librespot delivers data very fast. There is still some lag:

0s Press start 0s librespot starts loading 2s librespot loading complete 2s librespot starts writing to pipe 4s forked-daapd detects data on pipe 7s forked-daapd Airplay setup complete 9s Airplay speaker starts playback

So most of the time is spent starting Airplay (seconds 4 -> 9). That can probably be optimized, but I wouldn't know how to do that. What I might be able to optimize is the 2 seconds that elapse from librespot write to forked-daapd detect, but that requires further examination of what is taking the time.

[thorium232]

Some logs from my side: It looks like librespot chunks arrive out of order and it does not write to the pipe until chunk 1 is received (7 secs later in my case). The Track ... Loaded message seems to be related to chunk 1/48 complete event.

Jan 2 23:21:18 ornl-pi02 librespot[2111]: DEBUG:librespot_connect::spirc: kMessageTypeNext "U235" 83eff67541c44220cdc9724e3ca3728f4a992f1c 17 1546482019392 Jan 2 23:21:18 ornl-pi02 librespot[2111]: DEBUG:librespot_playback::player: command=Load(SpotifyId(u128!(21269819556111031925544821786406773212)), true, 0) Jan 2 23:21:18 ornl-pi02 pi: -rw-r--r-- 1 pi pi 0 Jan 2 23:20 out.wav Jan 2 23:21:18 ornl-pi02 librespot[2111]: INFO:librespot_playback::player: Loading track "Please Don't Touch - Performed by HeadGirl" with Spotify URI "spotify:track:0uc4eNX3KYXCFimVYQLX5O" Jan 2 23:21:19 ornl-pi02 librespot[2111]: DEBUG:librespot_audio::fetch: Downloading file 5f52cd1bf2706542740feef3bba3886f24ac1d9d Jan 2 23:21:19 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 0 Jan 2 23:21:19 ornl-pi02 pi: -rw-r--r-- 1 pi pi 0 Jan 2 23:20 out.wav Jan 2 23:21:19 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: chunk 0 / 48 complete Jan 2 23:21:19 ornl-pi02 librespot[2111]: DEBUG:librespot_playback::player: Normalisation Data: NormalisationData { track_gain_db: -10.550003, track_peak: 0.93841195, album_gain_db: -9.230003, album_peak: 1.0759456 } Jan 2 23:21:19 ornl-pi02 librespot[2111]: DEBUG:librespot_playback::player: Applied normalisation factor: 0.29682457 Jan 2 23:21:19 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 1 Jan 2 23:21:20 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 47 Jan 2 23:21:20 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 45 Jan 2 23:21:21 ornl-pi02 pi: -rw-r--r-- 1 pi pi 0 Jan 2 23:20 out.wav Jan 2 23:21:21 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: chunk 45 / 48 complete Jan 2 23:21:21 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 46 Jan 2 23:21:21 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 22 Jan 2 23:21:22 ornl-pi02 pi: -rw-r--r-- 1 pi pi 0 Jan 2 23:20 out.wav Jan 2 23:21:22 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: chunk 22 / 48 complete Jan 2 23:21:22 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 23 Jan 2 23:21:22 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 11 Jan 2 23:21:23 ornl-pi02 pi: -rw-r--r-- 1 pi pi 0 Jan 2 23:20 out.wav Jan 2 23:21:23 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: chunk 11 / 48 complete Jan 2 23:21:23 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 12 Jan 2 23:21:23 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 5 Jan 2 23:21:24 ornl-pi02 pi: -rw-r--r-- 1 pi pi 0 Jan 2 23:20 out.wav Jan 2 23:21:24 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: chunk 5 / 48 complete Jan 2 23:21:24 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 6 Jan 2 23:21:24 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 2 Jan 2 23:21:25 ornl-pi02 pi: -rw-r--r-- 1 pi pi 0 Jan 2 23:20 out.wav Jan 2 23:21:25 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: chunk 2 / 48 complete Jan 2 23:21:25 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 3 Jan 2 23:21:25 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 1 Jan 2 23:21:26 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: chunk 1 / 48 complete Jan 2 23:21:26 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 3 Jan 2 23:21:26 ornl-pi02 pi: -rw-r--r-- 1 pi pi 0 Jan 2 23:20 out.wav Jan 2 23:21:26 ornl-pi02 librespot[2111]: INFO:librespot_playback::player: Track "Please Don't Touch - Performed by HeadGirl" loaded Jan 2 23:21:27 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: chunk 3 / 48 complete Jan 2 23:21:27 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 4 Jan 2 23:21:27 ornl-pi02 pi: -rw-r--r-- 1 pi pi 23175680 Jan 2 23:21 out.wav Jan 2 23:21:27 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: chunk 4 / 48 complete Jan 2 23:21:27 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 6 Jan 2 23:21:28 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: chunk 6 / 48 complete Jan 2 23:21:28 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 7 Jan 2 23:21:28 ornl-pi02 pi: -rw-r--r-- 1 pi pi 24019968 Jan 2 23:21 out.wav Jan 2 23:21:29 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: chunk 7 / 48 complete Jan 2 23:21:29 ornl-pi02 librespot[2111]: TRACE:librespot_audio::fetch: requesting chunk 8 Jan 2 23:21:29 ornl-pi02 pi: -rw-r--r-- 1 pi pi 24867328 Jan 2 23:21 out.wav

[cdlenfert]

@snizzleorg did you ever check out this fork of librespot? https://github.com/billsq/librespot - it includes metadata pipe support.

[floodwayprintco]

Watching this. Really wish I could use the Spotify UI to browse and play through Forked-daapd as a Spotify Connect device.

The way I use it is that Spotify's volume is a master. And individual speakers can be controlled through Home Assistant. Most of the time we have all speakers going though and just use Spotify to control the master volume.

[cdlenfert]

@floodwayprintco the repo I linked above for librespot is a fork that creates a metadata pipe for Forked-Daapd to pick up artists/track/album info from Spotify. Librespot in general supports and audio pipe output (which Forked-Daapd can read and broadcast to your airplay speakers). So you can already do what you're wanting to do, you just need to build Librespot and configure it on your system. I doubt it's ever getting baked into Forked-Daapd directly unless the current Spotify integration completely fails. Word of warning, on my old old low spec FD server (a PogoPlug), Librespot will freeze up on seemingly random tracks. I don't believe it's an issue of resources however, but rather a known issue with Librespot. For me it makes it not worth using.

[floodwayprintco]

@floodwayprintco the repo I linked above for librespot is a fork that creates a metadata pipe for Forked-Daapd to pick up artists/track/album info from Spotify. Librespot in general supports and audio pipe output (which Forked-Daapd can read and broadcast to your airplay speakers). So you can already do what you're wanting to do, you just need to build Librespot and configure it on your system. I doubt it's ever getting baked into Forked-Daapd directly unless the current Spotify integration completely fails. Word of warning, on my old old low spec FD server (a PogoPlug), Librespot will freeze up on seemingly random tracks. I don't believe it's an issue of resources however, but rather a known issue with Librespot. For me it makes it not worth using.

thank you!

I did go through the thread but clearly not well enough. Sad to hear about the reliability issues.

It looks like there may be some other options to get a Spotify Connect + Airplay + Home Assistant solution going I'm just starting to think it won't have Forked-Daapd in the middle.

Appreciate your help!

[jshep321]

Hey, I love forked-daapd btw. Thanks for all the efforts!

I installed a wrapper/repo of librespotify called raspotify and connected as described above (via a pipe/fifo) and it works beautifully except for metadata. I can use my phone or laptop via spotifyconnect to control the raspotify instance and it keeps playing when the phone is unavailable.

Raspotify: https://github.com/dtcooper/raspotify My quick instructions here (at the bottom). It literally took 5 mins to setup. https://github.com/dtcooper/raspotify/issues/30

[GaWeiss]

Hi, I use forked-daapd the same way @floodwayprintco does. Until today using the pipe capability of raspotify was my approach too. Now I encountered a Java based connector called spocon. Additionally to the functionalities of raspotify it supports a metadata pipe that works fine with forked-daapd!

After following the installation instructions of spocon I created two files (spotify and spotify.metadata) and changed the configuration in the [player]-Section:

# Audio output device (MIXER, PIPE, STDOUT)
output = "PIPE"
# Output raw (signed) PCM to this file (`player.output` must be PIPE)
pipe = "/home/pi/music/spotify" 
# Output metadata in Shairport Sync format (https://github.com/mikebrady/shairport-sync-metadata-reader)
metadataPipe = "/home/pi/music/spotify.metadata"

After restarting spocon and forked-daapd I finally have metadata with artwork in my UI. I hope this helps everyone who is using forked-daapd with Spotify this way. Thank you for your great work on this topic!

[floodwayprintco]

Thank you @GaWeiss!!!

The metadata was kinda a silly annoyance, but I think this fixed another issue I had with Rapostify's implementation of Spotify Connect. I could never get shuffle to work correctly, it seemed to only shuffle the first 50 songs in a playlist, or just not shuffle at all.

[ejurgensen]

Yes, thanks for sharing @GaWeiss. I will promote this info to somewhere more visible, e.g. the Spotify section of the README.