Module stays invisible if label is initially blank

[TooManyChoices]

Using Waybar v0.10.4-1 on Hyprland and Arch Linux, tested on Waybar v0.10.4-6-g003dd3a9 and this still happens

Making a module that would use playerctl to display information about what's playing. If there wasn't anything playing when Waybar started up (i.e when "playerctl status" prints "No players found") the module would not be shown, and the script would call "playerctl status" every 10s until there's a player, which is what's expected. Then the module should appear with the information from playerctl, what happens instead is that the label gets set, but the module stays hidden. I know the label is set because you can hover over it's area and see a tooltip saying whatever the label is saying. If you killed Waybar and started it again while there was a player, the module would be visible and showing the script's output normally, it could even reappear after getting blanked out when the player stops. As a workaround, I'm making the module show filler text like "playerctl.sh" for 1s when starting, and it works perfectly fine now, but I would rather not do that, so, help me out pls.

tl;dr the module would not appear ever if it started as blank (there being no text) but being given text later. the module can appear and disappear just fine if it was not blank to begin with, but preferably it gets to be blank

Here is the module in the config:

"custom/playerctl": {
        "format": "{}",
        "exec": "$HOME/.config/waybar/playerctl.sh",
        "on-click": "playerctl play-pause"
    },

This is the shell script I have now, with the workaround:

#!/bin/sh

format="{{ title }} - {{ artist }} {{ duration(position) }}"
playing_icon=""
paused_icon=" "
sleep_time=10

# below was just an `echo ""` but changed for workaround
echo "playerctl.sh"
sleep 1

while true
do
    while true
    do
        player_status=$(playerctl status)
        prefix=""
        if [ "$player_status" = "Playing" ]; then
            prefix="$playing_icon"
        elif [ "$player_status" = "Paused" ]; then
            prefix="$pause_icon"
        else
            echo ""
            break
        fi
        info="$(playerctl metadata --format "$format")"
        echo "$prefix$info"
    done
    sleep $sleep_time
done

Still not sure if this is a bug with Waybar or my stuff :p

[RobertMueller2]

I can't reproduce any issues using the same Waybar commit. Of course, I've commented out the echo "playerctl.sh". :wink: What I notice is that it can take a while with the 10s sleep but I suppose you already knew that. I'm using this style and config:

#custom-test-output {
    background-color: #268bd2; /* blue */
}

#custom-test-output.disabled {
    background-color: transparent;
}

{
    "layer": "top", // Waybar at top layer
    "position": "top", // Waybar position (top|bottom|left|right)
    "height" : 20,
    "modules-center": ["custom/test-output"],

    "custom/test-output": {
        "format": "{}",
        "exec": "./script-3496.sh",
        "on-click": "playerctl play-pause"
    },
}

Starting waybar without anything playing:

Then, when starting song, after a while:

That said, the fans spin up. I'd probably add a sleep to the inner loop as well. Maybe not 10s, but something.

I don't really have any idea what's wrong, but here are two ideas:

• try json. Reason being, while the module does handle single line output, the manpage really says the expected format is text\ntooltip\nclass. This might just be how I feel about it, but I think Json offers better clarity for this than a 3 line output.
• I suppose you've considered and discarded the mpris module?

[TooManyChoices]

That said, the fans spin up. I'd probably add a sleep to the inner loop as well. Maybe not 10s, but something.

I didn't hear my fans spinning before because another fan was being too loud for me to hear my computer crying.

• try json. Reason being, while the module does handle single line output, the manpage really says the expected format is text\ntooltip\nclass. This might just be how I feel about it, but I think Json offers better clarity for this than a 3 line output.

I tried to fix the script with this idea, but I don't know which manpage you're talking about, and also just didn't know how to.

• I suppose you've considered and discarded the mpris module?

Yeah, I both considered thoroughly, and also decided to discard the mpris module, that I totally knew about before writing my own thing. With that being said, I think I'll just start using the mpris module, as it seems more generally functional and reliable than my sh script. I should read more, and I doubt this is an actual Waybar bug.

[RobertMueller2]

I tried to fix the script with this idea, but I don't know which manpage you're talking about, and also just didn't know how to.

You should be able to access the custom module's manpage with man waybar-custom on the command line. Manpages and wiki haven't always been perfectly synced, or sometimes stuff is missing there, still, I think using both is a good place to get information.

• I suppose you've considered and discarded the mpris module?

Yeah, I both considered thoroughly, and also decided to discard the mpris module, that I totally knew about before writing my own thing. With that being said, I think I'll just start using the mpris module, as it seems more generally functional and reliable than my sh script. I should read more, and I doubt this is an actual Waybar bug.

:smile: Well, there can be valid reasons to use a custom module where a native module exists, I guess for missing features, bugs, etc. That's why I worded it that way.

[TooManyChoices]

Thank you for the clarification!