Fix Symphonia seek for a duration with a fractional element of 0

[will3942]

Fixes: #686

[will3942]

@dvdsk Ready for review - it was harder to get a 0ms test file than it should have been...

[dvdsk]

Ready to merge as is, could make the unit test an integration test. Let me know what you choose and ill merge.

edit: oh and good find! thanks for fixing my bug (this one is my fault) 🎉

[will3942]

Ready to merge as is, could make the unit test an integration test. Let me know what you choose and ill merge.

edit: oh and good find! thanks for fixing my bug (this one is my fault) 🎉

No worries - have moved this to be an integration test :)

[PetrGlad]

Maybeif frac < 0.0001 { } else { } instead?

Next to the beginning of the Source saturating_sub will leave seconds unchanged, and the whole effect would be to actually seek forward almost a second.

[dvdsk]

its never called at the beginning of the source. This handles seeking beyond a source end.

[dvdsk]

so this is good to merge right?

[PetrGlad]

If it fixes the problem - yes, we can merge. Since it is already an improvement.
We can handle other cases later if necessary.
The source itself can be less than a second long. The check compares with < 1ms overlap, but tick-back is 0.1ms. what about overlaps in range 0.1...1.0 ms? I wonder if there are any symphonia functions to work with its timestamps or ways to convert those from/to Duration.

[dvdsk]

The source itself can be less than a second long

ahh damn, I did not think of that. Thanks for clarifying. No I agree now, lets fix this properly only then merge. This will need a comment in the code explaining this case or a future refactor might throw the code out.

[dvdsk]

I placed this comment in the code:

        let time = if seek_beyond_end {
            let time = self.total_duration.expect("if guarantees this is Some");
            skip_back_a_tiny_bit(time) // some decoders can only seek to just before the end
        } else {
            pos.as_secs_f64().into()
        };

As I remember symphonia does not seek if the time is beyond the length of the track. In rodio we have defined seek to saturate at the track length. If symphonia now saturates we can remove this.

[roderickvd]

When you seek to or beyond the end, you get an UnexpectedEof which is anyway what you get when the stream ends.

[dvdsk]

Though that is completely valid behavior for symphonia its not what we want in rodio (seeking beyond source should saturate as that is easiest for the end user) we do this instead. We also still want to return UnexpectedEof in case of other errors.

Though reading it now is still kinda fragile when audio has no total_duration. I'm strongly for leaving it as is for now. Since we have more then enough going on atm :)

edit: and the next release is already going to be gigantic. Do feel free to open an issue and present alternative behavior.

[roderickvd]

What do you mean with saturating? I assume the behavior should be that the iterator returns None. Is that also what you mean?

I would make (and have made) the Symphonia decoder such that it handles this specific end-of-stream UnexpectedEof that way.

[dvdsk]

What do you mean with saturating?

see the docs: https://docs.rs/rodio/latest/rodio/source/trait.Source.html#method.try_seek

As long as the duration of the source is known seek is guaranteed to saturate at the end of the source. For example given a source that reports a total duration of 42 seconds calling try_seek() with 60 seconds as argument will seek to 42 seconds.

I would make (and have made) the Symphonia decoder such that it handles this specific end-of-stream UnexpectedEof that way.

Yeah that's way simpler, go ahead and do that 👍 Maybe I was worried about skipping back? but that's not a feature nor can we make it one.