jdfraser
Posts: 12
Joined: Sat May 23, 2015 5:37 am

Re: Improved forked-daapd (iTunes server)

Tue Jan 24, 2017 12:46 am

Is anyone else using last.fm to 'scrobble' their played songs? I haven't seem to have scrobbled any songs for the last month or so. I see this error in my log:

[ WARN] http: Connection to http://ws.audioscrobbler.com/2.0/ failed: no error text (error 400)

when I touch my login credentials file I see:
[2017-01-23 16:43:56] [ LOG] lastfm: lastfm credentials file OK, logging in with username j******er
[2017-01-23 16:43:57] [ LOG] lastfm: Got session key from LastFM: *cd******b**afe****addf*******dead

which seems to indicate that forked-daapd is logging in correctly. Has anyone else experienced these issues with last.fm?

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

Re: Improved forked-daapd (iTunes server)

Tue Jan 24, 2017 9:25 pm

@jdfraser, you are right, I see I recently made a change so that the requests to the scrobbling service became GET instead of POST, as they should be. Will get it fixed asap. If you don't want to wait for that you can go back to [http://www.gyfgafguf.dk/raspbian/jessie ... _armhf.deb]this version[/url], which should still be good. Release 24.2 from Github (and Debian) should also be fine.

fergalom
Posts: 3
Joined: Thu Oct 29, 2015 3:11 pm

Re: Improved forked-daapd (iTunes server)

Mon Jan 30, 2017 2:48 pm

ejurgensen wrote:Ok I think I have located the problem, it looks like it is the whitespace after the content length:
"evrtsp_get_body_length: illegal content length: 21 "

Some developer clearly should be spanked for putting that there.

I've made a fix so that the whitespace gets ignored. Please try this package: http://www.gyfgafguf.dk/temp/forked-daa ... _armhf.deb

What's the timeline for release of 24.2.59 - have the same issue also and if its soon, will wait?
Thanks

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

Re: Improved forked-daapd (iTunes server)

Mon Jan 30, 2017 10:22 pm

I expect it will be in 2-4 weeks. A lot of changes have been made upstream recently, so it depends on how many bugs show up after that.

harry303
Posts: 1
Joined: Sat Feb 04, 2017 10:38 am

Re: Improved forked-daapd (iTunes server)

Sat Feb 04, 2017 10:43 am

Hello,

I try to connect a Bluetooth device and pipe the audio input with mkfifo to forked-daapd. Pipe playback works great but isn't very comfortable. Pipe is only showing up under Albums and not as playlist.

Can this be changed? Even better would be automatic playback if pipe is in use.

Greets harry303

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

Re: Improved forked-daapd (iTunes server)

Sun Feb 05, 2017 12:26 pm

Yes, automatic playback of pipes will be in the next RPi release.

In the meantime, I suppose you could make a m3u with a path to the pipe. That way it should appear in a playlist.

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

Re: Improved forked-daapd (iTunes server)

Thu Feb 16, 2017 10:06 pm

I've released a new RPi build, this one has version number 24.2.59. This is a version with a large number of "under-the-hood" modifications, but also the following improved functionality:

- Support for automatic playback of pipes + Shairport pipe metadata (excluding artwork) - see more info here
- Improved use of Spotify web api (no more need to reauthorise after restart, "Discover weekly" playlist is again available) - credit @chme
- Better buffering of input audio and improved handling of source underruns (= stream interruptions or data arriving too slowly)
- Support for local artwork for internet radio/playlists (suggested by @mswhalley)
- Fix for lastfm scrobbling
- Fix for wrong track length metadata sent to AirPlay devices
- Fix for some queries made by TunesRemote+
- Fix for special queue case (bug reported by @TomA)
- Fix for GGMM E3 speaker/contentlength issue mentioned above

BrandonQuest
Posts: 4
Joined: Tue Feb 21, 2017 3:02 pm

Re: Improved forked-daapd (iTunes server)

Tue Feb 21, 2017 3:32 pm

Hello,

first of all: congratulations to that nice peace of software.
I have some problems with it getting it running on my Pi3, but besides that, doubts come up, that I
am running into the wrong direction using it....
I need to make sure whether it's for the purpose I have in mind:

I would like to plug in an USB-Soundcard to the Pi, to get Amazon Echo Dot's (Alexa) Audio into the Pi.

THIS I than would like to spread over my Airport-Express architecture (6 Airport-X) to hear Alexa and also
the Alexa generated music-program
(be it Spotify or Amazon Musik, and I wouldn't mind, if it also
where my music-library on the Synology NAS, but the question whether that has to be solved through Echo Dot or may
an IFTTT -triggered command by Alexa accessing than the PI....we will see)
everywhere.

So for the beginning: is it possible to get USB-Audio just spread to once fixed Airport-Expresses?
Let's say after booting or starting/configurating there are no changes needed, just stream USB to Airplay....

And if not this way, any other idea?
I am messing around with that for two days, stumbling over Volumio, Max2Play, Shaircast, now to forked-daapd.

Best Regards
BrandonQuest

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

Re: Improved forked-daapd (iTunes server)

Tue Feb 21, 2017 7:21 pm

Interesting idea. I suppose you could do something like this (with the newest version of forked-daapd, 24.2.59):

1. Make a named pipe in your forked-daapd library, let's say: "mkfifo /your/library/Echo"
2. Use arecord to get the audio from the soundcard to the pipe: "arecord -f cd -t raw > /your/library/Echo" (note: not sure if it should be -t raw or -t wav)
3. forked-daapd should now automatically start playback of the pipe - check the status with Remote or with the mpc command line tool. You can also use Remote/mpc to select the AirPlay speakers where you want the audio to be played.

However, it probably won't be quite so simple. Some things to note:
1. The above assumes you have setup your soundcard with alsa so it 1) works and 2) is the default input. That probably will require some tinkering.
2. Even when there is no audio from the Echo, "arecord" might feed silence to the pipe - I suppose that would especially be the case if the audio link to the Echo is analog. That means forked-daapd will play this silence to the AirPlay devices all the time, which might not be desirable. If the link is digital then perhaps it is possible to setup alsa or arecord to only write to the pipe when there is audio. That will solve the problem as forked-daapd should then by itself start and stop when appropriate.
3. It might be possible to configure alsa to send all audio from the soundcard to the pipe, and then you won't need to start "arecord". Perhaps also possible to use something else than alsa to write the audio to the pipe.

And finally a disclaimer: I haven't tried this, and I'm not an expert on soundcards and alsa.

RWarner
Posts: 5
Joined: Sun Jan 24, 2016 6:24 pm

Re: Improved forked-daapd (iTunes server)

Tue Feb 21, 2017 10:08 pm

I'm having a bit of trouble setting up the remote on iOS. I always get this error message when running the helper script. What am I doing wrong?

Code: Select all

ryan@CloudServer:~ $ bash helperscript.sh
This script will help you pair Remote with forked-daapd
Please verify that these paths are correct:
  Log file: '/var/log/forked-daapd.log'
  Library:  '/srv/music'
Confirm? [Y/n] y
Please start the pairing process in Remote by selecting Add library
Press ENTER when ready...
Looking in /var/log/forked-daapd.log for Remote announcement...found
Ready to pair Remote 'Ryan’s iPhone', please enter PIN: 3112
Writing pair.remote to /srv/music...
Waiting for pairing to complete (up to 20 secs)...
forked-daap doesn't appear to be finding /srv/music/pair.remote...
Check /var/log/forked-daapd.log, removing pair.remote

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

Re: Improved forked-daapd (iTunes server)

Wed Feb 22, 2017 7:33 am

@RWarner, what does the log say? And did you try the troubleshooting here:
http://ejurgensen.github.io/forked-daapd/#using-remote

BrandonQuest
Posts: 4
Joined: Tue Feb 21, 2017 3:02 pm

Re: Improved forked-daapd (iTunes server)

Wed Feb 22, 2017 10:42 am

Hello ejurgensen,

thanks for your quick reply.
Since I am totaly new to Linux/Programming, what you wrote sounded strange to me (pipe?!),
but after I googled I guess this will work.

Only question is, how I can prevent arecord from making an infinite file while listening...
I thought about a limited "buffer" to write/pipe, limited with "dd bs=441000", that would mean a 10 second file
(I will sample with 44,1kHz, because more would force a re-sampling anyway).
And to keep drive-activity low (wear of SD-Card or HD) I would write that "endless" buffer to a RAM-Drive, where than
the library for forked-daapd will be established

Threshhold-listening you mentioned could also implemented.

After hours I got now forked-daapd running, mainproblem seemed to be my wish to work on my Synology-Server
in an NFS-Directory.

forked-daapd ignored the .spotify and .remote-files I don't know why (I restarted it after every trial-step for re-scan),
but to confess: I wasn' able (still) to give forked-daapd writing-rights in that nfs Network-mounted folder.

After I've gone to "http://forked-daapd.local:3689/oauth" I could at least see playlists in Remote , but chosing a song
resulted in swiping to that song, no playback, one second later I was back in the root-screen of Remote.

But anyway, I did registering-things localy on the raspberry and changed than back to NFS.

Now sound through 1 Airport-Express per time is possible chosen by Remote.
How/where can I choose more receivers simultaneously?
Is that the step where I have to have a closer look at mentioned "mpc"?

Regards
BrandonQuest


----------------------------------------------------------
my fault: I missed the Setting in Remote for more Speakers.
Anyway, how can I configure through mpc to be more independent from Remote?

The degree of independence I have in mind: starting raspberry and after starting forked-daapb
a pre-defined set of Airport-Exp. is feeded with a pre-defined stream/playlist/audiofile.

You see, these are the basic prerequisites for the project: USB-Soundcard to Airplay :-)

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

Re: Improved forked-daapd (iTunes server)

Wed Feb 22, 2017 1:27 pm

You have a lot of questions, and it is a bit too much for me to help you with all that. Google has a lot of the answers, and also the README...

A few remarks:

- Try do this one step at a time, get that working, and then add the next challenge. If you try to do everything at once (Echo, arecord, pipes, NFS, Spotify etc.) I think you will never be able to locate where the problems you run into are. Try to first get basic forked-daapd functionality working without Spotify and with a simple, local library of music.
- Pipes are not files, they are more like buffers. You cannot fill up the filesystem by writing to them.
- A bunch of stuff doesn’t work across network file systems, among other: pipes and notifications about changed files (so your .spotify file and .remote files).
- forked-daapd does not need write access to your library.

BrandonQuest
Posts: 4
Joined: Tue Feb 21, 2017 3:02 pm

Re: Improved forked-daapd (iTunes server)

Wed Feb 22, 2017 3:32 pm

Thank you, and of course you are right, that's too much of your time.

For the moment I found out how to use mpc for choosing Airports and playing playlists.

Only thing I have problems with: I can only load playlists getting with mpc lsplaylists, so
the ones forked daapd generated,
but every try to generate or load an m3u I generarated spotting
to a particular file will fail.

I will report when I come close to the mentioned cases I had in mind.

Best Regards
BrandonQuest

BrandonQuest
Posts: 4
Joined: Tue Feb 21, 2017 3:02 pm

Re: Improved forked-daapd (iTunes server)

Sat Feb 25, 2017 6:50 pm

Ok - as promised:
Everything works now, like you suggested.
Some little problems regarding the USB Soundcard and the Pi3, but when I plug in now something into my Pi USB-Card it goes to every Airplay-Receiver I want.

Only thing is a delay of about 3 seconds I have to work on.

Regards
BrandonQuest

RWarner
Posts: 5
Joined: Sun Jan 24, 2016 6:24 pm

Re: Improved forked-daapd (iTunes server)

Sat Feb 25, 2017 10:46 pm

So I got the Remote working, i'm still not quite sure how, but that's beside the point. My next question is about my iTunes library. It is stored on a computer on the same network, I feel like there should be some way to use the Home Sharing feature (which is enabled) to share the library with the server, is this true? Second, is there any way to get rid of the background hissing?
Thanks a lot!

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

Re: Improved forked-daapd (iTunes server)

Sat Feb 25, 2017 11:27 pm

@BrandonQuest: Good to hear you made it work. I guess you now need to teach Alexa how to send commands to enable/disable speakers - that would be pretty cool :-) Note that AirPlay normally has a buffer/delay of about 2 seconds, so it will probably be difficult to improve the lag very much.

@RWarner: There is no support for Home Sharing, that is a DRM thing. To my knowledge there are no open source projects supporting it. If the background hissing is when playing local audio at low volume it is simply because the RPi built-in sound sucks! I think the only solution is to get an external sound card.

florianpfeil
Posts: 4
Joined: Mon Mar 06, 2017 5:58 pm

Re: Improved forked-daapd (iTunes server)

Mon Mar 06, 2017 6:30 pm

Hello everyone,

I'm running forked-daapd 24.2.59 and everything is working great except one thing: When I'm using iTunes Remote 4.3.1 to stream music to an AirPlay device, playback stops after the first song and forked-daapd.log shows

Code: Select all

[  LOG]   player: Source is not providing sufficient data, temporarily suspending playback
Also the Remote App does not update the time display while playing. Does anyone have some idea, what could be causing this problem?

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

Re: Improved forked-daapd (iTunes server)

Mon Mar 06, 2017 8:09 pm

Doesn't sound like it is working so great if it stops after one song... :? Does this happen no matter what song you play?

Could you set the log level to debug and try again? Perhaps that will reveal what is going on.

florianpfeil
Posts: 4
Joined: Mon Mar 06, 2017 5:58 pm

Re: Improved forked-daapd (iTunes server)

Mon Mar 06, 2017 9:02 pm

Thank you for your fast reply! I'm using it mainly as 'shared library' in iTunes, which works perfectly ;) . The error occurs independent of played song and AirPlay device. This is the interesting part of the log file with log level 'debug':

Code: Select all

[2017-03-06 21:49:11] [DEBUG]   player: Input buffer has 178364 bytes
[2017-03-06 21:49:21] [DEBUG]   player: Input buffer has 179004 bytes
[2017-03-06 21:49:31] [DEBUG]   player: Input buffer has 179644 bytes
[2017-03-06 21:49:41] [DEBUG]   player: Input buffer has 180284 bytes
[2017-03-06 21:49:50] [ WARN]    xcode: Could not read frame: Invalid argument
[2017-03-06 21:49:50] [DEBUG]    xcode: Could not read packet, will flush decoders
[2017-03-06 21:49:50] [DEBUG]   player: Playback loop stopped (break is 0)
[2017-03-06 21:49:51] [DEBUG]   player: Input buffer has 61116 bytes
[2017-03-06 21:49:52] [  LOG]   player: Source is not providing sufficient data, temporarily suspending playback
[2017-03-06 21:49:52] [DEBUG]     raop: Building TEARDOWN for 'FireTV WZ'
[2017-03-06 21:49:52] [DEBUG]      mpd: Listener callback called with event type 1.
[2017-03-06 21:49:52] [DEBUG]      mpd: Notify clients waiting for idle results: 1
[2017-03-06 21:49:52] [DEBUG]   player: Player status: paused

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

Re: Improved forked-daapd (iTunes server)

Mon Mar 06, 2017 10:04 pm

Looks like libav (the library forked-daapd uses for reading media files) isn't returning the expected "end of file" value at read end. Not sure why that is... What happens if you run "avconv -i [your media file] test.wav" and let it complete? Does it do that without any error messages?

florianpfeil
Posts: 4
Joined: Mon Mar 06, 2017 5:58 pm

Re: Improved forked-daapd (iTunes server)

Tue Mar 07, 2017 2:04 pm

avconv works without errors and produces a playable wav-file.

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

Re: Improved forked-daapd (iTunes server)

Tue Mar 07, 2017 10:03 pm

Ok, so I don't really understand why libav does not return an end of file, but even on read errors like it is returning I don't think forked-daapd should stop playback - it should instead just proceed to the next track. So I have made a test version that does that, and if you want to test it, it would be great. You can get it here.

You will likely see error messages in the log about read errors, but playback should at least work.

SBob
Posts: 4
Joined: Wed Dec 17, 2014 8:57 pm

Re: Improved forked-daapd (iTunes server)

Wed Mar 08, 2017 1:39 pm

Hi

I have been enjoying this fantastic piece of software for a long time, thanks!

My set-up is that I have one AppleTV and three Airport Express.

The problem I have is that since I updated to IOS10 the I can no longer choose any Airport Express as output in the iTunes Remote app. The only device that shows up is AppleTV.

Is it just me missing something obvious or has Apple removed the possibility to listen via Airport Express?

My apologies if this has been covered before, but I could not find any mention of it.

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

Re: Improved forked-daapd (iTunes server)

Wed Mar 08, 2017 5:07 pm

It is possible that Apple has made an update that has broken something. Whenever they update I am nervous of that. I will try to get hold of an ApEx to test and see if functionality can be restored.

FYI it is not likely that the cause is the update of iOS or Remote. Remote just gets a list of devices from forked-daapd and cannot know what type they are. So if they are not in the list, it means forked-daapd is not finding the expected type of announcement from the ApEx's. The cause of that is probably that the ApEx's got updated. You can see in forked-daapd's log if the ApEx's are detected. On normal log level there will be a message, and I am guessing there is none about these devices.

Return to “Raspbian”

Who is online

Users browsing this forum: No registered users and 29 guests