I3status-rust: music block does not clear/close on player close

Created on 4 Dec 2020  路  16Comments  路  Source: greshake/i3status-rust

It appears the music block in update 0.14.3-1no longer clears or collapses when all players are closed. The contents of the music block remain as they were right before the final player was closed, even when hide_when_empty is set to true.

config snippet:

[[block]]
block = "music"
player = "playerctld"
max_width = 45
marquee = false
dynamic_width = true
hide_when_empty = true
buttons = ["prev", "play", "next"]

As a side note, how do I debug i3status-rust? I'd like to help fix things, but I'm unsure how to run it independently from my i3 config so I can see debugging info in the terminal.

awaiting confirmation of fix bug

Most helpful comment

Sorry, this got buried in all my other things. Yes, this appears to working as I would expect now. Thanks for your help!

All 16 comments

If you are talking about printf debugging then
for anything other than debugging click inputs you can just run it in a terminal and check the output there. There's not really any debug output so you'd have to add those yourself where necessary.

What does busctl --user get-property org.mpris.MediaPlayer2.playerctld /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player Metadata contain just before and after the final player is closed?

Before last player is closed:

a{sv} 7 "mpris:trackid" o "/16d" "mpris:length" x 208000000 "xesam:artist" as 1 "Peter Bence" "xesam:title" s "September" "xesam:album" s "Peter Bence" "xesam:albumArtist" as 1 "Peter Bence" "xesam:genre" as 1 "piano"

After the player is closed (bold and red):

Failed to get property Metadata on interface org.mpris.MediaPlayer2.Player: No player is being controlled by playerctld

Could you please do the same as above but with busctl --user monitor org.mpris.MediaPlayer2.playerctld running? Only interested in the "Member=PropertiesChanged" signals as it should make finding a fix easier.

I think #967 should fix this, could you give that a go?

So now the player closes music block closes/updates when players are closed, but now it collapses when a player is paused, and when a player opens, it does not register until a track has been skipped or play/pause toggled.

So it appears to vary on player. I don't appear to have any issues with ncspot, but cmus is giving me problems. I have an example here were I have both players open and paused with cmus being the most recently active; the music bar is collapsed. I begin logging dbus and hit play on the cmus player. The music bar remains empty. I let the song play for a few seconds and hit next; the music bar now appears. I let the song play a couple more seconds and then pause, and the music bar collapses again. Logging ends.

logfile

Regarding the issue with it collapsing with paused, can you provide the output of the below commands before/after it's paused?

busctl --user get-property org.mpris.MediaPlayer2.playerctld /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player Metadata

busctl --user get-property org.mpris.MediaPlayer2.playerctld /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player PlaybackStatus

Edit: missed your comment above, that log file might be enough. I'll take a look next time I'm at a pc

It might be easier if I can reproduce locally. What's the minimum config/setup needed to reproduce the two issues below? I take it the issue only occurs when using playerctld to control them?

Issue 1. Collapses when a player is paused

Issue 2. When a player opens, it does not register until a track has been skipped or play/pause toggled.

Sorry for the late response. I've played around with a lot of possible combinations of things and tried narrowing down the exact behavior of the problem. However, it really is a mess of things.

When set to playerctld in the config, a lot of things don't work. Both mpv and cmus collapse when paused or first launched and refuse to reappear until a track changes. Both players collapse regardless of playback status if the playerctld player queue is shift to them. Sometimes mpv will not appear collapsed when launched, but will show the wrong playback status (inconsistent behavior). Another player ncspot doesn't collapse when paused, but will not reappear until unpaused if the playerctld player queue is shifted back to it. When mpv or cmus is used in the config, the same behavior on pausing and launching occurs. However ncspot has no such issues.

I'm not sure what players you typically use, but I feel you should be able to reproduce some of these. All of these issues go away when I rollback to v0.14.2. I haven't had time to look at the commits on the music block since v0.14.2; I'll try to take a look and see if I can provide some insight.

I've only tested with mpd, mpv and random YouTube videos playing in firefox and the only thing I've come across so far is the block collapsing on right click if the next player (presumably) has empty metadata.

Just to clarify do you mean mpd or mpv? Also by player queue do you mean the queue in i3status-rs, or is it some feature of playerctld?

Yes, mpv is the player I'm referring to. I was not aware of a queue like structure in the music block. I was referring to the player queue in playerctld. This player is an alias for the most recently used player and maintains a queue of all the other active MPRIS players. One can issue a command to rotate the player queue such that the playerctld player now points to another player. I bind these controls so I can easily manage all my open players.

Somehow I was able to reproduce it now, at least the block collapsing issue. Can you try with #972?

The original "does not clear/close on player close" may be back, but that probably requires a different solution to what I already tried so let me know.

Ok so I setup playerctl and see what you mean by the last player not going away on close. It's kind of a quirk specific to playerctl but #973 seems to have fixed it for me.

@benjaminBrownlee Have you had a chance to try it out?

Sorry, this got buried in all my other things. Yes, this appears to working as I would expect now. Thanks for your help!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

michaelmrose picture michaelmrose  路  4Comments

boi4 picture boi4  路  3Comments

concatime picture concatime  路  4Comments

l4l picture l4l  路  6Comments

yawpitch picture yawpitch  路  4Comments