I'm somewhat tempted to close this as NOTGNOME, but that wouldn't be very productive.  My extremely brief investigation suggests that iTunes 7 has changed the cryptographic nonsense it uses to authenticate clients.

Have you tried any other DAAP clients?   Banshee, itunesbrowser, and I'm sure a few others use different DAAP client code bases, so their success or failure might tell us something.

Out of curiosity, what happens in the reverse case?  Can iTunes 7 read a rhythmbox DAAP share if it's enabled?

PS.  It's not just the DAAP stuff that's been changed (possibly to prevent interoperation but that's speculation), but also iPod firmware upgrades have caused problems, see:

http://abock.org/2006/09/14/we-need-you-and-apple-sucks-part-2/

iTunes 7 clients can still use rhythmbox DAAP shares.  No one other than apple wants to implement their client authentication scheme.

Any idea how much reverse engineering it will take to figure out what changed between iTunes 6 & 7?  I did a quick search on the web, the banshee list and bugzilla, but no other reports I could see.

I'm also having this problem but would suspect that it's not a rhythmbox specific problem. Does anybody have data on whether iTunes 6 can connect to an iTunes 7 db?

Banshee has the same problem so it's not rhythmbox specific. Furthermore this is the error that DAAP (through Banshee) spits out when trying to connect.

Connecting to DAAP share: 172.19.165.2:3689 (Gerald’s Music)

Unhandled Exception: DAAP.ContentException: Failed to find content code for: 1634027088
in <0x0054e> 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 <0x0044a> 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 <0x00098> DAAP.Client:.ctor (System.Net.IPAddress address, UInt16 port)
in <0x0003b> DAAP.Client:.ctor (DAAP.Service service)
in <0x00031> Banshee.Plugins.Daap.DaapSource+<>AnonHelp<1>:<#AnonymousMethod>1 ()
in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void ()

http://www.snorp.net/log/2006/09/12/itunes-7/#comments

Seems like Apple changed their validation hash calculation. FYI, iTunes 6 can't connect to iTunes 7 shares, but contrary to rhythmbox, gives an error message saying it can't open the share (can't remember the exact message)

Confirming bug.

Ubuntu bug about that: https://launchpad.net/products/rhythmbox/+bug/62842

The banshee task has already been fixed

If by "Banshee has been fixed" you mean "displays an message to the user about it not being supported". I guess we could display a nice message too, but iTunes 7 won't be supported until someone reverse-engineers the new broken-md5 hash.

I've not tried banshee, your comment seems right from the ChangeLog though

Here is the upstream banshee bug: bug #380972.

I don't see why this seems to be a minor issue in the eyes of the developers. It essentially entirely breaks access to DAAP shares in Rhythmbox because iTunes is pretty much the only DAAP program in heavy use.

It's not a minor issue, but since Apple deliberately (it appears) broke the protocol to prevent third-party clients (including iTunes < 7) from connecting to iTunes 7 servers they may have also made it difficult to reverse engineer (otherwise it probably would have been done by now).

Also, once one project figures it out (e.g. banshee or rhythmbox) the fix will probably be easily ported to other open source projects, but it will probably require somebody to sit down and do a lot of trial and error reverse engineering which isn't exactly a fun task.  Are you volunteering? ;)

I would volunteer if I even knew where to start. I know c++ fairly well but nothing about networking or DAAP.

These people seem to be involved in an effort to crack the new client authentication scheme:  http://www.saveourtunes.com/

Hey guys, I am running the SaveOurTunes project which Jonathan kindly referenced above. We are working on cracking the DAAP auth problem but could use all the help we can get. Right now we need people great with assembly and java. See the website for details or email saveourtunes {at} gmail {dot} com (In reply to comment #15)

> These people seem to be involved in an effort to crack the new client
> authentication scheme:  http://www.saveourtunes.com/
> 

Giving a usefull error message would actually be a first step. This message should educate users about Apple badness.

Today it still just "hang", and whatever is the reason, it is not good.

Fixing the hang is a one line change that I had a fix for at some point but lost in a repo update.  IIRC we were just not calling one of the callbacks on an error condition or something like that.

I've added a specific error message for this case - "Rhythmbox is not able to connect to iTunes 7 servers".

(In reply to comment #19)
> I've added a specific error message for this case - "Rhythmbox is not able to
> connect to iTunes 7 servers".

I think we should also say why. Something like "Rhythmbox is not able to
connect to iTunes 7 servers because Apple has intentionally prevented this."

i have the same problem here using Rhythmbox 0.11.6 on Ubuntu 8.10 (the Intrepid Ibex)
i wonder, where can i found information about the resolution of this "bug".
by the time i wrote thoses line, iTunes is now at version 8 i think.

There is no resolution.  Rhythmbox cannot connect to iTunes DAAP shares.