'[Bug 276779] New: extreme usability issues when some collection'

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

List:       amarok-bugs-dist
Subject:    [Bug 276779] New: extreme usability issues when some collection
From:       Ivan Vasin <nisavid () gmail ! com>
Date:       2011-06-29 20:41:05
Message-ID: bug-276779-71684 () http ! bugs ! kde ! org/
[Download RAW message or body]

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

           Summary: extreme usability issues when some collection items
                    are on a remote host (using WebDAV via davfs)
           Product: amarok
           Version: 2.4.1
          Platform: Ubuntu Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: amarok-bugs-dist@kde.org
        ReportedBy: nisavid@gmail.com

Version:           2.4.1 (using KDE 4.6.4) 
OS:                Linux

i'm using an ownCloud-powered cloud service, PackageCloud
<http://www.packagecloud.com/>, for storing some of my music.  i mount the
cloud file system using WebDAV via davfs to a mount point under /mnt, which is
symlinked into my local home directory.  thus my cloud-hosted music is
accessible locally in a subdirectory of my home directory.

i added this directory to Amarok's collection.  this revealed a number of
problems:

  * the collection takes an extremely long time to update.  this is somewhat
understandable, since it must read quite a few remote files.  however, it seems
that none of the scanned items are shown until all of them are scanned.  it
would be preferable if items were added to the collection view as they were
discovered.
  * during the collection scan, there is no information about the cause of the
delay, and the whole Amarok UI is completely unresponsive.  instead, the status
of the scan should be shown (preferably with information about which items
remain to be scanned and an estimate of the remaining time), and the UI
responsiveness should not be affected.
  * playing any remote tracks causes a long delay whose length seems to be
proportional to the size of the first track.  during this time, no information
is given about the cause of the delay, and the whole Amarok UI is completely
unresponsive.  instead, the status of loading the track should be shown
(preferably with % complete, loaded bytes, total bytes, and estimated time
remaining), and the UI responsiveness should not be affected.
  * when playing through a playlist and the next track is a remote track, there
is a long delay in the transition to it, similar to the one described above. 
instead, the next track should be loaded immediately after the current one
starts playing, so that effect of the loading time on seamless playing is
minimized.  up to a reasonable (preferably configurable) cache size, other
tracks in the playlist should also be cached, favoring those that are close to
the current track.
  * after playing a remote track, if it is re-played (by playing it from the
playlist view or by removing it and re-adding it), it exhibits the same delay
as described above.  instead, it should be cached up to some point (see above).
  * while playing a remote track, sometimes there is a delay, similar to the
ones described above, except that the progress through the track also skips the
time taken for the delay.  if a delay is unavoidable, the progress should
resume at the last point where it was moving.

any one of these issues would be a big annoyance, but all of them together make
cloud-stored music almost unusable in Amarok.

while i am admittedly unfamiliar with the implementation details of Amarok's
collection scanning and track loading mechanisms, so i make no claims about how
easy any of these issues are to resolve.  but i am quite sure that they are
solvable.

the general idea here, from my perspective, is that:

this is motivated by the following principles:
  * if a user wants to play music, he or she prefers that it plays now.
  * if a user knows that a track should be in the collection, then he or she
should be able to find it either in the collection view or in a list of items
yet to be scanned.
  * UI responsiveness should be favored over all other performance
characteristics.
  * up to a point, disk space should be sacrificed for the sake of usability.
  * up to a point, disk space should be sacrificed to save bandwidth usage.
  * for the vast majority of users, disk space is cheap.

it seems that most of these issues could be avoided by implementing a cache for
loaded tracks somewhere on the local disk.  the cache size limit should default
to something large enough for at least one typical FLAC track (at least 50 MB)
and perhaps large enough for at least one typical WAV track, and it should be
configurable, with no upper bound on the limit, since some users (such as
myself) have plenty of local disk space to spare and would gladly trade it for
smoother playing of remote tracks.  the location of the cache should also be
configurable, defaulting to something under /var/tmp.

it also seems that the issue of the UI freezing might be distinct from the
others.  intuitively, it seems that the UI thread(s) should be unaffected by
the collection scanning and track loading thread(s), as long as the system has
some CPU time to spare.

please accept my apology if this bug report is too broad in scope, and instruct
me how i should split it into smaller ones if that is the case.

Reproducible: Always

Steps to Reproduce:
1. add a davfs mount to Amarok's collection.
2. update the collection, play remote tracks, or switch between remote tracks.

Actual Results:  
long delays that cause delays in viewing collection items and playing tracks,
freezes in the UI, and little or no status information.

Expected Results:  
at worst, work reasonably and responsively with remote tracks, informing the
user about the status of collection scanning and track loading, and maintaining
UI responsiveness.

at best (in addition to the above):
  * provide information on collection scanning speed, the files that remain to
be scanned, and an estimate of remaining time.
  * provide information on the files that are being loaded, percent complete,
loaded bytes and total bytes, loading speed, and an estimate of remaining time.
  * make collection items available as soon as they are scanned instead of
waiting until the whole collection is scanned.
  * seamlessly cache all remote tracks up to a configurable cache size limit,
synchronizing the cached files as they become outdated, thereby making it
irrelevant whether the tracks are stored locally or remotely.

OS: Linux (x86_64) release 2.6.38-10-generic
Compiler: cc

davfs2 1.4.6

cloud server info: Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 PHP/5.2.6-1+lenny10
with Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_perl/2.0.4 Perl/v5.10.0

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Amarok-bugs-dist mailing list
Amarok-bugs-dist@kde.org
https://mail.kde.org/mailman/listinfo/amarok-bugs-dist
[prev in list] [next in list] [prev in thread] [next in thread] 