fix: don't trim too much when speed < 1 with playtime-remaining

[christoph-heinrich]

Speed < 1 can require more parts of the formatted time then when speed >= 1.
E.g. when a video is almost 1min long and the speed is reduced to <1 then the minutes part of the remaining time would still get trimmed, even though it's not 00:.

Alternatively the max seconds could also be

local max_seconds = math.max(state.duration, (state.duration - state.time) / speed)

so that the time only gets longer when the remaining time is large enough to require less trimming.

Really not sure what the best way of handling this is...

[tomasklaen]

I'd be fine with this. But shouldn't the elapsed time be handled the same way? So that its length format always matches the destination.

[hooke007]

But shouldn't the elapsed time be handled the same way

Where we display this data? theoretically, it's the duration we had played. So it shouldn't be scaled with speed.
If users would like to seek to the position in the past, it would make confusion.

[christoph-heinrich]

Where we display this data? theoretically, it's the duration we had played. So it shouldn't be scaled with speed.

It's not about scaling the elapsed time with speed, but about showing the same number of digits for elapsed time and destination/remaining time.

[hooke007]

Got it.