D23384: [WIP] Adding support for mounting KIOFuse URLs for applications that don't use KIO

[Nathaniel Graham]

ngraham requested changes to this revision.
ngraham added a comment.
This revision now requires changes to proceed.


  I tested this today with a variety of files on a Windows Samba share with fairly slow 6 Mb/sec bandwidth and it's almost perfect for all files and use cases. However I ran into some issues with handling large video files on a Samba share. This is an important use case and supports the workflow of viewing or working on video files stored on a NAS or media PC. I tried opening a large-ish 800 Mb video file using VLC, Totem (a.k.a. GNOME Videos), and SMPlayer. Here are the results:
  
  - VLC receives a `smb://` URL and failes to open the file, displaying the following error message:F7790278: Screenshot_20191129_141256.png <https://phabricator.kde.org/F7790278>
  - Totem launches immediately but displays nothing. Network traffic indicates that it is locally downloading the entire file to a cache somewhere. Once the network traffic ends, it begins playing the file.
  - SMPlayer receives a `smb://` URL and fails to open the file, displaying the following error message:F7790279: Screenshot_20191129_141354.png <https://phabricator.kde.org/F7790279>
  
  Issue #1
  ========
  
  It looks like both VLC and SMPlayer are getting the `smb://` URL and failing to open it because they don't already have credentials for the share, which is stupid and probably their own faults for not at least prompting the user for it (VLC used to do this on other distros I've used, so that may be a regression in the app, or a packaging issue on openSUSE). But neither app uses KIO, so they should be getting the path to the FUSE mount instead.
  
  Issue #2
  ========
  
  Even when opening the file directly from the hidden KIO-FUSE mount, all tested apps download the file locally instead of just reading it and starting playback. When I use Nautilus to mount the same samba share and open the file in Totem, the app opens and playback begins almost instantly. So it looks like the entire file does not have to be downloaded first with the GNOME FUSE implementation, but something in our implementation is causing this to happen compared to theirs.
  
  This can be confirmed by navigating to the hidden FUSE mount paths generated by KIO-FUSE and GVFS.
  
  `totem /run/user/1000/gvfs/smb-share\:server\=living-room-pc\,share\=users\,user\=gaston/Gaston/Desktop/Starship\ Troopers.avi` - Totem opens instantly and playback begins instantly
  
  `totem '/run/user/1000/kio-fuse-vCERHW/smb/gaston at living-room-pc/Users/Gaston/Desktop/Starship Troopers.avi'` - Totem opens instantly but downloads the entire file locally before starting playback
  
  The same behavior happens when using VLC or SMPlayer instead of Totem. So it seems like there is some issue with our KIO-FUSE mount that causes the app to not understand that it can skip the lengthy download. Or maybe KIO itself is still doing this, even though it's no longer necessary. Or maybe Totem, VLC, and SMPlayer have special logic to invoke the more desirable "play instantly" behavior for URLs opened with GVFS paths and will need to be patched to invoke the same behavior for our KIO-FUSE paths as well.
  
  Issue #3
  ========
  
  I feel like Dolphin should not hang when you open a large file from the FUSE mount path directly and a long download begins. This should happen in another process or thread so that Dolphin's main UI isn't blocked.
  
  ---
  
  Some of these issues may be out of scope for this patch but I thought I'd just put them here in this review, and we can figure out if they need to be addressed elsewhere.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20191129/92f98740/attachment.html>