I've got a fun one for you.
For some reason iTunes (and I suspect iOS 5) is "combining" services of AirTunes and AirPlay. I suspect on the AppleTV side of things they don't have a problem (and it was probably done to reduce confusion on the user side of things.)
Prior to the latest iTunes and iOS5 if a device had both AirPlay and AirTunes it would show up as separate entries (One with a speaker icon and one with a monitor icon next to it).
However if the MAC address from _airplay._tcp device id matches the MAC address from before the @ in _raop._tcp it will only display a monitor.
It takes the AirPlay's port and ignores what _roap is saying (I think). Meaning tada nothing coming through the speakers. Additionally, it doesn't seem like an AirPlay device will exist without AirTunes present. HOWEVER, there is a bug in iTunes that it still shows the device selection dialog, there's just nothing there but "Computer". If I had to guess I'd say the GUI display has an "if you find airtunes or airplay, display dialog" however in the dialog dropdown it's a "if you find airplay AND there is airtunes running, display the remote device".
Can someone with an AppleTV2 get Bonjour browser and take screenshots of what is showing up with them (without XBMC running) for AirPlay and AirTunes?
Examples:
This shows up as a remote speaker.
Code:
avahi-publish -s 001122334456@Testing _raop._tcp 36666 ch=2 cn=0,1 ek=1 et=0,1 pw=false sm=false sr=44100 ss=16 sv=false tp=UDP txtvers=1 vn=3
Now, if I launch an AirPlay instance, that changes to a monitor:
Code:
avahi-publish -s Testing@htpc _airplay._tcp 8000 deviceid=0:11:22:33:44:56 features=0x77 model=AppleTV2,1 srcvers=101.28
However if you click on it, it does nothing. It unchecks itself immediately.
Now kill both instances. iTunes returns to nothing.
Now. Fire up JUST the AirPlay announcement.
Code:
avahi-publish -s Testing@htpc _airplay._tcp 8000 deviceid=0:11:22:33:44:56 features=0x77 model=AppleTV2,1 srcvers=101.28
Legacy code goes "Aha. Display that thingy". So I know it's seeing the announcement. But when you go to it, nothing is there.
How to fix it?
You are going to need to change the AirPlay MAC address somehow for AirTunes. I just incremented by 1. It really doesn't "need" the MAC address it's just something unique.
Publish this as AirTunes.
You then need to create a matching AirPlay/AirTunes device and publish that also. Meaning you're going to do 2 _raop publishes, but one is just going to be a dummy for the AirPlay video.
Code:
CStdString appName;
CStdString appNameDummy;
appName.Format("001122334455@%s","Real AirTunes");
appNameDummy.Format("%s@%s", m_macAddress.c_str(), "Dummy Airtunes");
std::map<std::string, std::string> txt;
txt["cn"] = "0,1";
txt["ch"] = "2";
txt["ek"] = "1";
txt["et"] = "0,1";
txt["sv"] = "false";
txt["tp"] = "UDP";
txt["sm"] = "false";
txt["ss"] = "16";
txt["sr"] = "44100";
txt["pw"] = "false";
txt["vn"] = "3";
txt["txtvers"] = "1";
CZeroconf::GetInstance()->PublishService("servers.airtunes", "_raop._tcp", appName, port, txt);
CZeroconf::GetInstance()->PublishService("servers.airtunesDummy", "_raop._tcp", appNameDummy, port+1, txt);
Problem Fixed. Drinks for everyone!
Nope. Denied.
If I connect to the Dummy, it just sits there and spins.
And all this time the latest git pull from shairport works just fine. I haven't seen any commits by them about doing anything different. TCP dumps look near identical. I'm too lazy to dig through Wireshark.
But if you have the latest iTunes/iOS, that's what up.