Poll for the "elapsed" amount #1

Closed
opened 2 years ago by p · 1 comments
p commented 2 years ago
Owner

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_event timer, just repurpose it.

MPD could use some improvements, protocol-wise.

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_event` timer, just repurpose it. MPD could use some improvements, protocol-wise.
p self-assigned this 2 years ago
p commented 2 years ago
Poster
Owner

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.

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.
p changed title from Poll for the "elapsed" amount to Poll for the "elapsed" amount #easy 2 years ago
p closed this issue 2 years ago
p changed title from Poll for the "elapsed" amount #easy to Poll for the "elapsed" amount 2 years ago
p added the
easy
label 2 years ago
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.