[DBMandrake]

@AussieFries - all kudos to DBMandrake this time really. He has done the dirty work in finding out the right bits. Implementing this into testbuilds was not even called work imo.

@DBMandrake - well the problem with the cameraroll video which starts to play is not a shortcoming of the used airplay library because for photos and video it is no library involved (its code in our codebase handling all this). What you describe looks like a big change in the airplay protocol to me. Normally ios sends a /play command with the url attached when it wants us to play something. The case you describe is that it sends the /play with url without wanting us to start playback but instead only start buffering.

Somewhere buried in the iOS 7 thread (I think) is when I first brought up this problem about 6 months ago - I'd have to test iOS 6 (will do over the weekend) but from memory I think the problem first appeared in iOS 7.

My interpretation of it is that it's a video version of the photo asset cache introduced in iOS7 in the sense that when the user lingers on a particular video while scanning through the photo library Apple want the video pre-buffered and ready to play when the user presses the play button.

So when you scroll through and stop on a particular video first the still image is sent for display, then almost immediately a URL for the video is sent so that an HTTP request is made for the video and an initial portion of the video is buffered in the background and immediately ready for playback when pressing play.

Then when the user presses play another command is sent to tell the AppleTV to actually display and un-pause the buffered video and start playing it. If the user instead moves to the next video/photo in the roll the pre-buffered stream is aborted without being displayed or played.

It must be something like this - otherwise how does XBMC know what URL to use to download the video before the user asked for it to be played ? The photos app must be providing the URL in advance before the user presses play.

Now that I think back, when the Youtube app was first broken and then fixed (/play command support added in xbmc ?) there was a lot of strange behaviour when switching videos in the youtube app where they would start and stop unexpectedly and get out of sync with the user interface on the iOS device, perhaps also a symptom of misinterpreting the meaning of the /play command ?

There is another command called /rate 1/0 which atm is used for pause/unpause playback - might be that i got it all wrong the whole time. I think its really risky to change the airplay code here (e.x. on /play only "save" the url to be played back and wait for /rate 1 to actually start playback).

I agree the changes are very risky if we don't fully understand the consequences - and they definitely shouldn't be part of the same PR because the iOS 8 detection issue is completely separate. But it might be worth exploring a fix with a separate experimental PR on top of the first - I would certainly be willing to test it.

---

I played with that build for a while last night. I found it took several attempts to start playback correctly.
Sometimes xbmc didn't respond at all. Sometime the screen blanked as if were about to start playback but stopped immediately.
At this point I found that video wouldn't play even when airplay target was switched back to iphone.

This sounds like what happens when the mirroring feature bit (7) is not enabled - the video device can be selected but attempting to play results in a black frozen screen on the iOS device and no response or a blank screen on XBMC.

When this happened did you see a mirroring switch on the iOS device and was it definitely switched off ? (It must be off)

Can you use something like dns-sd to verify the correct features bits are being advertised in the bonjour announcements - eg those I posted a few posts back ?

What distribution is your XBMC build installed on ? I seem to remember that Raspbmc had it's own avahi hack some time ago that sent additional bonjour announcements external to XBMC - anything like that may be causing issues, especially intermittent ones.

Are you testing on an "ordinary" home wireless network, or like me were you testing on an enterprise wireless network which has some kind of bonjour management service ? (It's called "Service Control" on Meru, not sure about others) These can interfere with the announcement refresh hack XBMC is using.

As I'm one of the admins I was able to turn this off on our wireless network for a while to finish my testing...