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

Vega Open Beta Bug Reports
1

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:

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:

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:

    Crash reason: SIGSEGV

    Thread 0 (crashed)

    0 libRCT-folly-0.83.so.0.83 + 0x142ca8

    1 libRCT-folly-0.72.so.0.72 + 0xc3642

    2 libRCT-folly-0.72.so.0.72 + 0xc2c02

    3 libRCT-folly-0.72.so.0.72 + 0xc99a2

  • 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:

    CrashLang: Native

    CrashReason: AppNotResponding

    Crash reason: SIGQUIT

    Thread 0 (crashed)

    0 libc.so.6 + 0xe7b84

    1 libasync.so.0 + 0x9bc2

4. Expected Behavior

player.src = "<url to an MP3>" 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, 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, §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’ <minidump_stackwalk> sections. Happy to file those as separate issues if useful.

6. Environment

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:

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:

[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:

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.

4

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 ). (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 ).

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

5

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.

6

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 (284.9 KB)

2#crash_1788868569_30040_5000_5938_11_com_amazondeveloper_keplervideoapp.acr (285.2 KB)

21#crash_1788926931_30042_5000_9662_3_com_amazondeveloper_kepleraudioreferenceapp.acr (390.4 KB)

22#crash_1788926980_30042_5000_10053_3_com_amazondeveloper_kepleraudioreferenceapp.acr (388.1 KB)

3#crash_1788868573_30040_5000_5965_11_com_amazondeveloper_keplervideoapp.acr (286.4 KB)

4#crash_1788868654_30040_5000_7037_11_com_amazondeveloper_keplervideoapp.acr (287.6 KB)

5#crash_1788868912_30040_5000_9757_11_com_amazondeveloper_keplervideoapp.acr (287.1 KB)

loggingctl-playback-capture.log (701.6 KB)

7

@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> (URL mode) none, ever MEDIA_ERR_SRC_NOT_SUPPORTED
VideoPlayer.src = <url> (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:

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:

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 = <url> 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 —

[[needs.service]]

id = "com.amazon.definitely.not.a.real.service"

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, the snippet imports VideoPlayer and types the ref as useRef<VideoPlayer | null>(...), 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.