delete_playlist hangs Bridge (macOS 2.6.3) — reproduced on video and still

[suchanek]

delete_playlist hangs Looking Glass Bridge (macOS 2.6.3)

Summary

Calling the Bridge HTTP orchestration API's delete_playlist endpoint on a
playlist created via instance_playlist / insert_playlist_entry /
play_playlist (i.e. not Bridge's own "Studio Playlist") reliably leaves
the Bridge daemon completely unresponsive to further HTTP requests
afterward. Recovery required force-killing the process (kill -9) and
relaunching the app — a normal quit/restart from the tray icon did not
work; the process was found running with a /restart argument, suggesting
it was already stuck mid self-restart.

Environment

• Bridge version: 2.6.3
• OS: macOS (Darwin 27.0, arm64 / Apple Silicon)
• API base: http://localhost:33334
• Client: a from-scratch Python urllib client speaking the same HTTP
  orchestration API as this SDK (not bridge.js itself, but mirroring the
  same PUT + JSON request/response shape)
• Device: Looking Glass light-field (quilt) display, Portrait quilt
  preset (8×6, 3360×3360)

Reproduction

Standard cast sequence, matching this SDK's own pattern:

PUT /enter_orchestration      {"name": "default"}
PUT /show_window               {"orchestration": T, "show_window": true, "head_index": -1}
PUT /instance_playlist         {"orchestration": T, "name": "waverider", "loop": true}
PUT /insert_playlist_entry     {"orchestration": T, "name": "waverider", "index": 0,
                                 "uri": "<local file path>", "rows": 6, "cols": 8,
                                 "aspect": 0.75, "view_count": 48,
                                 "durationMS": 20000, "isRGBD": 0}
PUT /play_playlist             {"orchestration": T, "name": "waverider", "head_index": -1}

Then, to stop:

PUT /delete_playlist           {"orchestration": T, "name": "waverider", "loop": true}

(Also reproduced with "loop": false, matching this SDK's own
BridgeClient.stopStudioPlaylist() reference implementation, which calls
delete_playlist then show_window(false).)

Reproduced twice, independently:

1. Playlist held a single MP4 quilt video (~86–108 MB) mid-loop playback.
2. Playlist held a single quilt PNG still (~9.7 MB), no video involved.

Both times: the delete_playlist HTTP call itself returned normally
— 200 OK with a well-formed JSON body (status: "Completion", matching
the shape of every other successful call). The daemon became unresponsive
to all further HTTP traffic shortly after, including a bare GET / health
check (connection accepted, then times out with no response — not a
connection refusal, a hang). curl --max-time 5 http://localhost:33334/
timed out completely (000 status) on both occasions.

Since it reproduced identically on a plain still image with no video
decode involved, this doesn't look like a large-file/decode race — it
looks like delete_playlist on a non-Studio playlist puts the daemon into
a bad state regardless of payload.

Impact

Any client — ours or otherwise — that follows this SDK's own documented
"stop playback" pattern (delete_playlist → show_window(false), see
BridgeClient.deletePlaylist / stopStudioPlaylist) on a custom playlist
will hang Bridge and require a manual process kill to recover. Since
delete_playlist is the only documented stop mechanism in this SDK,
anyone implementing "stop" against this API by the book hits it.

Workaround (what we shipped downstream)

We stopped calling delete_playlist entirely. Instead, "stop" is now:

PUT /transport_control_pause   {"orchestration": T}
PUT /show_window                {"orchestration": T, "show_window": false, "head_index": -1}

This reaches the same visible end state (nothing showing, playback halted)
using only calls that have proven stable across repeated cycles, and
leaves the playlist in place so a subsequent play_playlist (or a fresh
instance_playlist + insert_playlist_entry + play_playlist) replaces
it cleanly without ever calling delete_playlist.

Questions

• Can you reproduce delete_playlist hanging Bridge 2.6.3 on macOS with a
  custom (non-Studio) playlist?
• Is there a Bridge-side log (Console.app / a log file under
  ~/Library/Logs or similar) that would show what happens internally
  when this call comes in — worth us grabbing next time it happens?
• Is delete_playlist expected to be safe on playlists created via
  instance_playlist rather than instance_studio_playlist, or is that
  combination untested/unsupported?

[alxdncn]

I've looked at and confirmed the issue. We will ship a patch fix in the next Bridge release, scheduled for sometime this month. Once that version of Bridge is out (2.7.0) I will notify you and ask you to test this again before closing.