Trying to download an encrypted HLS stream we faced the following behaviour: Setting requestCachePolicy and/or urlCache properties of URLSessionConfiguration that used to create the AVAssetDownloadURLSession seems to have no effect at all. This is important for as since we need the HTTP caching policy to be applied for the .m3u8 manifest file of the stream. Is this the intended behaviour of the download process or some kind of an issue?

Trying to download an encrypted HLS stream we faced the following issue: When we start a new download, calling resume() function of AVAssetDownloadTask, the download process gets stuck (not every time) and neither of urlSession(_:assetDownloadTask:didFinishDownloadingTo:) or urlSession(_:task:didCompleteWithError:) delegate functions (AVAssetDownloadDelegate) are getting called. There are cases where not even the urlSession(_:assetDownloadTask:didLoad:totalTimeRangesLoaded:timeRangeExpectedToLoad:) delegate function is getting called. Any suggestions on how to troubleshoot?

Trying to download an encrypted HLS stream we faced the following behaviour: Setting requestCachePolicy and/or urlCache properties of URLSessionConfiguration that used to create the AVAssetDownloadURLSession seems to have no effect at all. In our application the user can add multiple encrypted HLS streams at a queue. Before adding them in queue, we make sure that the manifest gets cached using the shared URLSession like this: URLSession.shared.configuration.urlCache = .shared let task = URLSession.shared.dataTask(with: media.url) { _, _, _ in self.addMediaToQueue(media) } task.resume() and we setup our AVAssetDownloadURLSession like this: // Create the configuration for the AVAssetDownloadURLSession. let backgroundConfiguration = URLSessionConfiguration.background(withIdentifier: "AAPL-Identifier") backgroundConfiguration.urlCache = .shared backgroundConfiguration.requestCachePolicy = .returnCacheDataElseLoad // Create the AVAssetDownloadURLSession using the configuration. assetDownloadURLSession = AVAssetDownloadURLSession(     configuration: backgroundConfiguration,     assetDownloadDelegate: self,     delegateQueue: .main ) Here is an example of the caching headers that we use: Last-Modified: Thu, 11 Mar 2021 02:23:57 GMT Cache-Control: max-age=604800 This is important for us since our manifest url is signed and expires after 12 hours. Example of manifest URL: https://example.host.gr/v1/791/888/773923397316/773923397316.ism/.m3u8[…]~hmac=ee37a750b8238745b5c8cf153ebcd0b693dd5d83 If the client followed the HTTP cache policy and didn’t request the .m3u8 manifest file over the internet, the download would start, despite the 12 hours limit. Is this the intended behaviour of the download process or some kind of an issue? Could you suggest a workaround?

We are facing a weird behaviour when implementing the AirPlay functionality of our iOS app. When we test our app on Apple TV devices everything works fine. On some smart TVs with a specific AirPlay receiver version, (more details below) the stream gets stuck on buffering state immediately after switching to AirPlay mode. On other smart TVs, with different AirPlay receiver version, everything works as expected. The interesting part is that other free or DRM protected streams, work fine on all devices. Smart TVs that AirPlay works fine AirPlay Version -> 25.06 (19.9.9) Smart TVs that AirPlay stuck at buffering state: AirPlayReceiverSDKVersion -> 3.3.0.54 AirPlayReceiverAppVersion -> 53.122.0 You can reproduce this issue using the following stream url: https://tr.vod.cdn.cosmotetvott.gr/v1/310/668/1674288197219/1674288197219.ism/.m3u8?qual=a&ios=1&hdnts=st=1713194669\~exp=1713237899\~acl=\*/310/668/1674288197219/1674288197219.ism/\*\~id=cab757e3-9922-48a5-988b-3a4f5da368b6\~data=de9bbd0100a8926c0311b7dbe5389f7d91e94a199d73b6dc75ea46a4579769d7~hmac=77b648539b8f3a823a7d398d69e5dc7060632c29 If this link expires, notify me to send a new one for testing. Could you please provide to us any specific suggestion as to what causes this issue on those specific streams?