just as the title shows, juk will take more than 10-20 seconds to start if tree mode is selected. While start juk in compact is just "instant". Reproducible: Always Steps to Reproduce: 1. Select to tree mode 2. Exit juk 3. Restart juk Actual Results: juk will take quite a long time to start Expected Results: juk starts as fast as in compact.
I am on gentoo and in any view modes, it starts very slowly. Sometimes it crashes. Starting Juk from a terminal shows this: Object::connect: Attempt to bind non-signal LyricsWidget::setShown(bool) I have no idea if this has something with this bug or not. Anyway, juk was fully working in 4.9.5. I even removed all the configuration and lost my playlists, but the issue is present with a newly created juk configuration. Some people on Arch have the same problem: https://bbs.archlinux.org/viewtopic.php?id=157710 Something else: Juk thinks that it cannot play through current device and then it falls back to another device. The other players in KDE like kplayer and clementine don't have such a problem.
Same here on Gentoo with Juk 3.9.1 Real slow startup on default view. Wasn't here with Kde 3.9
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? This bug will be moved back to REPORTED Status for manual review later, which may take a while. If you are able to, please lend us a hand. Thank you for helping us make KDE software even better for everyone!
Again I can only say that I can't test it. Gentoo delivers Juk 18.04.3 which seems to be heavily converted for qt5. Since that the Progress-bar doesn't move during playback, the Progress-clock/duration keeps at zero, jumping to ~80% manually makes jumping to another title and the bug-giving tree-mode seems to be just patched out. My word alone says not much, other distros might have a stable versions or I might ave compiled it somehow bad but I don't know how I could have done that.
Tested it now in an VM with Openuse Tumbleweed in an vm. Juk 18.08.3 Playback&progressbar works but the "tree mode" is not available.
Git commit d6b28a9b4c8e21a0b9ccd5bb7585091e501d94ab by Michael Pyne. Committed on 26/03/2021 at 01:48. Pushed by mpyne into branch 'master'. tag_scan: Fix painful rescan of music metadata on startup. 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. Related: bug 428772 FIXED-IN:21.04 M +58 -25 collectionlist.cpp M +5 -3 collectionlist.h M +11 -3 directoryloader.cpp M +6 -1 filehandle.cpp M +10 -1 playlist.cpp https://invent.kde.org/multimedia/juk/commit/d6b28a9b4c8e21a0b9ccd5bb7585091e501d94ab
Git commit a65a4e8a037bae5d2731267b60ed61bf09526413 by Michael Pyne. Committed on 26/03/2021 at 01:52. Pushed by mpyne into branch 'release/21.04'. tag_scan: Fix painful rescan of music metadata on startup. 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. Related: bug 428772 FIXED-IN:21.04 (cherry picked from commit d6b28a9b4c8e21a0b9ccd5bb7585091e501d94ab) M +58 -25 collectionlist.cpp M +5 -3 collectionlist.h M +11 -3 directoryloader.cpp M +6 -1 filehandle.cpp M +10 -1 playlist.cpp https://invent.kde.org/multimedia/juk/commit/a65a4e8a037bae5d2731267b60ed61bf09526413