1. 08 May, 2021 1 commit
  2. 07 May, 2021 2 commits
  3. 25 Apr, 2021 2 commits
  4. 14 Apr, 2021 2 commits
  5. 09 Apr, 2021 1 commit
  6. 29 Mar, 2021 1 commit
  7. 26 Mar, 2021 1 commit
    • Michael Pyne's avatar
      tag_scan: Fix painful rescan of music metadata on startup. · a65a4e8a
      Michael Pyne authored
      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.
      (cherry picked from commit d6b28a9b)
  8. 25 Mar, 2021 9 commits
  9. 18 Mar, 2021 5 commits
    • Michael Pyne's avatar
      history: Enforce specific date format that sorts right. · d4bf5912
      Michael Pyne authored
      The QTreeWidget we're using sorts by display text by default. This makes
      the date column in the history playlist a bit useless to sort by in the
      normal format.
      The ISO date format is a bit too ugly though, so I manually implement
      something more akin to RFC 3339. To properly fix this we should
      implement a specific role in each item that can be sorted by the
      underlying model. If the underlying model is a QStandardItemModel this
      might already be easy but I don't have time now to investigate further.
    • Michael Pyne's avatar
      Address undefined behavior during shutdown. · fce79085
      Michael Pyne authored
      Event filters strike again, along with our old friend, sibling ordering
      dependencies not captured by the Qt memory hierarchy. Again, noted by
    • Michael Pyne's avatar
      playlist: Avoid resizing columns until after we've generated weights. · 66ddbb3b
      Michael Pyne authored
      This avoids warnings about undefined use of NaN and similar, when we try
      to resize the columns too early (before there are any tracks to use to
      inform average column widths).
    • Michael Pyne's avatar
      Fix undefined behavior in PlaylistItem. · b67785f9
      Michael Pyne authored
      The PlaylistItem ctor meant to be called from its subclass's constructor
      (CollectionListItem) copied the this pointer too early. When
      PlaylistItem is being constructed, by C++ rules the PlaylistItem is not
      a CollectionListItem yet. This was appropriately flagged by ubsan.
      I fixed this by ensuring the only user of this subclass fixes up the
      pointer as soon as it can, and making it a private constructor so it's
      not used elsewhere by mistake.
    • Michael Pyne's avatar
      Fix use of undefined behavior in status label. · 10110d76
      Michael Pyne authored
      The event filter doesn't check that the received event is a QMouseEvent
      but it is possible (and actually happened) to receive other events from
      But in this case we don't even need an event filter, we're just handling
      mouse events and Qt provides entirely usable methods for that already.
  10. 13 Mar, 2021 2 commits
  11. 24 Feb, 2021 1 commit
  12. 23 Feb, 2021 1 commit
    • Michael Pyne's avatar
      clazy: Fix most remaining warnings. · 288c69eb
      Michael Pyne authored
      I'm not going to worry about non-POD statics in an application, and I
      can't fix the Q_PROPERTY warnings in Phonon. Other than that, all
      default clazy warnings should be gone now.
      Of note is the tagtransactionmanager.cpp setFile call, which is not just
      a warning but an actual bug (good job clazy!).
  13. 22 Feb, 2021 5 commits
  14. 13 Feb, 2021 2 commits
    • Michael Pyne's avatar
      test: Fix tagguessertest lookup error with ctest. · 3a3bc5e5
      Michael Pyne authored
      For whatever reason, running plain ctest or even "ninja test" on a
      testing-enabled does not succeed in finding tagguessertest to run it,
      probably because this test is located in the build directory's /bin
      subfolder and the test metadata is incorrect.
      However I was able to solve this just by using the existing ECM macro to
      add a single test (https://api.kde.org/ecm/module/ECMAddTests.html)
      directly, so that's what I did. ctest now runs and passes both tests
      fine again.
    • Michael Pyne's avatar
      cmake: Remove needless checks for Taglib format support. · 082914b0
      Michael Pyne authored
      The recent commit 9a54d6e7 to use
      FindTaglib from ECM breaks detection of Ogg Opus support in Taglib for
      some reason. This causes crashes when playing Ogg Opus files because
      their relevant Taglib::File subclass is not created from our MediaFiles
      However the check is needless. Taglib support for ASF and MP4 files has
      been standard since 2012 or so, and Ogg Opus support was made standard
      around the same time frame. So rather than check for these as optional
      features, just assume that supported versions of Taglib support these
  15. 11 Feb, 2021 1 commit
    • Michael Pyne's avatar
      Merge branch 'neoninteger/juk-fix-rename-folders' · 8956f56d
      Michael Pyne authored
      Merging a change from Callum Parsey to fix a bug with the file renamer
      where it was, in essence, trying to treat the resulting file basename as
      if it were another directory in the path, and failing as a result.
      This comes extremely late, as I somehow missed this merge request
      hanging out for JuK until after an unrelated one came in recently. But
      no excuses, that's my fault. My apologies to the submitter.
      I didn't see a corresponding bug to close. This fix should land in
      version 20.12.3 and later.
  16. 10 Feb, 2021 1 commit
  17. 06 Feb, 2021 3 commits