• 1
  • 4
  • 5
  • 6(current)
  • 7
  • 8
  • 20
[AirPlay][Warning] Don't update to iOS8 if you want AirPlay
#76
iOS 8 shows a lot of potential (especially extensions support, which I'm already liking) but boy the 8.0 release was rushed and buggy... I'm preying that the performance of my iPad 3 can be fixed in the next few minor releases because at the moment its a slow, stuttery crashing mess that has me wanting to throw it out the window sometimes...
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#77
(2014-09-26, 11:51)Memphiz Wrote: Another updatte. This time i added the rate==0 "/play" which wants us to start paused. This still only works for the very first video in photo app. If you want to hit play again the ios device just goes black and doesn't send anything to XBMC. I have no clue how to further fix this tbh.
Don't loose heart, good progress is being made. Smile

I can verify what you're saying about the photos app - it seems to me like some sort of caching is going on where the airplay receiver is expected to remember the last few videos that have been requested - a bit like the photo cache.

Perhaps when the video reaches the end the xbmc should remember the URL of the last played video then if it receives another rate=1 message (which is used to unpause ?) it should start playing the most recent video from the beginning again ? The blank screen on the iOS device could just be the iOS device waiting for this to (never) happen...

It looks like once the end of the video is reached xbmc terminates the playback session completely and perhaps the iOS device is expecting it to maintain a connection waiting for more commands (such as replaying the same clip from the beginning ?)

What's the best way to monitor the control channel messages - just a packet sniffer running on the xbmc box ? And how did you extract the plist you posted earlier that had rate 0 ?

If I can monitor the control messages in real time maybe I can spot a pattern...
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#78
(2014-09-24, 13:20)Memphiz Wrote: I don't think there is an easy way to fake the mac address which comes from the layer2 of the network stack. We only can influence the mac adress used in the announcements i guess.

the mac address advertised is irrelevant, you really could put anything there...

In earlier mythtv's airplay implementation, we used a random number, and it was different between the RAOP and the Airplay service. This caused two devices to appear on the iPhone, one video only and one audio only. You had to constantly switch between the two.

Making the mac address the same, made it behave the same as an AppleTV, it appears as a video device but it can do both audio and video.

In iOS 5 and later however, if you were advertising only an airplay (video) device and no corresponding raop one, it would not be displayed in the list of airplay device.

I was thinking earlier today, a fix, could be that we could advertise 3 services.
1, that appears like the old airport express, RAOP, RSA encryption only, with a unique deviceid/mac address
The name would be "Blah (Audio Only)"

And two services, both with the same deviceid/mac address, the first service RAOP linking back to the first service, but with fairplay support) , the second service being airplay, with the fairplay set. The name would be "Blah (Video/Phonto Only)

You would have to select "Blah (audio only)" if you want to stream music. For videos and photos, you use the other service.

Not ultra convenient, but that would work. That behaviour would be linked to an iOS 8 flag somewhere
Reply
#79
Unless I've missed something, the solution we found by tweaking the announcements should obviate the need to broadcast completely independent (different mac address) audio and video devices like you describe ?

There is still some work to improve the handling of playing video from the photos app, but those problems were there ever since the beginning of iOS 7 and are a separate issue...
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#80
I hadn't read the whole thread before I posted, only resumed on the first post I hadn't read Smile

I'm reflashing an iPhone 4S with iOS 7.1.2. Luckily, Apple still signs those so you can still go back

(2014-09-26, 14:23)DBMandrake Wrote: There is still some work to improve the handling of playing video from the photos app, but those problems were there ever since the beginning of iOS 7 and are a separate issue...


what are those?
my code in mythtv works just fine for the photo app ... only issue is when you swap photos quickly, and cross a video, and immediately stop to get to another photos. Sometimes that mess things up a bit...
Reply
#81
Actually your suggestion for separate audio and video services (three announcements, one with a fake MAC address) would be useful as a workaround for Android where the reannoucement hack doesn't work.

If the airplay model is announced as an AppleTV instead of xbmc it is seen as a video device immediately without the reannoucement hack...

That forces FairPlay for audio but presumably not for the separate fake MAC address audio only raop service.

A bit messy having a different implementation for android mind you. Wink
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#82
(2014-09-26, 14:38)DBMandrake Wrote: Actually your suggestion for separate audio and video services (three announcements, one with a fake MAC address) would be useful as a workaround for Android where the reannoucement hack doesn't work.

If the airplay model is announced as AppleTV instead of xbmc it is seen as a video device immediately without the reannoucement hack..

That forces FairPlay for audio but presumably not for the separate fake MAC address audio only raop service.

I clearly remember last year when I was trying to fix the iOS issue. Using AppleTV in the announcement was one of the first thing I tried. And while it made the iPhone see the device instantly; it caused raop to stop working (as it forced FairPlay). And seeing that I personally use raop more often than AirPlay, it's not suitable (at least for me)
Reply
#83
(2014-09-26, 13:33)DBMandrake Wrote:
(2014-09-26, 11:51)Memphiz Wrote: ... goes black and doesn't send anything to XBMC...
Perhaps when the video reaches the end the xbmc should remember the URL of the last played video then if it receives another rate=1 message (which is used to unpause ?) it should start playing the most recent video from the beginning again ?

Yes thats what i thought too - but as i wrote - it doesn't send anything to xbmc - it requests the server-info once and likely doesn't find the key/value pairs in it it expects. XBMC doesn't close the connection if you mean that. We only announce a "stop event" - since the client ignores all our events this doesn't make anything worse.

I sniff the stuff with wireshark. The plist can be listed via

dumpplist in airlay.cpp (just call it with the dict and the dll somewhere in the /play handler and it will dump it into xbmc.log) - to be found int my airplayios8 branch
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Reply
#84
Hold that PR Memphiz, I've been doing some more experimentation and I think I've just reduced the iOS 8 fix to a single line patch. Smile (excluding the rate==0 photos app issue which is kinda separate)

Will post details as soon as I'm happy that I understand it correctly.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#85
Not directly related to the problem at hand, but I was experimenting with a custom build of 13.2 with tweaked airplay announcements for my daily use (I'm not ready to start using Helix for regular use yet) so that I could at least use video and audio airplay again, even if photos didn't work properly. (I don't use photos so don't mind)

It was also bothering me that we changed a number of things and that we weren't 100% certain how many of those changes were actually needed - I couldn't help experimenting with the announcements again and tried reverting srcvers back to 101.28 and vs to 130.14 - as they originally were in Gotham but keeping the new features bitmask. It still worked absolutely fine on iOS 7 and iOS 8 - I couldn't tell any difference. Wink

It looks like all the secret sauce of getting it to work with iOS 8 is in the features bitmask, so if you want to simplify the code change in your PR and minimise the impact it doesn't seem necessary to advertise later version numbers as we first thought - this also avoids a potential issue in the future where one version is advertised and another reported when connecting - at the moment that doesn't seem to cause a problem but who knows what might happen in the future with a version mismatch.

Here's my theory on how the various parameters are interpreted by the client:

If the model is reported as a known version of the AppleTV, eg AppleTV2,1 or AppleTV3,1 the features bitmask is ignored and the supported feature set is derived from the version numbers - eg Apple knows that an Apple TV reporting 130.14 supported certain features, while 150.33 supported an increased set of features. There's no need for the client to check the bitmask (even though the AppleTV probably sets it) because Apple control the firmware versions and features of the Apple TV. So the bitmask gets ignored.

If the model is reported as an unknown model such as Xbmc,1 (3rd party vendor) then the version numbers don't matter as much or perhaps don't even matter at all. In the case of an unknown model the bitmask is used instead.

I spent a couple of hours tonight trying individual bits in the bitmask to get a better sense of what's going on - I tried both going backwards from a known working bitmask of 0x100029FF and forwards from the known broken bitmask of 0x77.

The first thing I discovered is that we don't need to set the bit for photo asset caching Smile At least not with the old version numbers re-instated. By turning bit 13 off the photo library now works properly with 13.2, so you may not need to implement the photo asset library at all - it certainly doesn't seem any slower to me without it. (Maybe keep it in your back pocket though in case it ever does become mandatory)

Next thing I tested was removing bit 31 - it's not documented and I can't find any change when disabling it. I then tried disabling mirroring (bit 7) and videofairplay (bit 2) both individually and together. The results are:

2 and 7 both off: detected as a video device but both video AND audio fail to work.

2 off, 7 on: video works but audio does not! (disabling the videofairplay bit kills audio for some reason)

2 on, 7 off: (this is original XBMC) audio works but video does not.

2 on, 7 on: both audio and video work.

I then decided to work forwards from 0x77 to see what the absolute minimally intrusive change is that fixes the iOS 8 issue.

It turns out it's very simple - changing features from 0x77 to 0xF7 (turning on bit 7 for mirroring) is the ONLY change needed! No other mystery bits, no changes to version numbers, no changes to model numbers, no photo cache support code required. A single line patch to restore functionality to the same level that we had with iOS 7. Smile

I've also tested 0xF7 with iOS 7 and iOS 6 - they are all working for audio, video, photos. IMHO this single bit change in the bitmask should be enough of a no brainer to go even into Gotham, if another maintenance release of Gotham is planned...(if not, Helix I guess) It is certainly going into my own custom build of Gotham.

Of course this doesn't address the separate issue you're looking at with rate support for the photos app, but that is a more intrusive fix and as yet we haven't got to the bottom of what's going on in the photos app even though honouring the rate in the initial connection does seem to be the right thing to do....but not the whole solution.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#86
(2014-09-28, 21:57)DBMandrake Wrote: It turns out it's very simple - changing features from 0x77 to 0xF7 (turning on bit 7 for mirroring) is the ONLY change needed! No other mystery bits, no changes to version numbers, no changes to model numbers, no photo cache support code required. A single line patch to restore functionality to the same level that we had with iOS 7. Smile

not working for me here...

At least not consistently..

I see playback causing data to be sent from the iphone only about 1 in 10 times...
Reply
#87
(2014-09-29, 04:21)jyavenard Wrote:
(2014-09-28, 21:57)DBMandrake Wrote: It turns out it's very simple - changing features from 0x77 to 0xF7 (turning on bit 7 for mirroring) is the ONLY change needed! No other mystery bits, no changes to version numbers, no changes to model numbers, no photo cache support code required. A single line patch to restore functionality to the same level that we had with iOS 7. Smile

not working for me here...

At least not consistently..

I see playback causing data to be sent from the iphone only about 1 in 10 times...
More info please ? What iOS device and iOS version ? What app is sending video ? Home or enterprise wifi network ?

Is this on Gotham 13.2 with the above tweak to the source or are you testing it on your Myth TV implementation ?

Does changing features back to 0x100029FF help ?

How about 0x100009FF, or 0x9FF ?

The re-announcement hack is still required, and I can't speak to other Airplay implementations than the one in Gotham.

For me on three different devices the results are absolutely identical to the previous suggested fix with the big long devices value, faked versions etc...
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#88
(2014-09-29, 04:21)jyavenard Wrote:
(2014-09-28, 21:57)DBMandrake Wrote: It turns out it's very simple - changing features from 0x77 to 0xF7 (turning on bit 7 for mirroring) is the ONLY change needed! No other mystery bits, no changes to version numbers, no changes to model numbers, no photo cache support code required. A single line patch to restore functionality to the same level that we had with iOS 7. Smile

not working for me here...

At least not consistently..

I see playback causing data to be sent from the iphone only about 1 in 10 times...
Any more word on this ?

Can you confirm if the issue you're seeing is with XBMC (if so what build etc) or some other Airplay implementation like MythTV ?

0xF7 is still working really well for me, especially in combination with the following patches that fix an intermittent airtunes issue that has been there (at least for me) for more than a year:

http://forum.xbmc.org/showthread.php?tid...pid1805240

Memphiz: have you had time to try any testing with only changing features to 0xF7 and not changing the versions etc ? The less changed the safer IMHO.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#89
Is there any way to apply this "patch" to raspbmc? I've no idea where to change the features, as you say. I'm kind of a noob but I miss AirPlay on my pi since I've used it every day. Any help is appreciated.
Thanks!
Reply
#90
(2014-10-01, 15:23)DBMandrake Wrote: Any more word on this ?

Can you confirm if the issue you're seeing is with XBMC (if so what build etc) or some other Airplay implementation like MythTV ?

0xF7 is still working really well for me, especially in combination with the following patches that fix an intermittent airtunes issue that has been there (at least for me) for more than a year:

http://forum.xbmc.org/showthread.php?tid...pid1805240

Memphiz: have you had time to try any testing with only changing features to 0xF7 and not changing the versions etc ? The less changed the safer IMHO.

it is with myth.

but the logic behind it is extremely close to xbmc... and here the problem is that the airplay server not even getting queries from the iPhone...
so doesn't matter how things are implemented...

Edit: it works fine for all applications, but iPhoto and videos taken on the iphone directly. I've seen it works, so long as the server receives the URL. But most of the time the iPhone sends nothing.
I see that in XBMC you changed the features from 0xF7 to 0x20F7, maybe that's why it makes a difference
Reply
  • 1
  • 4
  • 5
  • 6(current)
  • 7
  • 8
  • 20

Logout Mark Read Team Forum Stats Members Help
[AirPlay][Warning] Don't update to iOS8 if you want AirPlay1