This is due to a bug in rhythmbox.  It doesn't have the right byte order for something in the content-code response, IIRC.  I had talked to the RB guy who is responsible for it back when I originally found it, but I guess it hasn't been fixed still.

I've fixed this issue, but I still can't get banshee to play anything from a rhythmbox daap share.  Playback of local files works OK, though, as does playing from an itunes daap share.

Can you get rhythmbox to play anything from a banshee daap share? or doesn't that work either?

*** Bug 330286 has been marked as a duplicate of this bug. ***

I've just tested RB's daap server with several different clients, and Banshee seems to be the only one that doesn't like it.


Using Banshee and RB from cvs, Banshee can connect fine. However it segfaults when trying to play a song, as it attempts to allocate a ~3Gb chunk of memory.

Since other clients work fine, I'll assume it is a Banshee bug for now - however it could be a RB thing that other clients deal with (Banshee shouldn't try to allocate 3Gb of memory in any case).

I'm avahi-less right now, so I can't test Rhythmbox+Banshee, but no, it should not be eating 3GB of memory :)

To get around having to implement a custom GStreamer source, and so DAAP playback works on other media engines (Helix, VLC), I have a light weight embedded HTTP server that proxies DAAP streams over HTTP. Something like http://localhost:8089/{database_hash}/{song_id} is passed to the media engine, which will start the proxy server from streaming the DAAP data.

I'll see what I can find when I can get a box with Avahi back.

I am using mt-daapd 0.2.3 (on an NSLU-2) as my server. Banshee displays the same error Christian mentioned when connecting to the daap share:

Unhandled Exception: DAAP.LoginException: Failed to login ---> DAAP.ContentException: Failed to find content code for: 1634169456
in <0x004d4> DAAP.ContentParser:Parse (DAAP.ContentCodeBag bag, System.Byte[] buffer, System.String root, System.Int32 offset)
in <0x0004a> DAAP.ContentParser:ParseChildren (DAAP.ContentCodeBag bag, System.Byte[] buffer, Int32 offset, Int32 length)
in <0x003d4> DAAP.ContentParser:Parse (DAAP.ContentCodeBag bag, System.Byte[] buffer, System.String root, System.Int32 offset)
in <0x0004a> DAAP.ContentParser:ParseChildren (DAAP.ContentCodeBag bag, System.Byte[] buffer, Int32 offset, Int32 length)
in <0x003d4> DAAP.ContentParser:Parse (DAAP.ContentCodeBag bag, System.Byte[] buffer, System.String root, System.Int32 offset)
in <0x0004a> DAAP.ContentParser:ParseChildren (DAAP.ContentCodeBag bag, System.Byte[] buffer, Int32 offset, Int32 length)
in <0x003d4> DAAP.ContentParser:Parse (DAAP.ContentCodeBag bag, System.Byte[] buffer, System.String root, System.Int32 offset)
in <0x00025> DAAP.ContentParser:Parse (DAAP.ContentCodeBag bag, System.Byte[] buffer, System.String root)
in <0x0000f> DAAP.ContentParser:Parse (DAAP.ContentCodeBag bag, System.Byte[] buffer)
in <0x000da> DAAP.Database:RefreshSongs (System.String revquery)
in <0x00085> DAAP.Database:Refresh (Int32 newrev)
in <0x000a6> DAAP.Client:Refresh ()
in <0x000aa> DAAP.Client:Login (System.String username, System.String password)--- End of inner exception stack trace ---

in <0x002dc> DAAP.Client:Login (System.String username, System.String password)
in <0x00022> Banshee.Plugins.Daap.DaapSource+<>AnonHelp<1>:<#AnonymousMethod>2 ()
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void ()

My daap server can be accessed without any password, only the configuration pages are protected. Banshee is however asking for a password. 

The mt-daapd server is working correctly with my Roku Soundbridge M1001 (Firmware 2.4.4) and with GIT 0.8.1_r1. 
I'm running Banshee version 0.10.6 on Ubuntu Dapper Drake, fully updated on feb 22 21:44 UTC

Seems to be a problem with rhythmbox.  I used ethereal to sniff the traffic when requesting a song, and I got the following:

GET /databases/1/items/6.mp3?session-id=2104133250& HTTP/1.1

Accept-Encoding: gzip

Accept: */*

User-Agent: iTunes/4.6 (Windows; N)

Client-DAAP-Version: 3.0

Client-DAAP-Validation: 578A9B65BAB7D05BB18D204EE1795F23

Client-DAAP-Access-Index: 2

Client-DAAP-Request-ID: 11

Connection: close

Host: 192.168.1.101:3689

Authorization: Basic bm9uZTo=



HTTP/1.1 200 OK

Transfer-Encoding: chunked



4000


I don't know where that '4000' comes from, but it is certainly not the mp3 file :)

Rick: I just installed mt-daapd 0.2.3 on my box here, and banshee was able to play from it fine (listening to it now).

I think it's likely a byte ordering bug in mt-daapd exposed when you run it on the NSLU2.  Do you get the same behavior if you run it on a x86?  The similar RB problem was also a byte ordering issue.

Also, according to ethereal, after sending the '4000' body, the connection is closed.

Sigh, on a second look it appears that banshee is actually closing the connection.  Appears to be some kind of playback issue

Does Banshee support chunked encoding? because that's what RB is sending the data as, the "4000" is the chunk size in hex digits.

From the RFC:
"All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer-coding, and MUST ignore chunk-extension extensions they do not understand."

(In reply to comment #9)
> Rick: I just installed mt-daapd 0.2.3 on my box here, and banshee was able to
> play from it fine (listening to it now).
> 
> I think it's likely a byte ordering bug in mt-daapd exposed when you run it on
> the NSLU2.  Do you get the same behavior if you run it on a x86?  The similar
> RB problem was also a byte ordering issue.
> 

Hmm, sorry I've got no other system available at the momnent to check that...
But after reading what James wrote I get the feeling Banshee on my system interprets that 4000 as an error and so pops up the password prompt, which it obviously shouldn't, that should only be done after an 401 error.

This is quite weird:
I just rebooted my box and restarted Ubuntu Dapper Drake (I am dual booting between Dapper Drake and Breezy Badger) Now Banshee is playing perfectly. Seems something was not correctly started yesterday after installing all neccessary software... 

Please disregard my previous post: I was too fast and did not check what resource I was playing: turns out it was a local file. I stll get the password prompt when trying to connect to my mt-daapd server.

The password prompt is independent of streaming and proxying audio. The password prompt should only show when connecting to the share to initiate browsing, not streaming from an already connected share. Would you outline exactly what you're doing to see the password prompt?

(In reply to comment #16)
> The password prompt is independent of streaming and proxying audio. The
> password prompt should only show when connecting to the share to initiate
> browsing, not streaming from an already connected share. Would you outline
> exactly what you're doing to see the password prompt?
> 

I get the password prompt when trying to connect to the share. The connection always fails, it does not matter if I leave the password empty or if I use the admin password. Actually I think there should be no password prompt at all in this case, because there is no password configured in the server for browsing the files.

The password issue sounds like a separate problem. Please open a new bug for it.

*** Bug 330287 has been marked as a duplicate of this bug. ***

Created attachment 60878 [details] [review]
Patch to fix the crashing/freezing when playing from RB+DAAP

There were a few things going on here:

a) Stream lengtsh from RB were -1, so I adjusted the reading code to not rely on a ny kind of length; fixing this, along with not sending Content-Length header if there is no length solves the bug

b) There was another issue in that only the stream writer was being closed, and not the socket

I am now able to play music from a Rhythmbox DAAP share using both the 0.8 and 0.10 GStreamer backends and VLC backend in Banshee.

For the actual streaming from the Rhythmbox DAAP server, HttpWebRequest is used, which supports chunked HTTP 1.1.

Much thanks to Sebastian Dröge for helping to pinpoint the length issue.

I'm going to mark as FIXED; if anyone still has this issue, please re-open. Rick: please file a new bug about the password problem.