Improved forked-daapd (iTunes server)

[ejurgensen]

The media file engine of forked-daapd is ffmpeg, so if it is not able to get the fields then forked-daapd won't either. Going by this it looks like it can read TIT1, but not GRP1? How does that match with what you get from ffprobe?

If ffprobe has it mapped to "grouping" it should work with forked-daapd out of the box, but if ffprobe just says "TIT1" then I will need to add it here (however, maybe a good opportunity to revisit that map anyway).

[rambuster]

after manually setting TIT1 (id3v2 --TIT1=olaf <file>) the result was that ffprobe "only" saw the TIT1 tag but didnt map it:

Code: Select all

[...]
Input #0, mp3, from '11 - You're So Real.mp3':
  Metadata:
    album           : More Than You Think You Are
    artist          : Matchbox Twenty
    album_artist    : Matchbox Twenty
    encoded_by      : Encoded with FreeRIP
    genre           : Pop
    TLEN            : 181306
    TMED            : CD
    title           : You're So Real
    TIT1            : olaf
    track           : 11/12
    date            : 2002
  Duration: 00:03:01.37, start: 0.025057, bitrate: 153 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 153 kb/s
    Metadata:
      encoder         : LAME3.98r

So i guess you will have to revisit that mapping table, as you kinda expected...
EDIT: Now i have set up MP3Tag to write my values into TIT1: i am all set for an updated version of forked-daapd to collect those values into the grouping field of the database and populate my smart-playlists (those of the wife in the first place... )

[cdlenfert]

I'm coming up against an issue when running both forked-daapd and shairport-sync where shairport-sync is unable to use the mixer device because forked-daapd is currently using it.

The scenario where this happens is that I'm playing some music from my local forked-daapd library and outputing through my usb sound card. This works great. Then I decide a little later I want to stream some music from my phone (via Airplay and shairport-sync). Everything seems to go fine until the point where sound should be coming out of my speakers, and instead there is silence. I check the status of shairport-sync and get this message.

Code: Select all

shairport-sync[8557]: Failed to attach mixer

I know the mixer settings are correct, because if I reboot the Pi and start using shairport-sync first, I can Airplay to it and get sound. Also, if I go into the forked-daapd web interface (after having played music via forked-daapd) and uncheck the "My Computer"/local speaker and restart shairport-sync, I'm then also able to get sound output.

Is there an automatic way to make these two programs play nicer when switching back and forth between them, and they are both doing local output?

[ejurgensen]

I've uploaded a RPi release 66 (25.0.66) which should help with some of the above issues:
- support for id3 TIT1 (grouping) tag (+ I also added GRP1 in case a future version of ffmpeg picks it up)
- fixed iTunes XML bugs
- fixed problem with libraries on ACL filesystems
- avoid aborting immediately on certain ffmpeg errors (allows playback of some aac internet streams)

[ejurgensen]

@cdlenfert, maybe you can try changing the audio backends of forked-daapd (and maybe Shairport) to Pulseaudio? It requires some setting up, see this https://github.com/ejurgensen/forked-da ... E_PULSE.md

[rambuster]

@ejurgensen: that worked perfectly! thank you very much!

[rambuster]

OK, i have identified another issue...
originally, i have been running forked-daapd on my RaspberryPi (on wheezy) in version 24.2. When trying to solve my "grouping" problem i didnt find a way to update this version due to a lack of repositories (http://www.gyfgafguf.dk/raspbian/forked-daapd/ doesnt have a wheezy path anymore), so i installed it on my OrangePi under jessie in the most recent version.
Now i finally wanted to play one of my songs via airplay to my speakers only to find that it doesnt have any airplay speakers available...

i hope that this log snippet is useful for anything:

Code: Select all

[email protected]:~# sudo service forked-daapd restart; tail -f -n 20 /var/log/forked-daapd.log | grep raop
[2018-02-02 14:12:03] [DEBUG]     raop: Timing IPv4 port: 41025
[2018-02-02 14:12:03] [DEBUG]     raop: Control IPv4 port: 56456
[2018-02-02 14:12:03] [DEBUG]     mdns: Adding service browser for type _raop._tcp
[2018-02-02 14:12:04] [DEBUG]     mdns: Avahi Browser (_raop._tcp): no more results (CACHE_EXHAUSTED)
[2018-02-02 14:12:04] [DEBUG]     mdns: Avahi Browser (_raop._tcp): no more results (ALL_FOR_NOW)

when i checked with mzclient, i saw that they *should* be there:

Code: Select all

[email protected]:~# mzclient -t _raop._tcp
Hit ^C when you're bored waiting for responses.

*** Found name = '[email protected]', type = '_raop._tcp', domain = 'local'
*** Found name = '[email protected]', type = '_raop._tcp', domain = 'local'
*** Found name = '581FAAE9CC[email protected]', type = '_raop._tcp', domain = 'local'
*** Found name = '[email protected]', type = '_raop._tcp', domain = 'local'
^C

the respective snippet from my (working) RaspberryPi

Code: Select all

[email protected] ~ $ sudo service forked-daapd restart ; tail -f -n 30 /var/log/forked-daapd.log | grep raop
[....] Restarting DAAP/DACP (iTunes) server, support for AirPlay and Spotify: forked-daapd[  LOG]     main: Forked Media Server Version 24.2 taking off
[  LOG]     main: Built 2016-12-11 with: --enable-itunes --enable-spotify --enable-lastfm --enable-chromecast --enable-mpd --with-alsa --with-pulseaudio
[DEBUG]     main: Initialized with gcrypt 1.5.0
. ok
[2018-02-02 14:21:16] [DEBUG]     raop: Timing IPv4 port: 60113
[2018-02-02 14:21:16] [DEBUG]     raop: Control IPv4 port: 49026
[2018-02-02 14:21:16] [DEBUG]     mdns: Adding service browser for type _raop._tcp
[2018-02-02 14:21:17] [DEBUG]     mdns: Avahi Browser: NEW service '[email protected] (LibreELEC)' type '_raop._tcp' proto 0
[2018-02-02 14:21:17] [DEBUG]     mdns: Avahi Browser: NEW service '[email protected]' type '_raop._tcp' proto 0
[2018-02-02 14:21:17] [DEBUG]     mdns: Avahi Browser: NEW service '[email protected]' type '_raop._tcp' proto 0
[2018-02-02 14:21:17] [DEBUG]     mdns: Avahi Browser (_raop._tcp): no more results (CACHE_EXHAUSTED)
[2018-02-02 14:21:17] [DEBUG]     mdns: Avahi Resolver: resolved service '[email protected] (LibreELEC)' type '_raop._tcp' proto 0, host LibreELEC.local
[2018-02-02 14:21:17] [DEBUG]     mdns: Avahi Record Browser (LibreELEC.local, proto 0): NEW record 192.168.1.112 for service type '_raop._tcp'
[2018-02-02 14:21:17] [DEBUG]     raop: Event for AirPlay device Kodi (LibreELEC) (port 36666, id 102030405)
[2018-02-02 14:21:17] [ INFO]     raop: Adding AirPlay device [email protected] (LibreELEC): password: 0, encrypt: 1, metadata: 1, type Other, address 192.168.1.112:36666
[2018-02-02 14:21:17] [DEBUG]     mdns: Avahi Resolver: resolved service '[email protected]' type '_raop._tcp' proto 0, host AEX-Dach.local
[2018-02-02 14:21:17] [DEBUG]     mdns: Avahi Resolver: resolved service '[email protected]' type '_raop._tcp' proto 0, host AEX-Keller.local
[2018-02-02 14:21:17] [DEBUG]     mdns: Avahi Record Browser (AEX-Dach.local, proto 0): NEW record 192.168.1.248 for service type '_raop._tcp'
[2018-02-02 14:21:17] [DEBUG]     raop: Event for AirPlay device Dachgeschoss (port 5000, id 581faae9cc04)
[2018-02-02 14:21:17] [ INFO]     raop: Adding AirPlay device [email protected]: password: 0, encrypt: 1, metadata: 0, type AirPort Express 2 - 802.11n, address 192.168.1.248:5000
[2018-02-02 14:21:17] [DEBUG]     mdns: Avahi Record Browser (AEX-Keller.local, proto 0): NEW record 192.168.1.249 for service type '_raop._tcp'
[2018-02-02 14:21:17] [DEBUG]     raop: Event for AirPlay device Keller (port 5000, id 23dff94e2e)
[2018-02-02 14:21:17] [ INFO]     raop: Adding AirPlay device [email protected]: password: 0, encrypt: 1, metadata: 0, type AirPort Express 2 - 802.11n, address 192.168.1.249:5000
[2018-02-02 14:21:17] [DEBUG]     mdns: Avahi Browser (_raop._tcp): no more results (ALL_FOR_NOW)

do you have any clue why the new installation doesnt "see" the airplay devices? can i resolve anything there on my own?

[cdlenfert]

@cdlenfert, maybe you can try changing the audio backends of forked-daapd (and maybe Shairport) to Pulseaudio? It requires some setting up, see this https://github.com/ejurgensen/forked-da ... E_PULSE.md

Thanks @ejurgensen. I had an idea to simply set Forked-Daapd to output to the Shairport-Sync speaker. Doing this allows me to switch within a few seconds between playing audio from Forked-Daapd to sending from my phone via Airplay to Shairport-sync. I'm sure it's using more resources to do it this way, but it seems to work well and is a very easy trick.

[ejurgensen]

@rambuster, what does "avahi-browse -r -k _raop._tcp" return? I'm thinking Avahi is for some reason not picking up the mdns announcements.

[rambuster]

Code: Select all

[email protected]:~# avahi-browse -r -k _raop._tcp
+  wlan0 IPv6 [email protected]                           _raop._tcp           local
+  wlan0 IPv6 [email protected]                     _raop._tcp           local
+   eth0 IPv6 [email protected]                           _raop._tcp           local
+   eth0 IPv6 [email protected]                     _raop._tcp           local
=   eth0 IPv6 [email protected]                     _raop._tcp           local
   hostname = [AEX-Dach.local]
   address = [169.254.204.61]
   port = [5000]
   txt = ["sf=0x4" "fv=76900.11" "am=AirPort4,107" "vs=105.1" "tp=TCP,UDP" "vn=65537" "pw=false" "ss=16" "sr=44100" "da=true" "sv=false" "et=0,1" "ek=1" "cn=0,1" "ch=2" "txtvers=1"]
=   eth0 IPv6 [email protected]                           _raop._tcp           local
   hostname = [AEX-Keller.local]
   address = [169.254.74.35]
   port = [5000]
   txt = ["sf=0x5" "fv=76900.11" "am=AirPort4,107" "vs=105.1" "tp=TCP,UDP" "vn=65537" "pw=false" "ss=16" "sr=44100" "da=true" "sv=false" "et=0,1" "ek=1" "cn=0,1" "ch=2" "txtvers=1"]
=  wlan0 IPv6 [email protected]                     _raop._tcp           local
   hostname = [AEX-Dach.local]
   address = [169.254.204.61]
   port = [5000]
   txt = ["sf=0x4" "fv=76900.11" "am=AirPort4,107" "vs=105.1" "tp=TCP,UDP" "vn=65537" "pw=false" "ss=16" "sr=44100" "da=true" "sv=false" "et=0,1" "ek=1" "cn=0,1" "ch=2" "txtvers=1"]
=  wlan0 IPv6 [email protected]                           _raop._tcp           local
   hostname = [AEX-Keller.local]
   address = [169.254.74.35]
   port = [5000]
   txt = ["sf=0x5" "fv=76900.11" "am=AirPort4,107" "vs=105.1" "tp=TCP,UDP" "vn=65537" "pw=false" "ss=16" "sr=44100" "da=true" "sv=false" "et=0,1" "ek=1" "cn=0,1" "ch=2" "txtvers=1"]

[ejurgensen]

Those addresses are link-local, I am guessing the real addresses of the speakers are not 169.254.x.x? It is also odd that they are marked as IPv6.

I can't explain why Avahi isn't picking up the correct addresses. You can try assigning the speakers static IP addresses and see if that helps, even if it is not really a good solution.

[rambuster]

@ejurgensen
i figured it out (sort of). it turns out that i hasnt been a matter of configuration rather than a matter of connectivity. my raspi is attached to my central switch in the cellar with a direct connection (incl. broadcasts) to the airplay devices. the orangepi, however, has been attached to my airport extreme in the living room (that makes manual interaction easier than having to run down and up again just to replug a cable etc).

after digging around and especially after finding a hint here

mDNS uses a multicast address that is “administratively scoped”, meaning the packets will not travel across subnets

i took my orangepi down in the cellar and attached it to my switch as well, and sure enough forked-daapd is now perfectly capable of streaming to my airplay speakers... i dont really get why this happens because since all of my devices are placed in the same subnet, that shouldnt matter much, but if i assume that mdns packets will also not travel across routers, that would be the explanation... (maybe some networking guy can confirm or correct this, but for now thats what i observe and after all i have a working configuration anyway. since fiddling possibilities on airplay extremes/expresses are really (really ) limited, i think i'll leave it like this...)

Thanks anyway for looking into this, maybe you can include a hint to this finding in the airplay section of the docs...

[sirprancelot]

Hi all,

I have a really potentially stupid question but one that I didn't find an immediate answer to while scouring for info having just setup Forked-Daapd on my pi. Is it possible to have a thumbnail/image for playlist I make? I can see you can have them for radio urls. I tried making a thumbnail the same name as playlist and in the same folder but it's not showing in itunes. I've tried everything I can think of to get it showing. Should it be of a certain size for it to work? Or I am trying the impossible? Any assistance would be greatly appreciated. It's such a small thing but it would please me no end to have a picture showing up in the playlist in itunes. Other than that Forked-Daapd looks great. Many thanks for the development of it!! Cheers!

[ejurgensen]

Not a stupid question at all! In fact I think you are the first to ask it.

I looked into it, and I'm not sure how iTunes decides what to use as playlist thumbnail. When you select a playlist it does not make any requests to forked-daapd, so it would seem that it has already decided that there is no thumbnail for the playlist. That might simply be because DAAP doesn't support that concept (?), or because some previous request told iTunes that there was no thumbnail. Don't know which of those it is...

[obie1kanobie]

Kudos to ejurgensen !!!
forked-daapd is lightyears ahead of the server on the NAS that I just bought.

I rebuilt the source for ubuntu. It works very well, but if I have two files by the same name in two different directories, and a playlist in each directory that lists that file, it fails to import the file (in both directories):

[2018-02-13 01:50:21] [ LOG] scan: No file in the library matches playlist entry 'AAA.mp3'

The songs are available (by artist, album etc) in iTunes; they just are not in the playlist.

Again - great work on this software. Much appreciated.

[ejurgensen]

How is the entry listed in the playlist - just with filename or with a path? Even with a partial path forked-daapd should be able to find the right file. Example:

File A: /foo/bar/dir1/AAA.mp3
File B: /foo/bar/dir2/AAA.mp3

If the playlist only has "AAA.mp3" then forked-daapd cannot determine the right file. But if it has "dir1/AAA.mp3", "/foo/bar/dir1/AAA.mp3" or even "/some/else/dir1/AAA.mp3" the right file should be found.

[obie1kanobie]

@ejurgensen Yes filename only. So looks like that is used as a db key, and duplicates won't work.
Thanks for your help. Again, love the software!

[marioscube]

I have a question, maybe it's been asked and answered before but I could not find it.

Sometimes I want to play some music from my forked-daapd library but all my airplay devices are shut down (mainly for energy conservation reasons). I have a simple speaker set attached to the device(s) that runs forked-daapd (sometimes a Raspberry Pi with raspbian jessie, sometimes a Debian Jessie server.

The problem is that I cannot start music playing with forked-daapd when using my iPad as a remote. There is simply no devise to choose from. Only when I startup an airplay device I can choose for local speakers.

My question: is it possible to play music from local speakers (with forked-daapd even when there is no airplay device present on the LAN? And is so how? Or did I miss something?

Thank you for forked-daapd, an excellent piece of software!

[ejurgensen]

Do you mean have the audio play from the audio output of the RPi? That should actually work out of the box, the speaker will be named "Computer", and forked-daapd by default uses ALSA for this. Note that the audio quality of the RPi 1 and 2 is really poor. Don't know about 3.

forked-daapd should also be able to start playback with no output selected at all.

[marioscube]

@ejurgensen

You are right (off course).

Yesterday evening I tried an tried, but could not make it work.
Today I tried again, and it worked on the first try! I do not know what went wrong yesterday, but I'm happy now.

The Raspberry Pi has, as far as I know, the same internal sound chip as the 2 older ones. But I was thinking about using a USB DAC or an add on sound card to connect to an amplifier or receiver i might buy in the future. (They are cheaper without Airplay connectivity).

[claptondeep]

First of all, thanks very much for the development of forked-daapd and the continued support. I’ve got an external HD hooked up to my Pi which contains my digital music collection. I hope to be able to use this as a music library which I can access over the network with iTunes on my MacBook. I’ve got forked-daapd installed and running successfully and my library has been scanned and is appearing on the web console. How do I get iTunes to see this library and access the songs on my MacBook? I assumed that it would appear automatically but I can’t seem to see the Pi as a server in iTunes.

[darealdsisaac]

So I can't seem to get this to work. MPD or pulseaudio seem to be the problem, but i'm not sure what to do. The webserver doesn't show up, so I can't go there. I'll put the (seemingly) important parts of the log below.

[2018-02-19 20:19:44] [ LOG] laudio: Pulseaudio failed with error: Connection refused
[2018-02-19 20:19:44] [ LOG] laudio: Error initializing Pulseaudio: Connection refused
[2018-02-19 20:19:44] [ LOG] mpd: Could not bind to port 6600, falling back to IPv4
[2018-02-19 20:19:44] [ LOG] mpd: Could not create connection listener for mpd clients on port 6600
[2018-02-19 20:19:44] [FATAL] main: MPD thread failed to start
[2018-02-19 20:19:44] [ LOG] main: HTTPd deinit
[2018-02-19 20:19:45] [ LOG] scan: Bulk library scan completed in 1 sec
[2018-02-19 20:19:45] [ LOG] lib: Library init scan completed in 1 sec (0 changes)
[2018-02-19 20:19:45] [ LOG] main: Player deinit
[2018-02-19 20:19:45] [ LOG] main: Library scanner deinit
[2018-02-19 20:19:45] [ LOG] main: Cache deinit
[2018-02-19 20:19:45] [ LOG] main: Worker deinit
[2018-02-19 20:19:45] [ LOG] main: Database deinit
[2018-02-19 20:19:45] [ LOG] main: mDNS deinit
[2018-02-19 20:19:45] [ LOG] main: Exiting.

[ejurgensen]

Well it looks like you may have something else listening on port 6600? Maybe Mopidy or mpd itself? You could try disabling mpd or changing the mpd port in forked-daapd's config.

[ejurgensen]

I've released build 67 for RPi, which is a release that is equal to version 26.0 of forked-daapd. The purpose is mainly to align versions, but the new build also has new JSON API endpoints for outputs.

[cdlenfert]

forked-daapd should also be able to start playback with no output selected at all.

I understand what you're saying here, and it's how I'm able to access the MP3 stream without selecting any of my outputs. This made another question come to my mind though. Is it possible to have forked-daapd start without any music/playlist/whatever already selected? For example, when I'm listening to a radio stream and stop the music, then forked-daapd has nothing selected and the remote app goes from the "now playing" screen back to the "library" screen where I browse to pick the next track. I have 1 smart playlist that I almost exclusively listen to, and it would be great to just hit play from my mpd client (a pebble app in my case) and have it either a) start where it left off (which it will already do), or b) start a default playlist if no music is currently selected or "now playing".

Is this a possibility?