Closed cannawen closed 1 year ago
Tried it a second time for the same replay, and different numbers are skipped. [ 0, 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 15, 16, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31] Missing times: 00:02, 00:13, 00:21
This seems to suggest it is a polling issue.
Fixed; it was fairly easy to add some logic to GSI parsing code to fake time events. We are handling up to 5 skipped seconds. Any more than that and it does not backfill the time. This allows user to jump through replays without queuing up a bunch of events (even though replays is not really a supported use case)
Fun side note, this is also a +1 to handling events in a depth-first fashion in our engine. If we were doing it breadth-first, the later times would overwrite the first times without triggering the first times events
If it breaks again, reverse this commit for debug logs: dc8ad963e5acaf2d1dc340b1430bdc3cdb56ab75
It appears that GSI events "skip time" sometimes
For example, our time array looks like: [ 0, 1, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 15, 16, 17, 18, 19, 20, 22, 23, 24, 25, 26, 27, 28]
With missing times: 00:06, 00:14, 00:21
Question: Is this a polling issue? We are polling twice a second, so it shouldn't hit the Nyquist sampling rate problem Is this a GSI issue? Do certain seconds just not exist for certain replays?
We could poll more frequently, or just fake the time events to run through every single second. Alternatively we could make some rule that says ... probably not great for skipping around in a replay though. That would queue up a shit load of audio events