Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Handle concurrent splash screen connections #448

Open
vicwomg opened this issue Dec 26, 2024 · 0 comments
Open

[BUG] Handle concurrent splash screen connections #448

vicwomg opened this issue Dec 26, 2024 · 0 comments

Comments

@vicwomg
Copy link
Owner

vicwomg commented Dec 26, 2024

Describe the bug

If multiple splash screens are open, they go out of sync with one another. This results in them messing up the playback state, and often causing premature skips

To Reproduce
Steps to reproduce the behavior:

  1. Open two tabs with splash screens
  2. Play a file
  3. Skip a track
  4. Track will skip on one splash screen, but not the other

Same goes with volume changes, pause/play.

Expected behavior

Both splash screens should be mostly in sync, within a reasonable time margin of a couple of seconds

Additional context

I propose we primarily use the now_playing object for synchronization. This will also eliminate the need for much of the now_playing_command handling, as the clients just react to the server state instead of the command coming from the server.

{
    "now_playing": null,
    "now_playing_user": null,
    "now_playing_command": null,
    "up_next": null,
    "next_user": null,
    "now_playing_url": null,
    "is_paused": true,
    "transpose_value": 0,
    "volume": 0.85,
    "hash":  null
}

We can keep a local version of this object on the splash screen js. If they are not equal (I believe we can use the hash value to determine this), then execute the necessary action to synchronize them.

Examples:

  • If video is playing and nowplaying.is_paused == false, then pause the track
  • If volume does not match, then set the client volume to match
  • If video is playing and now_playing is null, then stop the video

I believe that only skip and restart would be necessary to send over now_playing_command. Of these, I think restart might be the trickiest to implement.

@vicwomg vicwomg changed the title [BUG] Handle concurrent splash screen connection states better [BUG] Handle concurrent splash screen connections Dec 28, 2024
vicwomg added a commit that referenced this issue Dec 28, 2024
Concurrent splash screens cause playback issues on one another. We can
do better with synchronizing them.

Probably not going to work miracles, the playback positions might be out
of sync by up to 1 second. And weird stuff happens when opening/closing
browsers mid-song. But at least they wont totally clobber the playback
between the two like it currently does.
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

No branches or pull requests

1 participant