Timer 'dies' unexpectedly if position exceeds duration

[adamcik]

Timer 'dies' unexpectedly if position exceeds duration

[jcass77]

Thinking about this some more, I'm sure this is not a bug in the timer itself, but rather an artefact of the specific sequence of start and set calls that the web extension calls based on Mopidy events.

I can't figure it out however, and wonder if

media-progress-timer/timer.js

Line 114 in 28007e9

this._running = false;

could not be the culprit. It is the only point at which the timer could be stopped without this being done explicitly by the user through calling ProgressTimer.prototype.stop or ProgressTimer.prototype.reset.

Either that, or there is some sort of unexpected delay in

media-progress-timer/timer.js

Lines 87 to 88 in 28007e9

	var adjustedTimeout = timestamp + this._updateRate - now();
	setTimeout(this._boundCallUpdate, adjustedTimeout);

which causes the setTimeout call to fail?

[jcass77]

Some more debugging results:

• Mopidy-Musicbox-Webclient uses mopidy.playback.getTimePosition to get the time position from Mopidy.
• when the end of the track is reached, the timer is reset to the length of the next track to be played, and starts polling Mopidy again with mopidy.playback.getTimePosition to figure out if the track has actually started to play yet so that it can sync up the progress timer.

The problem seems to be that (at least in Mopidy <= 1.1.2), the value that is returned by mopidy.playback.getTimePosition can be a little unpredictable as a track change is occurring. It looks as if Mopidy does not return '0' as soon as one track has finished playback and before the next track starts, but instead keeps returning a position associated with the previous track that we are changing from until some time after the next track has started to play.

The end result is that the web client tries to update the progress timer with a position that is greater than the timer's duration, and

media-progress-timer/timer.js

Line 114 in 28007e9

this._running = false;

then forces the timer to stop.

I guess the question then is whether it is reasonable for the timer to terminate the update loop if it receives a set value that is greater than duration. It is a little unforgiving and can cause issues when the consumer thinks that the timer should still be running (because a stop was not triggered explicitly).

Possible solutions could be to:

• prevent the timer from self-terminating; or
• let the consumer know when this has happened so that it can trigger a restart if it still needs the timer to be running.

[adamcik]

Ah, that explains a lot. I spent a lot of time trying to fix this for 2.0, but I can see how we should probably be more robust against "bad" data due to this type of issue.

[adamcik]

I don't think changing this for everyone is a great idea. What I'm considering instead is giving you an "overrun" option, which controls if you continue scheduling or stop when position catches up with duration.

[jcass77]

An 'overrun' option would be handy. This should also be less of an issue for Mopidy >= 2.0, in which I believe mopidy.playback.getTimePosition may return more consistent results during track transitions.

I think lots of people are still using Mopidy <= 1.1.2 on their Rasperry Pi's though, so it probably makes sense to make the changes regardless.