[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [frameworks-kio] [Bug 330192] Unable to open video files in common players (VLC, MPV, etc) over smb:
From:       Nate Graham <bugzilla_noreply () kde ! org>
Date:       2018-01-30 19:45:02
Message-ID: bug-330192-17878-j89hZBmNYn () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=330192

--- Comment #12 from Nate Graham <pointedstick@zoho.com> ---
How does GNOME handle this? Do apps using files on Samba shares accessed using
GVFs just freeze forever?


The larger issue is that not all software will use KIO for access, and it isn't
reasonable to expect them all to. Samba shares are really common in businesses
and schools, and people quite reasonably expect full file access support when
using non-KDE software like LibreOffice and Blender.

As far as I can tell, there are really two primary use cases here:

1. Reading/streaming large files on Samba shares (e.g. videos)

2. Editing and saving back to files on Samba shares using non-KIO software like
LibreOffice and Blender


The pain point for #1 is that unless every piece of software you'd want to use
for this use case implements a Samba client, you'll get stuck with KIO
downloading the file locally first, which is associated with many problems for
large files (lengthy download time with no progress bar, local space issues,
etc). This limits user choice. E.g I've helped solve the problem for VLC users,
but what about those who prefer MPV? If you want to edit huge video files
stored on a Samba share, we offer Kdenlive, which is KIO-aware, but but if you
prefer Pitivi, which isn't?

The pain point for #2 is that for non-KIO apps that use %F in their desktop
files, KIO will locally download the file and pass them a local path, BUT, once
the app saves the file, KIO doesn't re-upload it back to the share until the
program quits. This causes a lot of user confusion and pain. I've seen quite a
few bug reports about this behavior causing out-of-sync versions when people
save the file and don't realize that it only gets re-uploaded once they quit,
and then a co-worker, fellow student, or teacher looks at the file and says
"hey, it doesn't have any of the changes you said you made!"

#2 seems like we could maybe implement a tactical fix in KIO to save the file
back to the share before the program quits, but #1 I think is a tougher nut to
crack without implementing a local mount.

What are your thoughts, David?

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]