Improved forked-daapd (iTunes server)

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

@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.

@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.

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


Did you get to check the cpu use?

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.

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.

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...

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.

Have you checked for clues in the log?

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?

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.'

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?

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.

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.

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

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

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!