--not-when-audio doesn't timeout if audio stops after X goes idle
Opened this issue · 5 comments
While playing with this, I noticed that I can set a timeout with --not-when-audio like so,
xidlehook --not-when-audio --timer 'echo done' ''
Play some audio, e.g. in Spotify, and stop the audio remotely e.g. with the Spotify app on my phone, and the timer never times out.
This also happens when I let a youtube video time out on its own.
This is with xidlehook 0.8.2
That was actually intentional, as to not needlessly waste CPU cycles checking if audio is STILL playing or the window is STILL fullscreen. If you think that's bad behavior, I can probably fix it fairly quickly
Well I guess my expectation is if there's no audio, it's xidlehook's job to know about it and have accurate timers.
For me, pausing spotify from my phone as I leave my apartment is something I do regularly, and if I rely on xidlehook for power management it means my computer will stay awake.
But maybe for this case it might be better to look at dbus events to get the "PlaybackStatus" from "org.mpris.MediaPlayer2.Player". Idk if it's a good fix, but interpretting those events like you do X input events might solve the problem, because I guess xidlehook checks volume after input events. And both Spotify and Youtube broadcast those events.
It wouldn't solve the problem for players that don't connect to dbus though. What do you think?
Or maybe pulseaudio emits dbus events that can be caught? I don't know
I'm not actually using dbus, the only way I found out how to check for activity was to check every X seconds (where X is the time until your next timer triggers). I do get pulseaudio events, but those are on a separate thread. But I don't need the pulseaudio events live, I still wake up before I trigger the timer, so I have plenty of time to check all the required factors.
Don't worry about implementation, I'll get to work.
ahh, okay I understand the behaviour now. Just tried the fix out, and it does work. It's worth noting I guess though that depending on when you stop the music or fullscreen, the timer will go off in anywhere between 0...X seconds. Which can seem like weird behaviour especially if it's closer to 0 seconds (:
Thanks for the quick fix though!
Oh, good catch! I'll let the issue be open until that's resolved... Hm... wonder how I'd solve that