fix: prefer dedicated music players over browsers for media keys#5985
Open
loicfavory wants to merge 2 commits into
Open
fix: prefer dedicated music players over browsers for media keys#5985loicfavory wants to merge 2 commits into
loicfavory wants to merge 2 commits into
Conversation
Browsers (Chromium, Firefox) register as MPRIS players as soon as they open, even with no media playing. When playerctld is also running, it can pick a browser as the active player, causing media keys to silently target the browser instead of a running music app (cliamp, Spotify…). Extend omarchy-swayosd-client to detect this situation when --playerctl is used without an explicit --player: it scans all MPRIS players and injects --player <best> with the following priority: 1. Dedicated music player that is Playing 2. Browser that is Playing (e.g. YouTube actively running) 3. Dedicated music player that is Paused 4. Browser that is Paused This keeps the existing media.lua bindings unchanged and is transparent when --player is already supplied explicitly.
Contributor
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
When --playerctl is used without --player: - If a dedicated music player (non-browser) is Playing, always target it regardless of what browsers are doing. - If no browser is Playing and a music player is Paused, target it to resume it (avoids resuming YouTube when nothing is happening there). - Otherwise fall through to playerctld, letting it handle the active player naturally (e.g. YouTube playing while music is paused). The previous full-priority approach (music > browser > music-paused > browser-paused) caused a cycling bug: with cliamp and YouTube both playing, pressing play-pause once paused cliamp, then playerctld handed control to YouTube, then both were paused and the script kept resuming cliamp in a loop — YouTube stayed paused indefinitely. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Browsers (Chromium, Firefox) register as MPRIS players as soon as they open, even when no media is playing. When
playerctldis running, it can pick the browser as the active player — causing media keys (play/pause/next/prev) to silently target the browser instead of a running music app (cliamp, Spotify, etc.).The result: play/pause only works intermittently, or not at all, depending on which player
playerctldhappens to have prioritized.Fix
Extend
omarchy-swayosd-clientto detect this situation when--playerctlis used without an explicit--player: it scans all MPRIS players and injects--player <best>with the following priority:This means:
Scope
media.luaor any bindings--playeris already supplied explicitly--playerctlcalls, leaving all other swayosd behavior untouched