I’m working with FairPlay offline licenses using AVContentKeySession and ran into behavior that I cannot find documented. I am explicitly calling: contentKeySession.processContentKeyRequest( withIdentifier: identifier as NSString, initializationData: nil, options: nil ) Expected behavior I expect that each call to processContentKeyRequest will eventually result in the delegate callback: contentKeySession(_:didProvide:) Observed behavior If I call processContentKeyRequest with a new identifier, everything works as expected: didProvide is called I complete the request successfully However, if I call processContentKeyRequest again with the same identifier that was already processed earlier, then: No delegate callbacks are triggered at all The session does not appear to be blocked or stuck If I issue another request with a different identifier, it is processed normally So the behavior looks like the session is silently ignoring repeated requests for the same content key identifier. Important context This is not a concurrency issue — the session continues processing other requests This is reproducible consistently I am not using renewExpiringResponseData(for:) because I do not have a live AVContentKeyRequest at the time of retry Use case My use case is offline playback with periodically refreshed licenses. The app can stay alive for a long time (days/weeks), and I need to proactively refresh licenses before expiration. In this scenario: I only have the contentKeyIdentifier I do not have a current AVContentKeyRequest Calling processContentKeyRequest again for the same identifier does not trigger any delegate callbacks Questions Is this behavior expected — that AVContentKeySession ignores repeated processContentKeyRequest calls for the same identifier? What is the recommended way to re-fetch or refresh a license when: I only have the identifier I do not have a current AVContentKeyRequest I need to refresh proactively (not just in response to playback) What is the intended approach in this case? Maybe to create a new AVContentKeySession to force a new request cycle? Or something else? Is there any way to guarantee that a call to processContentKeyRequest will result in a delegate callback, or is it expected that it may be ignored in some cases? Any clarification on the intended lifecycle of AVContentKeySession and how repeated requests should be handled would be greatly appreciated.

Hi, I’m trying to better understand how AVAssetDownloadConfiguration selects video variants when downloading HLS content for offline playback. Suppose I have an HLS master playlist (.m3u8) that contains several video variants defined with #EXT-X-STREAM-INF. For example, the master playlist may contain multiple video streams like this: Same resolution, different BANDWIDTH Or different resolutions (for example 720p, 1080p, etc.) My question is: How many video variants are actually downloaded when using AVAssetDownloadConfiguration without specifying any variantQualifiers? In other words: If the master playlist contains multiple video variants, will the download task fetch only one variant, or multiple variants? Does the behavior differ depending on whether the variants differ only by BANDWIDTH or also by RESOLUTION? What I observed in testing In my tests, I always end up with only one video variant downloaded, specifically the one with the highest BANDWIDTH parameter. In the m3u8 files I tested, all video variants had identical parameters (resolution, codec, frame rate, etc.) and differed only by the BANDWIDTH attribute in the master playlist. However, when inspecting the downloaded .movpkg, I noticed something interesting in boot.xml. It lists two video streams: one with complete="true" (the one with highest bandwidth) another with complete="no" (the one with lowest bandwidth) I actually had 3 video streams listed in m3u8, but the one with middle bandwidth wasn't listed in boot.xml file at all. There are also additional streams for audio and subtitles in boot.xml file. This made me wonder whether the system initially attempts to download another video variant (possibly a lower bitrate one), but then switches to the highest-quality variant and only completes that one. Additional question about variantQualifiers If I provide a predicate such as: NSPredicate(format: "peakBitRate > 0") which should theoretically match all variants, will the download task attempt to download all matching video variants, or will it still select only one? Summary So the main questions are: Without variantQualifiers, does AVAssetDownloadConfiguration always download a single video variant, and if so, how is it chosen? Does the behavior differ if variants have different resolutions vs only different bitrates? When a predicate matches multiple variants, can multiple video variants actually be downloaded in a single .movpkg? Why might boot.xml list multiple video streams when only one appears to be fully downloaded? Any clarification on the intended behavior would be greatly appreciated. Thanks!