When I stream music with Spotify, Fedora goes to standby after ~15 mins (haven’t timed it), Spotify stops.
I think it doesn’t do this while I watch video on Netflix or Youtube, but it might be just because I keep moving the mouse before 15 mins run out.
How can I force the OS to always keep running media playback alive - including Spotify?
Thank you, and sorry I forgot to mention that I have KDE. I have the “Pause media players when suspending” setting (in System settings: Power managament > Advanced > other settings) not enabled, but it suspends anyway.
Pausing the player when suspended is not related to preventing the suspend.
That would need to be worded something like do not suspend when media is playing before it could be interpreted as preventing suspend.
Well what I’d really like is for it to “not pause media playback when suspending”
However, what exaclty the mechanism is less of a concern - it’s more like: “how do I fix this?”
It seems you are interpreting that phrase incorrectly.
Suspending means everything on the machine is powered down but the RAM which retains the current machine state for waking up.
How could it possibly continue playing media if the drive, audio card, processor, etc are all at minimum power and sleeping
1 Like
Alright then: What do I need to do for it not to suspend while media is playing - short of disabling all power savnig features?
Really suspension should only happen after x minutes of inactivity, so the OS seems to be judging media playback as inactivity. How can I convince it that as long as it’s playing media, it’s active and should hence not be suspended?
Don’t allow suspending.
Inactivity is evaluated as no keyboard or mouse action, not by apps running. Even a remote connection via ssh or similar is not considered activity.
I have no clue how that could be changed and only the developers could change that.
Three options come to my mind:
- left click on battery icon in status bar and click on “Manually block sleep and screen locking”; don’t forget to unset this if not required anymore, as there is no visual clue that you are inhibiting suspend…
- …that’s why I think it’s better to create a new activity, then open Settings > Activities, select the new activity and uncheck ‘Automatically shutting down or sleeping’ (and ‘Automatically turning off screen’ if you like) under ‘While on this activity, allow:’; switching to a different activity with different background helps you to quickly see that you are in no-suspend mode
- start your program with
systemd-inhibit, e.g.systemd-inhibit vlc; this will inhibit suspend as long as VLC is running (as opposed to playing media!); when you left click on battery icon, you will see a hint that VLC is blocking automatic suspend
I thought that some players would prevent suspend while playing media (as an option)…
…but it looks that this is video related (e.g. VLC has ‘disable screensaver during video playback’ option)
2 Likes
If some players actually do prevent suspending, it means that somewhere in the system there should be a list of it stored, no? Then Spotify coul just be added to that (ideally, it would do that during installation).
At this point, I think a bug report is in order…
I think it’s the other way around: some software can send an inhibit message via dbus (like firefox or VLC when playing videos, IIRC).
Here’s an idea: have some script running in the background which performs a pgrep or similar for all your programs that should inhibit a suspend.
If the pgrep comes back with results, execute a systemd-inhibit with something that will finish once the said program has finished (e.g. run a tail --pid=$pid -f /dev/null with $pid coming from the previous pgrep).
But again, then you will inhibit a suspend once the program is running, not while it is playing audio.
And maybe there is an easier solution to this?
1 Like
Rather than running a script, wouldn’t it be easier to copy the application’s launcher from /usr/share/applications/<whatever>.desktop to ~/.local/share/applications/<whatever>.desktop and modify the Exec=... line so that the application will be called via systemd-inhibit whenever its icon is clicked?
Don’t forget to run update-desktop-database ~/.local/share/applications after you’ve updated your launcher. 
2 Likes
I knew it ;-). Yeah, this one’s definitely easier as long as you start the programs from your DE.
From shell, like mpg123, you could create an alias.
1 Like
I have the Flatpak version of Spotify installed (the alternative is a Snap, no thanks).
It is installed here:
/var/lib/flatpak/app/com.spotify.Client/current/active/export/share/applications/com.spotify.Client.desktop
here’s the .desktop file:
[Desktop Entry]
Type=Application
Name=Spotify
GenericName=Online music streaming service
Comment=Access all of your favorite music
Icon=com.spotify.Client
Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=spotify --file-forwarding com.spotify.Client @@u %U @@
Terminal=false
MimeType=x-scheme-handler/spotify;
Categories=Audio;Music;AudioVideo;
Keywords=Music;Player;Streaming;Online;
StartupWMClass=Spotify
X-GNOME-UsesNotifications=true
X-Flatpak-Tags=proprietary;
X-Flatpak=com.spotify.Client
I don’t understand how Flatpak works so I can’t quite guess how this idea would be applied to it.
I tried replacing the Exec= line with
systemd-inhibit /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=spotify --file-forwarding com.spotify.Client @@u %U @@
but it didn’t work
Does Exec=/usr/bin/systemd-inhibit --what='idle:sleep:shutdown' --who='Spotify' --why='running' --mode='block' /usr/bin/flatpak run --branch=stable --arch=x86_64 --command=spotify --file-forwarding com.spotify.Client @@u %U @@ work? I’m not sure about editing the file in place. You might need to make a copy under ~/.local/share/applications and edit that instead. Also, I’ve never tried overriding a flatpak’s launcher, so I have no idea if it will even work.
Unfortunatley not. I copied it to ~/.local/share/applications and ran update-desktop-database ~/.local/share/applications, but it still suspends after the time defined in energy saving settings
Maybe trying running that command directly in a terminal window. Then run systemd-inhibit --list to verify that the program is listed as inhibiting system suspend/idle mode.
Oh, if the flatpak command forks into the background by default, that might be what is preventing the systemd-inhibit from taking hold. I think the flatpak command should have some options to prevent it from doing that. I don’t know for sure. I generally avoid using flatpaks.
Edit: If you launch it from a terminal, you will probably need to omit the @@u %U @@ part at the end. I’m not sure what those variables evaluate to when in .desktop files; hopefully nothing important.
Edit2: It looks like %U would evaluate to a URL. Sometimes the lauchers allow drag-and-drop of files and such on them, in which case those variables become defined: Desktop Entry Specification
1 Like
Looks like no:
WHO UID USER PID COMM WHAT WHY MODE
ModemManager 0 root 1386 ModemManager sleep ModemManager needs to reset devices delay
NetworkManager 0 root 1408 NetworkManager sleep NetworkManager needs to turn off networks delay
UPower 0 root 1294 upowerd sleep Pause device polling delay
PowerDevil 1000 ben 2436 org_kde_powerde handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch KDE handles power events block
4 inhibitors listed.
To be honest, I don’t know what that means. Fork into the background? Is there a part of the default Exec= line that tells it to do that?
Edit: I’m wondering if it would make sense to file a bug - but if yes, where? I can’t tell if the Flatpak edition is published by Spotify themselves - it says “by Spotify”, but also “unverified”.
Would you prefer the Snap in this case? At least that should be maintained by Spotify directly, if the Flatpak isn’t.
I wouldn’t use Snap. I tried it once and found that it installed an entire operating system under its directory just to run a tiny app. If Spotify isn’t available as an RPM package, flatpak would probably be the next best option. I just don’t know much about how flatpak works so I’m not sure how to get it to do what you want.
Googling just now, I found this bug report for a different program which seems to indicate that there is a “background” permission that a given flatpak app may or may not have set. The command to view whether an app is set to run in the backgound appears to be flatpak permission-list. Maybe if you toggle that setting from “yes” to “no” then systemd-inhibit will work. Sorry, I don’t know. I’m really out of my depth with flatpak.
Edit: Just found this similar bug report about getting a flatpak app to inhibit suspend: Inhibit suspend with flatpak applications? - Flathub Discourse It doesn’t look promising. It appears that the functionality has to be enabled when the flatpak is built (just going from the bug report; I don’t have any first-hand knowledge about how it works).
1 Like