Improved forked-daapd (iTunes server)

[liminal]

Seem to be getting an error.

mpc sendmessage pairing 0986: command not found

This is a brand new install

EDIT
Make sure you have MPC installed;

sudo apt-get install mpc

[ejurgensen]

@cdlenfert, another possible cause of the issue could be this.

Here is a build you can test that has the modification for slow system timers.

Let me know if this fixes the problem, then I will look into a proper way of supporting these kind of timers.

[cdlenfert]

@ejurgensen before I saw this post with the new deb, I updated the install to the latest version. I thought it was the fix I was looking for as I was able to play to a 1st gen, and 2nd gen AE pretty much add day long (after a full library rescan). However for the last couple days playing to the 3rd gen AE will either last a few songs, or only a single song, and then stream stops with the same resolution as before (toggling playback to the beginning usually starts the stream again). I'll try installing this deb and see if that changes anything. Thanks again for all your efforts.

@cdlenfert, another possible cause of the issue could be this.

Here is a build you can test that has the modification for slow system timers.

Let me know if this fixes the problem, then I will look into a proper way of supporting these kind of timers.

[cdlenfert]

With the latest deb installed I'm getting some different info in the log. There was a good stretch where playback to the "Kitchen" Airport Express (3rd Gen, also called 2nd Gen N version by Apple) lasted over several albums without stopping the airplay stream (about 30 songs). However this morning it would play a single song, then stop streaming (playback was still active, just not being output the the AE). The "Failed" error is a new one that I haven't seen before. I also see a lot of the "Source is not providing sufficient data..." errors. Could the issue be that the Pi Zero's wifi isn't able to handle the stream from a network device out to an Airport? It will be flawless for a while, but then stop and go again.

Code: Select all

[2017-05-11 06:03:35] [  LOG]   player: The AirPlay device 'Kitchen' FAILED
[2017-05-11 06:03:36] [  LOG]   player: Bug! Input metadata item_id does not match anything in queue
[2017-05-11 06:08:09] [  LOG]   player: Source is not providing sufficient data, temporarily suspending playback

[ejurgensen]

Did you get to check the cpu use?

[cdlenfert]

Did you get to check the cpu use?

Just watching the CPU monitor that comes installed by default in the top right bar on Raspbian during active streaming to multiple airplay speakers (also connected via a VNC session) the Pi ZeroW is showing between 30-40% and when it switches tracks (I think) it spikes up to around 70% and 100% on occasion. Maybe that explains the drop out after a track is completed. Please let me know if there's a better way to monitor this.

More testing and more mixed results recently. At least 10 songs playback to the AE3 and AE2 simultaneously. When there were dropouts earlier, the AE2 kept streaming, while the AE3 dropped.

[cdlenfert]

I removed the mounted network share that holds my main library and added an internet radio station to my local library and ran a new scan. The internet radio was picked up. It's broadcasting at 128kbps, and so far I'm able to stream much more consistently to all of my AEs. Maybe some of the 320kbps files in my library are too much for the PiZeroW?? I'll selectively add some lower bitrate files to my library and see if they stream more reliably.

[ejurgensen]

I don't have much knowledge about the Zero's computing power, but this statement "watching the CPU monitor that comes installed by default in the top right bar" seems to indicate you are also running a desktop environment on it? Guess that also draws some cpu cycles.

So maybe you should consider a Pi upgrade...

[cdlenfert]

I found a 320kbps internet stream and the PiZeroW handled it nearly perfectly. Successfully airplayed it to multiple speakers for several hours without a hiccup. I've also narrowed my library down to a small subset of files on my NAS that are lower bitrate, the result of streaming those files is that something still breaks the airplay stream between the end of a song and the beginning of the next. It doesn't seem like an issue with processing power or RAM maxing out to me, but I'm also extremely new to linux and the pi platform. I'll try a test with my library on only locally attached storage and see if that changes the result, but ideally I'd want to stream from my NAS storage.

[ejurgensen]

Have you checked for clues in the log?

[cgioconda]

N00b question, but I'm encountering this exact same issue: https://bugs.debian.org/cgi-bin/bugrepo ... bug=858696

but according to the bug report, it says the issue was fixed back in 24.2-2 (I have 24.2.60.gitb installed). Is it possible the bug is back, or that there is a version issue?

[ejurgensen]

For various reasons, the official debian package is packaged in a slightly different way than the one I release for Raspbian. From the bug report it seems I need to implement the same change to the packaging that has been made for the official debian package. I will include that in the next release.

If others encounter this problem the workaround apparently is: 'As a workaround, just execute "systemctl enable forked-daapd" after installing the package.'

[cdlenfert]

Here is what I found in the log when issues with continuous playback to the 3rd Gen AE started. I've included the specific debug log sections where issue occurred and summarized each issue with a prepended

Code: Select all

***

to make them easier to search for. For example:

Code: Select all

*** Somewhere below the connection to the kitchen speaker stopped, but playback to the office speaker continued *** 

[2017-05-19 09:25:41] [DEBUG]     raop: Got retransmit request, seq_start 3293 len 1
[2017-05-19 09:25:49] [DEBUG]   player: Input buffer has 176896 bytes

Pastebin: https://pastebin.com/2rguJWT2

Thanks for any feedback. Another quick question I have is how to keep internet radio stations I've added from showing up in my "songs" list. When I shuffle my music, inevitably a radio station will start playing and then it stays there. How can I keep them separate?

[ejurgensen]

Thanks, that is a lot of log output to look at. At first glance it looks like the new track is being opened and decoded too slowly. When this happens the internal buffers underrun, and forked-daapd will try to stop the AirPlay sessions nicely. After a little while, when the opening of the track has progressed and the buffers are nice and full, the AirPlay sessions should be started again. From the log, it seems that the starting/stopping is not reliable. Not sure why.

You are right about the shuffling and radio stations - I will look into that.

[johnstok]

Feature Request: option to specify encoding for ChromeCast stream

First, thanks for all the hard work on forked-daapd – it's great!

As you will know the CCA can support a range of audio codecs, including FLAC. Could I request the option to configure the encoding used when sending audio to CCAs so that a lossless codec such as FLAC can be selected. This would improve audio output from these devices when using forked-daapd.

Best wishes.

[ejurgensen]

Ok, I've added it here so I remember it

[cdlenfert]

At any rate, I noted every step and put them across three blog posts here: http://robpope.co.uk/blog/post/multi-ro ... -bluetooth

@Marioscube - Any chance you can get Jessie Lite running on a fresh SD Card and follow the instructions to see if it works for you?
.

Hi RobP, is there any chance you ever got this up and running on Rasbian Jessie Lite? Forked-daapd is failing to start for me. Thanks

[liminal]

Hi guys,

Coming back to my Alexa Spotify project

(Play Spotify from Echo Dot output though Forked-daapd using named pipes and controlling airplay speaker connect and disconnect/ volume though MPC using HTTP requests from HA-Bridge

Just wanted to know if anyone had any documentation/ how to ect for controlling MPC though http requests?

Thanks in advance!

[kalle2000]

Hi guys,

Coming back to my Alexa Spotify project

(Play Spotify from Echo Dot output though Forked-daapd using named pipes and controlling airplay speaker connect and disconnect/ volume though MPC using HTTP requests from HA-Bridge

Just wanted to know if anyone had any documentation/ how to ect for controlling MPC though http requests?

Thanks in advance!

I dont know your setup. In case you are using FHEM for home automation, then it is very easy to use alexa (ha-bridge) and control mpd/forked-daapd via custom skills. However I would not install FHEM if this is the only use-case.

Rgds
Kalle

[ejurgensen]

I've made a new Raspbian release of forked-daapd (24.2.61). The main feature is that it restores Airplay capability to Apple TV4.

Also note that the Remote pairing process has been simplified, so that the name of the Remote is no longer required in a .remote file. Now it should just contain the PIN. If you use the pairing-helper script for pairing, make sure to get the updated script.

[madz33]

Hello I am new to forked-daapd and am having trouble connecting to the Remote app 4.3.1 on iOS. I believe I have installed everything properly, and the pairing detects my phone, but when I run the pairing helper script I receive the following output.

Code: Select all

sudo sh pairinghelper.sh
This script will help you pair Remote with forked-daapd
Please verify that these paths are correct:
  Log file: '/var/log/forked-daapd.log'
  Library:  '/home/pi/Music'
Confirm? [Y/n] y
Please start the pairing process in Remote by selecting Add library
Press ENTER when ready...
Looking in /var/log/forked-daapd.log for Remote announcement...found
Ready to pair Remote 'Alex's iPhone', please enter PIN: 4207
Writing pair.remote to /home/pi/Music...
Waiting for pairing to complete (up to 20 secs)...
forked-daap doesn't appear to be finding /home/pi/Music/pair.remote...
Check /var/log/forked-daapd.log, removing pair.remote

Upon examining the log file, there are a few reoccurring statements regarding the pair.remote file and I'm not sure how to resolve this issue.

Code: Select all

remote: Discovered remote 'Alex's iPhone' (id 7398AA3C-8A13-4A45-97D4-75E2D86077BC) at 10.0.1.13:63827, paircode 17B38C13569A934D

remote: Invalid Remote pairing file /home/pi/Music/pair.remote: device name too long or missing pin

remote: Empty Remote pairing file /home/pi/Music/pair.remote

When I run the script, I can see the pair.remote file created in the Music directory and when I open the file the PIN is indeed written there as I typed it into the console prompt, so I think the problem is in the line

Code: Select all

forked-daap doesn't appear to be finding /home/pi/Music/pair.remote...

But I am not sure why I wouldn't be able to find it, when it had just written it there directly. Any help would be appreciated.

[ejurgensen]

Looks like you are using the new version of the pairing-helper script with an older version of forked-daapd. Solution: Upgrade forked-daapd (see original post in this thread) or use an older script.

[kalle2000]

@ejurgensen

Were you already able to get hold of iOS11 beta? I understood it will come with an API to Apple Music and support of AirPlay2.

[ejurgensen]

No, I haven't tried it. Right now forked-daapd doesn't really have any interaction with iOS, so not sure what you are thinking of? Airplay2 could be interesting on the speaker side, but I haven't looked into that either.

[kalle2000]

No, I haven't tried it. Right now forked-daapd doesn't really have any interaction with iOS, so not sure what you are thinking of? Airplay2 could be interesting on the speaker side, but I haven't looked into that either.

Support of AppleMuic (MusicKit) would be great (similar to Spotify). Since MusicKit has access to the the music uploaded into the iCloud Music Lib, network shares might not be needed anymore.