Hi Ivy,
Thanks for following up. I was able to gather more details and narrow the reproduction down quite a bit.
- Exact versions
Vega SDK:
0.24.9914
Vega CLI:
1.3.4
@amazon-devices/react-native-w3cmedia:
2.3.2
React Native:
0.83.0
VVD /etc/os-release:
NAME=“OS”
OE_VERSION=“4.0.0”
OS_MAJOR_VERSION=“1”
OS_MINOR_VERSION=“2”
RELEASE_ID=“21”
OS_VERSION=“1.2”
BRANCH_CODE=“TV Ship”
BUILD_DESC=“OS 1.2 (TV Ship/101520710)”
BUILD_FINGERPRINT=“1.0.152071.0(9a1d8dfa7da5d600)/101520710N:user/dev-keys”
BUILD_VARIANT=“user”
BUILD_TAGS=“dev-keys”
BUILD_DATE=“Wed Jul 15 22:17:13 UTC 2026”
BUILD_TIMESTAMP=“1784153833”
VERSION_NUMBER=“2111172071030”
- loggingctl capture
I was able to capture another MediaError 4 occurrence with:
vega exec vda shell loggingctl log -o short-precise -f
The UI showed:
VIDEO UNAVAILABLE
MediaError 4: No diagnostic message
0:00 / 0:00
The failure occurred at approximately 09:16:34 UTC on Sep 16 (18:16 JST), and I stopped logging immediately afterward.
I will attach the full loggingctl capture.
A few things I noticed in the same time window:
- PlayerSessionManagerImpl logged several:
“EventHook unintended callback for playback state”
- W3CMEDIA logged HtmlMediaElement::pause.
- A separate component,
com.amazondeveloper.keplervideoapp.onInstallOrUpdateTask,
crashed with SIGSEGV twice in the same general window.
I am not assuming any of those events are causal, but I am mentioning them in case they are useful when reviewing the full log.
- Player lifecycle
There is one VideoPlayer instance retained for the lifetime of the React hook.
The app does NOT autoplay on entry. App.tsx calls:
const playback = usePlayback(activeMediaUri, undefined, false);
However, on mount, usePlayback still initializes the player and prepares the source:
initialize()
→ player.src = uri
→ player.load()
Normal playback, pause/resume, source reloads, and Retry reuse the same initialized VideoPlayer instance.
The player is not deinitialized between normal plays or Retry operations.
When the app moves to the background:
When returning to foreground:
On unmount:
initialize/deinitialize operations are serialized through a Promise chain, and a generation value is used so callbacks from a retired session are ignored.
The lifecycle helper is:
export class PlayerLifecycle {
private chain: Promise = Promise.resolve();
private generation = 0;
private initialized = false;
private enqueue(operation: () => Promise): Promise {
const result = this.chain.then(operation, operation);
this.chain = result.then(() => undefined, () => undefined);
return result;
}
initialize(player: NativePlayerLifecycle): Promise {
const session = ++this.generation;
return this.enqueue(async () => {
if (!this.initialized) {
await player.initialize();
this.initialized = true;
}
return session;
});
}
deinitialize(player: NativePlayerLifecycle): Promise {
const retiredSession = ++this.generation;
return this.enqueue(async () => {
if (this.initialized) {
await player.deinitialize();
this.initialized = false;
}
return retiredSession;
});
}
isCurrent(session: number): boolean {
return this.initialized && session === this.generation;
}
}
Retry intentionally reloads the existing initialized player rather than deinitializing/reinitializing it.
- Reproduction pattern
After more testing, I need to correct my earlier impression about the failure appearing after repeated playback.
The issue now appears specifically related to a full VVD cold start.
Case A:
vega virtual-device start
→ launch Orchestra Lens immediately
→ MediaError 4 occurs
I can reproduce this shortly after the VVD is started.
Case B:
vega virtual-device start
→ wait approximately 1 minute
→ launch Orchestra Lens
→ playback works normally
Case C:
vega device reboot --device VirtualDevice
→ launch Orchestra Lens immediately after reboot
→ playback works normally
I repeated the reboot case several times and could not reproduce MediaError 4.
Also, once playback succeeds in a VVD session, repeatedly pausing and playing again has not reproduced the error for me.
So far, I do not see a correlation with the number of plays or elapsed playback time.
This looks more correlated with the first media initialization/load shortly after a full vega virtual-device start.
One additional UI detail: when the failing startup happens, Orchestra Lens remains in its own “Preparing recording…” state before MediaError 4 appears. That text simply means playback.ready is still false in the application.
- Physical device
I have only reproduced this on the Vega Virtual Device.
I do not currently have a physical Vega Fire TV device available for comparison.
One correction to my earlier report:
I can no longer reproduce the case where a VVD restart itself does not recover playback.
A guest reboot using:
vega device reboot --device VirtualDevice
works normally for me.
The reproducible distinction appears to be between a full VVD cold start using vega virtual-device start and a reboot of an already-running VVD.
Please let me know if you would like a more targeted loggingctl capture around the cold-start case, or any additional lifecycle logging.
I’ve also attached:
- FRICTION_LOG.md, which documents the issue history and troubleshooting
- orchestra-vvd.log, the full loggingctl capture from the reproduced MediaError 4 case
Warm regards,
Atsushi Yago
(attachments)
FRICTION_LOG.md (3.02 KB)
orchestra-vvd.log (555 KB)