How to seek to the "live edge" of an ongoing HLS stream

[SemaphoreMetaphor]

I have an HLS stream which is live and has the ability to pause. However we do not want to allow a DVR like functionality and as such the stream should seek to where the live stream currently is. How do I seek to the live position in the stream when getDuration() always returns 0?

[ojw28]

DVR functionality isn't supported yet (an enhancement request to add support is here: #87). The player should already be seeking to the live edge of the stream for you when playback starts, and any seek on the player will also seek to the live edge (the value passed is currently ignored, although this will change once #87 is implemented).

So in short, the player should already be giving you the behavior that you want.

[ojw28]

Ah, perhaps what you mean is that you want to allow the user to pause, but when the user resumes you want the playback to jump to the live edge again. You can achieve that by calling seek(0) when playback resumes (because any seek will seek to the live edge).

Alternatively you can call ExoPlayer.stop() when the user pauses, and ExoPlayer.prepare() when the user resumes. This will be more bandwidth efficient because it wont download any media after the user pauses, but is also a bit more effort.

[SemaphoreMetaphor]

@ojw28 Exactly. seekTo(0) doesn't seem to be getting me to the edge. And I'd rather not hurt UX by having to rebuffer, even more so on devices with poor network connection. Is there a way to cache the buffer to disk?

So another issue I've been having also is when I have multiple videos visible, memory takes a massive hit. Can you recommend some memory management strategies? Is there a granular control over the max buffer somewhere and also can we cache that buffer to disk rather than ram?

[ojw28]

Hm, yeah, I don't think it behaves quite like it's supposed to. It's probably seeking to the live edge, but in a stale playlist rather than an up-to-date one. I'll take a look.

---

Not related to this issue but responding to your other questions (please move further discussion elsewhere):

• There's no buffering to flash functionality at present. Generalize/enhance persistent caching functionality #420 is somewhat related. I'm not sure how I feel about making it really easy to do this, because if it's there then it's really tempting for every application to optimize for themselves (i.e. downloading more data than the user is likely to consume and/or filling up disk space) at the cost of overall device health. We'll continue to think about it, anyway.
• You can control the maximum buffer size for each player, as demonstrated here. If you have multiple videos visible at once I'd hope they're not particularly high resolution, in which case you can probably use a significantly smaller limit per instance.

[SemaphoreMetaphor]

@ojw28 Is there a way I can force it to update the playlist without having to re prepare the player?

[ojw28]

Not currently. Preparing the player again is pretty cheap, given you're going to be discarding the buffer to jump to a different position anyway. I'd suggest for now you call stop() when the user pauses, and prepare() when the user resumes.

[SemaphoreMetaphor]

@ojw28 Thank you for all the help!

[pajatopmr]

So if I understand this bug correctly, the recommended workaround to achieve a smooth seek to live behavior (say from a button click handler) is to immediately call: stop(); prepare(); seekTo(0). Would that be correct?

[pajatopmr]

So my last question did not seem to unearth any insight. Having tried it, as near as I can tell, it does not solve the puzzle. But let me try a different question: Can someone describe how seeking works in general in ExoPlayer using a few sentences? I'll post this to StackOverflow as well since that might be a more appropriate forum than using Github issues.

[btc]

My preferred solution is:

void start() {
  if (isLive()) {
    mPlayer.seekTo(0);
  }
  new PlayerControl(mPlayer).start();
}

[ojw28]

I think this has been fixed in dev-v2, although the fixes haven't landed in release-v2 yet. In any case, fixing this issue has been rolled into the larger task of supporting seeking in HLS, which is tracked by #87. Closing this issue. Please follow #87 instead. Thanks!

[Panzenbaby]

I solved this by using
mPlayer.seekTo(C.TIME_UNSET)