Bug 427035

Summary:	Poor and confusing juk behavior after system was soft-rebooted
Product:	[Applications] juk	Reporter:	local10
Component:	general	Assignee:	Scott Wheeler <wheeler>
Status:	RESOLVED FIXED
Severity:	normal	CC:	ivan.planinar, mpyne
Priority:	NOR
Version First Reported In:	22.04.3
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
URL:	https://lists.debian.org/debian-user/2020/09/msg00813.html
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description local10 2020-09-27 16:18:41 UTC

SUMMARY

Installed a kernel update and soft-rebooted (KDE menu > Power/Session > Reboot) the system to load the new kernel while juk was playing a playlist. After the system came back, juk could not be launched properly, it looked like juk was hanging, the juk window showed just an empty rectangle. When I tried to close the juk window, KDE said "Application "juk" is not responding" and offered to terminate juk.

Running juk from the command line produced the following output:

$ juk
org.kde.juk: Unable to setup to load cache... perhaps it doesn't exist?

After running juk through strace, it became clear that juk wasn't hanging but trying to rebuild/scan the playlist (or whatever it was doing with the playlist), so allowing juk to run for 5 minutes resolved the issue and juk was able to show its window properly and worked fine after that.

STEPS TO REPRODUCE
1. Have juk play a playlist with, say, 400+ items
2. Soft-reboot the system while juk is playing
3. When the system comes back try to launch juk

OBSERVED RESULT
Juk will not be able to start properly, the juk window will be just an empty rectangle with nothing in it. No indication will be given to the user that juk is rebuilding/scanning the playlist, it would look like juk is just hanging.

EXPECTED RESULT
Juk should show its window properly and, at the very least, should give the user indication that it's doing something and advise the user to wait until the work is completd.

SOFTWARE/OS VERSIONS
Linux: Debian 10 Buster
KDE Frameworks 5.54.0
Qt 5.11.3 (built against 5.11.3)
The xcb windowing system

ADDITIONAL INFORMATION

# echo "This is a Debin 10 Buster PC"; uname -a
This is a Debin 10 Buster PC
Linux tst 4.19.0-11-amd64 #1 SMP Debian 4.19.146-1 (2020-09-17) x86_64 GNU/Linux

# aptitude show juk
Package: juk
Version: 4:18.08.1-1
State: installed

Comment 1 ivan.planinar 2020-11-06 23:07:14 UTC

Yep. Same.

Unable to setup to load cache... perhaps it doesn't exist?

I already opened another thread about this slowness. IT re-scans every time it is started, over and over again with massive delays.

Comment 2 local10 2022-10-25 06:25:40 UTC

Juke still does it in the version 22.04.3-1. After logging out of KDE while juk was playing could not start juk after logging in back. Juk would start then Juk window would disappear from view completely and Juk process would appear to be hanging, seemingly with no CPU or other activity.

Had to remove the following files to be able to start Juk more or less normally:
    /home/luser/.local/share/juk/cache
    /home/luser/.local/share/juk/playlists

Operating System: Debian 12 Bookworm GNU/Linux
KDE Plasma Version: 5.26.0
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.4
Kernel Version: 5.19.0-2-amd64 (64-bit)
Graphics Platform: X11

Comment 3 local10 2023-01-22 21:17:49 UTC

Looks like this bug has been fixed. Did some reboots recently and juk never had any issues coming back properly after a reboot.

# aptitude show juk
Package: juk                             
Version: 4:22.12.1-1