One of our customers subscribed to a monthly plan on August 16 but the server-to-server notification seems to have been sent on August 18. What could be the reasons for such a delay between the purchase and the server-to-server notification which are usually sent right after the purchase? The receipt sent along with the notification seems to confirm that the receipt has only been created 2 days after the purchase. Here is an extract: { "environment": "Production", "receipt": { "receipt_type": "Production", "bundle_id": "fr.gaumontvideo.gaumontclassique", "application_version": "613", "receipt_creation_date": "2025-08-18 13:00:16 Etc/GMT", "receipt_creation_date_ms": "1755522016000", "receipt_creation_date_pst": "2025-08-18 06:00:16 America/Los_Angeles", "request_date": "2025-08-25 13:08:27 Etc/GMT", "request_date_ms": "1756127307346", "request_date_pst": "2025-08-25 06:08:27 America/Los_Angeles", "original_purchase_date": "2022-05-11 06:14:37 Etc/GMT", "original_purchase_date_ms": "1652249677000", "original_purchase_date_pst": "2022-05-10 23:14:37 America/Los_Angeles", "original_application_version": "265", "in_app": [ { "quantity": "1", "product_id": "fr.gaumontvideo.gaumontclassique.subscription.monthly.apple", "transaction_id": "270002386706194", "original_transaction_id": "270002386706194", "purchase_date": "2025-08-16 08:02:06 Etc/GMT", "purchase_date_ms": "1755331326000", "purchase_date_pst": "2025-08-16 01:02:06 America/Los_Angeles", "original_purchase_date": "2025-08-16 08:02:08 Etc/GMT", "original_purchase_date_ms": "1755331328000", "original_purchase_date_pst": "2025-08-16 01:02:08 America/Los_Angeles", "expires_date": "2025-09-16 08:02:06 Etc/GMT", "expires_date_ms": "1758009726000", "expires_date_pst": "2025-09-16 01:02:06 America/Los_Angeles" } }

While setting up our premium video-on-demand workflow in AWS, using AWS MediaConvert and MediaPackager and licence delivery from drmToday we encountered an issue with HLS+FairPlay playback (only) in Safari on macOS. The issue is that sometimes (more than 50% on the same video) the videoplayer initialization fails (with simple event of type=”error” in onerror callback). We are using Shaka player in our web application, so we first assumed that this (random) issue could be due to Shaka. However, we also tested with direct playback via the player and we observed the same issue, with same frequency. Since we have some content for which this problem does not occur and other content when the problem occurs very frequently, we tried to understand what could explain this difference. We noticed that for assets where the problem never occurs the order of the video submanifest was increasing, whereas for assets where the problem occurs frequently the order is decreasing. To isolate the issue we created a standalone page for a 2-minute asset and we are able to demonstrate that on this asset, when the bitrates are in decreasing order the playback with Safari on macOS fails more than 50% of the time. Test page using tag: KO: https://ntg-test-public-scr.s3.eu-west-1.amazonaws.com/aws-video.html OK: https://ntg-test-public-scr.s3.eu-west-1.amazonaws.com/aws-video.html?ok=1 Test page using Shaka: KO: https://ntg-test-public-scr.s3.eu-west-1.amazonaws.com/aws-shaka.html OK: https://ntg-test-public-scr.s3.eu-west-1.amazonaws.com/aws-shaka.html?ok=1 Notes: the issue is only reproducible with Safari on macOS (not with Safari on iOS) same HLS content + FairPlay plays OK 100% on tvOS the issue is only reproducible for HLS content with FairPlay (OK if no DRM)

We develop a video playback app on Apple TV which has the two following features: Its content browsing screen has installed a gesture recognizer for presses on the PlayPause Siri remote button in order to directly launch a playback. The gesture recognizer is attached to the content browsing UIViewController view. It presents its own custom playback UI with an AVPlayerLayer for the video and supports MPNowPlayingSession in order to publish current playback information and respond to remote commands. It also supports switching between fullscreen and Picture in Picture playback. Both features work fine, ie. the playback is launched when pressing the PlayPause Siri remote button and, during playback, the playback info are properly advertised on other devices and remote commands are also triggered as expected. However, when pressing the PlayPause Siri remote button while the video is playing in PiP, the "pause" remote command is sometimes triggered instead of the .playPause gesture recognizer. The issue may not occur the first time but for subsequent PlayPause presses. Navigating a bit in the app UI seems to help preventing the issue to occur. Finally, the issue only occurs if the video is playing. If the video is paused, the PlayPause Siri remote button gesture is always recognized instead of the remote command. Please note that, before using MPNowPlayingSession (and the corresponding MPRemoteCommandCenter), the app was using the default MPRemoteCommandCenter to support remote commands and the issue did not occur. We don't reproduce this issue with the Apple TV app so there's probably something we are not doing right. Has someone any clue?

Context We develop an iOS/Apple TV app that allows to play HLS+FP Live streams (custom playback UI), some of which use the same FairPlay content key id. All FairPlay content keys are requested to the same content key server. Implementation Despite Apple documentation warning to not reuse AVContentKeySessions, we use only one AVContentKeySession for all channels which allows the system to reuse the content key when a content key id is met again. As seen in another thread, people seems to think this is OK. Issue When reusing the AVContentKeySession and the user quickly tunes channels multiple times (up to 2 or 3 times per second using gestures), an inconsistency may occur where the content key request for a previous streams is asked to the delegate after a new stream is already being prepared and its AVURLAsset already assigned as the content key session AVContentKeyRecipient. Note that the previous content key recipient is removed before the new one is added. We also have been reported for crashes (though I haven't experienced it myself) when performing multiple channels tunings which makes us think that the AVContentKeySession should definitely not been reused. Note: On the other hand if a new AVContentKeySession is used for each stream, the system systematically requests a content key even if previous streams have used the same content key id. In this case, neither the crash nor the inconsistency issue are observed but it dramatically increases the number of calls to the content key server. Questions Should AVContentKeySessions definitely not be reused? Otherwise, how to handle the inconsistency issue described above?