MP4(iso5): try_seek just resetting the Source to start

[LDprg]

As the title says.
I only tested it with symphonia and mp4 data.

[roderickvd]

I know the PR #786 is closed for now, but could you test it with that?
If it doesn't work, are you at liberty to share the MP4?

[LDprg]

Oh I see. I will try to do so the next days. I will report back whether it worked, as soon as I tried.

[LDprg]

@roderickvd I looked into this again and sadly seek still fails.
When I create a Decoder without with_seekable it crashes with ForwardOnly error (no matter what, or if its actually forward seeking).
When I enable it, it does call the seek implmentation (I made a logging wrapper around Cursor) at the start. However, after this the behaviour is as before (resetting instead of seeking). Also the seek function wont get called.

Here is the audio file I tested with (It is compressed so I could upload it): output.tar.gz

And for completness the ffprobe metadata of the dile:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'output.m4a':
  Metadata:
    major_brand     : iso5
    minor_version   : 512
    compatible_brands: iso5iso6mp41
    encoder         : Lavf61.7.100
  Duration: 00:02:36.05, start: 0.000000, bitrate: 161 kb/s
  Stream #0:0[0x1](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 160 kb/s (default)
      Metadata:
        handler_name    : SoundHandler
        vendor_id       : [0][0][0][0]

The code I used for testing is similar to the seek_mp3.rs example.

[roderickvd]

I've pushed a fix for this to #786. The issue was that this specific M4A file - in ISO5 format - had set its frames metadata to 0, causing total duration to return 0, in turn causing seeking to be saturating to the start.

[LDprg]

The problem is now fixed for me. The reason it contains "broken" metadata probaply is, that it is from a hls audio stream. I guess the metadata gets stripped to reduce data traffic.

Thx, for your help!
However I won't close this issue until your PR gets merged.