I had another look at it and was able to observe some issues with some streams (some were working fine). What I observed was mainly connection issues. Playback on the receiver would not start and only showed a red on the bottom left.
We had a deeper look at this issue and identified an underlying iOS/tvOS bug as this is also reproducible with a vanilla AVQueuePlayer sample application. As soon as we use an AVQeueuPlayer with multiple AVURLAssets, which have an AVAssetResourceLoaderDelegate associated, playback on the receiver will fail (never start or start on the wrong AVURLAsset). Using just one AVURLAsset works fine.
We logged a feedback with Apple (FB13511509). To get some traction on this report, you could open a feedback using Apples Feedback Assistant yourself referencing our Feedback number.
We found a lot of other posts online reporting issues with AirPlay in general since tvOS 17, so we are cautiously optimistic Apple will address this sooner rather than later.
In the meantime, there would be two ways forward:
Not using the playlist feature (if AirPlay is enabled)
Hi @davidsteinacher
I have a question on behalf of a customer. You mentioned setting isCustomHlsLoadingEnabled to false comes with some drawbacks. Aside from DownloadFinishedEvents stated in the documentation, what other potential drawbacks/side effects could there be?
No DownloadFinishedEvents are the immediate impact of setting isCustomHlsLoadingEnabled to false. Furthermore, all parsing related features can not be enabled as setting isNativeHlsParsingEnabled to true will not have any effect. Which features those are can be seen in the linked documentation.
Other than that there should not be and drawbacks/side effects.
For the record. I just tested this again with tvOS 17.4 and the issue is still persistent.