Skip to content

feat(player): add visual buffer and preload progress indicator to seekbar - #378

Open
neerajlovecyber wants to merge 2 commits into
NuvioMedia:Devfrom
neerajlovecyber:feat/desktop-seekbar-buffer-indicator
Open

neerajlovecyber wants to merge 2 commits into
NuvioMedia:Devfrom
neerajlovecyber:feat/desktop-seekbar-buffer-indicator

Conversation

@neerajlovecyber

@neerajlovecyber neerajlovecyber commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds a secondary semi-transparent buffered progress line ahead of the primary playback tracker on the desktop player seekbar, providing real-time visual feedback on download health and cached stream data.

PR type

  • Reproducible bug fix
  • UI glitch/bug fix
  • Behavior bug/regression fix
  • Small maintenance only, with no UI or behavior change
  • Docs accuracy fix
  • Translation/localization only
  • Approved larger or directional change

Why

Currently, the video player only displays the active playhead position on the seekbar without indicating how much media data has been buffered or cached ahead by the demuxer. Users cannot tell if a stream is healthy or about to stall until playback abruptly halts. Adding a visual buffered line brings the desktop player in line with expected video player standards (e.g. YouTube, Netflix).

Desktop scope

Desktop player web controls overlay (controls.css, controls.js) and native player bridge (player_bridge.cpp, player_bridge.mm, build.gradle.kts).

Issue or approval

Fixes #320

UI / behavior impact

  • No UI change
  • No behavior change
  • UI changed only to fix a documented glitch/bug
  • Behavior changed only to fix a documented bug/regression
  • UI change has explicit maintainer approval
  • Behavior change has explicit maintainer approval

Policy check

  • I have read and understood CONTRIBUTING.md.
  • This PR is small, focused, and limited to one problem.
  • This PR is scoped to the desktop app, desktop packaging, desktop documentation, or shared code required for desktop behavior.
  • This PR is not cosmetic-only.
  • Any UI change fixes a linked glitch/bug and includes visual proof, or this PR has no UI change.
  • Any behavior change fixes a linked bug/regression or has explicit approval, or this PR has no behavior change.
  • This PR does not bundle unrelated refactors, cleanups, formatting, or drive-by changes.
  • This PR does not add dependencies, architecture changes, migrations, or product-direction changes without explicit approval.
  • I listed the testing performed below.

Scope boundaries

Only introduces the buffered duration property to the native player periodic update loop and renders the secondary --buffered bar in the seekbar gradient CSS. Does not modify playback engines, seeking algorithms, or non-desktop components.

Testing

  • Built and compiled native bridge on Windows with .\gradlew.bat :composeApp:buildWindowsPlayerBridge.
  • Verified on Windows 11 with .\gradlew.bat :composeApp:run.
  • Verified that during streaming, a secondary semi-transparent bar extends ahead of the active playhead reflecting cached packets.
  • Verified seeking backward and forward dynamically updates both position and buffer state.

Screenshots / Video

  • Feature: Semi-transparent buffer line renders on the player seekbar between current playback position and buffered boundary.
image

Breaking changes

None.

Linked issues

Fixes #320

@kali113

kali113 commented Aug 18, 2026

Copy link
Copy Markdown

[P2] Clear bufferedMs when Kotlin chrome replaces the current media — controls.js:2779

window.playerControls always merges durationMs / positionMs from Compose and never sends bufferedMs. The new field therefore survives title/source changes:

state = { ...state, ...nextState, isPlaying: currentPlaybackState };

@neerajlovecyber

Copy link
Copy Markdown
Contributor Author

@kali113 is this ok

@quiettinkerer

Copy link
Copy Markdown
Contributor

Additionally, we can have a stats icon in the player ui, like in Stremio, for detailed stats for nerds.

@neerajlovecyber

Copy link
Copy Markdown
Contributor Author

@quiettinkerer hehe was thinking same , i Need it badly idk why but i need it

@quiettinkerer

Copy link
Copy Markdown
Contributor

Hey @neerajlovecyber, I think you should look into fetch streams for next 30-45 seconds prior end credits in series and prior 80 percent completion in movies. Switch to next stream fast af on genuine completion, depending on settings set in the video and audio preferences.

I will check this if no one is looking into it.
Current behaviour: fetches next stream on threshold set and switches immediately.
Expected: prefetch sources 30-45 seconds prior 80percent source stream completion based on preference and switch to stream upon genuine stream completion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature Request]: Visual buffer/preload indicator on the player progress bar

3 participants