# AudioPlayer URL Mode fails with MEDIA\_ERR\_SRC\_NOT\_SUPPORTED on VVD — app never connects to com.amazon.media.server; both official media samples also fail **URL:** \ **Category:** Bug Reports\ **Created:** [September 9, 2026, 10:38am UTC](https://community.amazondeveloper.com/t/audioplayer-url-mode-fails-with-media-err-src-not-supported-on-vvd-app-never-connects-to-com-amazon-media-server-both-official-media-samples-also-fail/29117 "2026-09-09T10:38:15Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![TusharTechs](https://avatars.discourse-cdn.com/v4/letter/t/90db22/32.png) [@TusharTechs](https://community.amazondeveloper.com/u/TusharTechs)\ **Post date:** [September 9, 2026, 10:38am UTC](https://community.amazondeveloper.com/t/audioplayer-url-mode-fails-with-media-err-src-not-supported-on-vvd-app-never-connects-to-com-amazon-media-server-both-official-media-samples-also-fail/29117/1 "2026-09-09T10:38:15Z")
## Bug Description ### 1. Summary On the Vega Virtual Device (`vvrp-tv-arm64`, OS 1.2, SDK 0.24.9914), `AudioPlayer` URL Mode playback fails for every source I have tried. Setting `.src` produces `MediaError.code === 4` (`MEDIA_ERR_SRC_NOT_SUPPORTED`) and **no HTTP request is ever issued** — verified against an access log on the host machine. Native logging shows the app connects to `com.amazon.mediametrics.service`, `com.amazon.media.playersession.service` and `com.amazon.audio.control`, but **never connects to `com.amazon.media.server`** , despite that service being declared in `manifest.toml`. No `W3CMEDIA` log lines are emitted at all, even with journal priority set to `debug`. Separately, **both official media samples also fail on this same device** : `vega-video-sample` crashes with SIGSEGV, and `vega-audio-sample` hangs on launch and is killed with an ANR. That suggests this is not specific to my application. **App Name:** sightlineprobe (pre-release, not on the Appstore — a minimal app generated from the SDK’s own `helloWorld` template) ### Bug Severity **Blocks current development.** * * * ### 2. Steps to Reproduce 1. Generate a clean project from the SDK template: `vega project generate -t helloWorld -n sightlineprobe --packageId com.sightline.probe` 2. Add the media library, SDK-tracked: `vega project install @amazon-devices/react-native-w3cmedia` 3. Declare media and audio services in `manifest.toml` (full list in §7). 4. Replace `App.tsx` with the snippet in §7 — it constructs an `AudioPlayer`, calls `setMediaControlFocus()`, `initialize()`, then sets `.src` and plays. 5. `npm install && npm run build:debug` 6. `vega virtual-device start` 7. `vega run-app build/aarch64-debug/sightlineprobe_aarch64.vpkg com.sightline.probe.main` The app launches and runs stably. Only media playback fails. * * * ### 3. Observed Behavior Every source fails identically with `MediaError.code === 4`, and **no HTTP request reaches the server** : | Source | Content-Type | Result | | --- | --- | --- | | `http://10.0.2.2:8099/desc.mp3` (host-served) | `audio/mpeg` | code 4, **no fetch** | | `http://10.0.2.2:8099/desc.m4a` | `audio/mp4a-latm` | code 4, **no fetch** | | `http://10.0.2.2:8099/desc.wav` | `audio/x-wav` | code 4, **no fetch** | | `https://d1v0fxmwkpxbrg.cloudfront.net/audio-assets/Downtown.mp3` — **`vega-audio-sample`’s own track URL** | `audio/mpeg` | code 4, **no fetch** | The “no fetch” column is measured, not inferred: a `python3 -m http.server` on the host logs every request, and the device demonstrably can reach it (a `gst-launch-1.0 souphttpsrc` fetch from the device shell to the same URL succeeds and reaches EOS). **`canPlayType()` on the same player instance contradicts this:** ```auto audio/mpeg=probably audio/mp4=probably audio/aac=probably ``` `audio/flac=probably audio/ogg=probably` `audio/wav=no audio/x-wav=no` `application/x-mpegURL=no application/dash+xml=no` The player reports `"probably"` for `audio/mpeg` and then rejects an MP3 as `SRC_NOT_SUPPORTED` without attempting to fetch it. **Service connections during a playback attempt.** Captured with `loggingctl log -f` running on-device throughout (2367 lines), after `loggingctl config --set-level com.sightline.probe debug`, a device reboot, and re-applying the level: | Service | Connections observed | | --- | --- | | `com.amazon.mediametrics.service` | 15 | | `com.amazon.media.playersession.service` | 1 | | `com.amazon.audio.control` | 1 | | **`com.amazon.media.server`** | **0** | | `com.amazon.audio.stream` | 0 | | `com.amazon.audio.system` | 0 | | `com.amazon.mediatransform.service` | 0 | | `com.amazon.mediabuffer.service` | 0 | `com.amazon.mediametrics.service` starts, finds no clients, and is terminated: ```auto lcm_service: appInst[51](com.amazon.mediametrics.service): ``` ` No clients connected to the service, terminating` **No `W3CMEDIA` log lines are produced at any point** — no `set_src_uri`, no `MPBBackend`, no `makeMediaError`, nothing — even at `debug` priority with the rate limit raised to 60000. **Both official media samples also fail on this device:** - **`AmazonAppDev/vega-video-sample`** (unmodified, current HEAD) — SIGSEGV. Stackwalk shows `libRCT-folly-0.83.so.0.83` and `libRCT-folly-0.72.so.0.72` both loaded in one process, with the crashing chain crossing between them: - **`AmazonAppDev/vega-audio-sample`** (unmodified, current HEAD) — ANR on launch. `vega run-app` reports success, `vega device is-app-running` reports not running, the app never renders: * * * ### 4. Expected Behavior `player.src = ""` in URL Mode should fetch the resource and fire `loadedmetadata` / `canplay`, per the W3C Media API documentation, which lists MP3 as a supported URL Mode format — and consistent with `canPlayType()` reporting `"probably"` for `audio/mpeg`. * * * ### 4.a Possible Root Cause & Temporary Workaround **No workaround found.** The most likely area, based on the evidence above, is that the media playback backend is never engaged: `com.amazon.media.server` is declared in the manifest but receives no connection, the `W3CMEDIA` layer emits no logs, and the failure returns before any network activity. That ordering suggests the source is rejected before pipeline construction rather than during it. This may be related to [Documentation clarity for URL playback: KeplerVideoView vs KeplerVideoSurfaceView](https://community.amazondeveloper.com/t/documentation-clarity-for-url-playback-keplervideoview-vs-keplervideosurfaceview/29087), where `MEDIA_ERR_SRC_NOT_SUPPORTED` was attributed to a missing `setSurfaceHandle()`. That guidance is for _video_ via `KeplerVideoSurfaceView`. **Is there an equivalent surface or handle requirement for audio-only playback via `AudioPlayer`?** Nothing in the `AudioPlayer` documentation or in `vega-audio-sample` suggests one, but the failure signature is similar. It may also be related to [the `set_src_uri` / `apiStatus=50004` failure reported here](https://community.amazondeveloper.com/t/vpkg-installs-fine-on-kvd-emulator-but-fails-on-physical-hardware/28880), §5 of that thread — same `MediaError` code 4, same “fails before any HTTP request is issued”. That report is on SDK 0.23.8358 / RN 0.72 with a flat `.ts` file; this one is SDK 0.24.9914 / RN 0.83 with MP3/M4A/WAV. The difference is that the reporter there _does_ see `set_src_uri` reach the MPB backend and fail, whereas here the backend appears never to be reached at all. **Hypotheses eliminated by direct test** , so as not to waste anyone’s time: | Eliminated | How | | --- | --- | | Stale device state | Fresh VVD boot; both apps uninstalled; clean install | | Stale bundle | `build/` deleted; markers verified present in the aarch64 bundle | | `AudioPlayer` constructor args | `new AudioPlayer()`, `(SPEECH, USAGE_ACCESSIBILITY)`, `(SPEECH, USAGE_MEDIA)`, `(MUSIC, USAGE_MEDIA)` — all identical | | Source URL / scheme / host | `vega-audio-sample`’s own HTTPS CloudFront URL fails too | | Container / codec | MP3, M4A and WAV all fail | | `setMediaControlFocus()` | Added via `useKeplerAppStateManager().getComponentInstance()`; reports success; no change | | Load/play sequencing | Final attempt matched `AudioHandler.ts` exactly — no explicit `load()`, `play()` only on `canplay`. Identical failure | | Manifest declarations | Diffed against `vega-audio-sample`; this app declares a superset of its media modules | | Emulator audio disabled | Instance `config.ini` has no `hw.audioOutput` line, but resolved `hardware-qemu.ini` shows `hw.audioOutput = true` | | Device networking | `nslookup` resolves; `gst-launch-1.0 souphttpsrc` from the device shell fetches the same URL successfully and reaches EOS | | Missing audio hardware | `/proc/asound/cards` → `virtio-snd - VirtIO SoundCard`; `/proc/asound/pcm` → `VirtIO PCM 0 : playback 4 : capture 2` | * * * ### 5. Logs or crash report Available on request and can be attached — say which would be most useful: - Full 2367-line `loggingctl log -f` capture across a playback attempt - Both ACR crash reports (`vega-video-sample` SIGSEGV, `vega-audio-sample` ANR) - Host-side HTTP access log showing zero requests during playback attempts **Note on symbolication:** I could not symbolicate the ACRs. `vega exec acr-report` bootstraps its Python dependencies from PyPI at runtime and fails behind corporate TLS inspection, ignoring `PIP_CERT` / `REQUESTS_CA_BUNDLE`; after populating its venv offline by hand it runs and then stops at `Midway cookie not found at ~/.midway/cookie, please authenticate using mwinit`, which is internal-only. The MCP `symbolicate_acr` tool separately fails with “acr-report not found… ensure Vega SDK is installed”, apparently because the MCP server does not inherit `~/vega/env`. The stacks above are read directly from the ACR files’ `` sections. Happy to file those as separate issues if useful. * * * ### 6. Environment ```auto Active SDK Version: 0.24.9914 ``` `Vega CLI Version: 1.3.4` `@amazon-devices/react-native-w3cmedia 2.3.2` `@amazon-devices/react-native-kepler 4.0.1` `@amazon-devices/kepler-media-controls 1.0.25` `react-native 0.83.0` `react 19.2.0` `Device: Vega Virtual Device, vvrp-tv-arm64, aarch64, simulated, developer mode on` `Host: macOS 26.6.2, arm64, Node v26.7.0` `App State: Foreground` `/etc/os-release`: ```auto OS_VERSION="1.2" ``` `BUILD_DESC="OS 1.2 (TV Ship/101520710)"` `BUILD_FINGERPRINT="1.0.152071.0(9a1d8dfa7da5d600)/101520710N:user/dev-keys"` `BUILD_VARIANT="user"` * * * ### 7. Example Code Snippet `manifest.toml` — media and audio declarations: ```auto [needs] ``` `[[needs.privilege]]` `id = "com.amazon.network.privilege.net-info"` `[wants]` `[[wants.service]]` `id = "com.amazon.media.server"` `[[wants.service]]` `id = "com.amazon.mediametrics.service"` `[[wants.service]]` `id = "com.amazon.media.playersession.service"` `[[wants.service]]` `id = "com.amazon.mediabuffer.service"` `[[wants.service]]` `id = "com.amazon.mediatransform.service"` `[[wants.service]]` `id = "com.amazon.gipc.uuid.*"` `[[wants.service]]` `id = "com.amazon.audio.stream"` `[[wants.service]]` `id = "com.amazon.audio.control"` `[[wants.service]]` `id = "com.amazon.audio.system"` `[[wants.service]]` `id = "com.amazon.network.service"` `[[wants.privilege]]` `id = "com.amazon.devconf.privilege.accessibility"` Playback code — mirrors `vega-audio-sample`’s `AudioHandler.ts`: ```auto import {AudioPlayer} from '@amazon-devices/react-native-w3cmedia'; ``` `import {useKeplerAppStateManager} from '@amazon-devices/react-native-kepler';` `const appStateManager = useKeplerAppStateManager();` `const componentInstance = appStateManager.getComponentInstance();` `const player = new AudioPlayer(); // also tried with` ` // (CONTENT_TYPE_SPEECH,` ` // USAGE_ACCESSIBILITY)` `await player.setMediaControlFocus(componentInstance); // resolves successfully` `await player.initialize(); // resolves successfully` `player.addEventListener('canplay', () => player.play());` `player.addEventListener('error', () => {` ` console.log('code', (player as any).error?.code); // -> 4` `});` `player.src = 'http://10.0.2.2:8099/desc.mp3'; // fails here` `player.autoplay = false;` * * * ### Playback Issues - **Player SDK:** none — URL Mode only, no Shaka, no MSE - **Player SDK Version:** n/a - **Audio Codecs:** MP3 (LAME 128 kbps 44.1 kHz stereo), AAC-LC in M4A, PCM in WAV - **Video Codecs:** n/a — audio only - **Manifest Types:** none — flat files over HTTP/HTTPS - **Architecture:** aarch64 (also builds armv7 and x86\_64; tested aarch64) **Content URL:** `https://d1v0fxmwkpxbrg.cloudfront.net/audio-assets/Downtown.mp3` is `vega-audio-sample`’s own track and reproduces the failure, so no private URL is needed to reproduce. The local files were generated with macOS `say` + `ffmpeg` and served with `python3 -m http.server`; I can supply them if wanted. **Special headers:** none. Plain `GET`, no auth, no tokens, no geo restriction. * * * ### Additional Context The specific questions that would unblock me: 1. **Is media playback expected to work on the Vega Virtual Device at all** , or is physical hardware required? My project is entirely audio behaviour, so if the VVD cannot do media I need to order a device rather than keep debugging. The VVD documentation presents it as a general-purpose development target and doesn’t say otherwise. 2. **Is there a surface/handle prerequisite for audio-only `AudioPlayer` playback** , analogous to `setSurfaceHandle()` for video? If so it isn’t in the `AudioPlayer` docs and isn’t in `vega-audio-sample`. 3. **Should `com.amazon.media.server` receive a connection** when `.src` is set on an `AudioPlayer`? It is declared in the manifest but never contacted. 4. Separately — **`canPlayType()` returning `"probably"` for a type the player then refuses** looks like a bug in its own right, since that API exists precisely to let apps avoid this. Relatedly, I have not been able to enable VoiceView on the VVD by any of the three methods in the accessibility FAQ (Settings has no Accessibility section; the Back+Menu chord doesn’t fire; `vdcm set` returns “No permission for operation” via `vega device shell`, `vega device run-cmd` and `vega exec vda shell` alike, and `vsm developer-mode enable` doesn’t change the shell’s `uid=5000(app_user)` context). Happy to raise that separately if it isn’t the same underlying area. ---
**Author:** ![amen](https://avatars.discourse-cdn.com/v4/letter/a/ee7513/32.png) [@amen](https://community.amazondeveloper.com/u/amen)\ **Post date:** [September 9, 2026, 8:58pm UTC](https://community.amazondeveloper.com/t/audioplayer-url-mode-fails-with-media-err-src-not-supported-on-vvd-app-never-connects-to-com-amazon-media-server-both-official-media-samples-also-fail/29117/4 "2026-09-09T20:58:32Z")
Hi @TusharTechs, Thanks for the exceptionally thorough report - the evidence you’ve captured (service-connection counts, the absence of any `W3CMEDIA` log lines, the “no fetch” measurement, and especially both official samples failing on the same device) is exactly what we need to investigate. A few things to separate out: 1. The official samples failing is the key signal. **vega-video-sample** (SIGSEGV) and **vega-audio-sample** (ANR) failing unmodified on the same VVD is useful information. If you can attach both ACRs, we’ll investigate the sample failures on our side. 2. On your specific questions: - Q2 (surface/handle for audio): No. `setSurfaceHandle()` / `KeplerVideoSurfaceView` is a video rendering requirement only. Audio-only `AudioPlayer` URL playback does not require a rendering surface, so that isn’t a missing step here. - Q3 (should `com.amazon.media.server` receive a connection): We’ll confirm the expected connection behavior for `AudioPlayer` with the team, since the zero-connection observation is a key detail we want to look into. - Q4 (`canPlayType() = "probably" then SRC_NOT_SUPPORTED`): We’ll flag this for review as well. 1. One documented best practice to rule out: Vega’s media guidance is to deinitialize a player instance before initializing a new one, and to release media resources when the app is backgrounded. See “General requirements for media apps” ( [General requirements for media apps - Amazon Vega Docs](https://developer.amazon.com/docs/vega/0.24/media-player-requirements.html) ). (Noting your app reports failure on the first play from a clean boot, so this likely doesn’t apply - but it’s worth ruling out.) To move this forward, could you attach: 1. The two ACRs (vega-video-sample SIGSEGV and vega-audio-sample ANR). 2. The full loggingctl log -f capture across a playback attempt. 3. If possible, whether the same VPKG behaves differently on a physical Fire TV Stick 4K Select vs. the VVD - if it plays on a physical device, that isolates the issue to the VVD and unblocks your development while we investigate. On whether media is expected to work on the VVD at all: the VVD is a supported development/test target, and per our docs media apps must be validated on a physical Fire TV Stick 4K Select before submission. Confirming behavior on a physical device is the fastest way to isolate this ( [Test Your App Before Submitting to the Appstore - Amazon Vega Docs](https://developer.amazon.com/docs/vega/0.24/test-before-submission.html) ). Thanks again for the detail - please share the ACRs and log capture and we’ll dig in. Thanks for helping us improve the Vega platform. Warm regards, Aishwarya ---
**Author:** ![atsushiyago](https://dhm3gbtzu79o6.cloudfront.net/user_avatar/community.amazondeveloper.com/atsushiyago/32/6032_2.png) [@atsushiyago](https://community.amazondeveloper.com/u/atsushiyago)\ **Post date:** [September 9, 2026, 11:45pm UTC](https://community.amazondeveloper.com/t/audioplayer-url-mode-fails-with-media-err-src-not-supported-on-vvd-app-never-connects-to-com-amazon-media-server-both-official-media-samples-also-fail/29117/5 "2026-09-09T23:45:41Z")
Hi Tushar, Thank you for the extremely detailed investigation. I am seeing a related, but not identical, issue in my Vega Fire TV app. My environment is essentially the same: - Vega SDK 0.24.9914 - Vega CLI 1.3.4 - @amazon-devices/react-native-w3cmedia 2.3.2 - @amazon-devices/react-native-kepler 4.0.1 - React Native 0.83.0 - VVD OS 1.2 In my case, audio-only M4A URL playback usually works normally, but MEDIA\_ERR\_SRC\_NOT\_SUPPORTED (code 4) occurs intermittently after some use. So the main difference is: - Your case: playback appears to fail consistently before any HTTP request / W3CMEDIA backend activity. - My case: the same media URL often plays successfully, and in captured failure logs W3CMEDIA did recognize the M4A and began constructing the playback pipeline. I also found and fixed an application-side lifecycle race in my Retry path, so I am being careful not to attribute every code 4 failure to VVD itself. However, even before that investigation, I had observed the same VPKG and same URL alternate between successful playback and code 4 failures depending on the VVD session / uptime. Your finding that the official media samples also fail on your VVD is particularly interesting. I’ll keep testing the corrected build, and if the intermittent code 4 occurs again I’ll capture a fresh log from the current build and share the relevant sequence. Thanks again for documenting this so thoroughly. ---
**Author:** ![TusharTechs](https://avatars.discourse-cdn.com/v4/letter/t/90db22/32.png) [@TusharTechs](https://community.amazondeveloper.com/u/TusharTechs)\ **Post date:** [September 10, 2026, 6:14am UTC](https://community.amazondeveloper.com/t/audioplayer-url-mode-fails-with-media-err-src-not-supported-on-vvd-app-never-connects-to-com-amazon-media-server-both-official-media-samples-also-fail/29117/6 "2026-09-10T06:14:44Z")
Thanks @amen — artifacts attached: both vega-video-sample SIGSEGV ACRs, the vega-audio-sample ANR ACRs, and the full loggingctl -f capture across a playback attempt. Three updates since I posted. 1. I need to soften my framing. Moses has confirmed on Discord that media playback works on the VVD and he’s done it many times, and another developer in this thread is on an essentially identical stack (0.24.9914 / CLI 1.3.4 / w3cmedia 2.3.2 / kepler 4.0.1 / RN 0.83 / VVD OS 1.2) where audio-only URL playback usually works. So this is almost certainly specific to my environment rather than the VVD in general, and I’ve stopped claiming otherwise. 2. On Q3 — I don’t think com.amazon.media.server is missing. I re-ran a playback attempt while grepping the journal for “service not found” / “unknown service”: the only unresolved service is com.amazon.blemesh.service (unrelated). So the app is not failing to reach the media server — it never attempts the connection at all. The failure appears to be upstream of any service lookup. 3. Also probably worth distinguishing me from the other reporter above: in their failures W3CMEDIA recognises the media and begins constructing the pipeline, then fails intermittently. In mine there are no W3CMEDIA log lines whatsoever, on every attempt, from a clean boot. Likely two different problems, and I’d rather not have mine merged into theirs. On the deinitialize best practice — confirmed it doesn’t apply. Fresh VVD boot, clean install, first play, single player instance. On the physical-device comparison: I don’t have a Fire TV Stick 4K Select, and Moses has said hardware isn’t needed for the hackathon, so I can’t run that isolation myself. If it’s the fastest path for you I can look at sourcing one, but I’d rather not if the environment difference can be found another way. [1#crash\_1788868567\_30040\_5000\_5903\_11\_com\_amazondeveloper\_keplervideoapp.acr](https://community.amazondeveloper.com/uploads/short-url/1swlnd996GaWtZ9G6XcilQ80bXD.acr) (284.9 KB) [2#crash\_1788868569\_30040\_5000\_5938\_11\_com\_amazondeveloper\_keplervideoapp.acr](https://community.amazondeveloper.com/uploads/short-url/kqic4FX3dfEhBcyT0BIkPtqcUOS.acr) (285.2 KB) [21#crash\_1788926931\_30042\_5000\_9662\_3\_com\_amazondeveloper\_kepleraudioreferenceapp.acr](https://community.amazondeveloper.com/uploads/short-url/ctKjSIhC84KZ6g6UhTxe8bCbdwk.acr) (390.4 KB) [22#crash\_1788926980\_30042\_5000\_10053\_3\_com\_amazondeveloper\_kepleraudioreferenceapp.acr](https://community.amazondeveloper.com/uploads/short-url/gqiA9lisHAzwfsJvHcBnaEXpxGo.acr) (388.1 KB) [3#crash\_1788868573\_30040\_5000\_5965\_11\_com\_amazondeveloper\_keplervideoapp.acr](https://community.amazondeveloper.com/uploads/short-url/ez26oqnqimNRRS32R5yOP42avNu.acr) (286.4 KB) [4#crash\_1788868654\_30040\_5000\_7037\_11\_com\_amazondeveloper\_keplervideoapp.acr](https://community.amazondeveloper.com/uploads/short-url/qVAq8quq1f7YOpJCVP6qGrAKzoY.acr) (287.6 KB) [5#crash\_1788868912\_30040\_5000\_9757\_11\_com\_amazondeveloper\_keplervideoapp.acr](https://community.amazondeveloper.com/uploads/short-url/lVW8BzmF3f6pRXkccFjHM8qE5yV.acr) (287.1 KB) [loggingctl-playback-capture.log](https://community.amazondeveloper.com/uploads/short-url/dLx4m6WmWayAmUC6vafpnUCNKe2.log) (701.6 KB) ---
**Author:** ![TusharTechs](https://avatars.discourse-cdn.com/v4/letter/t/90db22/32.png) [@TusharTechs](https://community.amazondeveloper.com/u/TusharTechs)\ **Post date:** [September 11, 2026, 6:55pm UTC](https://community.amazondeveloper.com/t/audioplayer-url-mode-fails-with-media-err-src-not-supported-on-vvd-app-never-connects-to-com-amazon-media-server-both-official-media-samples-also-fail/29117/7 "2026-09-11T18:55:54Z")
@amen **Status first: I am unblocked and this is no longer urgent for me.** My app now uses MSE and plays correctly. Everything below is diagnosis rather than escalation — posting it because it localises the fault a long way, and because a few of the dead ends cost me days that better documentation would have saved. * * * ## 1. The short version Three paths, same app, same device, same session, same source footage. Only the way the bytes reach the player differs: | Path | HTTP request issued? | Result | | --- | --- | --- | | `AudioPlayer.src = ` (URL mode) | **none, ever** | `MEDIA_ERR_SRC_NOT_SUPPORTED` | | `VideoPlayer.src = ` (URL mode, with surface) | **none, ever** | `MEDIA_ERR_SRC_NOT_SUPPORTED` | | `MediaSource` + `SourceBuffer.appendBuffer()` | yes — 3,995,867 bytes, confirmed in my server’s access log | `canplay` → `playing`, audio audible | So the decoders, the media pipeline, the video sink, the audio sink, the surface handle and the app’s network access are all demonstrably working. The same player instance plays the same footage when the bytes are handed to it directly. The MSE run, with **no Shaka, hls.js or dash.js involved** — raw `MediaSource`: ```auto isTypeSupported('video/mp4; codecs="avc1.64001F,mp4a.40.2"') -> true ``` `sourceopen -> addSourceBuffer ok -> fetched 3995867 bytes` `-> appendBuffer -> updateend -> endOfStream` `-> loadedmetadata -> canplay -> playing (audio audible on the host)` ## 2. Hypotheses I eliminated, so nobody repeats them **It is not the audio track.** I expected `playbin` to build an audio sink during preroll, so a file carrying audio would fail where a video-only file succeeded. I tested both in URL mode: identical failure, `loadstart` then code 4. Both play fine over MSE. **It is not the surface handle.** Following the URL-mode pattern exactly — `initialize()` resolved before `setSurfaceHandle()`, handle cached from `onSurfaceViewCreated` — the surface attaches successfully and the failure comes after it. **It is not device audio, and not my manifest.** A second probe in the same project, same manifest, synthesises a sine wave in JavaScript and writes it as raw PCM through `keplerscript-audio-lib`: ```auto builder.setAudioConfig({ sampleRate: SAMPLE_RATE_48_KHZ, ``` ` channelMask: CHANNEL_STEREO,` ` format: FORMAT_PCM_16_BIT });` `builder.setAudioAttributes({ contentType: CONTENT_TYPE_SPEECH,` ` usage: USAGE_ACCESSIBILITY,` ` flags: FLAG_NONE });` `const stream = await builder.buildAsync();` `await stream.startAsync();` `await stream.writeAsync(pcm);` That is **audible**. So the app is granted audio access and gets a working `USAGE_ACCESSIBILITY` focus session with the manifest as filed. **`fetch()` works from the app.** The probes report progress by fetching my host and download their media the same way. URL mode issuing _no request at all_ is therefore inside the platform’s URL handling, not a networking problem at my end. **Please also disregard the “emulator audio disabled” line of enquiry** from my original report. Device audio works — the boot animation’s chime is audible, and `animationservice` logs `Audio Focus 1 is granted` and `initial audio frame presented to hardware` on every boot. ## 3. The question this narrows to What happens between `player.src = ` and the source element being opened, such that it fails with `MEDIA_ERR_SRC_NOT_SUPPORTED`, issues no HTTP request, and emits no `W3CMEDIA` log line at all — even at `debug` with the rate limit raised to 60000? `canPlayType()` on the same instance returns `"probably"` for the same type, so format negotiation is not where it stops. ## 4. Documentation gaps — the part I think is most worth acting on These cost me real time, and each is a small fix. **a. There is no guidance for “URL mode does not work”.** The docs present URL mode and MSE as a convenience/capability tradeoff. Nothing suggests trying MSE to isolate a URL-mode failure, and that single step would have saved me several days. A troubleshooting line — _if URL playback fails, test the same content via MSE to determine whether the fault is in source handling or in the pipeline_ — would be worth a lot. **b. MSE is documented only via Shaka / hls.js / dash.js.** For non-adaptive, non-DRM content, raw `MediaSource` + `SourceBuffer` is about fifteen lines, needs no player library, and avoids the Vega-patched `dist` build process entirely. That option is not mentioned anywhere I could find. Two details that are easy to get wrong and are not stated: - the content must be **fragmented** MP4 — a normal MP4 will not append (`ffmpeg -i in.mp4 -c copy -movflags +frag_keyframe+empty_moov+default_base_moof out.mp4`) - attachment is via **`srcObject`** , not `src` **c. `vega device run-cmd` is a sandboxed app context, and nothing says so.** It runs as `uid=5000(app_user)` with no component instance and no service grants. Platform probes run from there return confident false negatives: | Probe | Reports | Actual | | --- | --- | --- | | `gst-launch-1.0 audiotestsrc ! novaaudiosink` | `AudioServer is unavailable` | audio server running fine | | `ls /dev/snd` | `No such file or directory` | exists, namespaced away | | `ps aux | grep audio` | nothing | running, not visible | I concluded from those three that the virtual device had no audio output at all, and nearly filed it as a root cause here. The device had been playing an audible boot chime the whole time. A note in the debugging docs saying the shell is a sandboxed app context — and, better, a permission-denied path that says so rather than reporting the resource as absent — would prevent this entirely. **d. Service declarations cannot be verified in either direction.** Missing services under `[wants]` fail silently, which the guidance already acknowledges. But `[needs]` does not escalate it: a required service that cannot possibly exist still validates, installs, launches and runs — ```auto [[needs.service]] ``` `id = "com.amazon.definitely.not.a.real.service"` ```auto manifest validation found 0 errors ``` `Installing/Updating ... success` `com.sightline.probe.main is running` So there is no way for an app to confirm a service was granted. Validating service IDs at build time, where the manifest is already parsed, would close this — or a `vega device installed-services` command. **e. The audio-only example does not compile.** In [Selecting the Playback Mode](https://developer.amazon.com/docs/vega/0.24/media-player-select-playback), the snippet imports `VideoPlayer` and types the ref as `useRef(...)`, then constructs `new AudioPlayer()`, which is never imported. ## 5. On the physical device comparison I still don’t have a Fire TV Stick 4K Select, so I can’t run that isolation. If it would help your team, I’m happy to share the two probe apps — one that fails in URL mode and one that plays the same content over MSE — as a minimal reproduction. Thanks for the attention on this. The platform has been good to build on once past these; the media documentation is the part I’d point at.