Improved forked-daapd (iTunes server)

[chme]

There is already an open issue at https://github.com/ejurgensen/forked-daapd/issues/202

And some initial investigation was done. Unfortunately the work was never finished.

[boaty]

Thanks both. Afraid I'm not technically minded enough to offer much help here.

https://1drv.ms/f/s!AqwKbzP_wMJJgrlVvfDtdHrNWN7wqA

Link to instruction manual here but I doubt it's much help. Quite a basic product (though several together playing perfectly in sync is nice!) with no manufacturer support.

I'll keep an eye on this forum in case there are any developments but I can cope without this feature. Thanks

[ejurgensen]

That's a nifty little speaker, I wish I needed one so I could defend shelling out the money

[cdlenfert]

Question 1:
When I shuffle my songs, is it possible to get forked-daapd to skip the "pipe" track if nothing is being output to it? Currently if I play to my shairport-sync speaker (on the same Pi) it fills the pipe and forked-daapd plays the pipe audio automatically (which is how it should work).

My goal is to be able to leave my library shuffled and playing for hours without need of intervention from me. When I shuffle and repeat eventual the "pipe" comes up in the list and plays nothing until I manually skip to the next track.

Sidenote: When I want to skip from the pipe to the next track I have to do it via the iOS Remote app because my MPD client for my Pebble watch can't make the connection to forked-daapd while the pipe is playing. As soon as I go to a real song my controls come back. I'm curious if I set shairport-sync to send metadata to the pipe as well if that will let the Pebble MPD client connect when a pipe is playing.

Question 2:
Is there any way to get volume leveling in forked-daapd? I have some low quality (low bitrate) songs that I really love, and some high bitrate songs that I don't want to downgrade to match the low quality songs. When forked-daapd plays a low quality song, it's very quite so I turn up the volume, then a high quality song comes on and it's blasting out of the speaker. Any way to keep these songs at a more even volume?

[ejurgensen]

In general it might make sense to always exclude "infinite streams" (so also internet radio) when creating a queue - unless the stream is the first item. I'll look into that.

I can't figure out why mpd would not be responding during pipe playback, perhaps @chme has an idea about that?

I think there are ways of normalizing volume which entails using tools like ffmpeg to set volume parameters in the source files. I don't have any experience with it, but perhaps if you research "replaygain" and "ffmpeg" you can find a solution.

[cdlenfert]

Thanks for the info. I'd certainly welcome the "no infinite streams in a queue" feature.

I also wanted to add that as of late forked-daapd has performed much more reliably on my Pi Zero W than it did in past versions. So much so that I'm holding out on upgrading to a Pi3. So thanks!

[andysilch]

Hi,

I have read post pages 50 - 53 but cannot find a solution.

I am trying to sudo apt-get update (or ... install forked-daapd) on a RPi 3 Model B running 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux. It seems to be trying to update / install http://www.gyfgafguf.dk/raspbian/jessie ... _armhf.deb. When I wget this file it is html saying "<title>301 moved permanently</title>". I have tried a wget on forked-daapd_25.0.65.git8d043dd_armhf.deb but same result. The only "help" is a point to this topic. Where do I go to get a RPi package for forked-daapd?

Thanks, Andy.

[ejurgensen]

It's best to do like it says in the very first post of this thread, i.e. add the repository to your /etc/apt/sources.list. If you install the .deb you won't get updates with apt upgrade.

Make sure you have the right the link/line. As you can see in the first post, it should be:
deb http://www.gyfgafguf.dk/raspbian/forked-daapd/ jessie contrib

[chme]

Question 1:
When I shuffle my songs, is it possible to get forked-daapd to skip the "pipe" track if nothing is being output to it? Currently if I play to my shairport-sync speaker (on the same Pi) it fills the pipe and forked-daapd plays the pipe audio automatically (which is how it should work).

I think, this is a good case for a smart playlist (https://github.com/ejurgensen/forked-da ... SMARTPL.md). Something like the following excludes the pipe (data_kind for pipes is "pipe"):

Code: Select all

"Local music" {
  data_kind is file
  and media_kind is music
}

Sidenote: When I want to skip from the pipe to the next track I have to do it via the iOS Remote app because my MPD client for my Pebble watch can't make the connection to forked-daapd while the pipe is playing. As soon as I go to a real song my controls come back. I'm curious if I set shairport-sync to send metadata to the pipe as well if that will let the Pebble MPD client connect when a pipe is playing.

No clue, why the pipe playback interferes with the mpd client. I will try to reproduce this issue, but if you could get a debug log, that would be great.

[ejurgensen]

@cdlenfert, I think @chme's suggestion on how to accomplish this is much better than the filtering I was thinking about. With a smart playlist you can control the queue content better, e.g. exclude genres you don't think belong and exclude podcasts/audiobooks etc.

[IBM Portable PC]

I've had Forked-DAAPD working for a while now, however, no matter what I try I cannot label streams as I would like to see them in Apple Remote.

#EXTM3U
#EXTINF:-1,Aloha Joe - Relaxation Island
http://s2.voscast.com:7932;

For example, the above stream plays, however only shoutcast metadata is used to name the stream i.e. Aloha Joa - Relaxation Island is ignored. The same issue occurs with my other streams also.

I have also tried exporting the playlist from iTunes in various formats: m3u,m3u8,xml and txt. Interestingly, iTunes exports files in a "Classic Mac" format with CR's but not LF's at the end of each line. Even after correcting this in Text Wrangler, there is no change.

Any thoughts?

[ejurgensen]

Yes, Shoutcast metadata wins over the m3u tags. I don't recall have changed this, I think it has been that way for quite some time. Did you notice from what version you have noticed a change?

In relation to which metadata gets used, the format of the m3u doesn't matter, so I don't quite understand the latter you wrote? Perhaps I have misunderstood the issue?

[cdlenfert]

Thanks @chme. The smart playlist seems to have done the trick. As for why the mpd client on the Pebble can't skip the empty pipe. Well.. it shouldn't be much of an issue now that I won't be "accidentally" playing the pipe. But I did a quick test to see what gets captured in the log when I load the empty pipe:

Code: Select all

[2018-01-23 03:47:52] [  LOG]   player: Source is not providing sufficient data, temporarily suspending playback (deficit=188)

My experience with streaming (internet radio) stations through forked-daapd has always been that if I pause it, the station is no longer in queue. The iOS Remote app jumps back to the list of stations, the MPD Pebble client becomes unresponsive. I can't simply hit play to start the stream again. I have to "launch" the station again, and of course the Pebble client can't browse the library, so it becomes useless until I manually start the stream again. Maybe it works the same way with the pipe?

I can also confirm that as long as the pipe is full I can play/pause from the Pebble just fine. It only locks up when it's an empty pipe.

Sidenote: When I want to skip from the pipe to the next track I have to do it via the iOS Remote app because my MPD client for my Pebble watch can't make the connection to forked-daapd while the pipe is playing. As soon as I go to a real song my controls come back. I'm curious if I set shairport-sync to send metadata to the pipe as well if that will let the Pebble MPD client connect when a pipe is playing.

No clue, why the pipe playback interferes with the mpd client. I will try to reproduce this issue, but if you could get a debug log, that would be great.

[fabio1299]

I'm having a problem understanding how the playlists work in forked-daapd.

My installation is on a RPI3 works just fine (plays to my airplay and chromecast devices, which is really great!). However I can't get any playlists to show on my iOS remote.

I have copied the "iTunes Music Library.xml" from my iTunes library.
The file was read during the first scan and the libraries did display in the Remote app at first, but disappeared after the first reboot.
If I manually rescan the library, even though the "iTunes Music Library.xml" is still there, it is not read again.
I tried using an m3u file, but I can't get the system to read it... I think I probably have the file in the wrong place in the forked-daapd directory structure (did try different locations without any success)

I'm wondering if there is a tutorial/example that outlines all the steps of creating a playlist and loading it to forked-daapd. Ideally this could have the typical forked-daapd directory structure and the location of the various files.

Many thanks.

[ejurgensen]

I looked at it and noticed a few problems in the iTunes XML code, so it is most likely a bug in forked-daapd. I'm a making a few fixes. It is unlikely you are placing the file in the wrong location, since forked-daapd moniters all subdirs that are in the tree under your library directory.

1. What does the log say about the playlist if you restart forked-daapd? It probably says something about "Unchanged iTunes XML found". That is probably also what it says when you manually scan, right?
2. I expect "mpc lsplaylists" also does not list the playlists you expect - is that correct?

I'm not sure why m3u's wouldn't be working. Does the log reveal anything? It should say when it sees them and starts scanning them.

(note: you are welcome to share snippets of your log, but if so please keep them short)

[fabio1299]

Many thanks @ejurgensen for coding and maintaining this great tool and for your quick answer.
I did a bit more investigation and I did manage to import the m3u. It was actually in the wrong place because I had also changed the setting for the "directories" parameter (trying too many things at once is never the best approach to debugging... )
Indeed the log file shows that the .xml file is unchanged thus is skipped.
The strange thing is that at an early stage of the deployment of the service the log reports 12 active playlists:

Code: Select all

[2018-01-24 18:43:36] [  LOG]       db: Now vacuuming database, this may take some time...
[2018-01-24 18:43:42] [  LOG]       db: Database OK with 4836 active files and 12 active playlists

Then scans the 4800+ files and reports that the iTunes XML is unchanged:

Code: Select all

[2018-01-24 18:44:21] [  LOG]     scan: Unchanged iTunes XML found, not processing '/media/pi/MC128GB/iTunes/iTunes Media/iTunes Music Library.xml'

If I do an immediate rescan after that I get:

Code: Select all

[2018-01-24 18:53:53] [  LOG]       db: Now vacuuming database, this may take some time...
[2018-01-24 18:53:57] [  LOG]       db: Database OK with 4836 active files and 6 active playlists

And then again the notice that the iTunes xml is unchanged...
I can delete the xml rescan and put it back and I still get no playlists.

[andysilch]

@ejurgensen

Thanks for the reply - sorry for the late update.

Yes, I have corrected my sources.list and apt-get update now seems to complete. However I now get

W: GPG error: http://www.gyfgafguf.dk jessie InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY F62793319870F4F5

I presume this is just a warning and that I am safe to continue.

Thanks for your help, Andy.

It's best to do like it says in the very first post of this thread, i.e. add the repository to your /etc/apt/sources.list. If you install the .deb you won't get updates with apt upgrade.

Make sure you have the right the link/line. As you can see in the first post, it should be:
deb http://www.gyfgafguf.dk/raspbian/forked-daapd/ jessie contrib

[ejurgensen]

If you added the repository key you shouldn't be getting this message.

[ejurgensen]

@fabio1299, I believe I have the iTunes XML bugs you found fixed on github now. I'll see if I can make an update of my RPi package with the fix within a weeks time.

[fabio1299]

Thanks @ejurgensen.

I've been trying a few more things:

• I found some character encoding incompatibility between iTunes/MacOS and forked-daapd/Raspbian. The accented characters in MacOS seem to be composite characters whereas in Raspbian they are precomposed characters. This affects the playlists import even when I use m3u (I get all my playlists, but with only one song in them). To properly import m3u playlists generated with iTunes on MacOS I have to "clean" them with Clementine on the Raspberry. Once I do the cleaning in Clementine, forked-daapd imports them without issues.

• I'm not fully clear if I need to edit the path names of the songs in the m3u export file. At times it seems to work without editing and some times it does not. However I still need to do a little bit of testing on this.

• Some of the cover art from my iTunes library did not import. Haven't had the time to look into this, but I was wondering if you are aware of situations in which the covers shown in iTunes do not transfer to forked-daapd

I also have a more general question regarding the interaction between forked-daapd and the iOS Remote app: when I connect to iTunes I'm able to create/edit playlists directly from the remote. I don't have that functionality when I connect the forked-daapd, and was wondering whether there is a specific limitation that makes implementation of the function impossible or if it just a development decision on your part not to tackle this aspect?

Many thanks.

[ejurgensen]

I found some character encoding incompatibility between iTunes/MacOS and forked-daapd/Raspbian. The accented characters in MacOS seem to be composite characters whereas in Raspbian they are precomposed characters. This affects the playlists import even when I use m3u (I get all my playlists, but with only one song in them). To properly import m3u playlists generated with iTunes on MacOS I have to "clean" them with Clementine on the Raspberry. Once I do the cleaning in Clementine, forked-daapd imports them without issues.

Not sure I completely understand this. If you have example, especially one I can reproduce, it would be great.

I'm not fully clear if I need to edit the path names of the songs in the m3u export file. At times it seems to work without editing and some times it does not. However I still need to do a little bit of testing on this.

You shouldn't need to edit the paths, but if there is a char encoding problem perhaps the filename matching won't work.

Some of the cover art from my iTunes library did not import. Haven't had the time to look into this, but I was wondering if you are aware of situations in which the covers shown in iTunes do not transfer to forked-daapd

Yes, I have heard about that before. The reason is that iTunes saves some artwork in its own database, not in the media file itself.

I also have a more general question regarding the interaction between forked-daapd and the iOS Remote app: when I connect to iTunes I'm able to create/edit playlists directly from the remote. I don't have that functionality when I connect the forked-daapd, and was wondering whether there is a specific limitation that makes implementation of the function impossible or if it just a development decision on your part not to tackle this aspect?

Not impossible, the reason is simply that no-one ever added this capability to forked-daapd.

[fabio1299]

ejurgensen wrote:
Sun Jan 28, 2018 4:14 pm

fabio1299 wrote: ↑
Sun Jan 28, 2018 2:01 pm
I found some character encoding incompatibility between iTunes/MacOS and forked-daapd/Raspbian. The accented characters in MacOS seem to be composite characters whereas in Raspbian they are precomposed characters. This affects the playlists import even when I use m3u (I get all my playlists, but with only one song in them). To properly import m3u playlists generated with iTunes on MacOS I have to "clean" them with Clementine on the Raspberry. Once I do the cleaning in Clementine, forked-daapd imports them without issues.

Not sure I completely understand this. If you have example, especially one I can reproduce, it would be great.

For instance, I have an entry in my library for the file:
..../Maria Callas/Madama Butterfly/12 Già il Sole.mp3
the entry is the same both in my iTunes and in my forked-daapd library.

However when I check the UTF-8 encoding using:

Code: Select all

echo -n "à" | od -An -tuC 

on the Mac I get:

Code: Select all

97 204 128

whereas on the RPI I get:

Code: Select all

195 160

The first is the composite character created using the Unicode "COMBINING GRAVE ACCENT" with the basic "a", whereas the secodn is the preformed ASCII code 0xE0 (or 224).

Opening the m3u file with Clementine on the RPI allows me to edit and replace the wrong entries with the correct ones.
The same can also be done with a simple text editor, but using Clementine provides a visual of the errors and makes them easier to identify.

[rambuster]

Hello

i try to build up some smart playlists which make use of the "grouping" field. unfortunately i havent been able to successfully query the desired songs in my songs.db.
The point seems to be that the data isnt even been read from the file:
* when i observe forked-daapd.log when rescanning the library, i see the update-statements which do not carry a value for the grouping tag (value is NULL)
* when i manually update some records with values for the grouping-field, the smart playlists show the respective tracks).

Since december 2016 iTunes seems to have changed their sw to write their "grouping" info to the GRP1-Tag instead of the TIT1-tag from former days (see https://forums.mp3tag.de/index.php?showtopic=21878 for reference). Did anyone from the forked-daapd maintainers pick that up and update the code? when i have been researching on this i havent been able to manage to get the info across in any way (i also tried to rewrite the tags into TIT1 which didnt seem to work out as well) so i am a bit lost on how my .mp3s should look like to provide grouping info to the scanner.

Can someone please look into this? I learned that support for grouping had been implemented before so that i hope it is only a smal change...?
Forgot to mention, forked-daapd version is 25.0

Thanks in advance!
Olaf

[ejurgensen]

@fabio1299 I tried making a m3u in iTunes/Windows with a selection of files with special characters, and they were all imported ok. Maybe the problem requires MacOS to reproduce? I think you also mentioned that only one item in the playlist got imported, I also cannot see what could cause that. If you set the log level to debug you should be able to see in the log how each item in the playlist gets processed (and please don't paste all of it here...).

@rambuster can you try running "ffprobe" on one of the files and see if the grouping field is found, and what it is called? As far as I can tell the grouping field should be set provided ffmpeg finds it.

[rambuster]

Hello ejuergensen

thanks for picking it up. i have examined a reference file with several tools (strings, ffprobe, id3v2), the grouping info should be "party":

Code: Select all

prompt>$ strings 11\ -\ You\'re\ So\ Real.mp3 | head -20
TALB
TPE1
TPE2
TENC
TCON
TLEN
181306
TMED
TIT2
TRCK
11/12
TYER
2002
MCDI
GRP1
party
Xing
"%'),.257:<?BDGIKNPSVX[]_cehjmosuxz}

Code: Select all

prompt>$ ffprobe 11\ -\ You\'re\ So\ Real.mp3
ffprobe version N-85386-gd14a1bd Copyright (c) 2007-2017 the FFmpeg developers
  built with gcc 4.8 (Raspbian 4.8.2-21~rpi3rpi1)
  configuration: --arch=armel --target-os=linux --enable-gpl --enable-libx264
  libavutil      55. 60.100 / 55. 60.100
  libavcodec     57. 92.100 / 57. 92.100
  libavformat    57. 72.100 / 57. 72.100
  libavdevice    57.  7.100 / 57.  7.100
  libavfilter     6. 84.100 /  6. 84.100
  libswscale      4.  7.100 /  4.  7.100
  libswresample   2.  8.100 /  2.  8.100
  libpostproc    54.  6.100 / 54.  6.100
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
    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

Code: Select all

prompt>$ id3v2 -l 11\ -\ You\'re\ So\ Real.mp3
id3v1 tag info for 11 - You're So Real.mp3:
Title  : You're So Real                  Artist: Matchbox Twenty
Album  : More Than You Think You Are     Year: 2002, Genre: Pop (13)
Comment:                                 Track: 11
id3v2 tag info for 11 - You're So Real.mp3:
TALB (Album/Movie/Show title): More Than You Think You Are
TPE1 (Lead performer(s)/Soloist(s)): Matchbox Twenty
TPE2 (Band/orchestra/accompaniment): Matchbox Twenty
TENC (Encoded by): Encoded with FreeRIP
TCON (Content type): Pop (13)
TLEN (Length): 181306
TMED (Media type): CD
TIT2 (Title/songname/content description): You're So Real
TRCK (Track number/Position in set): 11/12
TYER (Year): 2002
MCDI (Music CD identifier):  (unimplemented)
GRP1 ():  frame

From my point of view, it seems like the tag and its content is technically "there" (see strings), id3v2 sees the tag but cannot see its content and ffprobe has no idea at all about it...?
The grouping tag on the file has been tagged with mp3tag, and the tag content can be seen both by mp3tag as well as iTunes in the correct fields (GROUPING).

According to the ID3v2.3.0 specification, GRP1 isnt included in the standard (TIT1 (content group description) seems to be the tag that should be used), whereas mp3tags website claims GRP1 would be included...
i could live with a solution where i have to rewrite the tag from GRP1 to TIT1 but i would really appreciate to know what forked-daapd expects to fill its grouping field...

Does that bring us anywhere?