Kodi Community Forum
Help us solving the AirPlay issue when using iOS7 devices - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: OS independent / Other (https://forum.kodi.tv/forumdisplay.php?fid=228)
+---- Thread: Help us solving the AirPlay issue when using iOS7 devices (/showthread.php?tid=179961)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - Axuttaja - 2014-01-10

How could i parse the Features hex myself?


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - edrikk - 2014-01-10

Let me rephrase my statement to make it simpler: Punch the Hex code here http://www.mathsisfun.com/binary-decimal-hexadecimal-converter.html Smile


What's weird is that in the unofficial spec, I just noticed "bit 6" is missing... WTF Is that a typo?

0 Video video supported
1 Photo photo supported
2 VideoFairPlay video protected with FairPlay DRM
3 VideoVolumeControl volume control supported for videos
4 VideoHTTPLiveStreams http live streaming supported
5 Slideshow slideshow supported
7 Screen mirroring supported
8 ScreenRotate screen rotation supported
9 Audio audio supported
11 AudioRedundant audio packet redundancy supported
12 FPSAPv2pt5_AES_GCM FairPlay secure auth supported
13 PhotoCaching


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - Axuttaja - 2014-01-10

0_o Interesting...
But does this mean that
110110001000 (Video=Yes Picture=Yes FairPlay=No...)
would be d88 which would make 0xd88? these bit are a new thing for me, Please?

@Memphiz sometimes when I launch testbuild 6 it doesn't follow instructions on airplay.xml, when checking from Bonjour Browser
Edit: typos in XML -_-


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - edwr - 2014-01-10

After further testing, it seems as long as the model is AppleTV* and the version is > ~120 and < ~160 (I can't be arsed to find the exact tip over points) and up to two decimal places it'll always display as a video target (w/ mirroring). Those were approximately the lowest and highest srcvers of AppleTVs via a google search.

One possible (and ugly) stopgap fix, at least until Memphiz or someone figures out the new back and forth communications, would be to have a toggle for audio-only or video-only in the airplay settings menu. Audio-only would default to the old announcements, which would always display at least an audio target and had working audio. Video-only toggle would change the model and version announcement and no longer have working audio, but at least it should always display a video target and (non-drm) video should mostly work?


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - Memphiz - 2014-01-10

(2014-01-10, 20:09)edwr Wrote:
(2014-01-10, 20:05)Memphiz Wrote: Beware ... i parse the feature hex number into dec - writing a string there might behave strange or even crash Wink. Did you verify that this announcement really was visible in bonjour browser?

Yeah, checked with bonjour browser to make sure.

http://imgur.com/ZMgDDXw
http://imgur.com/mtICt3S

LOL - i really tend to make this the default announcement Wink


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - Memphiz - 2014-01-10

(2014-01-10, 20:46)Axuttaja Wrote: 0_o Interesting...
But does this mean that
110110001000 (Video=Yes Picture=Yes FairPlay=No...)
would be d88 which would make 0xd88? these bit are a new thing for me, Please?

@Memphiz sometimes when I launch testbuild 6 it doesn't follow instructions on airplay.xml, wham checking from Bonjour Browser

You have to read binary from right to left ... 1100 ... is bit 0 - 0, bit 1 -0, bit 2 -1, bit3 - 1


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - edrikk - 2014-01-10

@edwr

It seems you're right. Although in my initial successful tests I did manage to have "Xbmc,1" come up at Video, I can't anymore... But AppleTV3,2 always does.

However, regardless of this, Apple seems to want to force FairPlay for the Audio side no matter how I set the mask (which is why the libshairplay author might be able to help more)...

For example,
0X1000009DC which I modified from the AirServer version still throws the same /fp-setup error (so same behaviour as 0x39f7) .

I think I've gone as far as I can go today I'm afraid...


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - Memphiz - 2014-01-10

Really good work so far. Thx so much that you are spending so much time on this - i don't feel alone anymore Smile


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - edrikk - 2014-01-10

Last piece of info for today (unless my obsessive compulsive takes over):

IF you can get a NON AppleTVX,Y model to show as Video, then EVERYTHING does work!
If you use AppleTVX,Y model, then Music *seems* to force Fairplay.

For example, I just changed the setting to be as follows (notice the new Feature Mask which seems to turn of mirroring correctly in this setup), and the results are nearly perfect!
No "mirroring" option, music plays perfectly, pictures are shown (but not correct), video shows perfectly from youtube app, but due to the pictures issue gotta go back-and-forth a few times for it to try to load from the Camera Roll. You'll notice I set "Xbmc,2" because "Xbmc,1" for the last while was just giving me Audio Speaker.

Code:
<!-- values taken from airserver -->
<!-- see http://nto.github.io/AirPlay.html#servicediscovery-airtunesservice for slightly outdated reverse engineering -->
<airplay>
<genericannounce>
<!--  <mac>FF:FF:FF:FF:FF:F3</mac> --><!-- uncomment for overwriting the real mac with custom value -->
  <features>0X3133</features> <!-- features bit field -->
  <model>Xbmc,2</model> <!-- the model name -->
  <srcvers>150.33</srcvers> <!-- used protocol version -->
</genericannounce>

<airplayannounce>
  <entry key="vv" value="1" /> <!-- key value pair to announce as txt record via zeroconf -->
</airplayannounce>

<airtunesannounce>
  <entry key="txtvers" value="1" />
  <entry key="cn" value="0,1" /> <!-- supported audio codecs pcm and alac -->
  <entry key="ch" value="2" /> <!-- number of supported channels 2 -->
  <entry key="ek" value="1" /> <!-- undocumented -->
  <entry key="et" value="0,1" /> <!-- supported encryptions 0-no enc, 1-RSA, 3, FairPlay, 4 - MFiSAP, 5-FairPlay SAPv2.5 -->
  <entry key="sv" value="false" /> <!-- undocumented -->
  <entry key="tp" value="UDP" /> <!-- transport protocol -->
  <entry key="sm" value="false" />  
  <entry key="ss" value="16" /> <!--sample size 16 bit -->
  <entry key="sr" value="44100" /> <!-- sample rate 44100 hz -->
  <entry key="pw" value="false" /> <!-- no password protection -->
  <entry key="vn" value="65537" /> <!-- undocumented -->
  <entry key="da" value="true" /> <!-- undocumented -->
  <entry key="md" value="0,1,2" /> <!-- metadata support 0-text, 1-artwork, 2-progress -->
  <entry key="sf" value="0x4" /> <!-- undocumented -->
  <entry key="rhd" value="4.7.1" />
</airtunesannounce>
</airplay>



[EDIT] I just as a test ONLY changed the Model to AppleTV3,2 in the above, and Mirroring option came back, which means that Fairplay is back, which means Audio won't play. Changed it back to Xbmc,2 and guess what? I only get the speaker now! LOL! (but again no mirroring)![/EDIT]


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - edwr - 2014-01-10

As an aside, I was wondering why the original fix by samnazarko with all three announcements changed was still inconsistent (as that's what the latest openelec rpi gotham newclock3 builds are using) and that's because the srcvers there is 160.10, which is a tiny bit too high apparently

edit:@edrikk, you can repeatedly toggle wifi in the control center to force it to change between audio and full target (or full target and unavailable for AppleTV + incorrect srcvers) randomly


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - edrikk - 2014-01-10

You're right.

3 Toggles for "Xbmc,2" gave 1 "Screen" and 2 "Speakers"


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - edwr - 2014-01-10

Here's the complete breakdown as far as I can tell:

1. Model != AppleTV*: Feature bits, airtunes announcements are adhered to. Will occasionally display as an audio-only target, with working audio (assuming correct encryption announcement), photos and video not working obviously. Will occasionally display as a full target (w/ mirroring depending on feature bits), with working audio (assuming correct encryption announcement), working photos (might be jumbled depending on feature bits), working nondrm video.

2. Model = AppleTV*, srcvers < ~120 or > ~160: Feature bits, airtunes announcements are adhered to. Will occasionally display as a full target (w/ mirroring depending on feature bits), with working audio (assuming correct encryption announcement), working photos (might be jumbled depending on feature bits), working nondrm video. Will occasionally not show up in Airplay menu at all.

3. Model = AppleTV*, ~120 < srcvers < ~160: Feature bits, airtunes announcements disregarded. Will always display as a full target (w/ mirroring), with not working audio, jumbled photos, somewhat working nondrm video. Airplay target must be selected prior to video start for xbmc to play. 1 and 2 also let you select airplay target after video start.


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - Axuttaja - 2014-01-10

(2014-01-10, 21:40)edrikk Wrote: Last piece of info for today (unless my obsessive compulsive takes over):


[EDIT] I just as a test ONLY changed the Model to AppleTV3,2 in the above, and Mirroring option came back, which means that Fairplay is back, which means Audio won't play. Changed it back to Xbmc,2 and guess what? I only get the speaker now! LOL! (but again no mirroring)![/EDIT]
Nice! I didn't figure out that AppleTV3,2 was forcing Fairplay.
I've been working on that why isn't XBMC,2 consistently Monitor, none of the other entries affect the thing... Except I haven't tried feature bits, try that.(why did i not think of that :/)
But retoggling AirPlay from settings works every time and makes it a Monitor icon, maybe it changes something in the announcment by accident?


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - Memphiz - 2014-01-11

(2014-01-10, 22:20)edwr Wrote: Here's the complete breakdown as far as I can tell:

1. Model != AppleTV*: Feature bits, airtunes announcements are adhered to. Will occasionally display as an audio-only target, with working audio (assuming correct encryption announcement), photos and video not working obviously. Will occasionally display as a full target (w/ mirroring depending on feature bits), with working audio (assuming correct encryption announcement), working photos (might be jumbled depending on feature bits), working nondrm video.

2. Model = AppleTV*, srcvers < ~120 or > ~160: Feature bits, airtunes announcements are adhered to. Will occasionally display as a full target (w/ mirroring depending on feature bits), with working audio (assuming correct encryption announcement), working photos (might be jumbled depending on feature bits), working nondrm video. Will occasionally not show up in Airplay menu at all.

3. Model = AppleTV*, ~120 < srcvers < ~160: Feature bits, airtunes announcements disregarded. Will always display as a full target (w/ mirroring), with not working audio, jumbled photos, somewhat working nondrm video. Airplay target must be selected prior to video start for xbmc to play. 1 and 2 also let you select airplay target after video start.

I really like your rational way of debugging this. :o)

I have something cooking again on the buildbot. I have implemented the photo caching (photo order will be corrected this way). Also i have switched the startup order - the next build first starts the airtunes server and then the airplay server. Its just a guess but maybe this is makeing it better. Beside that i would say we should go with the Xbmc,* model for now for having audio working.

Will add the links to the first post once the builds are done ... but i bet you will spot them on the mirrors before Wink

Here is the current commit log of that branch:

https://github.com/Memphiz/xbmc/commits/ios7airplaytry

Also in my tests the feature bits from the "server-info" command indeed alter behaviour of the used protocol. If i set them different each airplay request starts with the dreaded "/fp-setup" - or it doesn't get fired at all - doesn't matter what the bits in the announcement are in that case ... but in not like with airtunes - i just answer that fp-setup with an ok or an error and it just gets ignored and communication stays unencrypted.

Basically it seems the airplay protocol only uses fairplay if the server answers the handshake - and falls back to unencrypted immediatly, while airtunes really expects a valid handshake. (or libshairplay just doesn't send the correct rejection answer - nobody knows how this answer should look like i guess hehe).

The cache thing has one flaw. If i cached an image and deleted it and the client requested that cached image - based on the reverse engineered protocol the server should answer with "412 Precondition Failed" - to tell the client that we have a cache miss. Well i tested this case and the client just ignored the error. In that case xbmc doesn't switch the picture until the next pictures is swiped on the ios device.

So it seems that cache failed answer is wrongly documented in the unofficial airplay protocol Sad - (though this error can only be hit if someone deletes the cache on the filesystem during an airplay session ...)


RE: Help us solving the AirPlay issue when using iOS7 devices - Testers needed! - edwr - 2014-01-11

Thanks for the new code Memphiz! Tested a few things with this build:

- XBMC now always displays the correct photo in situations where it used to be out of order, so photo caching works brilliantly.
- Unfortunately, starting airplay after airtunes didn't make the full target show up more consistently. If anything, I'd guess that the previously noted (posts 27-29) behavior of XBMC more frequently showing up as a full target at first was due to airplay starting first.
- Not sure how to test the un-encrypted fallback? I tried sending music with encryption ("et" set to "0,1,3,5") turned on, but it wouldn't work. "0,1" still works, obviously.

As an aside, I'm worried renaming the model (to Xbmc,1 or whatever) might be a dead-end, especially if Apple is hard-coding consistent Airplay video support only for their AppleTVs going forward, which considering they don't license out Airplay video capability (?) is a possibility. Airserver and Reflector, the two somewhat readily available ios7-compatible software Airplay receivers both announce AppleTV and a valid srcvers, and thus always report as a full target. If there was an easier way that didn't involve reverse engineering the new handshakes, I'm assuming they would've done it :/


That said, two ideas for the model renaming case anyway:
- What happens when only airplay is started and not airtunes? I'm assuming audio wouldn't work, but if the full target displayed consistently and photos and videos did work, the two could perhaps be separated in the settings.
- I don't know much about networking protocols, but I did skim Apple's bonjour overview. These were the lines that stood out to me:

Quote:Service discovery in Bonjour is accomplished by “browsing.” An mDNS query is sent out for a given service type and domain, and any matching services reply with their names. The result is a list of available services to choose from.

[...]

When a host is browsing for services, it does not continually send queries to see if new services are available. Instead, the host issues an initial query and sends subsequent queries exponentially less often, for example: after 1 second, 3 seconds, 9 seconds, 27 seconds, and so on, up to a maximum interval of one hour.

This does not mean that it can take over an hour for a browser to see a new service. When a service starts up on the network, it announces its presence a few times using a similar exponential back-off algorithm. This way, network traffic for service announcement and discovery is kept to a minimum, but new services are seen very quickly.

I'm going to guess that XBMC sometimes shows up as an audio-only target because the device received the airtunes announcement first, and as of ios7, no longer checks for corresponding airplay announcements (if model and srcvers don't match specified criteria). Is it possible to simply add a short delay to the airtunes response, to guarantee the airplay response is received first? And approaching from the other angle, drastically reduce the frequency of airtunes initial announcements? Those are just shots in the dark - apologies if that's not how it works or is not possible to implement