Clamp Adobe Edge playhead to the accepted [0, 86400]s range - #462
Clamp Adobe Edge playhead to the accepted [0, 86400]s range#462tvanlaerhoven wants to merge 3 commits into
Conversation
On Samsung Tizen, live streams report the playhead as an absolute presentation timestamp with a finite (DVR window) duration, so the "live" branch of sanitisePlayhead was skipped and a value of billions of seconds was sent to the Adobe VA Edge API, which rejects adStart/ adComplete calls with a 400 Bad Request. Always clamp the playhead to the [0, 86400] range accepted by the API, on web, Android and iOS. Generated with [Devin](https://devin.ai) Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Generated with [Devin](https://devin.ai) Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Generated with [Devin](https://devin.ai) Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
🦋 Changeset detectedLatest commit: acd2a49 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| return clampPlayhead(date.getSeconds() + 60 * (date.getMinutes() + 60 * date.getHours())); | ||
| } | ||
| return Math.trunc(playheadInSec); | ||
| return clampPlayhead(Math.trunc(playheadInSec)); |
There was a problem hiding this comment.
🔍 Clamped playhead will pin every Tizen live event at 86400
For the reported Tizen case (finite duration, absolute-PTS currentTime) every event now reports playhead 86400 and never advances, and updatePlayhead (adobe-edge/src/internal/web/AdobeEdgeHandler.ts:237) will report a value far larger than the sanitised content length (sanitiseContentLength on the DVR window). Adobe accepts the beacon but the derived viewing-time/progress metrics will be wrong; the PR acknowledges this as a stopgap, so it may be worth confirming with Adobe that a playhead exceeding the declared content length is not itself rejected or dropped downstream.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
That doesn't sound correct: THEOplayer's playhead is always in seconds. For live content, the duration would be Infinite, otherwise a finite value in seconds. Retrace & explain.
Problem
On Samsung Tizen CTV, live stream playhead values sent to the Adobe VA Edge API exceed the API's valid
[0, 86400]second range, causing Adobe to rejectadStart/adCompletebeacon calls with a 400 error:{ "type": "https://ns.adobe.com/aep/errors/va-edge-0400-400", "status": 400, "detail": "Invalid request. Please check your input and try again.", "report": { "details": "Playhead must be in range [0, 86400] seconds" } }Root cause
sanitisePlayhead()only special-casesduration === Infinity(live → current second of the day). On Samsung Tizen, live HLS streams report a finite duration (DVR-window length) whilecurrentTimeis an absolute/epoch-based presentation timestamp (billions of seconds). The live branch is skipped and the raw absolute timestamp is passed throughMath.trunc()unclamped, straight into theplayheadfield thatqueueOrSendEventattaches to every media event on web.Fix
Always clamp the sanitised playhead to the
[0, 86400]range accepted by the Adobe VA Edge API, in all platform implementations:adobe-edge/src/internal/web/Utils.tsadobe-edge/android/.../Utils.ktadobe-edge/ios/Connector/AdobeEdgeHandler.swiftNote: clamping yields a wrong-but-valid playhead for platforms with broken absolute-PTS reporting; proper normalisation needs a player-side
currentTimefix. The clamp guarantees Adobe accepts the beacons instead of rejecting them.Tests
adobe-edge/src/internal/web/__tests__/utils.test.tscovering: clamping of absolute-PTS playheads, negative playheads, normal VOD truncation, live second-of-day, NaN/undefined handling.cd adobe-edge && npm test(28/28 pass) andnpm run typescript(clean). These are not covered by CI, which only runs the docs check + e2e.Notes
bugfix/adobe-edge-session-start-raceas this change builds on top of that PR; rebase ontomainonce that lands.@theoplayer/react-native-analytics-adobe-edge.