Dr.Player v3.2.0

Always-working seek bar (thin line with fill and tick from the first frame), progressive waves drawn on the same center with no transition, waveform disk cache for instant second opens, full-length decode with no duration cap, and a README table of which audio gets waves. See RELEASE_NOTES.md for details.

Dr.Player 3.1.0 — Audio Waveform Seek Bar

Two notes on reading this file, because it is a record of what shipped rather than a list of changes.

How these releases are identified: every version named below is the version Cargo.toml carried at the
commit that cut it, and nothing else. This repository carries one git tag, v0.3.0, and its name never
matched the crate: Cargo.toml reads 0.1.0 at that commit and at every commit before 1.0.0. There is
no tag for v1.0.0, v2.0.0, v2.1.0 or v2.1.1, so nothing here can be checked against one, and whether
a GitHub release exists for any version in this file is not visible from this repository. The tag the
update check compares against is the tag name in GitHub's releases API response, not a tag in this
tree.

Corrections: where an entry was wrong and has since been fixed, the fix is recorded in place with the
commit that changed it, rather than made silently. Two entries have been corrected in this revision:
the v2.1.1 opening paragraph, and two sentences in v2.1.0. The v0.2.0 and v0.3.0 sections are
reconstructions, and they got there differently. v0.2.0 did have an entry here, written by 5653afa
and deleted wholesale by 75e9ab8, which replaced this file with a single v1.0.0 heading. v0.3.0
shipped with no entry at all, and none has been added since. Each section says which of the two it is
at the top.

Dr.Player v3.1.0

A visual and functional upgrade to the seek bar, rendering the file's own audio waveform directly on the timeline with background decoding, resilient fallback, and no external dependencies.

Waveform Seek Bar
The flat seek track in the bottom chrome now renders a real audio waveform matching the video's soundtrack, tall where loud and flat where quiet, in clean white for played segments and subtle grey (#646466) for unplayed segments. The waveform is computed from actual audio samples decoded from the media container, normalised against the loudest peak so quiet recordings maintain visible shape without clipping.

Non-Blocking Background Decode with Resilient Fallback
Audio extraction runs on a dedicated background thread using the bundled symphonia library. The UI remains responsive and immediately scrubbable from the instant the window opens; peaks stream incrementally in 512-peak batches at 20ms resolution across the event loop, filling the waveform in from left to right. When playing files without audio (or formats/containers not readable by the demuxer), the seek bar remains the original plain line. If the video fails to decode while audio succeeds, the bar preserves the fallback plain line rather than showing an empty canvas.

Resource Bounding and Process Safety
Audio extraction enforces a generous 2-hour budget (WAVE_MAX_SECONDS = 7200.0), preventing denial-of-service or unbounded memory growth from enormous or crafted audio files. The background thread is detached, meaning closing the window mid-decode exits immediately without hanging.

Design Deviation Note:
design.md:124 specified that metadata (Meta) would be attached to the first Chunk only. The implementation instead sends a standalone Meta message before the first batch (carrying the container's declared duration) and another at the end of the decode (carrying the exact decoded duration). This allows the page to establish timeline boundaries immediately during streaming and settle accurately once decoding concludes.

Dr.Player v3.0.0

A major feature and UI overhaul introducing modern playback speed controls, YouTube-style hold-to-speed, intelligent control bar visibility, and portable state persistence.

Hold-for-Speed Playback & Floating Indicator

Pressing and holding the Spacebar (or pressing and holding the mouse on the video stage) now temporarily accelerates playback to a chosen fast-forward rate (default 2x). While held, the entire player chrome is smoothly hidden and a minimal, YouTube-style floating glassmorphic pill appears displaying the current temporary rate (e.g. "2x"). Releasing the key or mouse immediately restores normal playback speed and preserves chrome hiddenness until the mouse is moved.

Redesigned Glassmorphic Speed Adjustment Panel

The playback speed adjustment popover has been upgraded to a dark glassmorphic interface matching the player's aesthetic. A full-range slider spans the webview engine's entire range (0.06x to 16x) alongside a full-width editable input box. Preset buttons (1.5x, 2x, 3x, 4x) act as one-click quick targets. The chosen temporary speed is memorized globally across all videos and sessions.

Intelligent Controls Visibility on Pause

Controls remain visible whenever the video is paused, keeping playback controls and timeline accessible during inspection. While playing, controls automatically fade away after 3 seconds of inactivity. Controls hide completely in temporary speed mode or when explicit hide mode (H or the eye button) is toggled.

Portable Application State Persistence

Application state (state.json) is now stored directly in the executable's directory rather than in the operating system's roaming AppData directory. Existing state files from AppData are automatically migrated on launch. This ensures Dr.Player is fully portable whether installed or run standalone from any drive or directory, preserving window geometry, per-video resume points, and global speed preferences.

Dr.Player v2.2.0

The first release that adds a capability rather than correcting one. Three features, all of them
about where the app is rather than what it plays, and one defect fixed that made the drawing tools
quietly wrong.

This release also ends the app having no persistent storage at all. A single JSON file in the
per-user config directory now holds a playback position per file and the window rectangle, and it
is the first thing this app has ever written outside its own install directory.

Resume Playback

Opening a video that has been watched before plays from 0:00 as it always has, and offers a single
button reading "Continue from HH:MM:SS". Pressing it inside ten seconds seeks there and playback
continues. Letting it lapse does nothing, and the video keeps playing from wherever it has reached,
which is the right outcome for someone who came to watch the whole thing. The offer is not made for
a position under five seconds, past ninety per cent of the duration, or past the duration itself,
the last of which covers a file that has been replaced by a shorter one. Reaching the end clears
the stored position rather than recording the final timestamp, because a finished file that keeps
asking to be resumed is the commonest way this goes wrong.

The ten seconds run from the moment the offer appears and keep running while it is hidden. Hiding
the chrome with H takes the offer down with it, because that is the user asking for a clean screen,
and bringing the chrome back inside the window brings the offer back. The three second passive
auto-hide deliberately does not, or the window would be three seconds long in practice rather than
ten.

Window Size and Position

The window reopens where it was left, at the size it was left. There is no minimum on the live
resize path, because being able to make the window very small is deliberate and is not a defect to
be corrected. Two rules apply only when the saved rectangle is read back at launch: a size below a
small floor falls back to the default, and a rectangle that does not sit wholly inside a currently
connected monitor is discarded in favour of a centred window.

The second rule is not tidiness. This window is frameless, so one restored onto a monitor that is no
longer attached has no titlebar to drag it back with, which is why other projects have disabled
position restore on Windows outright rather than risk it.

Frame Stepping

The -1F and +1F controls moved the picture by exactly one sixtieth of a second. That is one frame
only on a sixty frame per second source. On twenty-four, twenty-five, thirty, fifty or a hundred
and twenty frames per second it moved a fraction of a frame or several of them, so stepping through
to mark a shot landed between frames. The step is now measured from the source itself, using
requestVideoFrameCallback where the engine provides it, and falls back to the old fixed step where
it does not.

This is not frame accurate seeking and is not described as such anywhere. currentTime is a position
in seconds and the engine decodes from whatever frame is nearest; only WebCodecs promises to land
on a frame. A variable frame rate source is not averaged over: every callback overwrites the
interval with the gap between the two frames it was just handed, so such a file is characterised by
the last two of them, and a measurement landing within two per cent of one of the nominal rates is
snapped to that rate exactly.

Known, and unchanged

The playback position is written when the video is paused and when the window is closed through the
window's own button. Alt+F4, the taskbar, or a crash keep whatever the last pause recorded.
Annotations drawn in draw mode are still discarded on exit and are still not exported, which is the
point of them.

Dr.Player v2.1.1

This is a correction release, not a feature release. No code changed: every fix below is in the
installer around the app, and none of them is a new capability. The binary and the installer were
both rebuilt rather than reused, because the version is frozen into the executable at compile time by
env!("CARGO_PKG_VERSION"): a version bump with no rebuild leaves the app asking GitHub for updates
against a number its own release has already moved past, and offering the user an update to the
version they were already running. Six behaviour changes are listed below, and two exist because
v2.1.0 shipped a claim it did not keep: the per-extension default it wrote, and the finish page that
said the association was there; a third does so if the v2.1.0 entry's claim that the how-to text file
was gone counts as one.

What this record cannot show you about that paragraph: the 2.1.0-sta...

Dr.Player v3.0.0

Dr.Player v3.0.0

A major feature and UI overhaul introducing modern playback speed controls, YouTube-style hold-to-speed, intelligent control bar visibility, and portable state persistence.

What's New in v3.0.0:

• Hold-for-Speed Playback & Floating Indicator:

  • Press and hold Spacebar (or press-and-hold the mouse on the video stage) to temporarily fast-forward playback (default 2x).
  • Minimal floating glassmorphic speed pill (e.g. 2x) at the top-center of the screen.
  • Video immediately resumes normal playback on release, and player controls remain cleanly hidden until intentional mouse movement.

• Redesigned Glassmorphic Speed Adjustment Panel:

  • Full-range continuous speed slider spanning 0.06x to 16x.
  • Direct custom numeric input field for precision playback speed.
  • One-click quick presets: 1.5x, 2x, 3x, and 4x.
  • Global persistence of the chosen temporary hold speed across all sessions and videos.

• Intelligent Controls Visibility:

  • Player controls stay visible whenever video playback is paused, making timeline scrubbing and inspections seamless.
  • While playing, controls auto-fade after 3 seconds of inactivity.
  • Controls hide cleanly during temporary fast-forward mode or when explicit hide mode (H / eye button) is toggled.

• Portable Application State Persistence:

  • Application settings (state.json) are now saved directly in the executable's directory rather than %APPDATA%, ensuring full portability whether installed or run standalone from any drive or folder.
  • Automatically migrates existing settings from %APPDATA% on launch.
  • Persists window geometry, per-video resume points, and global playback speed settings.

Assets:

• DrPlayer-Setup.exe — Windows installer with optional file associations
• dr-player.exe — Standalone portable executable

Dr.Player v2.2.0

Dr.Player v2.2.0

The first release that adds a capability rather than correcting one. Three features, all of them
about where the app is rather than what it plays, and one defect fixed that made the drawing tools
quietly wrong.

This release also ends the app having no persistent storage at all. A single JSON file in the
per-user config directory now holds a playback position per file and the window rectangle, and it
is the first thing this app has ever written outside its own install directory.

Resume Playback

Opening a video that has been watched before plays from 0:00 as it always has, and offers a single
button reading "Continue from HH:MM:SS". Pressing it inside ten seconds seeks there and playback
continues. Letting it lapse does nothing, and the video keeps playing from wherever it has reached,
which is the right outcome for someone who came to watch the whole thing. The offer is not made for
a position under five seconds, past ninety per cent of the duration, or past the duration itself,
the last of which covers a file that has been replaced by a shorter one. Reaching the end clears
the stored position rather than recording the final timestamp, because a finished file that keeps
asking to be resumed is the commonest way this goes wrong.

The ten seconds run from the moment the offer appears and keep running while it is hidden. Hiding
the chrome with H takes the offer down with it, because that is the user asking for a clean screen,
and bringing the chrome back inside the window brings the offer back. The three second passive
auto-hide deliberately does not, or the window would be three seconds long in practice rather than
ten.

Window Size and Position

The window reopens where it was left, at the size it was left. There is no minimum on the live
resize path, because being able to make the window very small is deliberate and is not a defect to
be corrected. Two rules apply only when the saved rectangle is read back at launch: a size below a
small floor falls back to the default, and a rectangle that does not sit wholly inside a currently
connected monitor is discarded in favour of a centred window.

The second rule is not tidiness. This window is frameless, so one restored onto a monitor that is no
longer attached has no titlebar to drag it back with, which is why other projects have disabled
position restore on Windows outright rather than risk it.

Frame Stepping

The -1F and +1F controls moved the picture by exactly one sixtieth of a second. That is one frame
only on a sixty frame per second source. On twenty-four, twenty-five, thirty, fifty or a hundred
and twenty frames per second it moved a fraction of a frame or several of them, so stepping through
to mark a shot landed between frames. The step is now measured from the source itself, using
requestVideoFrameCallback where the engine provides it, and falls back to the old fixed step where
it does not.

This is not frame accurate seeking and is not described as such anywhere. currentTime is a position
in seconds and the engine decodes from whatever frame is nearest; only WebCodecs promises to land
on a frame. A variable frame rate source gets the average of what was sampled, not a per-frame
figure.

Known, and unchanged

The playback position is written when the video is paused and when the window is closed through the
window's own button. Alt+F4, the taskbar, or a crash keep whatever the last pause recorded.
Annotations drawn in draw mode are still discarded on exit and are still not exported, which is the
point of them.

Dr.Player 2.1.1

Do not install 2.1.0. It overwrote another program's fallback file association and kept no copy, so a later uninstall left four file types resolving to a program that no longer existed. 2.1.1 fixes that. If you already installed 2.1.0, install 2.1.1 over it and do not uninstall in between.

This release changes the installer and the documentation only. No application code changed, so 2.0.0, 2.1.0 and 2.1.1 play video identically.

If you are on 1.0.0, launch it with a video first: the update chip in the top bar will offer you this release.

---

Dr.Player v2.1.1

This is a correction release, not a feature release. No code changed: the binary is the same
v2.1.0 build, and none of what follows is a new capability. What changed is the installer around
it, and four of the five fixes exist because v2.1.0 shipped a claim it did not keep.

Why a fresh install was needed rather than an upgrade: v2.1.0's installer wrote the per-extension
fallback default for all four types, so installing it on a machine that already had a video player
replaced that program's fallback with Dr.Player.Video and kept no copy of what was there. On a
machine where VLC is installed, .mp4, .m4v, .mov and .webm all read VLC.mp4, VLC.m4v, VLC.mov and
VLC.webm, and v2.1.0 put Dr.Player.Video over all four. The uninstaller then deliberately left
that value naming a ProgID it had just deleted, and nothing shipped to put VLC back, so
install-then-uninstall left four file types with a fallback pointing at nothing and no error at
either end. A machine that has already run v2.1.0 has those four values overwritten and this
release does not put them back, because doing it safely means reading each extension's current
value and restoring it only while it is still ours, which is a guarded restore and is not in this
release. The four VLC values are still on this machine today, untouched, and the values VLC keeps
beside them read WMP11.AssocFile.MP4 and WMP11.AssocFile.MOV.

• The per-extension (Default) is no longer written at all, and neither are Content Type or
  PerceivedType beside it. Windows consults that value only when no valid UserChoice exists for
  the type, so on any machine where the user has ever chosen a handler it did nothing at all; on
  the machines where it would apply, a fresh profile or a new image, it overwrote another
  program's fallback with no copy kept. OpenWithProgids, which is what actually puts Dr.Player in
  the Open with list, is unchanged and is the whole of what the section writes now
• Uninstalling removes the WebView2 profile directory, recursively, so it can finish. That
  directory is created by the embedded browser beside the exe on first run, 193 files and about
  8.5 MB on this machine, and no version of the installer had ever deleted it. RMDir only removes
  an empty directory, so uninstall used to delete the exe, delete the uninstaller, delete the
  Add/Remove Programs entry, and leave the install directory standing with that profile in it and
  no way back
• The uninstaller now deletes the shell's association-toast values under the names that key
  actually uses, <object>_.<ext>, for both objects a Dr.Player registration produces: the
  Dr.Player.Video ProgID and Applications\dr-player.exe. It was deleting a value named
  Dr.Player, and that key has never held one, so the line had never removed anything
• An install directory on a network share is now refused. AllowRootDirInstall was already refusing
  the share itself, \Server\Share, but not a subdirectory of it, and a typed
  \Server\Share\Dr.Player would have put a binary this user does not control into the handler
  for four file types. The refusal is a .onVerifyInstDir callback, which also rejects a
  drive-relative path such as C:Programs
• Installing now deletes v2.0.0's How to open a video.txt and the two shortcuts that pointed at
  it. They were deleted by the uninstaller only, so a machine upgraded from v2.0.0 still had all
  three on disk and still had the Win+R instruction on its own Start Menu after installing v2.1.0
• The finish page no longer says the association exists. It says that if you left the file
  associations selected, Dr.Player now appears in Open with, because the section that creates it
  is one you can untick
• Two comments that were wrong have been corrected rather than removed. The uninstaller no longer
  claims the shell residue "does not put Dr.Player back in the Open with list": on a machine that
  had already used Dr.Player it does, .mp4 holds i = dr-player.exe, .mov holds c and .webm holds d
  in Explorer\FileExts<ext>\OpenWithList, and those are positional letters bound to a shared
  most-recently-used list that also holds VLC, mpv, AfterFX, Premiere, Brave and Photos. Removing
  one shifts the rest, so they are left, and a user who wants it gone clears it from Explorer's
  own Open with list

Dr.Player 2.1.0

Do not install 2.1.0. Use 2.1.1.
2.1.0 overwrote another program's fallback file association and kept no copy, so uninstalling it afterwards left four file types resolving to a program that no longer existed. The release notes below also described the failed-decode behaviour incorrectly; that is corrected in 2.1.1. If you already installed 2.1.0, install 2.1.1 over it rather than uninstalling first.

---

Windows, as before: the installer installs into your own user profile and needs no administrator rights.

This release changes the installer and the documentation only. No application code changed, so 2.0.0 and 2.1.0 play video identically.

If you are on 1.0.0, launch it with a video first: the update chip in the top bar will offer you this release.

---

Dr.Player v2.1.0

File Associations

• Dr.Player now appears in the Open with list for .mp4, .m4v, .mov and .webm, so a video opens
  the way a video opens: double-click it, or pick Dr.Player from an Open with menu, and it plays.
  Four types and no more, because those are the ones the embedded engine decodes with no bundled
  codec. A type it cannot decode does not fail politely: the window comes up titled "Error loading
  video" and has to be closed from Task Manager, which is why .avi, .wmv, .flv, .mpeg and .ogv
  are absent rather than merely untested
• The registration goes under HKCU\Software\Classes, per user and with no administrator rights,
  which is the only scope an unelevated installer can honestly claim. One version-independent
  ProgID, Dr.Player.Video, sits behind all four, so a later release re-registers the same name and
  a user who has already chosen Dr.Player keeps a working handler instead of losing one to a
  handler that appeared and disappeared
• The installer will not make itself the default and does not claim to. Windows keeps that choice
  in Explorer\FileExts<ext>\UserChoice, which is obfuscated, hash-protected and blocked from
  writes by a filter driver, so no installer may take a file type away from the program someone
  already uses. Dr.Player sets AllowSilentDefaultTakeOver instead, which is Microsoft's way of
  saying the same thing from the other end: stay in the list, keep out of the decision. Somebody
  who already had another video player keeps it and simply gains Dr.Player beside it
• Becoming the default is one choice, made once, in Windows' own UI: Settings > Default apps, or
  right-click a video, Open with, Choose another app, then dr-player.exe. The finish page offers
  to open that screen, unchecked, and Windows 10 opens the plain page where Windows 11 opens
  Dr.Player's own
• Uninstalling takes back exactly what was added: the ProgID key and the application key, whole and
  recursively, so nothing is left pointing at an exe that is gone, plus Dr.Player's own value in
  each of the four OpenWithProgids lists and under RegisteredApplications. The per-extension
  default value is deliberately left in place, because Microsoft's guidance is not to remove a
  value another program may have taken over since

Installer

• The how-to text file is gone, with the Start Menu and desktop shortcuts that pointed at it and
  the finish-page checkbox that opened it. Nothing shipped tells you to run a command line any
  more, because nothing shipped needs one: the app still takes exactly one argument, and the
  association supplies it
• The optional desktop-shortcut section went with it. It existed only to shortcut to that text
• The finish page now says where the app installed and that it is in the Open with list, and offers
  to open Default Apps rather than to start the app. The app exits with code 2 when started with
  no argument, which is why there has never been a shortcut to the exe and still is not one

Dr.Player 2.0.0

Nothing in this release changed but the version number: no code, no dependency and no behaviour, so there is nothing here that has not already been described under v1.0.0.

It exists so that the update check added in v1.0.0 has something newer to report. A copy still stamped 1.0.0 compares equal to the old tag rather than behind it, and equal is not newer, so the chip would never appear for anyone already sitting on 1.0.0.

If you are on 1.0.0, launch it with a video and the update chip should appear in the top bar within a few seconds. Clicking it opens this page in your browser. Nothing downloads or installs on its own.

Windows, as before: the installer installs into your own user profile and needs no administrator rights. The portable binary is also attached if you would rather not install.

Dr.Player 1.0.0

Dr.Player v1.0.0

Window and Controls

• H hides every on-screen control and brings them back, from anywhere outside draw mode. It is the
  bare key, not Ctrl+H: WebView2 holds back a fixed set of its own chords and never delivers them
  to the page, which is what made the Ctrl+H this once used dead
• With the chrome hidden there is no title bar left to grab, so a press on the stage drags the
  window. Edge resize still wins over it, and it never fires in draw mode
• Hiding the chrome no longer hides the mouse pointer. It used to apply cursor: none along with
  the chrome, leaving no way to tell where the pointer was on the video; that rule is gone and the
  edge resize cursors are back
• The eye button in the top bar pins the chrome off, and the auto-hide timer no longer brings it
  back behind your back
• The shortcuts panel owns the keyboard while it is open, so nothing else fires behind it, and a
  Tab can no longer land in a control at opacity 0
• Hide and fill are inline SVG rather than the characters they were, and each swaps two variants so
  the state is in the icon and not only in the behaviour
• A help button opens the shortcuts panel

Fill Mode

• C, or the fill button, reshapes the window to the video's own shape, so the picture covers the
  window edge to edge with no bars, nothing cropped and nothing stretched. It changes the window,
  never the picture
• It is shape-aware. A resize drag corrects the axis the drag is not driving, so a gesture ends on
  the video's ratio whichever way it went; a corner follows the axis that moved less, so the axis
  the cursor led is the one kept
• When the window is reshaped from outside, fill mode gives way rather than arguing: no corrective
  resize is posted, the window is left where Windows put it, and the button stops claiming a mode
  that is no longer happening, so the picture goes back to fitting inside the window with the bars
  that fall

Window Sizing and Small Windows

• Window sizing is no longer clamped. A resize is refused only when a dimension is not a finite
  number of at least 1, so the window goes where the drag takes it
• A compact layout, because a window with no minimum size can be squeezed on both axes. Under 849px
  wide the buttons on the right of the bottom row go whole rather than half, keeping play/pause,
  both time readouts and the whole track, so a mouse-only viewer can still pause and scrub; what
  goes is on the keyboard anyway. Under 600px the title capsule, the update chip, hide, fill and
  minimize go, leaving the help button, the pen, the cross and the drag handle. Under 328px the
  digits drop to 10px so the track stays worth pressing. The bottom row is never hidden for height,
  because it is the only way to pause and scrub; a window shorter than 89px loses the title capsule
  instead, so the drag band stops lying over the row
• The rate field is fixed at six characters, so the group is the same width holding 0.0625 as
  holding 16.00 and no value a keyboard can produce widens the row

Bottom Chrome

• Flat chrome with no blur: the bottom bar is opaque and its chips carry no glass, so it does not
  wash the video out
• The timeline moved to a full-width strip with the time readouts bracketing it, and play/pause
  sits immediately beside it, so the control you reach for most is next to the thing it moves

Playback Speed

• Playback speed is a typed field rather than a row of stops, across the engine's own 0.0625 to 16
  range rather than a round subset of it. Typing clamps or refuses on Enter and on blur, and the
  field never ends up holding a number that is not playing
• [ and ] step the rate, the field's arrows step it, PageUp and PageDown step it a page, and Home
  and End are left to the caret. Every key inside the field stops propagating first, so typing
  0.0625 does not fire a frame step on the period in it

Keyboard

• A shortcuts panel on / or the help button, listing every binding the player and the draw bar
  actually have
• The player handler switches on e.code rather than e.key, so the bindings are the same on a
  non-US layout
• Escape leaves draw mode. The E key that used to do it is gone
• Backspace clears every shape on its own, and stays undoable. The Ctrl+Backspace it replaced was
  correct and unreachable, because WebView2 never delivers that chord to the page

Installer

• An NSIS installer for Windows, installing into the current user's own profile so no
  administrator rights are needed. Nothing installed can start the app on its own, because it needs
  a video file named on the command line, so the wizard points at a how-to text instead of a Run
  button
• The installer's version is passed in on the command line from Cargo.toml rather than written into
  the script, which is how the crate and the installer drifted apart before

Update Check

• One HTTPS GET per launch asks GitHub for the latest release. If it is newer, a chip appears in
  the top bar and its button opens the releases page in the default browser, so the video never
  leaves the window
• A copy bundled inside PDEA skips the request entirely rather than promising an update it cannot
  deliver, decided by a sibling app.asar so PDEA has to change nothing
• Every failure answers no. The cost of being wrong about a standalone copy is one prompt about a
  release that does exist; the cost of the other way round is a bundled copy that has gone quiet
• DRPLAYER_EMBEDDED forces the answer either way without a rebuild

Known

• No automated test suite. The earlier Vitest/jsdom suite was deleted; coverage is manual, through
  TESTING.md and the sample videos in TESTING_videos/
• The text tool is unreachable: no toolbar button and no key selects it, so text annotations cannot
  be created from the UI