Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--not-when-audio doesn't timeout if audio stops after X goes idle #43

Open
sidequestboy opened this issue May 24, 2020 · 5 comments
Open

Comments

@sidequestboy
Copy link

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

@jD91mZM2
Copy link
Owner

jD91mZM2 commented May 24, 2020

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

@sidequestboy
Copy link
Author

sidequestboy commented May 24, 2020

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

@jD91mZM2
Copy link
Owner

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.

@sidequestboy
Copy link
Author

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!

@jD91mZM2 jD91mZM2 reopened this May 29, 2020
@jD91mZM2
Copy link
Owner

Oh, good catch! I'll let the issue be open until that's resolved... Hm... wonder how I'd solve that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants