[Bug]: Old Image Stuck in Image Viewer

ValleyGeek commented

2026-08-13 14:18:15 +00:00

Owner

App version

0.5.0+feature.162 Beta

Platform

Windows

Steps to reproduce

Open a directory
Open another directory
Choose "Close directory and delete cache"
Open a third directory
View an image in the viewer

Expected behavior

The active image should display

Actual behavior

The last image viewed from the closed directory is stuck in the viewer. Changing images doesn't refresh it.

Additional context

No response

### App version 0.5.0+feature.162 Beta ### Platform Windows ### Steps to reproduce 1. Open a directory 2. Open another directory 3. Choose "Close directory and delete cache" 4. Open a third directory 5. View an image in the viewer ### Expected behavior The active image should display ### Actual behavior The last image viewed from the closed directory is stuck in the viewer. Changing images doesn't refresh it. ### Additional context _No response_

ValleyGeek added the

Kind/Bug

Priority/Medium

labels

2026-08-13 14:18:15 +00:00

Claude referenced this issue from a commit

2026-08-20 22:05:08 +00:00

fix(viewer): reload image when reopening session with matching filename

Claude commented

2026-08-20 22:05:19 +00:00

Member

Root cause: ImageViewerSub.open_session() cleared the display/size/fit caches on a new session but never reset _current_rel_path/_current_meta. _go_to_session_index() has an "already showing this image" fast path that skips reloading when the requested session index equals the current one and its resolved relative path matches _current_rel_path. On a freshly opened session that comparison could spuriously match leftover state from the previously viewed directory (e.g. reused filenames, or common camera defaults like IMG_0001.jpg), so the viewer never issued a load for the new directory's image and the stale pixmap stayed on screen.

Fix: open_session() now resets _current_rel_path/_current_meta before positioning, so the fast path can never fire on the first navigation of a new session.

Pushed to 0.6.1/issue-163-stale-viewer-image with a regression test (tests/test_pr8_viewer.py::test_open_session_reloads_when_relative_path_matches_prior_session) that reproduces the stuck image via two directories sharing a filename at the same session index. Full suite (701 passed) and ruff pass. Not yet merged to main — awaiting PR request.

Root cause: `ImageViewerSub.open_session()` cleared the display/size/fit caches on a new session but never reset `_current_rel_path`/`_current_meta`. `_go_to_session_index()` has an "already showing this image" fast path that skips reloading when the requested session index equals the current one *and* its resolved relative path matches `_current_rel_path`. On a freshly opened session that comparison could spuriously match leftover state from the previously viewed directory (e.g. reused filenames, or common camera defaults like `IMG_0001.jpg`), so the viewer never issued a load for the new directory's image and the stale pixmap stayed on screen. Fix: `open_session()` now resets `_current_rel_path`/`_current_meta` before positioning, so the fast path can never fire on the first navigation of a new session. Pushed to `0.6.1/issue-163-stale-viewer-image` with a regression test (`tests/test_pr8_viewer.py::test_open_session_reloads_when_relative_path_matches_prior_session`) that reproduces the stuck image via two directories sharing a filename at the same session index. Full suite (701 passed) and ruff pass. Not yet merged to `main` — awaiting PR request.

Claude referenced this issue from a commit

2026-08-22 00:21:11 +00:00

fix(ui): close directory while in viewer must return to the grid

Claude commented

2026-08-22 00:21:16 +00:00

Member

Found a second, distinct bug behind this — different from the open_session() fix already on this branch (which addressed the original repro through a new directory's session picking up a stale cached image). Your report ("closing a directory and deleting cache is keeping the last viewed image in the viewer") pointed at the close flow specifically.

Root cause: _finalize_workspace_close() (the "Close Directory and Delete Cache" handler) force-cleared self._in_viewer_sub = False directly, then called _reset_workspace_to_grid() — which reads that same flag to decide whether the widget stack needs to switch away from the viewer back to the grid. Since the flag was already cleared, that check always evaluated as "wasn't in the viewer," so the actual widget switch never happened whenever you were browsing the grid before opening the viewer (the common case). The internal bookkeeping said "not in viewer" but the screen kept showing the viewer with the last image, since nothing ever told the QStackedWidget to switch back.

Fixed by removing that premature flag clear, so _reset_workspace_to_grid() sees the true prior state and correctly switches back to the grid. Verified with a regression test that fails without the fix (confirmed currentWidget() was still the viewer) and passes with it. Details in DR-040.

Pushed to 0.6.1/v0.7.0 at f834e80. Let me know if you still see stale images after a directory close on the next build.

Found a second, distinct bug behind this — different from the `open_session()` fix already on this branch (which addressed the original repro through a new directory's session picking up a stale cached image). Your report ("closing a directory and deleting cache is keeping the last viewed image in the viewer") pointed at the close flow specifically. Root cause: `_finalize_workspace_close()` (the "Close Directory and Delete Cache" handler) force-cleared `self._in_viewer_sub = False` directly, then called `_reset_workspace_to_grid()` — which reads that same flag to decide whether the widget stack needs to switch away from the viewer back to the grid. Since the flag was already cleared, that check always evaluated as "wasn't in the viewer," so the actual widget switch never happened whenever you were browsing the grid before opening the viewer (the common case). The internal bookkeeping said "not in viewer" but the screen kept showing the viewer with the last image, since nothing ever told the `QStackedWidget` to switch back. Fixed by removing that premature flag clear, so `_reset_workspace_to_grid()` sees the true prior state and correctly switches back to the grid. Verified with a regression test that fails without the fix (confirmed `currentWidget()` was still the viewer) and passes with it. Details in DR-040. Pushed to `0.6.1/v0.7.0` at `f834e80`. Let me know if you still see stale images after a directory close on the next build.

Claude referenced this issue from a commit

2026-08-22 01:51:00 +00:00

fix(ui): stop closing a directory from permanently killing viewer loads

Claude commented

2026-08-22 01:51:09 +00:00

Member

Found the actual root cause — confirmed by live instrumentation of the real async load pipeline, not a guess. Your report ruled out both prior fixes (no filename overlap between the two directories, so no cache-key collision was possible), which pointed me at the async loading path instead of session/state-transition logic.

_release_workspace_db_locks() unconditionally calls self.viewer.shutdown(), which permanently sets the viewer's image-loader signals to inactive — and nothing anywhere in the codebase ever reactivates them. shutdown()'s own docstring says "before window teardown," and it's correctly called from closeEvent() (real app exit) — but _release_workspace_db_locks() is also called from the routine "Close Directory and Delete Cache" path, not just app exit. Once that flag flips, ViewerImageLoader.run()'s very first check silently no-ops every future image load, for any future directory, for the rest of the session. The very first directory close in a session permanently breaks the viewer — exactly matching "even when cycling image, the tiger image never changed," since no image would ever load again after that first close.

Fix: moved viewer.shutdown() out of the shared helper and into closeEvent() directly, so real app teardown is unaffected but routine directory closes no longer touch it.

Verified with a real (non-mocked) reproduction: two directories with real, distinctly-sized JPEG files, loaded through the actual background thread pool — the test fails on the pre-fix code showing the exact symptom (viewer still shows the first directory's image after opening the second) and passes with the fix. Also confirmed smoke-ui-exit.sh still shows clean app teardown with the relocated call.

Pushed to 0.6.1/v0.7.0 at 7c4d718. Full writeup in DR-041, including why the first two fixes on this branch were each real but insufficient. Appreciate you pushing back on my earlier theories with concrete detail each time — that's what actually got to the real cause.

Found the actual root cause — confirmed by live instrumentation of the real async load pipeline, not a guess. Your report ruled out both prior fixes (no filename overlap between the two directories, so no cache-key collision was possible), which pointed me at the async loading path instead of session/state-transition logic. `_release_workspace_db_locks()` unconditionally calls `self.viewer.shutdown()`, which permanently sets the viewer's image-loader signals to inactive — and nothing anywhere in the codebase ever reactivates them. `shutdown()`'s own docstring says "before window teardown," and it's correctly called from `closeEvent()` (real app exit) — but `_release_workspace_db_locks()` is *also* called from the routine "Close Directory and Delete Cache" path, not just app exit. Once that flag flips, `ViewerImageLoader.run()`'s very first check silently no-ops **every future image load, for any future directory, for the rest of the session**. The very first directory close in a session permanently breaks the viewer — exactly matching "even when cycling image, the tiger image never changed," since no image would ever load again after that first close. Fix: moved `viewer.shutdown()` out of the shared helper and into `closeEvent()` directly, so real app teardown is unaffected but routine directory closes no longer touch it. Verified with a real (non-mocked) reproduction: two directories with real, distinctly-sized JPEG files, loaded through the actual background thread pool — the test fails on the pre-fix code showing the *exact* symptom (viewer still shows the first directory's image after opening the second) and passes with the fix. Also confirmed `smoke-ui-exit.sh` still shows clean app teardown with the relocated call. Pushed to `0.6.1/v0.7.0` at `7c4d718`. Full writeup in DR-041, including why the first two fixes on this branch were each real but insufficient. Appreciate you pushing back on my earlier theories with concrete detail each time — that's what actually got to the real cause.

Claude referenced this issue from a commit

2026-08-22 04:34:30 +00:00

docs: PR-prep for 0.6.2 (issues #163, #167, #168)

Claude referenced this issue from a pull request that will close it,

2026-08-22 04:35:05 +00:00

Fix viewer stuck image, onefile cache prune, status bar scope (0.6.2) #172

ValleyGeek closed this issue

2026-08-22 04:37:18 +00:00

ValleyGeek referenced this issue from a commit

2026-08-22 04:37:21 +00:00

Fix viewer stuck image, onefile cache prune, status bar scope (0.6.2) (#172)

Claude referenced this issue from a commit