[GH-ISSUE #46] Save data to files while recording in real time #35

New issue

Closed

opened 2026-02-25 20:32:20 +03:00 by kerem · 4 comments

kerem commented

2026-02-25 20:32:20 +03:00

Owner

Originally created by @cronfy on GitHub (Oct 25, 2013).
Original GitHub issue: https://github.com/asciinema/asciinema/issues/46

If one wants to record a really large screencast (kernel build, cluster deploy or just a terminal session of several days long), it would require alot of memory. There is also a risk of that asciinema process can be killed, and in this case even if it catched anything, data wil be lost.

To solve this, asciinema can save data into files in real time. Then it would be possible to recover aborted screencasts and record really long sessions. It also partially solves #21.

Originally created by @cronfy on GitHub (Oct 25, 2013). Original GitHub issue: https://github.com/asciinema/asciinema/issues/46 If one wants to record a really large screencast (kernel build, cluster deploy or just a terminal session of several days long), it would require alot of memory. There is also a risk of that asciinema process can be killed, and in this case even if it catched anything, data wil be lost. To solve this, asciinema can save data into files in real time. Then it would be possible to recover aborted screencasts and record really long sessions. It also partially solves #21.

kerem closed this issue

2026-02-25 20:32:20 +03:00

kerem commented

2026-02-25 20:32:20 +03:00

Author

Owner

@ku1ik commented on GitHub (Nov 25, 2013):

The recorded stream is just a text + some control sequnces. It's really not that much. You probably can record several hours long session and it will take at most several MBs of memory. Given we all have GBs of mem these days this isn't really an issue.

@ku1ik commented on GitHub (Nov 25, 2013): The recorded stream is just a text + some control sequnces. It's really not that much. You probably can record several hours long session and it will take at most several MBs of memory. Given we all have GBs of mem these days this isn't really an issue.

kerem commented

2026-02-25 20:32:20 +03:00

Author

Owner

@cronfy commented on GitHub (Nov 26, 2013):

Probably the more important thing I wanted to mention was that if session is killed by some reason, it is lost completely. If it would saved to tmp files, it could be recovered then.

This is very useful feature for automatically recording all sessions (as live logs of everything was done in console).

Can you please reopen the issue?

@cronfy commented on GitHub (Nov 26, 2013): Probably the more important thing I wanted to mention was that if session is killed by some reason, it is lost completely. If it would saved to tmp files, it could be recovered then. This is very useful feature for automatically recording all sessions (as live logs of everything was done in console). Can you please reopen the issue?

kerem commented

2026-02-25 20:32:20 +03:00

Author

Owner

@ku1ik commented on GitHub (Nov 26, 2013):

If it was saving to a file and the session recording was interrupted would you still upload unfinished recording? What's the value in it? I don't see anyone want to do that honestly...

@ku1ik commented on GitHub (Nov 26, 2013): If it was saving to a file and the session recording was interrupted would you still upload unfinished recording? What's the value in it? I don't see anyone want to do that honestly...

kerem commented

2026-02-25 20:32:20 +03:00

Author

Owner

@cyc115 commented on GitHub (Apr 9, 2019):

This is a long dead thread, but I for one would like to have the ability to recover accidentally closed sessions. Especially when a recording can be multi hour long and the only thing you need to to destroy the recording is a cmd+w 😄 .

@cyc115 commented on GitHub (Apr 9, 2019): This is a long dead thread, but I for one would like to have the ability to recover accidentally closed sessions. Especially when a recording can be multi hour long and the only thing you need to to destroy the recording is a `cmd+w` 😄 .

kerem referenced this issue

2026-03-15 04:28:23 +03:00

[GH-ISSUE #35] Problems with color and -c option #628