You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have no experience with previous versions of Airplay, but my IOS 5 client had some strange behavior with pictures. Photos would show, but would erratically display the prior photo, or the next one in the sequence, and sometimes would get stuck. It turns out that there is some new logic with caching directives:
At first you'll get 3 calls - I'll paste in the headers which will help explain:
You can see that the first is "this" photo, and the other two are the prior and next pictures in the album which are sent as a pre-cache (cacheOnly). In the current airplay, all three of these are loaded in a non-deterministic and non-thread-safe order which explains the erratic behavior.
Note two things:
a. The content-length of the first one is 0, and it's X-Apple-Assetaction is 'displayCached' - with the reference to the AssetKey and Session from the first exchange.
b. The second entry is caching the next picture with an actual payload, and, again, cacheOnly.
I have a patch which solves this by separating the caching from the showing, caching in a "session" directory, and generally trying to clean up after itself when the session ends. I have no way of testing on a non-IOS 5 Beta4 client, nor do I know how this will behave on any other target beyond XBMC (though it looks like Boxee/Plex don't implement pictures anyhow)
The text was updated successfully, but these errors were encountered:
Hi. Airplayer might indeed not be iOS 5 compatible right now. However, I'm not going to spend time on investigating iOS 5 related issues until iOS 5 matures.
First of all - awesome tool!
I have no experience with previous versions of Airplay, but my IOS 5 client had some strange behavior with pictures. Photos would show, but would erratically display the prior photo, or the next one in the sequence, and sometimes would get stuck. It turns out that there is some new logic with caching directives:
{'X-Apple-Session-Id': 'b108f96e-bdcd-4935-8fb2-3103be84853a', 'Content-Length': '159460', 'X-Apple-Assetkey': '857DDE75-1986-4D44-A9A1-2935903CE1FF', 'User-Agent': 'MediaControl/1.0'}
{'X-Apple-Session-Id': 'b108f96e-bdcd-4935-8fb2-3103be84853a', 'Content-Length': '196144', 'User-Agent': 'MediaControl/1.0', 'X-Apple-Assetaction': 'cacheOnly', 'X-Apple-Assetkey': '2065D39A-8DFD-4C41-B0A1-CEF928B7D56E'}
{'X-Apple-Session-Id': 'b108f96e-bdcd-4935-8fb2-3103be84853a', 'Content-Length': '101450', 'User-Agent': 'MediaControl/1.0', 'X-Apple-Assetaction': 'cacheOnly', 'X-Apple-Assetkey': 'DECAC583-F80A-4A38-B926-57ED78266E6F'}
You can see that the first is "this" photo, and the other two are the prior and next pictures in the album which are sent as a pre-cache (cacheOnly). In the current airplay, all three of these are loaded in a non-deterministic and non-thread-safe order which explains the erratic behavior.
Subsequent calls may look like:
{'X-Apple-Session-Id': 'b108f96e-bdcd-4935-8fb2-3103be84853a', 'Content-Length': '0', 'X-Apple-Assetkey': '2065D39A-8DFD-4C41-B0A1-CEF928B7D56E', 'User-Agent': 'MediaControl/1.0', 'X-Apple-Assetaction': 'displayCached', 'X-Apple-Transition': 'Dissolve'}
{'X-Apple-Session-Id': 'b108f96e-bdcd-4935-8fb2-3103be84853a', 'Content-Length': '182319', 'X-Apple-Assetkey': 'F1F713A7-A8FC-4707-900D-0E1056E0E323', 'User-Agent': 'MediaControl/1.0', 'X-Apple-Assetaction': 'cacheOnly', 'X-Apple-Transition': 'Dissolve'}
Note two things:
a. The content-length of the first one is 0, and it's X-Apple-Assetaction is 'displayCached' - with the reference to the AssetKey and Session from the first exchange.
b. The second entry is caching the next picture with an actual payload, and, again, cacheOnly.
I have a patch which solves this by separating the caching from the showing, caching in a "session" directory, and generally trying to clean up after itself when the session ends. I have no way of testing on a non-IOS 5 Beta4 client, nor do I know how this will behave on any other target beyond XBMC (though it looks like Boxee/Plex don't implement pictures anyhow)
The text was updated successfully, but these errors were encountered: