marco79
Posts: 6
Joined: Sat Jan 05, 2019 4:45 pm

Re: Improved forked-daapd (iTunes server)

Fri Aug 23, 2019 3:03 pm

:arrow: First of all a big "Thank you" for this wonderful piece of software!

I installed it without any problems on a Raspberry Pi 4 with the latest Raspbian (Buster). It detects all my AirPlay speakers (also older AirPlay 1 speakers like Sony SA-NS310!) and plays multiroom without interruptions! Don't know how you did it but it's way better than my previous Mac mini/Airfoil setup (which basically does the same thing). Your REST api is also wonderful to build Siri Shortcuts actions! 8-)

I'm using it mainly to listen to flac radio streams on my Sonos setup (e.g. Radio Paradise) because the native Sonos controller can't play flac online streams (just local flac music). Out of curiosity, what exactly happens with the flac audio when you send it on-the-fly to the Airplay speakers? Is it downsampled to 44,1 kHz? Is the output format apple lossless or wav :?:

I'm also using it to play radio stations from my cable DVB-C set-top box (Enigma2/Linux based). Basically all public german radio stations are available in 320kbps (instead of 128 kbps from the online streams) but the output format is MPEG-TS MP2 (MPEG1, Layer 2) which can't be played by Sonos natively - but with forked-daapd! ;)

I tried the latest Apple Remote app on iOS 13 (beta 8) and it basically works except that the app crashes as soon as I select the Airplay targets. All other interactions work perfectly fine. It's probably a beta issue with iOS 13 and doesn't affect older versions.

Cheers,
Marco
Last edited by marco79 on Sat Aug 24, 2019 9:26 am, edited 1 time in total.

ejurgensen
Posts: 587
Joined: Thu Jul 04, 2013 8:11 pm
Location: Denmark

Re: Improved forked-daapd (iTunes server)

Fri Aug 23, 2019 8:40 pm

I've uploaded a new release of forked-daapd to the repo, it has version 26.5.83. These are the improvements:

1. Fix issue with incorrect RTP packet resend, plus possible infinite loop
2. Some fixes to playback, especially some issues that could occur at the end of a track, or where incorrect "now playing" would be displayed
3. web ui has a new icon and supports pausing streams
4. Add a delay to Chromecast playback so it starts close to Airplay/local audio
5. ICY metadata in forked-daapd's mp3 stream
6. Case insensitive directory/file listing (web ui)
7. Support for Spotify collaborative playlists

Credit to chme, whatdoineed2do and cdlenfert for contributing with the above.

@marco79 thanks for the kind words, much appreciated! And yes, Radio Paradise is excellent :-) You are right that forked-daapd will decode the flac stream and resample to 44100 if the target does not support the native sample rate. For Airplay targets that will be the case. And yes, for Airplay the samples are then alac-encoded and sent in packets.

marco79
Posts: 6
Joined: Sat Jan 05, 2019 4:45 pm

Re: Improved forked-daapd (iTunes server)

Sat Aug 24, 2019 9:50 am

Ah, cool that you know and like Radio Paradise as well. 8-)

Do you think it would be possible to add the correct metadata (album, artist, cover) for the Radio Paradise flac streams in forked-daapd?

Background:
Since a few months, Radio Paradise offers a static radio stream in flac for two different mixes:
Main Mix: http://stream.radioparadise.com/flac
Mellow Mix: http://stream.radioparadise.com/mellow-flac

There is also an api which delivers the metadata of the currently playing song, including the (remaining) time how long this song is still playing, so it's updated with each call.
Main Channel: https://api.radioparadise.com/api/now_playing?chan=0
Mellow Channel: https://api.radioparadise.com/api/now_playing?chan=1

Example Result:

Code: Select all

{  
   "time":152,
   "artist":"Jefferson Starship",
   "title":"Have You Seen The Stars Tonite",
   "album":"Blows Against The Empire",
   "year":"1970",
   "cover":"https://img.radioparadise.com/covers/l/B000002X2B.jpg"
}
I built a plugin (nodejs-based) for Volumio based on this. So all you have to do as soon as the stream starts playing is query the api, show the results in the GUI and set a timer with the length of "time" after which you query the api again (to get the next track metadata).

I know that this is a very special feature request and it's totally fine if you ignore it because it's not of any interest. But just in case, it would be a wonderful feature for all RP fans out there (including me).

Cheers,
Marco

ejurgensen
Posts: 587
Joined: Thu Jul 04, 2013 8:11 pm
Location: Denmark

Re: Improved forked-daapd (iTunes server)

Sat Aug 24, 2019 8:19 pm

As much as I like Radio Paradise, I won't add stuff that is just for one radio station. I'm not that into flac format, but I'm surprised there isn't some standard way of conveying metadata that they can use.

A possible other alternative: forked-daapd can already read metadata from a pipe, but currently it is limited to when audio is also being input that way. So a more generic solution would be to remove that limitation, and I would be open to that.

marco79
Posts: 6
Joined: Sat Jan 05, 2019 4:45 pm

Re: Improved forked-daapd (iTunes server)

Sun Aug 25, 2019 5:35 pm

OK, no prob, it was worth a try. ;)

It would be great if you could add the possibility to read just the metadata from the pipe. But no hurry. Maybe I can already play around with the pipe feature in the meantime. Do you have an example of how the pipe.metadata content has to look like (format/syntax)?

By the way I was playing a lot with forked-daapd this weekend and am still impressed about both the features and the stability :!:
I tried Spotify, LastFM, Pairing with Apple Remote and AppleTV, all kinds of radio/m3u etc. I can even control it with my Sonos remote (and therefore on the Apple Watch by using the app "Lyd"). Awesome! I built a Siri shortcut that plays an item from my playlist and asks in which rooms/players I'd like to listen to it. The REST api is really great and useful for that.

ejurgensen
Posts: 587
Joined: Thu Jul 04, 2013 8:11 pm
Location: Denmark

Re: Improved forked-daapd (iTunes server)

Sun Aug 25, 2019 9:04 pm

Sounds great!

You can read about pipes here: https://ejurgensen.github.io/forked-daapd/#library

The format of the metadata is documented here: https://github.com/mikebrady/shairport- ... ata-reader

marco79
Posts: 6
Joined: Sat Jan 05, 2019 4:45 pm

Re: Improved forked-daapd (iTunes server)

Sun Aug 25, 2019 9:24 pm

I already figured out how to write the content of a radio stream to a named pipe and it works quite easy, forked-daapd plays it automatically:

Code: Select all

mkfifo /srv/music/outpipe
ffmpeg -i http://SOME-URL/radio.mp3 -f s16le pipe:1 > /srv/music/outpipe
Now the way harder part is the metadata. The documentation from your linked reader project describes the already decoded content of the file. What I have to do is to write the metadata to the pipe. The base64 encoded content looks extremely complicated:
https://github.com/idubnori/shairport-s ... oneartwork

I think that's too complex (for me) to write a metadata writer...

marco79
Posts: 6
Joined: Sat Jan 05, 2019 4:45 pm

Re: Improved forked-daapd (iTunes server)

Mon Aug 26, 2019 10:41 am

dan_ce wrote:
Wed Oct 17, 2018 1:24 pm
Can anyone advise - I'm basically looking to use youtube-dl to download BBC Radio 4 PM every day, then stream that downloaded file using the AirPlay protocol to my old school Airport Express plugged into the back of my AudioEngine A5s. Is forked-daapd the missing link that will allow me to do this? Thanks!!
Yes, it is. I'm doing exactly this (with a daily german radio show). You don't even have to use youtube-dl and also not have to wait until the episode is available online. Just record it live by using ffmpeg and a cron job. Copy the final mp3 file to your forked-daapd library afterwards.

So here is the ffmpeg command to record a radio stream, including metadata and cover:

Code: Select all

ffmpeg -i http://bbcmedia.ic.llnwd.net/stream/bbcmedia_radio4fm_mf_p -i https://pbs.twimg.com/profile_images/842774198753918976/XyZcU3lM.jpg -c:a copy -c:v copy -map 0:0 -map 1:0 -id3v2_version 3 -metadata:s:v title="Album cover" -metadata:s:v comment="Cover (front)" -t 00:00:30 -metadata title="PM - `date +'(%a) %d-%m-%Y'`" -metadata artist="BBC Radio 4 PM" /home/pi/temp/bbc4_pm_`date +"%d-%m-%Y"`.mp3
As always with ffmpeg commands it looks complicated at first sight but it isn't that bad.
The first "-i" (input) parameter is the url of the online radio stream, in this case BBC Radio 4.
The second input is the url of a jpg for the cover in the resulting mp3 file. "-c:a copy -c:v copy" tells ffmpeg to just copy both inputs (audio and video) as they are without doing any transcoding or conversion. Afterwards the id3 tags (metadata) are defined. I'm using the date of the current day so both the title and file name look like "PM - (MO) 26-08-2019" or "bbc4_pm_26-08-2019.mp3". An important parameter is "-t 00:00:30" which tells ffmpeg to record for 30 seconds in this case and then it stops automatically. This is just for testing, you have to extend it to 1 hour (in case of BBC Radio 4 PM) or whatever fits your needs.

I'm using a shell script to run this command and this shell script is triggered by cron.

Code: Select all

crontab -l
0 17 * * 1-5 /bin/bash /home/pi/scripts/ffmpeg.sh &>/dev/null &
The cronjob is triggered from monday to friday (1-5) at 5pm (17:00). There is another cronjob which runs one hour later and moves the recorded mp3 file somewhere in my forked-daapd library. I'm doing this in two steps so that the library scanner of forked-daapd won't get triggered all the time during recording.

As soon as you come home you can then use the forked-daapd JSON api to search for the new item in your library and then play it on your desired output. I'm using a Siri shortcut for that. Of course you could just use the web gui as well. Or the command line for maximum nerdyness. ;)

Code: Select all

track="$(curl -X GET "http://forked-daapd.local:3689/api/search?type=tracks&expression=media_kind+is+music+order+by+time_added+desc&offset=0&limit=1" | jq -r '."tracks"["items"][0].uri')"
curl -X PUT "http://forked-daapd.local:3689/api/player/stop"
curl -X PUT "http://forked-daapd.local:3689/api/queue/clear"
curl -X POST "http://forked-daapd.local:3689/api/queue/items/add?uris=${track}"
curl -X PUT "http://forked-daapd.local:3689/api/outputs/set" --data "{"outputs":["101889459182266"]}"
curl -X PUT "http://forked-daapd.local:3689/api/player/play"
Cheers,
Marco

ejurgensen
Posts: 587
Joined: Thu Jul 04, 2013 8:11 pm
Location: Denmark

Re: Improved forked-daapd (iTunes server)

Mon Aug 26, 2019 12:39 pm

The format of the metadata pipe may not be as complicated as it could appear. You would create an xml document, and then have <item> structures for each kind of metadata (artist, album etc.). Each item consists of:

type -> value doesn’t matter to forked-daapd
code -> 4 byte hex that tells forked-daapd what metadata it is (artist, title etc.), see https://github.com/ejurgensen/forked-da ... ipe.c#L401
length -> ignored by forked-daapd, but I assume it is just the length of the unencoded data
data -> standard base64 encoding of the metadata

So to elaborate on "code", the hex value 61736172 equals “asar”, which is the dmap tag value that means artist name.

marco79
Posts: 6
Joined: Sat Jan 05, 2019 4:45 pm

Re: Improved forked-daapd (iTunes server)

Mon Aug 26, 2019 11:05 pm

Thanks, now I understood it somehow. :)

I successfully displayed title, album and artist via metadata pipe in forked-daapd.

But I had no success with the album art (cover). I tried to add it to the xml as well with type "ssnc", code "PICT" and the data as base64 (cat cover.jpg | base64) but it won't be displayed in forked-daapd. I also tried to add the image in the same folder as the pipe with the same name as the pipe but also with no success. Any hints on this? The shairport source code has a comment saying this is not base64?

Code: Select all

if item.type == "ssnc":
if item.code == "PICT":  # the payload is a picture, either a JPEG or a PNG. Check the first few bytes to see which.
self.info.songcoverart = CoverArt(binary=item.data, base64=item.data_base64)  # this is not base64, but raw.
By the way, my forked-daapd instance always eats up one core of my CPU (>100%) when playing around with the pipes. I have to restart the service to resolve this.

ejurgensen
Posts: 587
Joined: Thu Jul 04, 2013 8:11 pm
Location: Denmark

Re: Improved forked-daapd (iTunes server)

Tue Aug 27, 2019 8:31 am

Unfortunately forked-daapd doesn't support artwork via pipe metadata. I'll take a look at the CPU issue and see if I can get that fixed.

EckartH
Posts: 11
Joined: Sun Feb 03, 2019 12:35 pm

Re: Improved forked-daapd (iTunes server)

Sun Sep 01, 2019 12:07 pm

As you are talking about artwork. I see lots of these errors

Code: Select all

[2019-09-01 13:19:27] [  LOG]    xcode: Cannot open encoder (png): Invalid argum
ent
[2019-09-01 13:19:27] [  LOG]  artwork: Source 'embedded' returned an error for 
'Backstroke'
[2019-09-01 13:19:27] [  LOG]    xcode: Cannot open encoder (png): Invalid argum
ent
[2019-09-01 13:19:27] [  LOG]  artwork: Source 'embedded' returned an error for 
'Freeze'
[2019-09-01 13:19:27] [  LOG]    xcode: Cannot open encoder (png): Invalid argum
ent
[2019-09-01 13:19:27] [  LOG]  artwork: Source 'embedded' returned an error for 
'Collins Shuffle'
[2019-09-01 13:19:28] [  LOG]    xcode: Cannot open encoder (png): Invalid argum
ent
[2019-09-01 13:19:28] [  LOG]  artwork: Source 'embedded' returned an error for 
'Albert's Alley'
[2019-09-01 13:19:28] [  LOG]    xcode: Cannot open encoder (png): Invalid argum
ent
[2019-09-01 13:19:28] [  LOG]  artwork: Source 'embedded' returned an error for 
'Defrost'
[2019-09-01 13:19:29] [  LOG]    xcode: Cannot open encoder (png): Invalid argum
ent
[2019-09-01 13:19:29] [  LOG]  artwork: Source 'embedded' returned an error for 
'Thaw Out'
[2019-09-01 13:19:29] [  LOG]    xcode: Cannot open encoder (png): Invalid argum
ent
[2019-09-01 13:19:29] [  LOG]  artwork: Source 'embedded' returned an error for 
'Backstroke'
I have yet to find the systematics behind these, i.e. what sets these files apart from the other ones which work flawlessly.

ejurgensen
Posts: 587
Joined: Thu Jul 04, 2013 8:11 pm
Location: Denmark

Re: Improved forked-daapd (iTunes server)

Sun Sep 01, 2019 8:57 pm

@EckartH can I ask you to add an issue on my github? Please add information about the version of ffmpeg. I hope you are also able to share one of the tracks that produces the error.

@marco79 the CPU issue should be fixed in the github source repo now, and will be included in the next RPi release I make.

ejurgensen
Posts: 587
Joined: Thu Jul 04, 2013 8:11 pm
Location: Denmark

Re: Improved forked-daapd (iTunes server)

Fri Sep 27, 2019 9:03 pm

I've made a new release of the RPi build, its version number is 26.5.84.git547222e. It has:

1. Fix for CPU issue reported by @marco79
2. Support for Shairport artwork via pipe (doesn't work with web UI yet, however)
3. Configurable mp3 streaming quality
4. New JSON api for toggling speakers
5. Web UI improvements, e.g. option to show composer for now playing track

tinbert
Posts: 3
Joined: Tue Mar 19, 2019 9:03 pm

Re: Improved forked-daapd (iTunes server)

Mon Sep 30, 2019 8:04 pm

Has something changed with pipe_autostart?

I have trouble to switch between the four input pipes that I have configured to switch between four radio stations.
My setup worked for some month with a former version of forked-daapd (in March '19 on Stretch). Unfortunately I had to fresh install the Raspi with Buster.

Now with the fresh installation this problem occurs:
The first radio station is played without problems, but switching to a different station will never start playing music.

My setup:
To stream cable radio (DVB-C) from my router to my AirPlay devices, I have to use a somewhat tricky setup: there are 4 services which each run a gstreamer pipeline to read and convert a rtsp-MPEG-2-stream coming from the cable router.

Each gstreamer service writes into one pipe, which forked-daapd listens to. There are four pipes, one for each service, and before my new installation, switching pipes was no problem: one gstream was stopped (and restarted to "pause" stat), the next gstream was un-paused when the respective pipe was activated by forked-daapd.

Do you have an idea?

ejurgensen
Posts: 587
Joined: Thu Jul 04, 2013 8:11 pm
Location: Denmark

Re: Improved forked-daapd (iTunes server)

Mon Sep 30, 2019 9:22 pm

I haven't directly changed pipe_autostart, but I have made other changes to the pipe module, so it is possible that the bug comes from that.

It would be helpful if you could open an issue on github.com/ejurgensen/forked-daapd with a log extract where the log level is set to debug. That way I can see what happens. Just attach a snippet from around the time the bug occurs, so not the full log.

Until I get it fixed you can find old versions of forked-daapd here (xxx-1 is for jessie, -2 is for stretch and -3 is for buster) : http://gyfgafguf.dk/raspbian/forked-daa ... ked-daapd/

Return to “Raspbian”