Irresponsive interface on network copy

[Vladimir-csp]

I've copied a large video file over sshfs (from remote to local), SpaceFM GUI became frozen about a minute after transfer started, it did not respond nor update, but FS in background still worked, file transfer continued. GUI was frozen until it finished copying.

A bunch of messages in terminal:

[matroska,webm @ 0x7f3d5c3c86c0] Read error
Seeking in video failed, will use first frame
[matroska,webm @ 0x7f3d5c3c5c00] Read error
Seeking in video failed, will use first frame
[matroska,webm @ 0x7f3d5c3c5c00] Read error
Seeking in video failed, will use first frame

[IgnorantGuru]

I doubt this is anything new. Even where change detection on a filesystem is disabled, if you do something in the tab, such as right-click, the GUI thread needs filesystem info to build the menu, etc. Any such unresponsiveness in SpaceFM is generally always the kernel not responding because the filesystem is busy. SpaceFM is as fast as your filesystem.

To avoid those temporary hangs, you can generally close the tab of the remote dir while the copy is in progress, or avoid that tab.

The messages you showed are from the video thumbnailer (soon to be gone, the developer just removed that verbose logging for the next release). Ofc if change detection is disabled for sshfs, then those messages probably came from a local dir being thumbnailed.

I don't see how any changes in 1.0.0 would have changed responsiveness in this situation. Sounds normal for sshfs in SpaceFM.

[Vladimir-csp]

I had the local tab in the foreground. So if the remote tab is not active, it still reacts to actions in active tab, or there is some background processing?

[IgnorantGuru]

It would depend on what you're doing in the active tab, but nothing specific comes to mind. You could try the BUILD DEBUG instructions in README, and when it hangs, press Ctrl+C in the gdb terminal window. Or, send a KILL signal to SpaceFM from another window:

killall -s KILL spacefm

Then in the gdb window SpaceFM should be interrupted (you may need to wait for the i/o hang to release for this to happen. Then use 'bt full'. That may show you approximately where in the code it hung. If you show me that I might be able to tell you more.

I'll leave this issue open as the unresponsiveness is a usability issue. Generally speaking, there is no quick fix for this, it would require redesign in certain areas.