feverfew added a comment.
In D23384#569926 <https://phabricator.kde.org/D23384#569926>, @ngraham wrote: > In D23384#569645 <https://phabricator.kde.org/D23384#569645>, @fvogt wrote: > > > **Issue #1:** > > > > That happens because the .desktop file sets `X-KDE-Protocols=ftp,http,https,mms,rtmp,rtsp,sftp,smb`: > > https://code.videolan.org/videolan/vlc/blob/master/share/vlc.desktop.in#L124 > > > I'm not sure about that. If I remove that line from VLC's installed desktop file, the problem still happens. And SMPlayer exhibits the same problem yet its desktop file doesn't define `X-KDE-Protocols` at all: https://sourceforge.net/p/smplayer/code/HEAD/tree/smplayer/trunk/smplayer.desktop This isn't reaching KIOFuse at all. I believe this is related to this bug and that you've also blogged about: https://bugs.kde.org/show_bug.cgi?id=330192 https://pointieststick.com/2018/01/17/videos-on-samba-shares/ This can be solved in this patch (and I did, although I removed it at Harald's request). I think I'll move it back in, and will leave it if it does solve this issue for you. >> **Issue #2:** >> >> The only explanation I have for that is that totem for some reason starts reading the file from the end. >> If you start `kio-fuse -d` manually (kill the other kio-fuse process first) and then use totem again, what's the debug output > > There is no debug output, and the whole file is downloaded locally as with the other apps. It seems like Totem is not getting the FUSE mount path; it gets an `smb://` URL and it or KIO downloads the file normally. Again, this happens even if I open the file from the FUSE mount path itself. > > I can confirm that the FUSE path handoff is working properly. For example if I open `smb://gaston@living-room-pc/Users/Gaston/Desktop/Shep Face Code.txt` in Gedit, Gedit displays the file's path as follows: F7791491: Screenshot_20191130_133857.png <https://phabricator.kde.org/F7791491> You must be doing something wrong. FUSE provides output of all calls that it receives (and how kio-fuse responds). Let me write the instructions more verbosely for CLI to make sure no steps are missed: `$ killall kio-fuse` `$ export QT_LOGGING_RULES="*.debug=true" `$ kio-fuse $myFavLocation -d &> ~/kio-fuse-debug.txt` (I recommend `$myFabLocation` isn't empty if you haven't installed the `kio-fuse-tmpfiles.conf` exclusion file at the system level.) Then open the file in the media player. Once your done simply attach `~/kio-fuse-debug.txt` here. It's really important for us to know what kind of read requests are being called to help us diagnose the issue. >> **Issue #3:** >> >> Everything is in a separate process and async already. When/how does it happen? > > When I open a large video file from the hidden mount path in any of the media player apps. KIO (or something) downloads the entire file, during which time Dolphin freezes. The moment the network activity ends because the file is finished downloading, Dolphin becomes responsive again. It's 100% reproducible for me. I'm a bit confused. Which one of the three are you doing: 1. Opening a KIO Url via Dolphin. 2. Opening a KIOFuse mount local URL via Dolphin. 3. Opening a KIOFuse URL via the media players file picker. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D23384 To: feverfew, fvogt, davidedmundson, dfaure, ngraham Cc: sitter, davidedmundson, kde-frameworks-devel, ngraham, LeGast00n, GB_2, michaelh, bruns
