Fully quit Stremio when you need the media keys for another application; this is the safest immediate workaround. If your AwesomeWM shortcuts use playerctl, a better long-term fix is to make each shortcut target your music player explicitly instead of whichever media application Linux selects by default.
The available report does not confirm a built-in Stremio setting that disables hardware media-key handling. The problem was reported with Stremio 1.2.0 installed through Flatpak on Arch Linux, using AwesomeWM and X11.
Why Stremio may receive the media keys
Linux media keys are often routed through MPRIS, a standard interface used by media applications and desktop controllers. Stremio may remain registered as an available media player while its window is open, even when no video is playing.
The key itself might not be going directly to Stremio. An AwesomeWM binding, playerctl, another shortcut daemon, or a desktop media service may be sending the command to the currently selected MPRIS player. If that service selects Stremio instead of your music application, play, pause, next, or previous will appear to be consumed by Stremio.
This explanation is likely but not confirmed by logs from the original report, because no logs or diagnostic output were included.
1. Confirm that Stremio is the trigger
Use this quick test before changing any configuration:
- Open your music application and start playback.
- Open Stremio, but do not start a video.
- Press play/pause or next on your keyboard.
- Close the Stremio window completely and test the same key again.
Make sure Stremio actually exits rather than remaining active in the background. To find its Flatpak application ID, run:
flatpak list --app | grep -i stremio
Copy the application ID shown in the output, then terminate that Flatpak process if necessary:
flatpak kill APPLICATION_ID
If the media keys start controlling your music application immediately after Stremio exits, the conflict is probably related to player registration or media-command routing. If nothing changes, investigate your AwesomeWM bindings or any separate hotkey daemon instead.
2. Check which MPRIS players are visible
If you already use playerctl, list the media players it can see:
playerctl --list-all
Run the command once with Stremio closed and again with Stremio open. If a Stremio-related entry appears while the application is idle, that supports the MPRIS-routing explanation.
You can also check the status of each listed player:
playerctl --player=PLAYER status
Replace PLAYER with an exact name from playerctl --list-all. Player names differ between applications and installations, so do not assume a name without checking the output.
If playerctl is not installed and your AwesomeWM configuration does not use it, you do not need to install it merely for this fix. First inspect how your media keys are currently configured.
3. Target the music player in AwesomeWM
This is usually the most practical workaround when an AwesomeWM keybinding runs a generic command such as:
playerctl play-pause
Without a player name, the controller must decide which available media application receives the command. Change the command to target the intended music player:
playerctl --player=PLAYER play-pause
playerctl --player=PLAYER next
playerctl --player=PLAYER previous
Use the exact player identity returned by playerctl --list-all.
Before editing anything, make a backup of your AwesomeWM configuration. Media shortcuts are commonly defined in ~/.config/awesome/rc.lua, but configurations vary. Search for likely key names or commands with:
grep -nE 'XF86Audio|playerctl' ~/.config/awesome/rc.lua
Look for bindings associated with names such as XF86AudioPlay, XF86AudioNext, and XF86AudioPrev. Replace only the generic player command, preserve the surrounding Lua syntax, and then reload AwesomeWM using the method configured on your system.
If the selected player name changes between launches, run playerctl --list-all again. Do not copy a player name from an unrelated system.
4. Check for duplicate media-key handlers
AwesomeWM users may have shortcuts managed by more than one component. For example, a key may be configured in AwesomeWM while a separate tool such as xbindkeys or sxhkd also listens for it.
Search your user configuration for media-key definitions:
grep -R -nE 'XF86Audio|playerctl' ~/.config/awesome ~/.config/xbindkeys* ~/.config/sxhkd 2>/dev/null
If the same key appears in multiple active configurations, temporarily disable one binding and test again. Keep one clear owner for each play, pause, next, and previous key.
Do not remove volume-control bindings unless volume keys are also affected. System volume controls are often handled separately from application playback controls.
5. Update the Flatpak safely
The report concerns Stremio 1.2.0, so behavior may be version-specific. After identifying the Flatpak application ID, check for an available update through your normal software manager or run:
flatpak update APPLICATION_ID
Restart the session after updating and repeat the idle-window test. An update is worth checking, but there is no supplied evidence confirming that a later build fixes this particular problem.
Avoid deleting Stremio data or resetting all Flatpak permissions for a media-key conflict. Those actions are more disruptive and are not supported by the available report.
6. Advanced confirmation without changing permissions
If playerctl does not reveal enough information, systems with busctl can display registered MPRIS services:
busctl --user list | grep -i mpris
Compare the output with Stremio open and closed. This is a diagnostic check only.
Do not broadly block Stremio from the session bus or remove unknown Flatpak D-Bus permissions. Those permissions may be required for unrelated desktop integration, and the correct interface name has not been established by the report.
What worked for affected users
The supplied issue contains the original problem description but no confirmed reply, patch, or successful user workaround. Therefore, no solution can currently be presented as verified for every affected installation.
The safest practical options based on the reported behavior are:
- Fully exit Stremio when another application must receive generic media commands.
- Configure AwesomeWM or
playerctlto address the intended music player explicitly. - Remove duplicate media-key bindings if more than one shortcut service is active.
- Update Stremio and retest, without assuming the update contains a fix.
Troubleshooting checklist
| Check | Expected result |
|---|---|
| Exit Stremio completely | Music application receives the keys again if Stremio is involved |
Run playerctl --list-all |
Shows which players can receive media commands |
| Open Stremio while idle | Reveals whether it remains listed as a media player |
| Target the music player by name | Prevents generic commands from being routed to Stremio |
| Search AwesomeWM configuration | Finds generic or duplicate media-key bindings |
| Update the Flatpak | Rules out behavior already changed in a newer available build |
FAQ
Is there a Stremio option to disable hardware media keys?
No such option is confirmed by the evidence supplied with this report. The reporter specifically requested an enable-or-disable option, which suggests one was not available or discoverable in that installation.
Why does this happen when no video is playing?
A media application can remain visible to a Linux media controller while idle. The controller may then choose it for a generic play/pause or skip command. Confirm this on your system with playerctl --list-all rather than assuming that Stremio is directly intercepting the physical key.
What should I include in a bug report?
Include the Stremio version and installation type, Linux distribution, AwesomeWM version, X11 or Wayland session, the output of playerctl --list-all with Stremio open and closed, and the relevant media-key command from your AwesomeWM configuration. Also state whether fully terminating the Flatpak restores normal key behavior.
Last reviewed: September 7, 2026