[miappa]

Pi test builds with these commits for Raspbmc and OpenELEC already exists.

[popcornmix]

Can you provide testbuilds for Raspberry PI?

Latest build here has it:
http://forum.xbmc.org/showthread.php?tid=192380

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.

I force killed the browser (I was using iCab). Video then played again on iphone, and when switched to xbmc it played correctly.
I tried a dozen videos and all now were playing correctly.

I'm on iOS8 (iPhone 5S).

[nazarbayev]

Can you provide testbuilds for Raspberry PI?

Latest build here has it:
http://forum.xbmc.org/showthread.php?tid=192380

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.

I force killed the browser (I was using iCab). Video then played again on iphone, and when switched to xbmc it played correctly.
I tried a dozen videos and all now were playing correctly.

I'm on iOS8 (iPhone 5S).

Thank you. I will try it.

[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...

[DBMandrake]

Nope jenkins doesn't build rbpi in a distributable way. You need someone in the RBPI forum to build it for you (maybe millhouse adds it to his test builds).

@DBMandrake for the /play vs. /rate thingy - i think i do it right. At least based on the reverse engineered protocol:

http://nto.github.io/AirPlay.html#video-httprequests

It say /play should start playback ...

Is there any other difference in the headers sent between the photos app pre-buffering video and something like instacast sending video ?

[Memphiz]

Didn't sniff traffic lately ...

[DBMandrake]

Didn't sniff traffic lately ...

If the control channel is unencrypted I'll have a look with wire shark next week if work is not too busy...

[popcornmix]

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.

I'm on a home network. Using Pi running OpenELEC (milhouse's latest buid).
I've just tried to reproduce. I rebooted OE and airplay was still behaving fine.
I rebooted the iPhone and then airplay misbehaved. The airplay TV symbol appeared (without the audio symbol) and when selected it shows a (disabled) mirroring button.
I pressed Done and screen blanked then returned to menu on OE. From this point iPhone is unhappy. If I switch airplay back to iPhone I just get a black screen where the video should be.
The progress bar moves as if video were playing.
This was using safari. I then navigated to the same (youtube) video in iCab and this played on iPhone screen, and when OE was selected it played happily there.
Subsequent videos are happy too.

I did try to capture this in a log. As usual after enabling debug it didn't behave quite the same. In this log:
http://sprunge.us/GAWT

it did the usual start/stop on first play. I think this corresponds to this in log:

Code:

17:40:58 116.911842 T:2777674832    INFO: AIRPLAY Server: Disconnection detected

And a CDVDPlayer::CloseFile() just after.

But this time switching to iphone playback worked okay, and then switching back to OE worked correctly.

[Memphiz]

I think ios8 is buggy really here. I also have seen a black screen on the ios client in some situations. I wouldn't care that much about it until apple releases a good ios8 version ...

[Memphiz]

@DBMandrake fyi:

http://pastebin.com/VAZbbH9V

Thats the plist i get for /play ... i think i need to evaluate "rate == 0" here

[DBMandrake]

Ah, Bingo.

I'm assuming that's a play request from the photos app preloading a video, while a play request from another app that doesn't try to preload shows an initial rate of 1.0 ?

[Memphiz]

Didn't investigate that but i assume it. Also the youtube.app sets streamtype to 1 (still no clue how that strange url from yt.app can be used).

The problem is that the photo app doesn't react to the events. e.x. if i pause or seek on xbmc - the photo app doesn't reflect it. YT from safari does.

Also once the movie was played once from photo app (same for safari yt) i am not able to "restart" it. Once i push play again the screen on the ios8 device just goes black and nothing is sent to XBMC. The only thing it does is requesting the "server-info" (which holds Xbmc,1 , srcvers, proto and feature flags <- similar to the bonjour announcement).

It seems there are new keys added in that server-info xml and the client expects something in there which we don't send. Its nearly impossible to figure out which keys/values are supported now as all other devices encrypt all the messages with fairplay.

Also if i set the version in the server-info xml to the same from bonjour (150.33) i get urls with the new /play scheme (like i figured out during ios7 development). Also the url then contains an ipv6 url like http://[fe80::1441:ccba:a356:3564]:7001//1/e9b6f10d-b316-5b0a-8c0e-46c09aa39718.MOV - unfortunately XBMCs player doesn't support this url format (yet?). So i can't do any further tests with "correct" protocol version in the server-info xml before someone fixes the player ipv6 support

[Memphiz]

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.

The code for the testversion is here:

pull request to mainline: https://github.com/xbmc/xbmc/pull/5410

osx:
http://mirrors.xbmc.org/test-builds/osx/...x86_64.dmg

ios:
http://mirrors.xbmc.org/test-builds/darw...ay-ios.deb

atv2:
http://mirrors.xbmc.org/test-builds/darw...y-atv2.deb

win32:
http://mirrors.xbmc.org/test-builds/win3...irplay.exe

android-arm:
http://mirrors.xbmc.org/test-builds/andr...bi-v7a.apk

[DBMandrake]

I'm on a home network. Using Pi running OpenELEC (milhouse's latest buid).
I've just tried to reproduce. I rebooted OE and airplay was still behaving fine.
I rebooted the iPhone and then airplay misbehaved. The airplay TV symbol appeared (without the audio symbol) and when selected it shows a (disabled) mirroring button.
I pressed Done and screen blanked then returned to menu on OE. From this point iPhone is unhappy. If I switch airplay back to iPhone I just get a black screen where the video should be.
The progress bar moves as if video were playing.
This was using safari. I then navigated to the same (youtube) video in iCab and this played on iPhone screen, and when OE was selected it played happily there.
Subsequent videos are happy too.

I wouldn't worry about this intermittent failure to play Video in Safari, I've just noticed the following release note from the quickly yanked 8.0.1 update:

"– Safari: Fixes a problem with videos occasionally not playing"

http://9to5mac.com/2014/09/23/ios-8-1-bug-fixes-update/

Safari on iOS 8.0 on my iPad is a complete train wreck, so much so that I'm wishing I hadn't updated until 8.1...

Bad UI design choices, sluggish and stuttery, at least a couple of times a day Safari completely freezes on me while typing leaving the pressed key stuck down and the UI totally unresponsive. Switching to another app and back leads to a crash with all work (usually typing a forum post) lost...

iOS 7.0 had massive Airplay bugs as well, even on software like Reflector - a lot of the worst issues cleared up not with updates to Reflector, but during the incremental iOS updates. It wasn't until 7.1 that it worked fairly reliably...

[fritsch]

Off topic: Apple's shareholder value dropped by 24 billion dollars cause of the 8.0.1 fuckup.But it seems not only you was pissed by their software quality standards.