Updated stream url: https://tr.vod.cdn.cosmotetvott.gr/v1/871/504/1755406917024/1755406917024.ism/.m3u8?qual=a&ios=1&hdnts=st=1716553550~exp=1716596780~acl=*/871/504/1755406917024/1755406917024.ism/*~id=cf1bbd7c-8288-436c-91f9-60d686d182a3~data=de9bbd0100a8926c0311b7dbe5389f7d91e94a199d73b6dc75ea46a4579769d7~hmac=8fdb478fee2c14d5de4c379251cccb05fd061265

New stream url that reproduces the issue: https://tr.vod.cdn.cosmotetvott.gr/v1/871/504/1755406917024/1755406917024.ism/.m3u8?qual=a&ios=1&hdnts=st=1716389374~exp=1716432604~acl=*/871/504/1755406917024/1755406917024.ism/*~id=01f67f47-805e-4a41-be29-e14cc9a86830~data=de9bbd0100a8926c0311b7dbe5389f7d91e94a199d73b6dc75ea46a4579769d7~hmac=be120d41a0be6c07bd8e4531d41a489153fedb56

After some tests we determined that the issue is related to the segment duration. Specifically the old playlist manifest looks like this: #EXTM3U #EXT-X-VERSION:5 #EXT-X-PLAYLIST-TYPE:VOD #EXT-X-MEDIA-SEQUENCE:1 #EXT-X-INDEPENDENT-SEGMENTS #EXT-X-TARGETDURATION:2 #USP-X-TIMESTAMP-MAP:MPEGTS=900000,LOCAL=1970-01-01T00:00:00Z #EXT-X-KEY:METHOD=SAMPLE-AES,URI="skd://...",KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1" #EXTINF:1.92, no desc segment-1.ts #EXTINF:1.92, no desc segment-2.ts #EXTINF:1.92, no desc segment-3.ts and the test streams that work on all AirPlay receiver versions, look like this: #EXTM3U #EXT-X-VERSION:5 #EXT-X-PLAYLIST-TYPE:VOD #EXT-X-MEDIA-SEQUENCE:1 #EXT-X-INDEPENDENT-SEGMENTS #EXT-X-TARGETDURATION:4 #USP-X-TIMESTAMP-MAP:MPEGTS=900000,LOCAL=1970-01-01T00:00:00Z #EXT-X-KEY:METHOD=SAMPLE-AES,URI="skd://...",KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1" #EXTINF:3.84, no desc segment-1.ts #EXTINF:3.84, no desc segment-2.ts #EXTINF:3.84, no desc segment-3.ts To the best of my knowledge, a segment duration of 2 or less shouldn't be a problem. Is this correct? Is this an issue of the specific version of the AirPlay receiver? Is there any workaround besides changing all our streams to have segment duration of 4?

@deepeshcko well, in my case a public github repository with a binary attached to its release, was appropriate. (I wanted to send a closed source library to a client outside my company) I don't known if that's your case also.

This is probably due to the fact that Xcode tries to download the zip file, specified by the url, without knowning that it's an attached file at a private github repository, and does't add the personal access token in the headers. As a result: 404 file not found. The exact same logic is working on a publicly accessed github repository.