GNOME Bugzilla – Bug 659146
Banshee can't connect with the forked-daapd daap server
Last modified: 2012-03-17 17:20:27 UTC
Banshee will not connect to forked-daapd, because in the first call to daap:/server/update, it does not pass a "revision-number" parameter, which forked-daapd expects. This is arguably a bug in forked-daapd, as the specification (insofar as it has been reverse engineered) does not appear to require this parameter in the first update call after login, but recent versions of iTunes apparently pass it (I haven't tested it with versions prior to 9). In addition, even if this is worked around (which I did by hacking forked-daapd so that it does not require the parameter), Banshee will not play transcoded files from forked-daapd because forked-daapd does not add a "Content-Length" header to the http response to the "play" request because it cannot accurately calculate the size until after the transcoding is complete. Banshee requires this header and requires it to be greater than or equal to 1. It's hard to say that forked-daapd is buggy here, because this is not an issue iTunes has to deal with on the server side, because it does not transcode, but as a client, iTunes is not thrown off by the lack of a Content-Length header, and so Banshee should not require it either if it is going to behave consistently with iTunes.
Please file a bug per issue, not 2 issues in 1 bug. In regards to the requiring of Content-Length header, can you paste a debug log of Banshee when it tries to reproduce the track?
Created attachment 196883 [details] Banshee debug log Debug log showing Content-Length error attached
*** Bug 659276 has been marked as a duplicate of this bug. ***
*** Bug 666237 has been marked as a duplicate of this bug. ***
Confirming because of multiple duplicates. Logs from the duplicate : Error client side: [Warn 10:38:41.213] Caught an exception - Daap.ContentException: Could not find root node 'dmap.serverrevision' (in `Banshee.Daap') at Daap.ContentParser.Parse (Daap.ContentCodeBag bag, System.Byte[] buffer, System.String root, System.Int32& offset) [0x00000] in <filename unknown>:0 at Daap.ContentParser.Parse (Daap.ContentCodeBag bag, System.Byte[] buffer, System.String root) [0x00000] in <filename unknown>:0 at Daap.Client.GetCurrentRevision () [0x00000] in <filename unknown>:0 at Daap.Client.Refresh () [0x00000] in <filename unknown>:0 at Daap.Client.Login (System.String username, System.String password) [0x00000] in <filename unknown>:0 Daap.LoginException: Failed to login (in `Banshee.Daap') at Daap.Client.Login (System.String username, System.String password) [0x00000] in <filename unknown>:0 at Daap.Client.Login () [0x00000] in <filename unknown>:0 at Banshee.Daap.DaapSource.<Activate>m__7 () [0x00000] in <filename unknown>:0 Error in forked-daapd: daap: Missing revision-number in update request.
thanks, solutions?
Bug #667508 was just filed for the Content-Length issue, so let's make this one just about the revision-number problem.
Created attachment 209972 [details] [review] Send revision-number on every update request so that some daap servers reply correctly to them It seems that some daap servers (e.g. forked-daapd) do not accept update requests without if a revision-number is not passed in the query. Using Wireshark, I took a look at the communication that took place between Rhythmbox and forked-daap, and Rhythmbox always sends the revision-number in the update request, even in it's initial one. The initial value is 1. This patch implements the same behavior in Banshee.
Comment on attachment 209972 [details] [review] Send revision-number on every update request so that some daap servers reply correctly to them Thanks for the patch, committed !
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.