Forum Discussion

nowhereman's avatar
nowhereman
Visitor
15 years ago

roAudioPlayer.Seek()

Has anyone had success using roAudioPlayer's Seek() function? I expected it to work similarly to roVideoPlayer's Seek(), but that doesn't seem to be the case. No matter what offset value I send it; positive numbers, negative numbers, zero; it always seeks forward a few seconds.

8 Replies

  • renojim's avatar
    renojim
    Community Streaming Expert
    I've had the same results as you. I even created an mp3 of me counting 1 number per second and the time it seeks seems to be totally random.

    -JT
  • "renojim" wrote:
    I've had the same results as you. I even created an mp3 of me counting 1 number per second and the time it seeks seems to be totally random.


    Thanks. At least now I know I wasn't losing my mind. :shock:
  • It's been a while since I looked at this, but I believe MP3 files don't contain indexing information that would tell the player where to seek. For CBR MP3s it would be possible to make a pretty good guess based on the stream bandwidth (although the player doesn't currently do this) but for VBR it would be essentially impossible to seek accurately.

    --Mark
  • renojim's avatar
    renojim
    Community Streaming Expert
    I did a little research myself and it looks like some (all?) mp3 software players, and possibly hardware players, seek by brute force working their way through the mp3 data packets. Is that something that's possible with the Roku hardware/software or would it take too long to be usable?

    -JT
  • destruk's avatar
    destruk
    Streaming Star
    I really wish this feature would work. I mean, if you have a 3 hour long podcast episode in mp3 format, with a working seek feature you could listen to an hour, store a bookmark, and resume it later instead of having to start all over from minute 0 again. Not to mention being able to use fast forward or a button press to jump ahead past topics being discussed you don't want to listen to. I was thinking of splitting the podcast into 12 mp3 files - that would make each one 15 minutes long, and setting it to a playlist, so pressing the right arrow key could skip ahead 15 minutes, and left arrow could go back 15 minutes, but each time it does that there is a rebuffering delay, and it's not an exact 15 minutes unless you want to cut into the middle of a word. It's much more difficult that way - not optimal either. Does Seek work for WMA?
    Would the issue probably be in the documentation already?
    Boolean Seek(Integer OffsetMs)
    Set the start point of playback for the current song to OffsetMs milliseconds.

    How can a boolean pass an integer? Or am I reading that as a boolean return value?

    If I can make a suggestion, why not use mp3's seek feature to be a byte offset for the file itself? That way the developer would at least have some way of fast forward through the file? That wouldn't require any knowledge of the file contents besides the total filesize. start is 0, end is number of bytes for the file length, and split it into a number of arbitrary pieces like jump ahead 100,000 bytes or something.
  • "destruk" wrote:
    Boolean Seek(Integer OffsetMs)
    Set the start point of playback for the current song to OffsetMs milliseconds.

    How can a boolean pass an integer? Or am I reading that as a boolean return value?

    Boolean is the return value.