MPEGPlayer resume failure

[Mizutsuki]

Heya.
I have a gigabeat f40s.  I downloaded the given example Elephant's Dream video and it plays and resumes fine, but when I went to encode my own movies I found that they would play, but not resume.  I would select resume and the screen would turn black, and for a while I could hear/feel the hard drive clicking.  When I ran the same test in the simulation environment on my PC, the CPU usage was 100% and it never recovers no matter how long I wait.  Again, Elephant's Dream doesn't have this problem so it probably has something to do with my encoding method.  I'm using Tsunami MPEG to encode.
I've got a short sample video that I'd be happy to send to anyone but I'm reluctant to simply post on a forum.
Thanks for you're help.
Stephen

[jhMikeS]

If you can play you movies from the beginning, your encoding is fine. The seek algorthm doesn't guarantee that it will end and gets stuck in infinite loops at times.

[Mizutsuki]

If you can play you movies from the beginning, your encoding is fine. The seek algorthm doesn't guarantee that it will end and gets stuck in infinite loops at times.

Ok, but every single one of my encodes does it and ED doesn't, that seems suspect to me.
So is that a bug, or is that some kind of intended feature I don't understand?
Thanks for the help.

[jhMikeS]

If the files can simply play from the start without problems, they're fine - bottom line. If the player won't seek in them properly, it's the player's fault. Until this is sorted out, try to find a way to encode them so they behave better - either a different program or experiment with various settings if your program has any.

[Mizutsuki]

If the files can simply play from the start without problems, they're fine - bottom line. If the player won't seek in them properly, it's the player's fault. Until this is sorted out, try to find a way to encode them so they behave better - either a different program or experiment with various settings if your program has any.

Well, part of the reason I ask is that I was thinking about tracking this down. I'd like to try to fix this bug, if it's not too presumptious of me to make the attempt and if it actually is a bug.
Anyway, thanks for your help.
Stephen

[jhMikeS]

It is a bug. If you've got an algorithm that can search timestamps without presuming the presence of an audio stream (say, using SCR values for rough seeks), is fast, robust against stream errors (invalid timestamps, timestamps out of order, etc.) and guaranteed to finish in all cases, offer it up. I was about to start on that part myself.

Some successive linear interpolation over smaller intervals would probably converge very quickly to the desired system header (the one where the earlier stamp is <= to the desired time and the later > the desired time).