Skip to content

fix(viewer): release old folder images and prevent playback stalls - #87 - #95

Merged
TheRealShek merged 3 commits into
mainfrom
fix/87-folder-image-cache
Sep 15, 2026
Merged

TheRealShek merged 3 commits into
mainfrom
fix/87-folder-image-cache

Conversation

@TheRealShek

@TheRealShek TheRealShek commented Sep 14, 2026 •

Copy link
Copy Markdown
Owner

Problem:
Opening an unrelated video folder left decoded images from the previous folder cached. Repeated image/video transitions also exposed a playback deadlock: GTK queried playbin's mute property while a streaming thread held the playsink lock and waited for GTK to initialize the video sink.

Solution:

  • After cancelling obsolete decodes, retain only cached images in the installed folder. Same-folder opens keep cache hits; empty/error presentation clears the cache and pin without discarding Navigation or Trash Undo state.
  • Prepare the GTK sink in Ready on the main thread before starting playbin. Normal playback, subtitle replacement, and subtitle recovery share this boundary. Failed startup and stop also release a prepared sink that playbin has not adopted.
  • Update the README and owning requirements. Add regressions for cache ownership, late completions, startup failure cleanup, repeated playback and broken-video errors, subtitle rebuild/recovery, and real rotate-save → Trash → Undo.

The sink's main-thread requirement is visible in its Null → Ready implementation. Preparing it before streaming removes the lock cycle instead of suppressing transport queries.

Tests:

  • Passed: cargo fmt --check, cargo clippy --locked --all-targets -- -D warnings, cargo test --locked (194 passed; 16 desktop/fixture checks ignored by default), cargo build --release --locked, and diff whitespace checks.
  • Passed separately on GNOME/Wayland: 12 targeted desktop checks covering folder replacement, late decode results, external edits and rename races, bounded decoding, ten repeated image/video cycles with malformed-video errors, subtitle replacement/recovery, rotate-save → Trash → Undo, subtitle failure UI cleanup, and cached-navigation presentation latency.
  • Passed: three complete image/video cycles each with Intel vavp8dec, NVIDIA nvvp8dec, and explicitly selected software vp8dec. No open-request timeouts; all three old glycin-frame mappings disappeared on every transition to the video folder.
  • Passed: 20 cached Next/Previous actions timed through GDK compositor presentation feedback: 6.8 ms minimum, 9.5 ms median, 51.8 ms maximum, below the 100 ms navigation target. This includes action dispatch through presentation, but not physical keyboard-device latency.
  • Standards review: 0 findings. Spec review: 0 findings.
  • Packaging checks skipped because scripts, dependencies, packaging and application metadata are unchanged.

Measured release-build process-tree PSS (MiB):

Decoder Fresh video settled Post-image video settled, cycles 1 / 2 / 3 Video-transition sampled peaks, cycles 1 / 2 / 3 Whole-run sampled peak
Intel 143.3 153.6 / 158.8 / 152.3 229.5 / 165.5 / 238.2 245.4
NVIDIA 228.5 241.0 / 244.5 / 245.8 296.3 / 312.7 / 245.8 312.9
Software 130.6 147.5 / 170.1 / 170.3 157.3 / 176.8 / 249.0 250.3

The earlier local base software run retained three old frame mappings and settled at 214.4 / 224.2 / 238.4 MiB across three cycles. The final build retained zero old image mappings in all nine video transitions. Native decoder/renderer allocations still contribute to PSS; cache cleanup does not promise fresh-launch memory usage.

Method: Fedora GNOME/Wayland, optimized build, GSK_RENDERER=gl, default 256 MiB cache, three 4000×3000 gradient JPEGs, and a 1920×1080/30 VP8 WebM. Each process opens a fresh video, browses a/b/c images, reopens b, and returns to the unrelated video folder three times. Recursive process-tree PSS is sampled approximately every 100 ms, including while forwarding open requests; video settled values are medians of seconds 5–8. Peaks can miss shorter spikes and PSS does not fully account for GPU memory. These are exploratory single runs with three cycles each, not statistical guarantees. The earlier base run sampled after forwarding returned, so its peaks are not directly comparable to the final peaks above.

Issue:
Fixes #87

Note:
Implementation and agent-run verification are complete. This remains a draft for author review and personal desktop testing; no installation or merge was performed.

Close any existing instance, then run ./target/release/open-mpv /path/to/media. Review same-folder reopening, repeated image/video switching, volume/mute and playback controls, external image edits, and rotate-save → Trash → Undo. The former repeated-transition deadlock is resolved and is no longer a verification blocker.

@coderabbitai

coderabbitai Bot commented Sep 14, 2026 •

Copy link
Copy Markdown

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 8ebae192-4a98-4d7d-9264-6713c089d8fa


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@TheRealShek TheRealShek changed the title fix(loader): release decoded images from previous folders - #87 fix(viewer): release old folder images and prevent playback stalls - #87 Sep 14, 2026
@TheRealShek
TheRealShek marked this pull request as ready for review September 15, 2026 04:55
@TheRealShek
TheRealShek merged commit 89edcea into main Sep 15, 2026
4 checks passed
@TheRealShek
TheRealShek deleted the fix/87-folder-image-cache branch September 15, 2026 05:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Release decoded images from the previous folder to reduce RAM usage

1 participant