iTunes not visible in server list

[GoogleCodeExporter]

What steps will reproduce the problem?
1. start iTunes
2. start TunesControl
3.

What is the expected output? What do you see instead?
iTunes should (presumably) appear in the list of servers. However it does not 
and the manual add has to be used instead. 

What version of the product are you using? On what operating system?
Mar 01 file, on HTC Desire Froyo

Please provide any additional information below.
iTunes _touch-able._tcp service is visible from other applications and works 
with iTunes Remote.

I'm looking to help you guys update this software (I've written a DACP server 
for Songbird http://addons.songbirdnest.com/addon/1764), getting easy pairing 
is a first step! :)

Original issue reported on code.google.com by a.wi...@gmail.com on 3 Aug 2010 at 10:03

[GoogleCodeExporter]

hey welcome aboard, I wrote the server for MediaMonkey and have made all the 
local code changes here to TunesRemote while I was doing my debugging of 
MonkeyTunes.  So the version on the Android Market is actually behind but only 
the owner of this project can release a new version.

I have compiled the APK of the latest version and put it on this download site.

Good news: I think the reason it doesn't pair with Bonjour is becuase the 
version of JmDNS is 2.0 and they are up to 3.2.1 and fixed MANY bugs with the 
Java Bonjour implementation.   I have it on my list to update to JmDNS 3.2.1 
and see if that fixes the pairing issues.

Original comment by mellowaredev on 29 Aug 2010 at 2:24

[GoogleCodeExporter]

Try the latest download the pairing issues have been fixed.

http://code.google.com/p/android-cookbook/downloads/list

Original comment by mellowaredev on 1 Sep 2010 at 12:05

[GoogleCodeExporter]

Original comment by mellowaredev on 2 Sep 2010 at 1:03

• Changed state: Started

[GoogleCodeExporter]

Now with iTunes 10 pairing is again broken. Phone doesn't see the library, nor 
does iTunes see the phone to pair it. Evo Froyo

Original comment by brian.ro...@gmail.com on 3 Sep 2010 at 5:33

[GoogleCodeExporter]

Crap!  I haven't gotten Itunes 10 yet but I will let you know what I find out.  
I am still using 9.2.

Original comment by mellowaredev on 3 Sep 2010 at 5:52

[GoogleCodeExporter]

If its any help, I did a packet dump of an iPod Touch and the last version of 
TunesRemote. Interestingly tcpdump (OSX 10.6.2) decoded the mDNS announcements 
from the iPod, but didn't decode the announcement from TunesRemote. (I had to 
attempt a manual connection to get it to announce itself in the first place.)

Original comment by brian.ro...@gmail.com on 3 Sep 2010 at 6:19

[GoogleCodeExporter]

Hmmm, I run in the Android 1.6 emulator and compile for 1.6 and it works from 
the emulator.  Maybe it has something to do with Froyo 2.2.  I wonder if I 
should pull the 2.2 SDK and try with that?

Had you any luck with this before Itunes 10?   And you are using the latest 
download right?  I just updated for JmDNS 3.2.1 the old TunesRemote was using 
2.0 which definitely had some bugs in it.

Let me know any other information you gather.

Original comment by mellowaredev on 3 Sep 2010 at 7:08

[GoogleCodeExporter]

Honestly, I hadn't tried it until after I upgraded (or should I say downgraded) 
to iTunes 10. The apk used was the one posted as of yesterday (that I believe 
is only ~2days old). 

I'll try to find some time to tinker more later tonight and will post if I find 
anything interesting.

Original comment by brian.ro...@gmail.com on 3 Sep 2010 at 7:11

[GoogleCodeExporter]

I checked out the trunk from about 15 minutes ago, updated to the Android 2.2 
profile, built and ran it in a 2.2 VM, and it seems to be able to see the 
library, but on selecting it iTunes 10 doesn't begin the pairing process.... 
I'll keep tinkering and will try to compare the packet dumps between the Evo 
and VM and try to see what's happening.

Original comment by brian.ro...@gmail.com on 3 Sep 2010 at 8:35

[GoogleCodeExporter]

you rock.  Anything you need me to check in if you fix it just let me know.

Original comment by mellowaredev on 3 Sep 2010 at 8:40

[GoogleCodeExporter]

Although the original author mentions somewhere the pairing process doesn't 
work in the Emulator because the Emulator doesn't allow incoming Port 1024 
access but the real Android devices do.  It was on his blog post.

Original comment by mellowaredev on 3 Sep 2010 at 8:55

[GoogleCodeExporter]

I've read that, and I wasn't quite so concerned because I couldn't even get the 
library to appear....

So I pulled a computer over w/ iTunes 9.... No joy on either computer from the 
Evo - and the emulator only sees the iTules library on the local machine 
(probably something in the emulator itself, so I'm not going to get two wrapped 
up....

I fired up a copy of tcpdump *on* the Evo tiself to verify.... Both the Emu and 
Evo send a properly formatted multicast query for _touch-able._tcp.local. to 
224.0.0.251.5353.... Where things diverge is only the Emu sees a reply. the Evo 
never gets any return traffic. What I can't be sure of (yet) is if any other 
mDNS responders are attempting to send that reply, but I know no reply comes 
from the machine with iTunes 10.

I'm hesitant to say this isn't iTunes 10 specific, but the initial not seeing 
the library issue may be FroYo-device specific.... I'm open to any ideas.

Original comment by brian.ro...@gmail.com on 3 Sep 2010 at 9:27

[GoogleCodeExporter]

That is some GREAT debugging work.

I have to admit I don't know much about Froyo yet as mostly over the last year 
my MonkeyTunes users were using the Nexus One or G1 or HTC etc and it worked on 
that from 1.5-2.0 Android.  Have not followed much since 2.1 or 2.2 has come 
out so you are the first to report problems.

I was hoping the update to JmDNS 3.2.1 had fixed most of these pairing issues 
but it appears not to be the case!

The only thing I can think of it is at the network device driver level between 
the Emu and Evo???

Original comment by mellowaredev on 3 Sep 2010 at 9:32

[GoogleCodeExporter]

I've been looking at this as well, but my knowledge of mDNS is poor, Running 
SVN TunesControl on a Froyo Desire I can't even get what used to work (manual 
add).

They way I did it before was to click manual add, type in an IP and random 
pairing code. This would cause the phone to announce itself the same way the 
iPhone remote does and I could then start pairing, as it would use the IP I 
gave it for the server (it seemed it couldnt browse, but could register). Now 
the register command doesnt work either, as the phone doesnt appear in Songbird 
on in my mDNS browser.

Wireshark shows that when I start the pairing process, JmDNS sends out 3 ANY 
0000000000000000000000006._touch-remote._tcp.local queries, and then 3 answers 
with a PTR, SRV and TXT bit in them. iTunes Remote does the same thing (except 
it works :) ), I think JmDNS mangles the answer (PTR,SRV,TXT) messages as the 
Wireshark filter doesn't quite decode it correctly. I don't really understand 
how mDNS works, and I'm guessing you 2 don't either, so maybe we should take 
this to the JmDNS guys.

I should point out I'm not touching iTunes 10 here, the problem appears to be 
with the new update of TunesControl on Froyo. Also this isn't to do with 
servers appearing in the server list, its to do with the manual add function 
not causing the phone to announce itself.

On the server listing front I can also confirm that a Froyo VM does list server 
correctly, but then the pairing proces doesnt start because the phone can't 
register its _touch-remote service. On the actual phone no servers are listed.

Summary of JmDNS functions on Android:
2.2 Emulator:
- Browse: Works
- Register: Broken

2.2 Device:
- Browse: Broken
- Register: Broken

Original comment by a.wi...@gmail.com on 4 Sep 2010 at 12:15

[GoogleCodeExporter]

I just added an Issue to the JmDNS Sourceforge page pointing back to this 
thread.

https://sourceforge.net/tracker/?func=detail&aid=3059323&group_id=93852&atid=605
791

Original comment by mellowaredev on 4 Sep 2010 at 12:37

[GoogleCodeExporter]

Perhaps I've hit paydirt....

http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLoc
k.html

I haven't done much (ok, any) Android dev work, so I'm a bit out of my element, 
but fron what I can see, neither the library, nor the app itself call for the 
lock and therefore, if I read the API correctly, receive the MCast DNS reply. 
(Perhaps the emu is broken in that it still gets the reply because it's 
filtered through localhost. Donno.)

I'll tinker with trying to add it and see if I get anywhere, but itll be a 
hack-n-slash job at best.

Original comment by brian.ro...@gmail.com on 4 Sep 2010 at 8:09

[GoogleCodeExporter]

2 Steps forward.... 1 Step back....

Perhaps we're dealing with an android bug...:

http://code.google.com/p/android/issues/detail?id=2917#c46

Original comment by brian.ro...@gmail.com on 4 Sep 2010 at 10:01

[GoogleCodeExporter]

This same question was asked before, answered, except the comment says that a 
HTC incredible doesn't work with the same code, so god knows tbh.

http://stackoverflow.com/questions/2474143/how-can-i-discover-zeroconf-bonjour-s
ervices-on-android-im-having-trouble-wit

Original comment by a.wi...@gmail.com on 4 Sep 2010 at 11:06

[GoogleCodeExporter]

Looks like I'm down to the wpa_supplicant binary and the wireless driver in the 
EVO, the bcm4329.

Short version - adding in some debugging statements fidn this right after I 
request a Mcast lock:

09-04 18:14:14.740: INFO/wpa_supplicant(830): Rx Data Filter Remove [4] command
09-04 18:14:14.740: INFO/wpa_supplicant(830): Rx Data Filter: do not support, 
ignore
09-04 18:14:14.740: INFO/wpa_supplicant(830): Rx Data Filter Remove [3] command
09-04 18:14:14.740: INFO/wpa_supplicant(830): Rx Data Filter: do not support, 
ignore
09-04 18:14:14.740: INFO/wpa_supplicant(830): Rx Data Filter Remove [0] command
09-04 18:14:14.740: INFO/wpa_supplicant(830): Rx Data Filter: do not support, 
ignore

Now... I can't seem to find the source file for wpa_supplicant that includes 
the "do not support" text, so it's hard to be sure, but looking at the stock 
source for some TI wireless chips in the android git tree, it appears as though 
the OS issues a request to the wpa_supplicant on obtaining the first Mcast lock 
to unfilter multicast traffic....  It's hard to tell because the 
wpa_supplicants I've found have params of 0-3, not 0-4, but I'm guessing one of 
those is for multicast.

So, not able to find the wpa_supplicant source, I turned to the HTC EVO kernel 
source and the wifi driver. IT does seem to enable packet filtering by default 
on wake, and disable upon sleep in such a fashion as to render multicast 
filtered by default.... and with wpa_supplicant not removing the filter, it 
seems as any reception of multicast traffic on the Evo (and it's kin) is not 
possible with the stock driver.

... just shoot me now. I'll post back after I've tinkered with the driver some. 
:)

(Yes, getting this working has become a crusade at this point... :)

Original comment by brian.ro...@gmail.com on 5 Sep 2010 at 12:24

[GoogleCodeExporter]

Hi guys I take care of JmDNS. I would really be interested in looking at the 
messages Wireshark do not decode.  Could you send me the binary dump of the 
messages that do not work and those that work?

Thanks

Original comment by arcac...@gmail.com on 5 Sep 2010 at 1:15

[GoogleCodeExporter]

Ok, new news... First, the initial mDNS announcement/reception issue (getting 
the library to appear).... 

I now have 3 "devices" I'm testing from against iTunes 10: (I'm a glutton for 
punishment)

Android Emulator on the PC w/ iTunes 10: Sends/receives mDNS packets and can 
see the iTunes 10 library (from the local machine).

HTC Hero (CDMA): Sends/received mDNS packets and can see the iTunes 10 library.

HTC Evo 4g: Sends but does not receive mDNS replies.

My earlier captures do show a slight difference in packets between the iPod 
Touch and the Evo in the transmission, but given the same build was running on 
the Hero, I may have been in error early pointing at JmDNS. (For that I 
apologize - and unfortunately I don't have the captures handy.)

At this point I have confirmed the wireless driver on the Evo does indeed 
filter packets not unicast or network broadcast to the phone. Multicast on the 
Evo is not going to work out of the box. I'm currently looking at the CM kernel 
which has some patches around the filtering on the wireless driver but that's 
another story...

Speaking to the original post, failure on the HTC Desire - The Desire and Evo 
share the same wireless chipset, and, though I haven't confirmed it via kernel 
source, I would expect the same driver implementation and filtering.

My apologies on taking the long way around this bug but at this point, the 
failure to get the library to appear on the Desire / Evo does appear to be 
OS/Build related, and not software related. (Later problems of failing to pair 
w/ iTunes 10 is an entirely different issue.)

Original comment by brian.ro...@gmail.com on 5 Sep 2010 at 1:55

[GoogleCodeExporter]

Great debugging.  I will continue to work with the JmDNS team to see if I can 
make sure this is not on the JmDNS side of things. I will let you know how the 
results go.

Original comment by mellowaredev on 6 Sep 2010 at 1:23

[GoogleCodeExporter]

Just an update.  I wrote a Junit test in standalone Java on my desktop to test 
the latest JmDNS.  The "touch-able" service appears to be working fine in my 
Unit Test but the Registration of the Remote in iTunes appears to be failing.  
I have sent the JMDNS developer my unit test and my observations.

I have attached the same files if anyone here wants to look at it....

Original comment by mellowaredev on 6 Sep 2010 at 1:56

Attachments:

• itunes-test.zip

[GoogleCodeExporter]

I don't know if this applies, but make sure you're using the latest HEAD from 
JmDNS - There were some typos in one of the files that may cause SRV records to 
be called SRC records. 

Original comment by brian.ro...@gmail.com on 6 Sep 2010 at 5:44

[GoogleCodeExporter]

Hi! We have an iOS app and an Android 2.1 app both using zerconf(bonjour on the 
iOS and jmdns on android). Our problem is that the initial detection of 
services registered by the iOS(in our case an IPad) takes very long. By initial 
detection I mean when both the device has just entered the wifi network and the 
iOS has just started the app that registers a service. This initial detection 
takes approximately 5 minutes. After the first detection and as long as the iOS 
device does not disconnect on the network, the service detection behaves 
normally.

Original comment by hyang...@gmail.com on 20 Sep 2010 at 8:39

[GoogleCodeExporter]

As an additional info, I've added logging in jmdns' SocketListener class so 
that it shows a log whenever a packet is recieved. It seems that the first 
packet received by the android device from the hosting iOS device comes after 
roughly 5 minutes even though the android device has sent multiple queries for 
existing services. Other android devices with the same app(e.g. jmdns to jmdns) 
running replies immediately. The problem is only observed when it is jmdns 
asking for services that should be advertised by bonjour.

Original comment by hyang...@gmail.com on 20 Sep 2010 at 9:35

[GoogleCodeExporter]

Just to let everyone know we duplicated this issue on the new TunesRemote+ 
project to track it over there as well...

http://code.google.com/p/tunesremote-plus/issues/detail?id=1

Original comment by mellowaredev on 27 Sep 2010 at 12:34

[GoogleCodeExporter]

This issue has been resolved in TunesRemote+ by reverting back to JmDNS 2.0.  
This fixes it for everyone except those of you that own HTC Desire, it still 
has the WIFI driver issue listed above.

Original comment by mellowaredev on 29 Sep 2010 at 10:39

[GoogleCodeExporter]

It looks like there has been quite a bit of debugging to determine that the WPA 
supplicant is the problematic binary.  The problem is that I have the same 
issue with WEP.  I haven't heard anyone mention that so I just wanted to let 
everyone know it's a bit more widespread than just WPA.

Here are a few details:
Android Version: 2.2
Kernel Version: htc-kernal@and18-2#17
Baseband Version: 2.15.00.09.01
Wireless Security: WEP
Phone: HTC EVO

Original comment by WesGils...@gmail.com on 4 Dec 2010 at 10:31

[GoogleCodeExporter]

As for the comment in #29, the WPA supplicant is active even if WEP is used, so 
the problem behavior is expected.

On to better news, for EVO owners at least, flips Fresh EVO ROM, as of 3.5.0, 
is now working with mDNS. (And thus, TunesRemote). The 3.5.0 mod is based off 
the latest Sprint/HTC OTA update, which gives some home for those running a 
stock ROM. (The OTA is version 3.70.651.1, and may differ slightly depending on 
your hardware version.)

If you're running a stock ROM, and have the OTA (check for Swipe keyboard), let 
us know if TunesRemote is working (or at least finding the library) for you.

Original comment by brian.ro...@gmail.com on 21 Dec 2010 at 9:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Interesting note about the WPA active if WEP is used, didn't figure that.  
Sorry it took so long to get back to you on this, but my interest level dropped 
quite a bit knowing that such a huge issue could exist.  Unfortunately, the 
problem still exists on the EVO stock ROM with the exact OTA version posted in 
comment 30 (3.70.651.1).  

I've got a really nasty little hack that works around this issue by taking 
advantage of the fact that uni-cast still works fine on these phones.  The hack 
allows broken phones to communicate with one another as long as you have at 
least one phone that can receive broadcasts and is also running the hack.  It 
also requires phones to know that they are broken, which means I'm compiling a 
list of broken phones for the hack.  So if you have this issue and you'd like 
to help me out a bit, respond back with your android.os.Build.MODEL and I can 
get the model added to my "busted phones" list.

Original comment by WesGils...@gmail.com on 7 Feb 2011 at 5:52

[GoogleCodeExporter]

Original comment by mellowaredev on 7 Feb 2012 at 12:41

• Changed state: WontFix