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@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

Reply via email to