Putting gBar into Hyprland exec-once breaks it about gbar HOT 16 CLOSED

Strange... I use it in the exact same way as you (Also exec-once = gBar bar 0). Have you tried running it from the command line? If it breaks there too, what does the log say?

from gbar.

It works from the command line.

from gbar.

I'm seeing the following in your flake.nix meson build --buildtype=release -DWithHyprland=false -DWithNvidia=false -DWithBlueZ=false I assume that is the build script. Dependencies that are not met will be dynamically disabled at runtime anyways, so there is no need to disable them at compile time (Especially the -DWithHyprland=false, because that is completely disabling the Hyprland workspace widget). I don't think that is the cause of the issue, but can you try with only meson build --buildtype=relase to see if that fixes it?

from gbar.

I am getting the below output, so I believe the build script isn't being actually used.

NVML not found, disabling Nvidia GPU
AMD GPU not found, disabling AMD GPU
Can't connect to BlueZ d-bus! Disabling Bluetooth!
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.bluez was not provided by any .service files
Cannot open network device! Disabling Network widget.

It is possible to pass flags somehow but I'm not sure how.

from gbar.

This is where it is stuck:

(gdb) bt
#0  0x00007f6f17d856b4 in read () from /nix/store/lqz6hmd86viw83f9qll2ip87jhb7p1ah-glibc-2.35-224/lib/libc.so.6
#1  0x00007f6f1618b1f1 in pa_read ()
   from /nix/store/f81zvfglqqv566cw66cx02h43b0vf9mc-libpulseaudio-16.1/lib/pulseaudio/libpulsecommon-16.1.so
#2  0x00007f6f16e7bbde in pa_mainloop_prepare () from /nix/store/f81zvfglqqv566cw66cx02h43b0vf9mc-libpulseaudio-16.1/lib/libpulse.so.0
#3  0x00007f6f16e7c648 in pa_mainloop_iterate () from /nix/store/f81zvfglqqv566cw66cx02h43b0vf9mc-libpulseaudio-16.1/lib/libpulse.so.0
#4  0x00007f6f180e4240 in System::GetAudioInfo() () from /nix/store/xnh4f2b6a03bgzanccfi9vsq3m351jqd-gBar/lib/libgBar.so
#5  0x00007f6f180ecb00 in Bar::DynCtx::UpdateAudio(Slider&) () from /nix/store/xnh4f2b6a03bgzanccfi9vsq3m351jqd-gBar/lib/libgBar.so
#6  0x00007f6f180f109a in Bar::WidgetAudio(Widget&)::{lambda(Widget&)#1}::operator()(Widget&) const [clone .constprop.0] ()
   from /nix/store/xnh4f2b6a03bgzanccfi9vsq3m351jqd-gBar/lib/libgBar.so
#7  0x00007f6f180f1570 in Bar::WidgetAudio(Widget&)::{lambda(Widget&)#2}::operator()(Widget&) const [clone .isra.0] ()
   from /nix/store/xnh4f2b6a03bgzanccfi9vsq3m351jqd-gBar/lib/libgBar.so
#8  0x00007f6f180f1698 in Bar::WidgetAudio(Widget&) () from /nix/store/xnh4f2b6a03bgzanccfi9vsq3m351jqd-gBar/lib/libgBar.so
#9  0x00007f6f180f32a0 in Bar::Create(Window&, int) () from /nix/store/xnh4f2b6a03bgzanccfi9vsq3m351jqd-gBar/lib/libgBar.so
#10 0x00000000004023b2 in main ()

Maybe related to PipeWire?

from gbar.

Thanks for the stacktrace.
Looking at it, it is definitely a problem with the PulseAudio Server.
Do you use Pipewire or PulseAudio?
Does pactl list sinks work?
Can you give the value of the variable 'pending' in frame # 4 after it has run for a while?

from gbar.

Okay, I found a bug in my code, that could cause the described behaviour. The bug should now be fixed in the latest commit. Can you check if that is the case?

from gbar.

I use PipeWire.

With the new patch the hang is at a different location:

#0  0x00007f3d7f228856 in ppoll () from /nix/store/lqz6hmd86viw83f9qll2ip87jhb7p1ah-glibc-2.35-224/lib/libc.so.6
#1  0x00007f3d7e31b079 in pa_mainloop_poll () from /nix/store/f81zvfglqqv566cw66cx02h43b0vf9mc-libpulseaudio-16.1/lib/libpulse.so.0
#2  0x00007f3d7e31b656 in pa_mainloop_iterate () from /nix/store/f81zvfglqqv566cw66cx02h43b0vf9mc-libpulseaudio-16.1/lib/libpulse.so.0
#3  0x00007f3d7f583260 in System::GetAudioInfo() () from /nix/store/4xbbyhrjfscqg346pbfc30fli8d918np-gBar/lib/libgBar.so
#4  0x00007f3d7f58bb50 in Bar::DynCtx::UpdateAudio(Slider&) () from /nix/store/4xbbyhrjfscqg346pbfc30fli8d918np-gBar/lib/libgBar.so
#5  0x00007f3d7f5900ea in Bar::WidgetAudio(Widget&)::{lambda(Widget&)#1}::operator()(Widget&) const [clone .constprop.0] ()
   from /nix/store/4xbbyhrjfscqg346pbfc30fli8d918np-gBar/lib/libgBar.so
#6  0x00007f3d7f5905c0 in Bar::WidgetAudio(Widget&)::{lambda(Widget&)#2}::operator()(Widget&) const [clone .isra.0] ()
   from /nix/store/4xbbyhrjfscqg346pbfc30fli8d918np-gBar/lib/libgBar.so
#7  0x00007f3d7f5906e8 in Bar::WidgetAudio(Widget&) () from /nix/store/4xbbyhrjfscqg346pbfc30fli8d918np-gBar/lib/libgBar.so
#8  0x00007f3d7f5922f0 in Bar::Create(Window&, int) () from /nix/store/4xbbyhrjfscqg346pbfc30fli8d918np-gBar/lib/libgBar.so
#9  0x00000000004023b2 in main ()

from gbar.

Okay, back to the drawing board. The hang is btw still the same. I'll try to put some logging in place, so I have it easier debugging.

from gbar.

I'm kind of suspicious of the libpulseaudio in buildInputs. Does the app need to be compiled specifically against PipeWire or will a Pulseaudio build also work with PW?

from gbar.

If it compiles correctly, it should be correct. And yes, gBar needs to link with pulseaudio, even on a PipeWire system(I use PipeWire too).

from gbar.

Can you test the newest commit and post the log found in /tmp/gBar.log?

from gbar.

cat: /tmp/gBar.log: No such file or directory Packaging it with nix may have done something to that path. I will try building it differently in the weekend.

Meanwhile I've been using ironbar. That one uses a lot less CPU for some reason. 0.5% vs the 6% used by gBar.

from gbar.

I have a strong suspicion that you're not recompiling the new commits(including the bugfix) properly, since I currently use absolute path and /tmp is pretty much guaranteed to exist on Linux systems. I suggest building it locally without a package manager (As outlined in the readme, but without installing, then running build/gBar ...) and see if the issue persists. After that you can clean and rebuild the nix package.

Meanwhile I've been using ironbar. That one uses a lot less CPU for some reason. 0.5% vs the 6% used by gBar.

Per core or per CPU? (For me it's 0.5% whole system and 4-6% for a single core) I can probably add a config option to decrease the workspace polling rate, which is a huge bottleneck. Decreasing it will increase latency though.

from gbar.

I have a strong suspicion that you're not recompiling the new commits(including the bugfix) properly, since I currently use absolute path and /tmp is pretty much guaranteed to exist on Linux systems.

I checked, and I am absolutely sure that it is built from a git hash that includes the logging. Then I built it manually and the bug was gone and logging happened. So yes, the bug is fixed. How the old binary gets into my PATH is a mystery.

Yes, 6% of one core, which is a bit much IMO. With workspace polling rate you mean the indicator that shows which WM workspace you are in? IIRC that is instant on i3bar even though the rest is updated only once in 5 seconds, which is not often enough. Is the Hyprland API for that bad?

from gbar.

I checked, and I am absolutely sure that it is built from a git hash that includes the logging. Then I built it manually and the bug was gone and logging happened. So yes, the bug is fixed. How the old binary gets into my PATH is a mystery.

Okay, glad it's now fixed. I will close the issue now.

Yes, 6% of one core, which is a bit much IMO. With workspace polling rate you mean the indicator that shows which WM workspace you are in? IIRC that is instant on i3bar even though the rest is updated only once in 5 seconds, which is not often enough. Is the Hyprland API for that bad?

Okay, I did some investigation. Every 1 second or so 2% is used because of redrawing the sensor widgets. There is not much that I can do.
ironbar, waybar and others communicate with Hyprland via the ext-workspace-unstable-v1 Wayland protocol, whereas gBar uses Hyprland's IPC. I think here lies the reason for the high CPU usage. I added some commits today, which reduced the IPC calls from 18 every 100 ms to 2 every 100ms. This resulted in CPU utilization just from the workspaces to drop from 6% to 4%. Because of the still high CPU utilization I'll probably implement the Wayland protocol in the near future, which (hopefully) will reduce CPU usage.
Since this discussion is getting a bit off-topic, I think it would be best to move it to the issue I just created (#8). I'll ping that issue once it is done

from gbar.