*** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY When the display is off (but the computer is not sleeping), kalarm does not start the audio for a recurring command alarm. The command alarm is a script which invokes mpv with the --loop option to play a flac file (since phonon has been replaced with libcanberra, I can no longer play any audio file with the audio alarm other than .ogg files). The audio is not played through monitor speakers, but through speakers on the analog audio controller interface. The HDMI audio controller is set off. STEPS TO REPRODUCE 1. Set up a recurring command alarm to play an audio file in a loop at a given time that is suitably long enough away (longer than a few minutes, currently observed with 6+ hours). 2. Ensure that the display is set to be turned off after a period of inactivity less than it will take for the alarm to be triggered, and that the screen locks before, or very shortly after, the screen turns off. 3. Wait for the alarm to be triggered at the appropriate time. 4. After the alarm does not trigger at the expected time, provide input to turn the display back on and observe that the alarm starts. OBSERVED RESULT As stated above, the alarm does not trigger when it's set to but well after, when providing input to wake up the display. EXPECTED RESULT The alarm to go off when it's supposed to, regardless of the screen's state. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora Linux 40 (available in About System) KDE Plasma Version: 6.1.1 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Using wayland. I have tried to recreate this with a shorter duration for the screen to turn off before the alarm triggers. This works as I would normally expect (not replicating the bug) at least up until 5 minutes into the future. I don't have the time to bisect *when* this becomes a problem, and it is quite possible that there is some other condition I'm unaware of that happens which makes this look time related.
I wonder if this problem is a KAlarm bug, or something else. I don't see why the screen lock status would have any effect on alarms being triggered. To check this, could you please try two things: 1) Set up a KAlarm command alarm which triggers at the same time as your audio command alarm, and which does something not audio related - for example writing something to a file. Check whether this runs successfully after the screen locks. Ideally, make a command alarm which first writes to a file and then plays the audio file. You can then see if the alarm has triggered, and whether only the audio part fails. 2) Set up a little script which executes a "sleep" for long enough for the bug to occur, and then executes the same command as the KAlarm alarm. Execute the script in a terminal window (not in KAlarm) and leave it running. Check whether it plays the audio file after your screen has locked. On a separate note, can you please raise a separate bug report about KAlarm no longer playing audio files other than .ogg ones, and attach an example of an audio file which does not work. Mention any error messages which are shown. This isn't something which has previously been reported.
(In reply to David Jarvie from comment #1) > I wonder if this problem is a KAlarm bug, or something else. I don't see why > the screen lock status would have any effect on alarms being triggered. To > check this, could you please try two things: > > 1) Set up a KAlarm command alarm which triggers at the same time as your > audio command alarm, and which does something not audio related - for > example writing something to a file. Check whether this runs successfully > after the screen locks. Ideally, make a command alarm which first writes to > a file and then plays the audio file. You can then see if the alarm has > triggered, and whether only the audio part fails. > > 2) Set up a little script which executes a "sleep" for long enough for the > bug to occur, and then executes the same command as the KAlarm alarm. > Execute the script in a terminal window (not in KAlarm) and leave it > running. Check whether it plays the audio file after your screen has locked. > > On a separate note, can you please raise a separate bug report about KAlarm > no longer playing audio files other than .ogg ones, and attach an example of > an audio file which does not work. Mention any error messages which are > shown. This isn't something which has previously been reported. For the audio file one, I have submitted a bug report: https://bugs.kde.org/show_bug.cgi?id=489597. To summarize, kalarm now uses libcanberra to play audio files, but because canberra does not support flac or mp3 codecs, those cannot be used for audio alarms now. I will set a command alarm that executes a script which first writes a message to a file, then plays an audio file. It will be interesting to see if this doesn't impact file IO. I believe the root cause of the problem is some funky interaction with wayland. When the screen wakes up, I get these messages in journalctl: "kalarm[4487]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash" - this applies to all my kde apps and components like kactivitymanagerd.
After rebooting, the alarm works again as it had previously. I will report this again if this occurs, but maybe it was some weird combination of things that simply got reset by rebooting.
Since it seems to be working again for you, I'm closing this bug for now. If it happens again, please reopen the bug report.