image preview gets stuck on `loading...`

[2084x]

since updating from r38 to r39 I've encountered issues with the image preview getting stuck on loading... after moving up and down the file list a few times. resizing the window temporarily fixes the issue until you start moving around again and it comes back. example video:

https://github.com/user-attachments/assets/d5c19aeb-b948-4d27-9590-491f7d35bde0

os: arch linux version: r39 terminal: st previewer: ueberzugpp configs: https://codeberg.org/djvu/dotties/src/branch/master/.config/lf lfub: https://codeberg.org/djvu/dotties/src/branch/master/.local/bin/lfub

[veltza]

I was able to reproduce this issue using 2084x's configuration files.

The issue is quite strange because it only happens when you quickly move from one image to another by holding down the up or down key. And when the image files get stuck in the loading... state, lf no longer runs the previewer script for these files. You can see this happening by monitoring the ueberzugpp log file with tail -F /tmp/ueberzugpp-*.log.

I did some bisecting and found that the issue started when the preload feature was added with https://github.com/gokcehan/lf/pull/2206. Note that this configuration doesn't even use preload.

Edit. I also managed to reproduce the issue with these minimal configuration files that use preloading:

set preload
set previewer ~/.config/lf/previewer

#!/bin/sh
bat -pp -f -- "$1"
echo "$(date): $1" >> /tmp/lf-previewer.log

Press ctrl-r a couple of times, and you should notice that some files remain in the loading state.

[TAforever]

I have the same problem with sixel

[joelim-work]

Thanks for reporting this.

I think what is happening is that previews requests are consolidated for optimization purposes - in other words when scrolling through a list of files, the previewer is only invoked for the last file to avoid making too many system calls. The problem is that if an 'earlier' file is skipped, it will still be marked as 'loading' and the previewer won't be invoked for that file again even if it is selected afterwards.

Does the following patch help fix the issue?

diff --git a/nav.go b/nav.go
index 9b7c601..9754484 100644
--- a/nav.go
+++ b/nav.go
@@ -930,7 +930,7 @@ func (nav *nav) preview(path string, win *win, mode string) {
 
 func (nav *nav) loadReg(path string, volatile bool) *reg {
 	r, ok := nav.regCache[path]
-	if !ok {
+	if !ok || (!gOpts.preload && r.loading) {
 		r = &reg{loading: true, loadTime: time.Now(), path: path}
 		nav.regCache[path] = r
 		nav.startPreview()

[veltza]

@joelim-work It seems to fix the issue when preload is disabled, but not when it is enabled. See my previous post.

[joelim-work]

Enabling preloading results in a completely different scenario.

A list of files to be preloaded is sent to the preload thread, and when scrolling through files by holding down j/k, the list can accumulate very quickly. The preload thread does not skip any files in the same way that the preview thread does, so likely what happens for you is that loading... is displayed for a file because the preload thread is still working on other files and the task for the current file is still somewhere in the queue (it will eventually process but can take a while). This is different compared to the OP where files are marked as 'loading' but actually skipped by the preview thread.

Maybe it's possible to improve the prioritization of files when preloading, but it is outside the scope of this issue. If the above patch works and there are no other objections then I will add it since it fixes a regression. I am also considering creating a patch release to address this bug more urgently.

---

EDIT: I have submitted the following PRs:

• #2292
• #2291

The bug fix is more urgent and if it works I will create a patch release for it. Preloading should still be treated as an unstable feature for the time being, the important thing is to fix the regression.

[2084x]

Does the following patch help fix the issue?

yes, fixes it for me.

[veltza]

The OP has also confirmed that the fix works, so I think the patch release can be created now.

---

(off-topic)

The preload thread does not skip any files in the same way that the preview thread does, so likely what happens for you is that loading... is displayed for a file because the preload thread is still working on other files and the task for the current file is still somewhere in the queue (it will eventually process but can take a while).

No, it won't process them eventually. Some files will stay in the loading state forever.

This is different compared to the OP where files are marked as 'loading' but actually skipped by the preview thread.

Maybe so, but the end result is the same. Some files will never be loaded. I'll try your PR #2291 and leave feedback there.

[joelim-work]

Thanks, I have merged #2292 and closed this issue.

As for preloading, you can try logging if the preload thread receives updates from nav.preloadChan, and see if the previewer is being called for them or not: https://github.com/gokcehan/lf/blob/a9dbaa9dd142763afd2de1713c5991485a4ad2bc/nav.go#L755-L777

Please create a new issue to discuss this further - even if the result appears to be the same, it is still calling a completely different code path so I would regard it as a separate issue.