Is it possible to play a asciinema stream in the terminal?

[jfly]

I naively tried asciinema stream --remote in one terminal, and asciinema play in another. This does not work:

Start stream:

$ asciinema stream --remote
::: asciinema session started
::: Live streaming at https://asciinema.org/s/VBmX1fmymP11QURL
::: Press <ctrl+d> or type 'exit' to end
...

Attempt to watch stream:

$ asciinema play https://asciinema.org/s/VBmX1fmymP11QURL
Error: download failed: <link rel="alternate" type="application/x-asciicast" href="..."> not found in the HTML page

I'm surprised I haven't been able to find anyone requesting this feature. Is this possible?

[sts19813]

At the moment, I do not think asciinema play is the right client for a live stream URL.

play expects a finished asciicast recording, either a local file or a URL that exposes an asciicast file. The stream page is different: while the session is live, it is a web player page backed by the live streaming transport, so there is no <link rel="alternate" type="application/x-asciicast"> for play to download. That error is basically saying: I found an HTML page, but not a recording.

The supported live-viewing paths today are:

• asciinema stream -r and watch it in the browser through asciinema.org or another asciinema server
• asciinema stream -l and watch it in the browser through the local/LAN web server
• asciinema session -o demo.cast -r -l if you want to stream and also save a recording that can later be replayed with asciinema play demo.cast

So the short answer is: browser live viewing is supported; terminal playback is supported for recordings; terminal viewing of a remote live stream does not appear to be supported by asciinema play right now.

If this were added, it would probably need to be a separate watch/subscribe mode rather than reusing play, because the client would have to subscribe to the live stream events instead of downloading a static asciicast file.

[jfly]

Thanks, @sts19813! I am surprised I'm the first to ask for this.

If this were added, it would probably need to be a separate watch/subscribe mode rather than reusing play, because the client would have to subscribe to the live stream events instead of downloading a static asciicast file.

I don't totally understand your reasoning here. I understand that watching a stream is a fundamentally different thing than watching a completed recording, but it's not obvious to me that asciinema play is the wrong UX here. It would certainly help people out when they do the naive thing I tried in the OP.

[sts19813]

You are right — I overstated the UX argument. play is exactly the command a user will naturally try, and accepting a stream URL would be a sensible, friendly behavior.

The distinction I meant is implementation-level, not necessarily command-level: after recognizing a stream URL, play would need to connect to the live WebSocket consumer endpoint and run a live consumer loop, rather than download a static asciicast. That comes with live-specific behavior (no seeking/rewinding, reconnect handling, and no recording to replay once the stream ends unless the server records it), but none of that makes play <stream URL> a bad interface.

So the better answer is: it is not supported today, but it could reasonably be supported by asciinema play, perhaps by detecting /s/ URLs and switching into live mode. The current static-recording error is definitely not helpful. Thanks for pushing back on that.

[FatBoyXPC]

@sts19813 are you posting AI responses?

[sts19813]

no, no hablo muy bien ingles, solo la utilice para la traduccion, jejejeje, aunque creo si fue muy antinatural

[sts19813]

@FatBoyXPC aunque realmente soy un humano que esta detras de su mac revisanco cosas en git, como hago todos los dias.