1. 16 Mar, 2019 1 commit
  2. 04 Mar, 2019 1 commit
  3. 19 Feb, 2019 4 commits
  4. 18 Feb, 2019 1 commit
    • Michael Pyne's avatar
      Fix crash with threaded file loading. · 24b0edd1
      Michael Pyne authored
      Although Qt protects access to functions in the GUI thread (where I was
      seeing crashes in the new threaded file loading code in some
      situations), as long as you use signals/slots, Qt Concurrent doesn't do
      anything to keep your non-GUI threaded code from trampling on each
      other.
      
      Which is obvious enough, in retrospect, but that seems to have been the
      reason for the crashes I was sometimes seeing (TagLib and/or FileHandle
      not being thread-safe).
      
      The immediate bugfix is to serialize access into FileHandle/TagLib file
      reading code in DirectoryLoader, though I also did some cleanups in the
      process of debugging that I think are worth keeping.
      24b0edd1
  5. 03 Feb, 2019 1 commit
  6. 20 Jan, 2019 1 commit
  7. 06 Jan, 2019 4 commits
  8. 03 Jan, 2019 3 commits
  9. 28 Dec, 2018 1 commit
  10. 27 Dec, 2018 2 commits
  11. 26 Dec, 2018 4 commits
  12. 24 Dec, 2018 1 commit
  13. 22 Dec, 2018 3 commits
    • Michael Pyne's avatar
      Merge branch 'Applications/18.12' · 6a1d0ec4
      Michael Pyne authored
      6a1d0ec4
    • Michael Pyne's avatar
      Port sort function for list of playlists to KF5. · 468a5169
      Michael Pyne authored
      Now that sorting is enabled, it turned out that the sort really was
      broken for everybody (sorry!). The old Qt 3 and 4 "sort by subclassing
      the list item" feature wasn't actually ported into the Qt 5
      compatibilility list view. So although we were defining the compare
      function, nothing was actually using it.
      
      Things seemed to work fine on my local system but I suspect that's
      because I had playlists from KDE 4 times that I copied over which would
      have already sorted the special playlists to the beginning.
      
      Since the old method doesn't work I've just added a hidden sort key
      column for now. The "proper solution" is probably to use a
      QSortFilterProxyModel but that will be some time away.
      
      CHANGELOG:Restore proper sorting of the list of playlists.
      BUG:402398
      FIXED-IN:18.12.1
      468a5169
    • Michael Pyne's avatar
      Force sorting on so that special playlist sort to top. · dc3124e4
      Michael Pyne authored
      That is, so that special playlists hopefully sort to the top. Although
      the sorting of special playlists (Collection List, Play Queue, etc.) has
      worked for me since the port to KF5, I have a good report that it
      doesn't for others.
      
      The code itself appears correct but reviewing the Qt documentation
      indicates that QTreeWidget (which is one of the base classes for the
      list of playlists) doesn't sort by default.
      
      If QTreeWidget doesn't sort, then the comparison function might not be
      getting called at all, which would make it accident that it seems to
      work for me.
      
      CCBUG:402398
      dc3124e4
  14. 21 Dec, 2018 4 commits
  15. 20 Dec, 2018 6 commits
    • Michael Pyne's avatar
      Merge branch 'Applications/18.12' · 3b931e90
      Michael Pyne authored
      Conflicts:
      	CMakeLists.txt
      3b931e90
    • Michael Pyne's avatar
      Disable tag updating from inline editor. · c6afa4c5
      Michael Pyne authored
      This mitigates a potential data-loss situation that might happen when
      adding new music items:
      
        Juk starts processing the new items in addFiles,
        Results in a new CollectionListItem being created,
        The resultant PlaylistItem superclass calls setFlags,
        This causes Qt to send a *data* changed signal from the QTreeWidget
          holding all the playlist items, saying that a *different*
          QTreeWidgetItem / PlaylistItem has been changed.
        This signal is normally only possible because of user interaction with
          the inline editor. As a result JuK assumes the signal is a user
          request to edit the track's tag, and does so. I have seen this
          cause existing files to take on the same tag values as one of the
          incoming new tracks.
      
      Although in theory a user could immediately select the "Undo" command to
      fix this, that's not a very good workaround. Since we have a separate
      tag editor already, we'll just use that instead until we can figure out
      a way to ensure that dataChanged signals are sent only when the data
      itself has changed (not just flags caused by unrelated items being
      created).
      
      CHANGELOG: Prevent opening new items from inadvertently editing track metadata on existing items.
      FIXED-IN:18.12.1
      c6afa4c5
    • Michael Pyne's avatar
      4d63212f
    • Michael Pyne's avatar
    • Michael Pyne's avatar
      Remove debug spam for power management. · a15af145
      Michael Pyne authored
      a15af145
    • Michael Pyne's avatar
      Prefer QVector to QList for most auxiliary lists. · 6e518da4
      Michael Pyne authored
      Includes template-template parameter usage in playlist.h's createItems
      until all usages of QList gone.
      6e518da4
  16. 19 Dec, 2018 3 commits
    • Michael Pyne's avatar
      Apply some cleanup to file loading code. · 13505df0
      Michael Pyne authored
      13505df0
    • Michael Pyne's avatar
      Use a thread pool for the threaded music loader. · eb4a4d15
      Michael Pyne authored
      Large music libraries can cause dozens/hundreds or even more of threads
      to be created at once. But all we really need is to do the loading off
      of the GUI thread, and the I/O will be the bottleneck no matter how many
      threads we use. So use Qt Concurrent to manage a threadpool instead,
      which also simplifies the code somewhat.
      
      I also fixed the broken global status updating when using threaded
      loader while refactoring to support this.
      eb4a4d15
    • Michael Pyne's avatar
      Move initial music load to a separate thread. · 3cf74c35
      Michael Pyne authored
      I ran into all the problems one might expect from adding threading to an
      old codebase but this variant seems pretty stable.
      
      The benefit is that the heavy I/O with large music libraries is now off
      of the GUI thread. So even though it will still take awhile to load all
      music until I fix the bug(s) with using cached tags, at least the
      application itself will be responsive while it loads audio.
      3cf74c35