Poll for the "elapsed" amount
Closedopened 3 years ago by p · 1 comments
Reference in New Issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Setting our own periodical timer isn't reliable, sometimes MPD pauses playback and doesn't let anyone know (can be reproduced with sshfs and network failures).
At least make it an option to poll every 500ms, which is also what Sonata did. And make it the default. Given that there already is an
elapsed_eventtimer, just repurpose it.
MPD could use some improvements, protocol-wise.
The naïve approach is very unstable and rather unacceptable, distracting to look at: 0, 0, 1, 1, 2, 3, 3, ...
We might want to run two timers, one for the more accurate internal clock, and another one for polling the daemon, which also gives us usable bitrate information to show.
Then there's the question of how to detect the situation that MPD has stopped responding. We could restart the polling clock (use a state boolean: sending/waiting) once we issue the "status" command and stop advancing the internal clock if the response doesn't arrive in time. (To stop the auto-advancement it suffices to stop the timer.)
Polling the daemon re-syncs the internal clock. Make sure to inspect how often the internal elapsed time ticker gets adjusted/re-run. It may help to set it to run a few milliseconds later, e.g., 5 or even just 1: timer readjustments have unnoticeable overhead but premature runs cause an extra syscall and a CPU wake-up event.
This hybrid solution has a drawback: when playback stalls and the next elapsed second should come earlier than the polling timer is triggered, we will keep going back and forth a second. So while it would no longer advance indefinitely, there's a 50% chance of strange behaviour and we haven't achieved much.
Another option is to adjust the polling timer so that it uses the value for the internal ticker but should it run in less than 500ms, make it run after one more second. It will synchronise and only run once per second.
This may skip a second when unpausing and sadly on most other events as well.
We can also use the value directly and remember what the last elapsed time was (reuse
elapsed_since): if it hasn't changed since the last time, set the timeout to 500ms, which might happen to resolve the question of MPD older than 0.16. The server would have to be seriously fucked for this to go into a busy loop.
It can also be hybridised as above for more precision, yet it seems unnecessary.
Poll for the "elapsed" amountto Poll for the "elapsed" amount #easy 3 years ago Poll for the "elapsed" amount #easyto Poll for the "elapsed" amount 3 years ago