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: 593
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: 593
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: 593
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: 593
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: 593
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: 593
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: 593
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: 593
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/

barish
Posts: 2
Joined: Thu Oct 24, 2019 8:14 am

Re: Improved forked-daapd (iTunes server)

Thu Oct 24, 2019 8:38 am

Thanks, ejurgensen, for the tons of work that went into this great project, forked-daapd, which I use every day on my Lime2, which is an A20 and thus runs fine with your armhf compilation. Right now I am working on a NAS project and chose an EspressoBin as hardware platform, which is arm64 based. I tried to compile forked-daapd from source, but it somehow messed up the whole debian (Armbian) installation. The debian package unfortunately lacks web interface and I believe spotify (and other services) support as well?
Is there any chance that you might ever offer an arm64 build on gyfgafguf.dk? If not I will certainly go through the procedure of learning to make it compile on this platform, but if it's only a flic of compiler switch for you, I would greatly appreciate it. 8-)

P.S.: I am sorry that this is slightly offtopic on the raspberry forum, though raspberry might soon need arm64, too!

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

Re: Improved forked-daapd (iTunes server)

Thu Oct 24, 2019 11:14 am

The debs in my repository are compiled natively, since I am not strong with cross-compilation. I am also not strong on the difference between Debian’s armhf and arm64, and whether there is a simple way to build arm64 packages on an RPi. So I wouldn’t know how to go about making arm64 packages.

So maybe the best would be if you can straighten your Armbian install and then build from source following the Debian instructions in the INSTALL file.

barish
Posts: 2
Joined: Thu Oct 24, 2019 8:14 am

Re: Improved forked-daapd (iTunes server)

Thu Oct 24, 2019 9:29 pm

Thanks for your quick reply!
It took me a little longer but I seem to have succeeded finally and forked-daapd:arm64 is working. In the process I found out that armhf binaries should run on most arm64 systems without a problem, only aptitude has to learn that it's allowed to use armhf packages as well:

Code: Select all

dpkg --add-architecture armhf
does the trick.

joshkinsey
Posts: 1
Joined: Sat Oct 26, 2019 1:18 pm
Location: United States
Contact: Twitter

Re: Improved forked-daapd (iTunes server)

Sat Oct 26, 2019 1:30 pm

I recently updated my macOS install to the Catalina version and discovered that the Music app included with Catalina doesn't seem to work properly with forked-daapd. iTunes was eliminated with Catalina and replaced with an app called Music. The new Music app sees the share is available but it won't actually load the shared library when you click on it. No idea if it's a Catalina issue or a forked-daapd issue.

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

Re: Improved forked-daapd (iTunes server)

Sat Oct 26, 2019 7:25 pm

Yes, Apple Music on Catalina doesn't work with current forked-daapd. However, I'm optimistic that I can fix it. You can follow progress here: https://github.com/ejurgensen/forked-daapd/issues/785

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

Re: Improved forked-daapd (iTunes server)

Wed Nov 20, 2019 8:00 pm

I've made a new release of the RPi build, it is version number 27.0.100.git5ac3a27. It has a fix for Apple Music on Catalina, but other than that the release is mostly to bring the RPi build up to version 27.0.

u_newman
Posts: 4
Joined: Sun Dec 08, 2019 9:22 pm

Re: Improved forked-daapd (iTunes server)

Sun Dec 08, 2019 9:33 pm

Hi all,

I installed forked-daapd on my Raspberry 4 (running Butcher, fresh installed) with version 27.0.

when I followed the installation guide (see "http://ejurgensen.github.io/forked-daapd/#references") I started the server and checked the status with

Code: Select all

/etc/init.d/forked-daapd status
or

Code: Select all

sudo service forked-daapd status
I see that the service failed to start:

Code: Select all

forked-daapd.service - DAAP/DACP (iTunes) and MPD server, supporting AirPlay and Spotify
   Loaded: loaded (/lib/systemd/system/forked-daapd.service; disabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sun 2019-12-08 22:09:12 CET; 3min 5s ago
     Docs: man:forked-daapd(8)
  Process: 10847 ExecStart=/usr/sbin/forked-daapd -f (code=exited, status=1/FAILURE)
 Main PID: 10847 (code=exited, status=1/FAILURE)

Dez 08 22:09:12 DAAPEasyLiving systemd[1]: forked-daapd.service: Service RestartSec=100ms expired, scheduling restart.
Dez 08 22:09:12 DAAPEasyLiving systemd[1]: forked-daapd.service: Scheduled restart job, restart counter is at 2.
Dez 08 22:09:12 DAAPEasyLiving systemd[1]: Stopped DAAP/DACP (iTunes) and MPD server, supporting AirPlay and Spotify.
Dez 08 22:09:12 DAAPEasyLiving systemd[1]: forked-daapd.service: Start request repeated too quickly.
Dez 08 22:09:12 DAAPEasyLiving systemd[1]: forked-daapd.service: Failed with result 'exit-code'.
Dez 08 22:09:12 DAAPEasyLiving systemd[1]: Failed to start DAAP/DACP (iTunes) and MPD server, supporting AirPlay and Spotify.
The log is not really helping, I set the log level to debug but the level does not seem to change (log from /var/log/forked-daapd.log):

Code: Select all

[2019-12-08 21:02:55] [  LOG]     main: Forked Media Server Version 27.0 taking off
[2019-12-08 21:02:55] [  LOG]     main: Built with:
[2019-12-08 21:02:55] [  LOG]     main: - ffmpeg
[2019-12-08 21:02:55] [  LOG]     main: - iTunes XML
[2019-12-08 21:02:55] [  LOG]     main: - Spotify
[2019-12-08 21:02:55] [  LOG]     main: - LastFM
[2019-12-08 21:02:55] [  LOG]     main: - Chromecast
[2019-12-08 21:02:55] [  LOG]     main: - MPD
[2019-12-08 21:02:55] [  LOG]     main: - Device verification
[2019-12-08 21:02:55] [  LOG]     main: - Websockets
[2019-12-08 21:02:55] [  LOG]     main: - ALSA
[2019-12-08 21:02:55] [  LOG]     main: - Pulseaudio
[2019-12-08 21:02:55] [  LOG]     main: - Webinterface
[2019-12-08 21:02:55] [  LOG]     main: mDNS init
[2019-12-08 21:02:55] [  LOG]     mdns: Avahi state change: Client running
[2019-12-08 21:02:55] [  LOG]       db: Configured to use database file '/var/cache/forked-daapd/songs3.db'
[2019-12-08 21:02:55] [  LOG]       db: Could not prepare statement: no such table: admin
[2019-12-08 21:02:55] [  LOG]       db: Could not prepare statement: no such table: admin
[2019-12-08 21:02:55] [  LOG]       db: Could not check database version, trying DB init
[2019-12-08 21:02:55] [  LOG]       db: Database OK with 0 active files and 6 active playlists
[2019-12-08 21:02:55] [  LOG]   laudio: Pulseaudio failed with error: Connection refused
[2019-12-08 21:02:55] [  LOG]   laudio: Error initializing Pulseaudio: Connection refused
[2019-12-08 21:02:55] [  LOG]     scan: Skipping library directory /srv/music, could not dereference: No such file or directory
[2019-12-08 21:02:55] [  LOG]     scan: Bulk library scan completed in 0 sec
[2019-12-08 21:02:56] [  LOG]      lib: Library init scan completed in 1 sec (0 changes)
[2019-12-08 21:12:32] [  LOG]     main: Got SIGTERM or SIGINT
[2019-12-08 21:12:32] [  LOG]     main: Stopping gracefully
[2019-12-08 21:12:32] [  LOG]     main: mDNS deinit
[2019-12-08 21:12:32] [  LOG]     main: Remote pairing deinit
[2019-12-08 21:12:32] [  LOG]     main: MPD deinit
[2019-12-08 21:12:32] [  LOG]     main: HTTPd deinit
[2019-12-08 21:12:32] [  LOG]     main: Player deinit
[2019-12-08 21:12:32] [  LOG]     main: Library scanner deinit
[2019-12-08 21:12:32] [  LOG]     main: Cache deinit
[2019-12-08 21:12:32] [  LOG]     main: Worker deinit
[2019-12-08 21:12:32] [  LOG]     main: Database deinit
[2019-12-08 21:12:32] [  LOG]     main: Exiting.
Does anybody has an idea what happened or where to check for further details?

The directory

Code: Select all

/srv/music
exists (but is empty for now).

Thanks for any hints or tips in advance!

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

Re: Improved forked-daapd (iTunes server)

Mon Dec 09, 2019 8:23 am

I think that you have multiple versions of forked-daapd installed. Both the log and the fact that changing log level doesn't work are indications of that. See this issue: https://github.com/ejurgensen/forked-daapd/issues/843

I recommend you clean up and then install forked-daapd as per the instructions in the first post of this thread.

u_newman
Posts: 4
Joined: Sun Dec 08, 2019 9:22 pm

Re: Improved forked-daapd (iTunes server)

Mon Dec 09, 2019 9:21 am

Hi @ejurgensen,

thanks for the advice. I'll try checking for a duplicate installation this evening.

Although I have to mention that I did a clean install of rapsberry and forked-daapd before running into the issue, no second re-installation, uninstall or so.

I'll come back after checking your issue guide later.

Thanks so far!

Return to “Raspbian”