GitLab

Task: https://phabricator.kde.org/T14543

(cherry picked from commit f59c5ced)

(cherry picked from commit 9935119b)

It was added by mistake in a5b8c609

This has been available since KF5 5.32 or so, which has long been
available, so no separate check is used.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

(cherry picked from commit b46a4dd1)

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

(cherry picked from commit 16856752)

(cherry picked from commit e3c98323)

(cherry picked from commit ac6515a0)

Andreas Sturmlechner authored Apr 24, 2021 and Albert Astals Cid committed Jul 10, 2021

This was working as long as it was implicitly provided by KIO.

See also: frameworks/kio!426

Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
(cherry picked from commit 3f25d720)

(cherry picked from commit ff21a0e4)

(cherry picked from commit 1d028026)

http://cldr.unicode.org/index/cldr-spec/plural-rules

(cherry picked from commit 5ef02682)

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

(cherry picked from commit 10d21658)

Also some miscellaneous cleanups for whitespace but that's the bulk of
this commit.

For the longest time, JuK has suffered from a problem where its intended
behavior to load music metadata from a cached database, instead of
re-scanning every individual track on startup, was not working right.

There has been debugging lines in JuK since all the way back to 2013
trying to trace what area of startup sequence was taking up all the
time, but to no avail in helping me fix the bug.

The Problem
===========

Recently I took a different approach, of adding a debug-only crash
whenever we would load a music track tag the "slow" way, and long story
short there were two bugs that each would cause slowdown:

1. Playlists aside from the CollectionList would cause every music track
   in that playlist to be re-scanned. What this means is that every
   though the music in the CollectionList would be loaded quickly, if
   you had that same music track in a separate Playlist, that music
   track would reload the same tags from disk rather than copying from
   the existing CollectionList item.  This was especially bad for users
   of the old "tree mode" view, since every individual artist *and*
   album were rendered as individual playlists, which would therefore
   each re-scan the music over and over again.
2. JuK supports a "folder scan" feature, and in fact really wants the
   user to have at least one folder assigned. Any music identified in
   this folder is added to the CollectionList automatically on startup
   and, you guessed it, causes the music track information to be loaded
   from disk, even if the music was already in the CollectionList! :(

The net effect is that most music would be re-scanned on startup unless
you were a user who used CollectionList exclusively, and had most of
your music not visible to the folder scanner.

The Solution
============

Due to how painful this problem has been, I had ended up adding a
threaded solution for the folder scan process. This didn't help make
things any faster but at least the GUI wasn't frozen. But now that the
threading code is present I judged it would be easier and safer to make
the central object holding track metadata (CollectionList's m_itemsDict)
available in thread-safe fashion.

This then permitted me to check for whether a track has already been
loaded when performing folder scan, and to check whether a track has
already been loaded when creating a new (non-CollectionList) Playlist.
In either event if the track already exists, then we copy the FileHandle
rather than create a new one.

The combination speeds up loading significantly, taking anywhere from
60% to 70% off of the total time to load on my system, with mostly a
CollectionList under folder scan and few additional playlists. In this
configuration I go from about 5.4 seconds to 1.5 seconds with cold
caches. The difference should be even more stark on systems where disk
I/O is expensive, or where there are a great number of tracks in
playlists outside of the CollectionList.

I consider this a bugfix (and there are even multiple bug reports) so I
will backport shortly.

CHANGELOG:Reduce startup time by 60-70% or more.
BUG:428772
BUG:317666
FIXED-IN:21.04

LGTM points out that DynamicPlaylist's destructor calls a function which
indirectly leads to a virtual call (updateItems) in a potential subclass
(SearchPlaylist). By C++ rules, SearchPlaylist has ceased to be a
SearchPlaylist by the time DynamicPlaylist::~DynamicPlaylist() begins,
so the virtual call would never actually be dispatched to
SearchPlaylist.

Fix by having SearchPlaylist do its own updating on destruction.

I tried to ensure this only causes the playlist to jump when the user
isn't directly interacting with the track (e.g. double click to play).

BUG:356224
FIXED-IN:21.04