After a certain length of time (30 minutes or so, I think), a DAAP stream will time out. For example, pause a stream playing via Rhythmbox or Banshee. Attempt to resume playback 30 minutes later. It will fail. The only way to resume playback is to disconnect from the DAAP server and reconnect. At that point, the prior playback position has been lost.
Is it possible to add a keepalive or timeout that could be controlled via a parameter in forked-daapd.conf?
This might require a client fix instead/as well.
Could you ask Rhythmbox or Banshee if they make any attempt to tell the server they are still using the connection?
I take your point, but FWIW iTunes exhibits the same behaviour. I get the feeling Apple would be less than accommodating.
Should be fixed in forked-daapd v0.13
when playing music with iTunes 10.2.1 on a Mac, it gets disconnected from forked-daapd after 30 minutes (exactly 30 minutes from the moment iTunes is connected to the playlist, no matter if I play music or not).
I've tried with forked-daapd 0.14-1 and 0.15-1 on debian.
I didn't had the problem on 0.12 and I don't remember if I have used 0.13.
It seems that I don't have the problem when playing with Rythmbox 0.13.1 on Ubuntu (but I haven't checked seriously).
The only message I see in forked-daapd log file is:
httpd: Connection failed; stopping streaming of file ID XXX
(which is the same message I have when I skip a song in iTunes)
ldesgrange is right.
I tried Forked-Daapd 0.14 on a D-Link DNS-323 with Alt-F Firmware and exactly 30 minutes after I start playing music on Itunes 10.2.1 on a Mac the connection drops, even in the middle of playing a song.
I wrote to Julien Blache (Forked-Daapd author) and he said that he is aware of the bug, but that he doesn't have time at this moment to resolve a bug that needs each time 30 minutes to reproduce.
I did a tcpdump to check if something specific was happening. Here is what I did:
On the tcpdump I only see iTunes properly closing the connection:
iTunes -> forked-daapd: [FIN, ACK]
forked-daapd -> iTunes: [FIN, ACK]
iTunes -> forked-daapd: [ACK]
I don't know, maybe while connected iTunes is waiting for some "keep alive" messages (even while already playing music from the shared library).
By the way I'm realizing that the problem we are discussing is a bit different from the original one (which I remember used to happen to me before I upgrade forked-daapd and get this disconnection instead), sorry for that.
I am using forked 0.14 and see this problem with iTunes on both Windows and OS X. I do not see it with Rhythmbox on ubuntu. I rarely pause so have never seen it while paused. It always happens exactly 30 mins after starting to stream in iTunes. I can stream for hours with Rhythmbox. Log shows same basic message as others have reported.
Updated to 0.16. Still has the same annoying problem.
I can't believe that with so many installations on commercial NAS (and vast majority of users mostly using iTunes) there is not much of an outcry and that nobody has already solved this bug. I mean, there is surely tons of people having this annoying problem, it should be top priority.
@bobcote: afaik forked-daapd is nearly not used in commercial NAS, most of them are using mt-daapd (which didn't had this timeout issue last time I used it). I'm afraid that we are not so many using it, forked-daapd is more of a "pet project" and I don't think there are enough contributors with enough time to tackle this problem quickly (considering that you need at least 30 minutes to test each time as you said earlier). If you have any knowledge to solve this problem I'm sure everybody here will be happy ;-).
Maybe I'm wrong. I was with the impression that when last year iTunes 10 temporarily broke compatibility with mt-daapd/firelfy that QNAP and Synology had packaged Forked-Daapd as a solution, which could have lead to many people with the same problem we have here. But as I don't have those NAS (I have a D-Link DNS-323) and had this impression only by reading all the forum posts at those companies websites, I could possiibly be wrong indeed. I really thought Forked-daapd was more "serious" and was the de facto new daap server privileged by NAS makers.
I don't know, maybe you are right, but since Apple released a fixed version of iTunes 10 quite quickly I thought NAS makers didn't switched to forked-daapd, maybe if they did, at that time forked-daapd didn't had this issue either and they are still using that old version… I haven't seen people complaining about this bug on NAS (but I had only a quick look so maybe you have found some). Could be interesting to know how many NAS makers use forked-daapd by default or if they provide it as an alternative DAAP server only).
I have a QNAP NAS that I'm running this on and it came with mt-daapd. I had to replace that with forked-daapd.
I'm having this same problem, however. Exactly at the 30 minute mark iTunes drops the connection. I didn't have this problem with mt-daapd and I don't have the problem when playing through the Remote app. I found a tweet from February by someone who was looking into the problem and he found a hardcoded maximum in a file. He said he'd provide more details so hopefully that will help solve this issue.
I confirm this problem still exists in forked-daapd 0.18. iTunes 9.2.1 closes the connection exactly 30 minutes after connecting, regardless of activity. (i.e. I can be playing a song or paused during the 30 minutes, it doesn't matter)
UPDATE 2011-08-24: I believe I have fixed the timeout problem. Changes can be found on this fork:
The two commits solve a 30 minute time-out problem and also enable dynamic updating of the music listing whenever you add using files to your server. Before you had to disconnect iTunes from the server, now the new music should show up within about ten seconds.
I contacted the author Julien Blache and he seemed receptive to include one or both patches for the future.
Good job CBGoodBuddy!
I can't unfortunately test as I rely on the version included in Alt-F firmware for D-Link DNS-323, which is ARM based, so patches will need to be backported to the last arm compatible version.
Great work! It doesn't seem to be completely fixed though.
With both patches applied iTunes happily kept playing for hours while forked-daapd was scanning my library and adding new songs every few seconds. After it finished, it eventually kicked me off and has continued to do so every +-30 minutes. (Haven't timed it, though)
Tested with iTunes 10.5(b)
Well, that's frustrating. Sadly, I can't replicate the problem with iTunes 9 or 10. Can you tell if the time out is 30 minutes or 25 minutes? The new code ensures that iTunes gets some kind of activity at least every 25 minutes, but maybe that's too infrequent. (one possibility is something else is timing out, like your router)
If you have access to the code, it may be worth trying to change http_daapd.c line 64,
#define DAAP_UPDATE_TIMEOUT 1500
which is a 25 minute time out expressed in seconds, to something shorter, like,
#define DAAP_UPDATE_TIMEOUT 60
which guarantees activity at least every minute.
I don't know what the real iTunes does....
Rather than time the 25 minutes, I changed the line. First to 60, then to 120.
On my computer (with lion and itunes 10.5) that causes a disconnect after respectively 60 and 120 seconds.
On another computer I tried (snow leopard and iTunes 10.4) it's still going strong.
I don't have a lion/10.4 machine myself, but I'm going to have someone try that as well.
If it's only 10.5, it might just be a (beta) bug in iTunes, though mt-daapd works fine.
OK, that's pretty weird. I'm not sure why forced activity would force-close the connection. I checked mt-daapd which uses exactly the same method (except 30 second time-outs).
I tested iTunes 9.2.1 and 10.4 on Snow Leopard. I don't have access to Lion yet.
Sounds like there is some new behavior in Lion.
Could you try a 30 second time-out just to see if that improves things? Also, if you can enable debug mode, that might give a little more information about the transactions. But, you will want to operate on a reduced music library, otherwise you will be overwhelmed with debug statements. (I usually test in debug mode with a different config file that points to a single album)
I'll try the debug thing later, but I do have some new info, tried both 30 and 20 second timeouts and they fail.
Had a friend try with lion/10.4 which gave no problems, so it seems to be a 10.5 beta problem.
It would be disappointing if the new version of iTunes changes the protocol, but I guess it wouldn't be the first time.
I had this problem too; I solved it by removing some changes made in c70caad; also, I disabled autologout by setting the value for "msal" to 0.
Try this patch against head:
diff --git a/src/httpd_daap.c b/src/httpd_daap.c
index 3017b3b..b1613c9 100644
@@ -633,10 +633,8 @@ daap_reply_server_info(struct evhttp_request req, struct evbuffer *evbuf, char
dmap_add_int(evbuf, "apro", apro); / 12 /
dmap_add_string(evbuf, "minm", name); / 8 + strlen(name) */
dmap_add_int(evbuf, "mstm", DAAP_SESSION_TIMEOUT); /* 12 */
dmap_add_char(evbuf, "msal", 0); /* 9 */
dmap_add_char(evbuf, "mslr", 1); /* 9 /
dmap_add_char(evbuf, "msau", (passwd) ? 2 : 0); / 9 */
That does solve the original problem, but it also disables CBGoodBuddy's awesome auto update feature which I've come to really enjoy.
Some further experiments showed iTunes ejecting when the forced update message was sent. I assumed it might have something to do with the new == old rev id on the iTunes side, so I added some hacky code to ensure it never sends a forced update with both being equal to the update method. And it seems to work. The library both auto updates and doesn't eject after either the update or the session timeout in iTunes 10.5.
I couldn't find any daap documentation, so I don't know how many rules I'm breaking doing this, but it works for me.
Code I used:
if (force == 1) ++db_rev;
```DPRINTF(E_DBG, L_DAAP, " (update, session-id=%d, old_rev=%d, current_rev=%d, force=%d)\n",
ur->session_id, ur->revision_number, db_rev, force);
if (force == 1) ++db_rev;
On line 857 of httpd_daap.c
Should be fixed in v0.19
Updated my box with 0.19, iTunes was not disconnected in the last few hours. Congrats guys! Thank you very much.
It's still working on my box, auto-update is working too.
@Max905 if everything is fine for you, maybe you should close this issue?
Running 0.19 vanilla, just checked out a fresh copy. iTunes 10.4.1 works like a charm (though I am not seeing autoupdates), 10.5 still disconnects every 5 minutes, regardless of the value of 'msal'. So, does not work for me.
Ditto here. It looks like the timed update response sent by update_refresh_cb() isn't making it very happy.
Two quick hacky fixes that worked for me are:
1) disabling this timer altogether (or bumping DAAP_VERSION_REFRESH) -- I assume this would break updates and;
2) incrementing current_rev before sending the mupd reply in update_refresh_cb.
Using #2 now; no problems yet, and updates seem to work; no long-term tests yet.
Issue #70 (#70) argues that the number should increment whenever we see a directory rev change; this makes sense to me, as a long-term fix.
I've had this problem for a while now, and I tried applying fix #2 to the GCD version of 0.19.
It didn't seem to do any live updating like CBGoodBuddy's version does though; has anyone else tried the GCD version?
You folks are right. Something has changed about iTunes 10.5: it rejects "update" notifcations that 10.4 does not. If you update the db_rev each cycle, then you will incur the penalty of iTunes re-downloading your entire music library every so often, which is not optimal and terrible for mobile use. Someone needs to understand better what iTunes needs as a response.
I think this issue describes the problem I had after updating to iTunes 10.5. iTunes would disconnect after being connected for five minutes. I decided to disable the refresh timer by commenting out line 897 on the 0.19 build: //ret = evtimer_add(&ur->timeout, &tv); . I think this is what unsynchronized mentioned as hacky fix 1.
So far, no disconnects. Hoping I didn't break something without realizing it.
Hey, im really new to programming... can you please describe me where exactly i have to make these changes, to fix the issue tha i get kicked out?
-so in wich file is the "line 897" //ret = evtimer_add(&ur->timeout, &tv); ??
I commented out line 897 in src/httpd_daap.c of the .19 release (http://alioth.debian.org/~jblache/forked-daapd/forked-daapd-0.19.tar.gz). Hope that helps, but I also don't know if my workaround is a particularly good solution.
Hmm, i cannot see the line when i use the git-hub version (0.19gcd)
any idea where i can find it there?
one more thing: what is the difference betwen the gcd version and the "normal"?
Since my library is mostly static, to get this working, I just disabled the timer completely. Here is the patch I used:
diff --git a/src/httpd_daap.c b/src/httpd_daap.c
index 7c424c3..cd4297c 100644
@@ -1000,9 +1000,9 @@ daap_reply_update(struct httpd_hdl *h, struct evbuffer *evbuf, char **uri)
- dispatch_time(DISPATCH_TIME_NOW, DAAP_UPDATE_REFRESH * NSEC_PER_SEC),
- DISPATCH_TIME_FOREVER /* one-shot */, 30 * NSEC_PER_SEC);
+// dispatch_time(DISPATCH_TIME_NOW, DAAP_UPDATE_REFRESH * NSEC_PER_SEC),
+// DISPATCH_TIME_FOREVER /* one-shot */, 30 * NSEC_PER_SEC);
/* Freeze the request */
http_server_response_freeze(h->c, h->r, update_free_cb, ur);
GCD stands for grand central dispatch. His blog post explains it pretty adequately:
so is it right that i disable with this patch the ability to update the database completely while running forked-daapd?
Is forked-daapd updateing the library when restrarting it?
And thanks for the explanation what GCD is!!!
Yes, this will disable dynamic updates. Restarting the daemon will update the database, at least it does for me (I just tried).
However, I had a stream playing all night using newest stable itunes.
This is GREAT!!!
My Server is shutting down every night at 2.00 and boots at 8.00 - so it should update the database...
ill see ;)
I realise this doesn't fix the 5 minute disconnect problem, and only works if you have the relevant bits of kit, etc, but a workaround that seems to be working for me, is to define my Airport Express in the config, use 'Remote' on my iPhone, and cut out iTunes altogether.
Hey, what do you mean with "relevant bits of kit"?
The workaround seems to fix the issue on my 0.19 build...
He means if you have Airport Express and an iPhone.
There IS a problem when using this patch above:
i cannot control itunes after around half an hour - so i stay connected to the library, but i cannot click play for example (of course only in the forked-daapd library). in my house everybody has this problem! (4x osx, 1x windows, itunes 10.5)
I seem to have some similar issues with iTunes 10.5, every few minutes music stops with error message in log "httpd: Connection failed; stopping streaming of file ID xxxx".
Like ioquatix my iTunes 10.5 (141 build) disconnects every 5 mins in the middle of whatever is playing. This basically means forked-daapd ver. 0.19 isn't a solution that works with 10.5 (which is required now for iPhone 5 OS). :(
I'm also having the iTunes 10.5 issue. It's really frustrating as I can't listen to any of my music anymore :(
Same thing here, which is specially frustrating because I just switched from mt-daapd because it stopped working. Is there any alternative or can we expect a fix? :/
Hmm, somehow here it kind of workes:
i can connect to my library, but i:
Just to confirm the same issue: after 5 minutes iTunes 10.5 stops and forked-daapd gives the httpd: Connection failed; stopping streaming of file ID...
I have forked-daapd 0.19 installed on a Ubuntu 11.10.
I too have the same timeoutproblem that has been described here. I recently bought a LaCie network storage for a friend and made a system upgrade on it (the last one had been released today) and I don't know what they base their iTunes server on but it works without any timeouts. Do anyone know what laCie bases their solution on ?
Any News about this bug?
I was planning to hook up a debugger and take a look, but I am away on a conference this week. However, if nothing has happened by next weekend I may take a look into the issue.
Any new news? I'm just waiting to have it working again.
I alos like to report, based on AMCC PowerPC platform, with iTune 10.5.x, the music streaming stops exact 5 minutes when you click the the library both in Windows XP/7 as well as Mac OS Lion. Looks like the port is closed after 5 minutes after starting of the connection. But we tried using 2 computers streaming from the NAS server with different starting time, the two streams play exactly 5 min regardless of their starting time. And we found out when that happens, iTune actually sending an rst packet to the server. Not sure the packet is the cause or the result?
No news? thats sad...
i think im goin to use Subsonic or something else, to be independent to iTunes....
It is not very hard to downgrade to 10.4.1, the last version that works well. The Internet is full of tutorials. It is a better solution than coming back with "me toos" every once in a while. It's not as if 10.5 brought some monumental changes, aside from the cockup with the protocol.
That is true, but 1. This is not a fix for the problem and second, here there are around 20 people using the shared library. I really cannot tell anybody to downgrade to 10.4.1!! There are a lot of users which simply can switch their machine on and use itunes + safari...
Thats the reason why a real fix would be really great!
True, it is not a fix and I, too, am anxiously awaiting one, and I cannot contribute, because I am not a programmer. Nothing has happened with forked-daapd for almost two months and I can only suspect it's for the lack of time on Julien's side (see: end of the year, busy time).
Over the new year, I did some investigation and found the problem. It's a detailed problem with how the forked-daapd server sends information about its capabilities to the client.
This patch appears to resolve the problem:
The patch has been submitted upstream to the author Julien Blache as well.
It should apply against forked-daapd version 0.19 from the author, and is tested with many clients.
Also there is a separate patch to respond to issue #78, which should allow Banshee and Amarok clients to connect. Here is the patch:
Also submitted upstream.
I do not have the capability to make .debs or other builds for embedded boxes, but hopefully there are others that do.
Best wishes for the new year!
Hey, that sounds really great, but i cannot manage it to compile!
i tried this:
git clone https://github.com/CBGoodBuddy/forked-daapd.git - this should be your version with the changes!?
then autoreconf -i, configure.... and then make. when i want to build forked-daapd, i get this error:
evhttp/http.c:28:26: fatal error: event-config.h: Datei oder Verzeichnis nicht gefunden
make: *** [forked_daapd-http.o] Error 1
make: Leaving directory /home/user/Download/forked-daapd/src'
make: *** [all] Error 2
make: Leaving directory/home/user/Download/forked-daapd/src'
make: *** [all-recursive] Error 1
make: Leaving directory `/home/user/Download/forked-daapd'
make: *** [all] Error 2
make: *** [all] Error 2
make: Leaving directory
Any Idea what im doing wrong? the problem seems to be that there is no event-config.h. but where should this come from?
If this is the first time you have built forked-daapd... it sounds like you are missing the prerequisites, probably "libevent" and development libraries. Unfortunately, I found that collecting all the dependencies was the worst part. Good luck getting that straightened out. It's one of the reasons I'm not able to work with the new 0.19gcd branch.
Also, be sure that you use branch "itunes_v10_5", i.e.
git checkout itunes_v10_5
before you start the autoconf & build process.
It looks as if he's using the gcd branch. As for the dependencies, that for me was no different for the gcd branch, since the only extra requirements are clang and libdispatch with blocks support. Perhaps give it another try, CBGoodBuddy? As for the patch itself, it works for me. I myself am on the libevent branch (gcd was unstable on my hardware and there was no point to it with a single core) and there were no hiccups there, 10.5.2 does not disconnect and all looks good so far, 33 minutes in.
hmm im not a programmer but try to understand what im doing here.
Compiling the "original" forked daapd code (git clone https://github.com/jasonmc/forked-daapd.git) workes fine.
So the problem is, im using the wrong code? how can i use the non gcd version?
@pcace - I think the issue is that version 0.19 I'm branching from uses a different set of libraries - the original set. You need to be sure you have libevent and (probably) libevent-dev installed on your system. The most recent update to jasonmc/forked-daapd is called 0.19"gcd" which doesn't use libevent, but libdispatch instead, which is probably why your compilation of that branch worked.
You should also be able to apply the same git patches against the 0.19 tar file available from Julien Blache's home site.
@freultwah - my Linux box is has an older OS on it, so it's a fairly heroic effort to install all these special dependencies. I'd rather be doing some coding, or other things in my life, than figuring out dependency hell. :-)
i just reinstalled libevent (apt-get said: libevent-dev is already the newest version.)but still i get the information:
evhttp/http.c:28:26: fatal error: event-config.h: Datei oder Verzeichnis nicht gefunden (not found...)
(i also downloaded compiled and installed the newest version from libevent.org... (libevent-2.0.16-stable - but nothing helps...)
i really don't know what to do now ideas?
@pcace - you can check if you have this file which should be in /usr/include/event-config.h
It should be provided by the libevent-dev package as shown here....
# dpkg -S event-config.h
If the file is present on your system, then double check that the "configure" step worked right, i.e. it actually found the right version of libevent.
in the debian repo there is no libevent1 nor a libevent1-dev...
yes it is there:
root@t64:/home/user/Download/forked-daapd-0.19# dpkg -S event-config.h
but what do i have to do now ;)?
hahaha, got it! Thank you all for your help! I just had to download and compile the libevent 1.4....
THANKS, hopefully forked-daapd works now how i wish ;)
Ok, forked-daapd is NOT running like i want i to do:
i cannot connect from iTunes 10.5.2 (OSX Lion)
i installed forked-daapd like that:
git clone https://github.com/CBGoodBuddy/forked-daapd.git
git checkout itunes_v10_5
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-flac --enable-musepack
everything seems to work, but i cannot connect to the server via itunes... did i miss something?
i also manually controlled wether there are the new lines in the httpd_daapd.c
i also checked wether it is the new compiled version im using:
-rwxr-xr-x 1 root root 1296539 Jan 2 13:43 /usr/sbin/forked-daapd
any idea would be great!
@pcace - Perhaps this line from the INSTALL file will be helpful in resolving your issue:
Support for iTunes Music Library XML format is optional. Use --enable-itunes to enable this feature.
@pcace If this really is not working (you may want to reconfirm by enabling a more verbose log level to see what it does) you likely have some flaws in your build environment. I've seen this error >>evhttp/http.c:28:26: fatal error: event-config.h:<<< before and it indicates you had old configuration data from a gcd compile. These files are libevent includes that are patched and included in the source tree for the non GCD version. They are no longer required in GCD (no libevent)
Anyway further up you said that the compiling the original git works fine. So why not start from scratch from there?
clone the repo
#git clone http://anonscm.debian.org/git/users/jblache/forked-daapd.git
cd to src dir
checkout non gcd version (by tag = 0.19)
#git checkout -b nongcd 0.19
#./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-flac --enable-musepack
cd into src directory and run it from there in foreground. I.e like this
#./forked_daapd -f -d 5 -D daap,main
and see what it does. (enable more debug options if you like)
Then just pick the commit you need from CBGoodBuddys repo. Some beautiful git magic ;-)
Fetching the remote branch
#git fetch git://github.com/CBGoodBuddy/forked-daapd.git itunes_v10_5
List commits in it
#git log --oneline FETCH_HEAD
c2e6eed Fixes for Amarok and Banshee clients which don't send revision-number in their update request.
bd10978 Fixes for iTunes v10.5 time-outs.
#git cherry-pick bd10978
Repeat the test..
c2e6eed Fixes for Amarok and Banshee clients which don't send revision-number in their update request.
bd10978 Fixes for iTunes v10.5 time-outs.
#git cherry-pick bd10978
Repeat the test..
If this doesn't work as such your build system/dependencies/packages are broken somewhere.
Hope this helps..At least I seem to have written a howto on pullin in and apply this patch that maybe helpful to others.
BTW. debian provides libevent-dev and compability packages. Just stay away from anything that looks like libevent 2.xx
yes it seems that you have written a howto ;) thank you very much - the bad thing is, here it simply does not work. (here)
i painfully followed every single of your steps, everything worked, BUT i still cannot connect with itunes. it simply happens nothing (also when i use 9 as logging level)
root@t64:/home/user/Download/forked-daapd/src# ./forked-daapd -d 9 -f -D daap,main
main: Forked Media Server Version 0.19 taking off
main: Initialized with gcrypt 1.5.0
main: mDNS init
main: Initializing database
main: Registering rendezvous names
nothing more happens also when i try to connect (i tried several machines...). the log simply stays like this...
Where else could i look for the missing part?!
PS: when configuring i also tried to enable --enable-itunes
thank you sooo much for the hint to stay away "from anything that looks like libevent 2.xx". That was the reason why nothing worked. i uninstalled everything which had to do with libevent and reinstalled the 1.4.x. Now everything seems to work again!!!
Thank you all for your great endurance with me ;)
Hey, is it possible to use the patch also in the GCD version?
maybe im wrong, but scanning takes much much longer with the non GCD version (?). The server here (dualcore intel 1,83ghz 4gb ram) scans my library now for around 4h and he did the half of it... (100.000 songs)...
But hey, @CBGoodBuddy thank you sooooo much for your Work!!!
The timeout patch won't apply directly to the 0.19 GCD version, sorry. I don't have that version up and running so I can't test it. In principle it's not that hard to change though.
Trying to build from the repo, I get
main.c:587: undefined reference to `register_ffmpeg_evbuffer_url_protocol'
at link time. Google searches lead me back to forked-daapd pages. Which library am I missing?
Oh, apparently you can just comment out the call to register_ffmpeg_evbuffer_url_protocol in main.c. Noting here in case anyone ends up here trying to solve the problem.
hey, there is one feature im missing now: auto-update!
is there any possibility to have the library autoupdate function back?
Thanks again for the fix!!! it just works!
@lpar: strange, register_ffmpeg_evbuffer_url_protocol is part of the distribution, in src/ffmpeg_url_evbuffer.c. It shouldn't have flagged as a linking error unless you also had a compilation error.
@pcace: in August I filed a patch to do automatic updating, but the maintainer did not accept it. From what I can tell, neither of the new releases from September (0.19 nor 0.19gcd) has the capability to do automatic updating, so I'm kind of surprised that you were enjoying it. The easiest workaround is to disconnect and reconnect to your iTunes server. New library additions should appear then.
@CBGoodBuddy: i know! I used your patch to have automatic updating enabled....
So again my question: do i have any chance to have this again?
From the configure script, it looks like the code switches from using ffmpeg for evbuffers to using libavformat if libavformat is new enough. Unfortunately this isn't working properly, and src/ffmpeg_url_evbuffer.c isn't getting compiled and linked in if libavformat's major version is < 53.
I tested by downloading and compiling libav 0.7, and with that, the build process worked fine.
@CBGoodBuddy This fix works! Thanks alot!
If you want to have a test environment to test gcd etc I can provide you with a VM to do so, I've compiled it on that VM. You can even listen to the server if you use openvpn (it's configured to send broadcasts).
@BernardV thanks for your offer, that's very kind and I appreciate it.
Unfortunately one of my stumbling blocks is that the new "GCD" version is actually written in a new dialect of the C programming language and I don't quite understand how it works. It's all very cutting edge, but unfortunately I have a masters degree in keepin' it old style. That, plus my real life is intruding for a while. I'll keep your kind offer in mind.
Would there be interest in a virtualbox image with both the latest git version compiled and the iTunes fix version compiled?
I can make and host such an image on the latest debian stable (I think :) I now have a mix of testing/stable).
Just FYI - for Ubuntu 11.10 users, all you have to do is download the Ubuntu source package, replace src/httpd_daap.c with the @CBGoodBuddy 's patched version of the file, and do the package rebuild. A good how-to for this is http://www.cyberciti.biz/faq/rebuilding-ubuntu-debian-linux-binary-package/
Thanks guys, just compiled a pkg for Ubuntu 11.10 - worked flawlessly!
Craig, great work on this fix. For anyone who's interested, I ported the changes to the GCD version, and it seems to be working for me. Any feedback is appreciated!
@kekiefer well done! Be sure to forward your patch information to Julien Blache so that (hopefully!) he can put it in the next release.
Hmm again i do not understand so well what im doing to install this patch...
git clone https://github.com/jasonmc/forked-daapd.git
then downloaded this file:
and copied it to the src folder.
Then compiled forked-daapd. When using it, i cannot skip in tracks, and there is no length of tracks. What is wrong there?
EDIT: i also tried to clone https://github.com/kekiefer/forked-daapd.git and make this: the result is a forked-daapd version where i cannot skip in tracks...
Hmm i still cannot get the GCD to work properly,
can anyone again please help out ;) ?
When i compile the kekiefer version, there is no possiblility to skip in tracks...
Thanks for the feedback, @pcace, sounds like I may have missed something.
Can someone confirm if track scrubbing works in @CBGoodBuddy's fix?
yes, in CBGoodBuddy's fix it works perfectly!
Is it working at your machine? Whats wrong then there? is it working somewhere else?
Please can someone make a .dpkg I can't compile this.. My Debian installation just xxx with me so I just beg for a dpkg to install with instead...
Note that this was made using checkinstall and I think it's missing the /etc/init.d script.
Any chance to have this *.deb for a 32 bit system?
Not from me, unless there's some configuration option I'm unfamiliar with. My Debian system is pure 64 bit. Sorry.
Hmm ok no problem, but can you tell me which version this is exactly?
Has it the fixes from @kekiefer also? - so is it the 0.19GCD with the ability to skip in tracks?
commit f7d7dfc of branch nongcd of http://anonscm.debian.org/git/users/jblache/forked-daapd.git
patched as described by @elwertk above.
And a quick test reveals that skipping in tracks works for me.
I've tried to compile the Ubuntu 11.10 source file as @markgsd said and now I can hear my music with Apple iTunes 10.6 for more than 5 minutes! Thanks @CBGoodBuddy for your nice work!
I'll post ASAP a link for my home-build .deb package (64bit version, of course) in my personal Website, so that people will not need to install the development tools... stay tuned!
UPDATE (24/03/2012 23:51):
I've compiled the package for both platforms (32bit and 64bit) with the @CBGoodBuddy patch. These are the links:
Hey, this is really wonderfull!
But: Has somebody a working 0.19GCD version with these Patches installed?
is there any chance that someone could compile a 0.19 GCD version of forked-daapd?
Yeah, my build dies after a few minutes, so I guess I'm missing a patch. A current working commit reference would be appreciated.
Here's a build for debian testing: http://www.mmacleod.ca/files/forked-daapd_0.19gcd-2_amd64.deb
And also what I did to make it work: http://www.mmacleod.ca/blog/2012/05/patching-forked-daapd-so-it-actually-works/
Now if only forked-daapd wouldn't disappear as soon as I enable IPv6 on my workstation...
And can you skip in tracks?
Is auto database updating working?
Huh, I cannot skip in tracks. Dunno about auto updating. All I can say with certainty is that it doesn't disconnect after 5 minuters, which is more than I had before.
Just thought i'd comment and say that using a Raspberry Pi, elwertk's instructions at #19 (comment) fixed the timeout problem. I have ended up with a rather large installed package list and to be honest i'm not sure why my most recent try worked when my previous ones didn't but in the end I got there. I think I am able to skip songs and am unsure about whether it is auto-updating but it will stay connected.
Thanks to all of you for working hard to get this working! And particular thanks to elwertk and CBGoodBuddy! :)
I had the 5 minute timeout issue myself; running Ubuntu 11.10 Server.
After following everything mentioned in #19 (comment) to the letter, iTunes still refused to connect.
Then I removed libevent-2.0.5 and replaced it with libevent-1.4-2 (libevent-core, libevent-dev, libevent-extra), I had to download the .debs from an older version of Ubuntu. This instantly broke transmission-daemon. I use Deluge now.
Then I built against the older libevent and it worked.
I think it bears repeating how building against libevent-1.4-2 will save you a lot of grief.
Thanks CBGoodBuddy for your patch!
Hey, i solved the 5 min bug, thanks to @CBGoodBuddy BUT i still cannot skip in every track: only tracks converted with VBR are able to skip... in Mp3s with CBR i cannot skip.
Has anyone an idea how to solve that?