harrisi / bookplayerweb

web frontend for BookPlayer
MIT License
0 stars 0 forks source link

Update metadata #4

Open harrisi opened 1 year ago

harrisi commented 1 year ago

Thinking about how best to update metadata to keep things in sync without sending too much data. The two extremes are

  1. Send updates for every event that changes any of the metadata (primarily time changes)
  2. Send a collection of updates at the last possible moment

(1) isn't great because it's far too many events. (2) is potentially nice since in a long session, all the previous states that don't matter won't get uploaded. If the user ends up having updates for 100 items in one session though, it can be a lot to send all at once. Also, there may be events that need to happen in a certain order. Handling (2) nicely across browsers is potentially an issue, but also it seems like it's easy enough to do some work before the tab is closed with visibilitychange.

An alternative for (1) is to periodically send events every n seconds. This is what the app does, with n=10. For (2), the alternative is to send updates on every major state change, such as changing track, moving or renaming, adding files/folders.

Are bookmarks a major event? (EDIT: yes.)

harrisi commented 1 year ago

I could also potentially send events to my server rather aggressively and then when the app closes, consolidate and send them to the bookplayer api when a heartbeat is lost.

harrisi commented 1 year ago

Also, since everything works offline, I need to queue events anyway. I should definitely start from this assumption.

harrisi commented 1 year ago

Partially fixed by eaf7d997038fdf14c007113f5de50697b83e1865

Doesn't handle name changes, movements, speed, etc.