Auto-playing clip even though it was sent a long time ago #83

Open
opened 2026-03-27 17:17:00 +00:00 by talksik · 1 comment
talksik commented 2026-03-27 17:17:00 +00:00 (Migrated from github.com)

This happens if a client has stale data and receives new data. It's debatable whether this is a bad thing at all.

We could have a check in our auto-play logic to check not only whether the particle was first loaded particle (logic we currently have to avoid auto-playing on initial load), but also check the created_at time to ensure that it was just sent in the last 5 seconds.

This happens if a client has stale data and receives new data. It's debatable whether this is a bad thing at all. We could have a check in our auto-play logic to check not only whether the particle was first loaded particle (logic we currently have to avoid auto-playing on initial load), but also check the created_at time to ensure that it was just sent in the last 5 seconds.
talksik commented 2026-04-09 15:53:28 +00:00 (Migrated from github.com)

This is somewhat okay with me, because it will only ever play one of the clips that I missed.

However, it does make it feel as though the received message was just composed.

P.S. this also occurs if I am in the Closed streams tab, and then I go back to the Open streams and I missed something. This is why sending signals via websocket from a background processor would be much cleaner. Clients would receive relevant events to react to, and miss events if they are disconnected.

This is somewhat okay with me, because it will only ever play one of the clips that I missed. However, it does make it feel as though the received message was just composed. P.S. this also occurs if I am in the `Closed` streams tab, and then I go back to the `Open` streams and I missed something. This is why sending signals via websocket from a background processor would be much cleaner. Clients would receive relevant events to react to, and miss events if they are disconnected.
Sign in to join this conversation.