Closed BennyOe closed 5 months ago
But when I close the terminal without exiting yazi before and then reopen yazi in a new terminal the preview is messed up
You mean you directly killed the parent process (terminal) of Yazi right? If so, Yazi would also be killed, without having the chance to properly clean up the ueberzugpp
process it created, which could lead to issues with ueberzugpp.
Just to double-check, if you exit Yazi normally (by pressing q
), does this issue still occur?
Yes, exactly. So when I kill the parent process the bug occurs and when I'm quitting yazi properly everything works as expected the next time I open it
When you exit the terminal to end Yazi, is the ueberzugpp
process still running? What if it ends like this in other terminals? Is the ueberzugpp
process still running?
Also, could you try the latest code of Yazi to see if this issue still?
No, when I kill the terminal the ueberzugpp process is gone too. I didn't try it with other terminals yet but will later and report. Also I will try with the latest code and report later. Thanks for investigating with me and for this awesome piece of software :)
I have to correct myself. This bug is not happening when the terminal gets killed when yazi is open. Instead it happens after every terminal window is closed when yazi was launched before. This also happens on xTerm.
So as long as one terminal window stays open after yazi was first launched, I can do whatever I want and everything is working. But as soon as I kill all terminal windows the bug occures.
Please follow this https://yazi-rs.github.io/docs/image-preview#why-cant-i-preview-images-via-%C3%BCberzug to see if this is a problem with Überzug++ itself
Unfortunately this works as expected. Also when I kill all terminals and test again, Überzug is showing the images correctly. Also in the Überzug logs everything seems to be ok.
Hi, I've created a PR that includes some debug code, https://github.com/sxyazi/yazi/pull/895. Please build it in debug mode (cargo build
without --release
flag) and repeat the same steps then paste the contents of yazi --debug
, ~/.local/state/yazi/yazi.log
, and /tmp/ueberzugpp-$USER.log
here.
yazi --debug
yazi logs
Ueberzug log
Some additiional information I found. The bug occurs when you kill the first terminal window. You don't even had to run yazi in it. So all is working until you close the first opened terminal window after a reboot. It doesn't matter if this terminal is st or xTerm.
From the log, Yazi sent the correct commands to ueberzugpp, but only the position of the first created subwindow is correct:
[2024-04-11 09:16:18.101] [main] [info] Command received: {"action":"add","identifier":"yazi","max_height":88,"max_width":203,"path":"/tmp/yazi/5a6f49b8dede08f609377205e119afd6","x":344,"y":2}
[2024-04-11 09:16:18.151] [X11] [debug] Created child window 35651584 at (2410,39) with parent 14680070
And the positions of the subsequent ones are (0,0)
:
[2024-04-11 09:16:27.502] [main] [info] Command received: {"action":"add","identifier":"yazi","max_height":88,"max_width":203,"path":"/tmp/yazi/5a6f49b8dede08f609377205e119afd6","x":344,"y":2}
[2024-04-11 09:16:27.543] [X11] [debug] Created child window 35651584 at (0,0) with parent 14680070
So I think this is a bug in ueberzugpp, maybe @jstkdng can provide some input.
It might be related to https://github.com/jstkdng/ueberzugpp/issues/170.
Hi @BennyOe, could you try rolling back ueberzugpp to a version before 2.9.4 to see if it works? As I noticed your ueberzugpp version is also 2.9.4.
Downgrading ueberzugpp to 2.8.8 worked! :+1: Thanks so much for the help!
It's a shame that OP never answered my further inquiries on the other issue. I'll see what I can do. Could be an issue with ST as everything is working fine on my end. @BennyOe can you post your ST patches/config?
I had a similar problem yesterday, after having updated ueberzugpp from 2.9.4-1 to 2.9.4-2 on Archlinux (but this bump of the pkgrel has only been triggered to fix some out of date/missing libraries, I don't know which ones).
It's working again since a reboot, but I still managed to identify a potential problem similar to what I observed yesterday: with Yazi I navigated into a folder with hundreds of images. While everything looked ok on the ui side, a generation process seemed blocked:
When I tried to quit properly Yazi, it warned me:
1 task running, sure to quit?
In the meantime, here was the unfinished job from the ueberzugpp log:
[2024-05-11 13:07:12.939] [opencv] [info] loading file /tmp/yazi/5b580669acab7d41a304b978b4138b2a
[2024-05-11 13:07:14.583] [main] [info] Command received: {"action":"remove","identifier":"yazi"}
# nothing else after
But when I forced quit and re-opened Yazi, everything was still working, so maybe I had no luck yesterday...
Hey @Ornanovitch, this might be due to the failure of image preloading, which is unrelated to the reported Überzug++ bug, since Überzug++ is not handled by the task scheduling system of Yazi, it won't cause the progress bar to appear.
If the issue occurs again, press w
to open the task manager, then hover on the task and press <Enter>
to inspect it, and copy the error information to file a new issue.
I'm going to lock this issue because it has been closed for 30 days. ⏳ This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
What system are you running Yazi on?
Linux X11
What terminal are you running Yazi in?
Suckless Simple Terminal (st)
Did you try the latest main branch to see if the problem got fixed?
Tried, but the problem still
yazi --debug
outputDescribe the bug
When I run yazi in the terminal everything works and the preview is looking good. But when I close the terminal without exiting yazi before and then reopen yazi in a new terminal the preview is messed up. This can only be undone by a system restart.
Expected Behavior
When closing the terminal with yazi open and open it again on another terminal, the preview should still be in place.
To Reproduce
This is happening on Arch Linux with dwm as window manager and st as terminal emulator.
Configuration
Anything else?
This is the log output