Delay (30s+) between clicking a menu and actual script

[jontelang]

Not sure how to debug this. I often (several times daily) experience periods where xbar is unresponsive, each tap takes minimum 30s up to a minute to actually invoke the shell script. I can help investigating this but I am not sure where to start, or even wether this is an xbar issue or something else. I have never experienced this in many years of (BitBar usage) but now it happens frequently.

For context, I have multiple menus (dozens) that I use to manage git repos. Commands to copy names, make branches, pull, push, stash, you name it. Each one more or less has terminal=true and it closes the terminals automatically. In case there is an issue with opening multiple, but again I have been using it like this for years with BitBar.

So either, is this something that has happened to anyone else? Or what can I do to debug it myself.

Thanks

[leaanthony]

That is strange! There's nothing I can think of that might cause this delay other than congested CPU. Is it off the charts?

[jontelang]

Not that I remember seeing, but I will look closer next time. I mean I am doing normal things while waiting, so it's not like the computer is overloaded in general.

[jontelang]

Some kind of update, still unsolved though.

I am using https://timingapp.com/ to track work automatically, this reads through accessibility APIs window contents and whatnot. When I tap my xbar command, the Timing App menu bar helper item stops responding. I am not sure wether it is xbar that does something, or vice versa. But as soon as it starts to respond again, all buffered actions from xbar happens all at once.

It might be Timing App that is the issue, as think I noticed this happening at one other point. Although I can't confirm it to 100% yet.

My command for example:

echo "--Terminal |                \
    shell=cd                  \
    param1=\"$rootdir/$dir/\" \
    terminal=true             \
    refresh=true              \
    image=$terminal"

And a screenshot:

I have used them both in the same way for years though, so something is up that's for sure.

[MrMage]

Hi @jontelang,

I am the developer of Timing and stumbled upon this issue. My theory would be that Timing is trying to fetch information from xbar, and because xbar itself is also unresponsive, gets stuck waiting for xbar. As soon as xbar becomes responsive again, Timing is able to obtain this information and resumes operation again.

That being said, the screenshots also indicate that you are using a very old version of Timing. I can't exclude the possibility that newer versions of Timing behave differently under these circumstances. If you'd like to check that, please feel free to reach out via https://timingapp.com/contact so I can send you a free temporary license for the latest version of Timing.

All the best, Daniel Alm Founder, Timing

[jontelang]

Hi @MrMage, I appreciate the message, and the offer. I can however report that I do not really have the issues anymore, and what's worse is that I don't remember what (if anything) I did. I am definitely using an old version so I didn't reach out for support myself in this case.