Poll for the "elapsed" amount #1

New Issue

p · 2020-10-10T21:23:09+02:00

p commented

2020-10-10 21:23:09 +02:00

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 2020-10-10 21:23:09 +02:00

p referenced this issue from a commit

2020-10-18 07:30:57 +02:00

Give up and implement elapsed time polling Playback may sometimes stall but it won't produce any events. This popular workaround likes to jump around, though. It might be a good idea to use some kind of hybrid approach. Therefore this is disabled by default so far. Updates #1

p commented

2020-10-18 08:13:38 +02:00

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

2020-10-21 21:15:30 +02:00

p referenced this issue from a commit

2020-10-23 02:58:35 +02:00

Avoid jumping around in polling mode While still avoiding busy loops. It works well enough to enable this by default. Closes #1

p closed this issue

2020-10-23 02:58:35 +02:00

p changed title from ~~Poll for the "elapsed" amount #easy~~ to Poll for the "elapsed" amount

2020-10-24 15:01:41 +02:00

p added the

easy

label 2020-10-24 15:01:46 +02:00