Cannot do playback of recordings in Subtle Game

[rhoslynroebuck]

I am trying to replay a recording during Subtle Game, but I am having an issue that looks like it is something to do with the locking of the simulation box:

thread 'tokio-runtime-worker' panicked at nanover-rs\src\tracked_simulation\replay.rs:95:14:
Could not lock the scene: KeyLocked
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'tokio-runtime-worker' panicked at nanover-rs\src\services\state.rs:117:58:
called `Result::unwrap()` on an `Err` value: PoisonError { .. }

The last two lines then are continuously written out to the terminal.

In the game, the simulation box is moved and rescaled, which might be the issue (but is essential for the game). I tried removing this key from the shared state recordings, but then the server said that they were not valid NanoVer recordings.

@jbarnoud, Is there a way to get round this? E.g., can we tell the server to ignore the recorded 'scene' key or give the power to overwrite the recording to the VR client?

[jbarnoud]

I'll have a look but I am fairly busy this week. Can you send me your recording so I can reproduce the error?

On 7 August 2024 15:52:49 CEST, Rhoslyn Roebuck Williams @.***> wrote:

I am trying to replay a recording during Subtle Game, but I am having an issue that looks like it is something to do with the locking of the simulation box:

thread 'tokio-runtime-worker' panicked at nanover-rs\src\tracked_simulation\replay.rs:95:14:
Could not lock the scene: KeyLocked
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'tokio-runtime-worker' panicked at nanover-rs\src\services\state.rs:117:58:
called `Result::unwrap()` on an `Err` value: PoisonError { .. }

The last two lines then are continuously written out to the terminal.

In the game, the simulation box is moved and rescaled, which might be the thing causing this problem. I tried removing this key from the shared state recordings, but then the server said that they were not valid NanoVer recordings.

@jbarnoud, Is there a way to get round this? E.g., can we tell the server to ignore the recorded 'scene' key?

-- Reply to this email directly or view it on GitHub: https://github.com/IRL2/nanover-rs/issues/234 You are receiving this because you were mentioned.

Message ID: @.***>

[rhoslynroebuck]

Yeah this is not a good time to be asking, sorry! I can't seem to send the recording files here, so I will send them on Slack, and here is the branch where you can try it in game.

[jbarnoud]

I am not in a position to reproduce the error right now, but after looking at the code, I think the problem is that the replay tries to lock the scene to prevent the clients from moving the box, making the state inconsistent with the recording. If the scene is already locked, the replay crashes.

If my assumption is correct, then the issue should be fixed in the replay-lock-error branch. In that branch, the server emits a warning instead of crashing.

[rhoslynroebuck]

This is exactly what I want, thanks so much!

[jbarnoud]

Be careful that there is a big caveat with the branch: if the server cannot lock the scene initially, I think it does not get the lock later on. So another client may move the scene making it outbox sync with the avatars. I don't know either what would happen if the recording moves the scene while a client holds the lock.

Another solution may be for the server to steal the lock. It may be more robust but would be unexpected for a client that relies on always holding the lock.