From the Apple (UMC) scrape, the ESPN/SportsCenter deep links consistently show up as sportscenter://x-callback-url/showWatchStream?...&x-source=AppleUMC, and they split into two distinct forms: asset-specific links with playID=<uuid> and linear-network links with playChannel=<network>. When we counted the Apple punchouts, ~75% were playID and ~25% were playChannel. The playChannel values were a small, consistent set that maps to ESPN’s linear brands (e.g., espn1, espn2, espnu, espnews, sec, acc, espndeportes). This suggests Apple is surfacing two different “play” concepts: open a specific stream vs tune a channel.
On the ESPN direct-API side that I used on ESPN4CC4C, the dataset shows a very similar divide in practice: the stuff that tends to be problematic for direct playback (“Re-Air”/replay-style items) overwhelmingly behaves like linear-network inventory rather than ESPN+ stream assets. In the DB extract, ~28% of events are flagged is_reair=1, and essentially all of those re-air events have no ESPN+ package attached (i.e., not ESPN_PLUS). That lines up with the Apple observation that playChannel is “network-like” content and may not reliably start playback depending on device/auth/provider context.
Putting both scrapes together: the working hypothesis is that Apple playID links correspond more often to stream-asset playback (higher success rate), while playChannel links correspond to linear tuning (more fragile / sometimes launch-only).
If folks have seen different behavior on Android/Fire vs iOS, I’d love to compare notes—especially whether playChannel ever reliably jumps straight into playback on non-iOS devices. I could add filtering to clearly note the playChannel vs playID (likely ESPN3 events). The playChannel events may not be appropriate for ADBTuner-- unless we figure out some specific keystroke to open the event as direct deeplink doesn't join the event live.