# Live Auto Record: a pnpm and Turborepo monorepo that records Chinese streaming platforms with ffmpeg

> Live Auto Record is a TypeScript project for automatically recording live streams from Bilibili, Douyu, Huya and Douyin, offered three ways: an Electron desktop client, a server deployment built from the same packages, and the @autorecord/manager package with per platform plugins that anyone can use to build their own recorder. The recording format defaults to fmp4 for damage resistance and live viewing.

**WhiteMinds/LiveAutoRecord** — 基于 Electron 的多平台直播自动录制软件

- Repository: https://github.com/WhiteMinds/LiveAutoRecord
- Stars: 1,009 · Forks: 108
- Language: TypeScript
- License: LGPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/whiteminds-liveautorecord

## One engine, three ways to use it

Live Auto Record is a project for automatically recording live streams across multiple platforms, and the description of the project is organised around three audiences rather than around features.

Ordinary users can use the client version directly to automatically record live streams and their bullet comments for later review. Professional users can use a server deployment to record offline automatically. And developers can extend the set of supported streaming platforms through the plugin system, or build their own software on top of the @autorecord/manager package and the already implemented platform plugins.

That structure is the most important thing about the project. The client and the server are not two products, they are two front ends over the same packages, and the manager package is the part that has no UI at all. Everything else follows from that.

The primary language is TypeScript, the licence is LGPL-3.0, and the topic tags name the stack and the platforms: electron, ffmpeg, typescript, vue, bilibili, douyin, douyu and huya. The recent releases are v4.11.0 and v4.10.0 on 2026-02-16, plus a separate @autorecord/manager at 1.3.0 on the same day, which is the clearest possible signal that the packages are versioned independently of the application.

The repository is not archived, and the last push was on 2026-05-14. The README also links an old versions branch, the 3.x tree, which tells you the 4.x line is a rewrite rather than an increment.

The build stack is listed in the Built With badges and it is a modern one: pnpm, Turborepo, TypeScript, Vite, Vue, Tailwind CSS, Electron, FFmpeg and Express. The top level listing confirms the monorepo shape, with apps/ for the applications, packages/ for the publishable packages, turbo.json for the task runner, pnpm-workspace.yaml for the workspace definition, and a .changeset/ directory for the release workflow. There is a .husky/ directory for git hooks and a .prettierrc with a .prettierignore, and the lint-staged configuration formats js, ts, jsx, tsx, vue, json, css, scss, md and yaml files.

## What the desktop client does, and what it does not claim to do

The client section is short, and the reason it is short is that the interesting decisions have already been made elsewhere in the project.

The client is built on Electron and integrates the http-server and the web parts, with some functionality implemented natively. The native part is what you would expect: the things a browser page cannot do, which for a recorder means the filesystem, the process management for ffmpeg, and the system integration. Everything else is the same Vue and Tailwind front end that the server deployment serves.

That is the key architectural point and it is easy to miss. The Electron client is not a separate application with its own logic. It is the web interface plus a native shell, which means the two deployment modes cannot drift apart, and it is also why the project can offer a server and a desktop client from one codebase without maintaining two front ends.

The keyboard support claim is specific. It has good keyboard operation support, and it is expected to be fully operable from the keyboard alone. For a tool whose main job is a background task that you set up once and then leave alone, keyboard operability is not a nicety, it is the difference between a tool you use and a tool you configure once through a GUI and never touch again. The preview images show the record task list, the add task dialog, the recording history, a web page player with full screen, and the global recording configuration, and the record task list is the screen you live in.

The supported systems are Windows and macOS, and the Linux note is the honest kind. Since the Linux user base is smaller, there has been no attempt to compile on that system, but in theory it could be supported.

That last clause is doing useful work for a reader. It says the absence of a Linux build is a resource decision rather than a technical blocker, which is a different proposition from the code being unportable. It also means a Linux user who wants this is looking at either the server deployment or a contribution, and the roadmap does not list Linux packaging either way.

The client is distributed through the releases page, and the README links the old 3.x branch for people who are still on it, which is the polite version of saying that 4.x is a different thing and the old one is not going to receive the same attention.

One structural note from the repository listing that explains the client layout. There is an apps/electron/build/icons/256x256.png in the README, so the Electron application lives under apps/electron in the monorepo, with the icon files sitting in the build directory alongside the build output. The packages/ directory is where the publishable packages live, and the top level README.md is what the npm packages and the site share.

## The manager package, and the plugin contract it defines

The core package is @autorecord/manager, and the README describes what it implements as the model of channels and the scheduling of automatic checks.

The example is the whole API in twenty lines:

```typescript
import { createRecorderManager } from '@autorecord/manager'
import { provider as providerForDouYu } from '@autorecord/douyu-recorder'

const manager = createRecorderManager({
  providers: [providerForDouYu],
  // ... other options ...
})
manager.addRecorder({
  providerId: providerForDouYu.id,
  channelId: '74751',
  quality: 'highest',
  streamPriorities: [],
  sourcePriorities: [],
  // ... other options ...
})
manager.startCheckLoop()
```

Three things in that snippet are the contract. The manager is constructed with a list of providers, so a platform is a plugin and not a switch. A recorder is added by provider id plus a channel id, so the manager is platform agnostic. And startCheckLoop is a single call that begins the polling that discovers whether a channel has gone live.

The quality field takes the string highest, and the two priority arrays are empty in the example. Those are the parts of the contract that are worth reading closely. A recorder for the same channel can produce more than one stream, and when it does, the provider offers them and the manager needs a rule for which to take. The empty arrays are the place where that rule would go, and the fact that they are called streamPriorities and sourcePriorities suggests two axes of choice rather than one, so a provider may offer the same content from several sources at several qualities.

The known platform plugins are listed and they map to the topic tags. @autorecord/douyu-recorder, @autorecord/bilibili-recorder, @autorecord/huya-recorder and @autorecord/douyin-recorder. You add them with pnpm add @autorecord/manager or through another package manager.

And the README points out that the http-server package is itself built on @autorecord/manager and several of those plugins, and that it can be used as a reference while you develop. So the server is not a separate implementation, it is the manager plus a web front end, and it is offered as the worked example of how to build on the packages.

## Running the client and running the server

The client is an Electron application that integrates the http-server and the web parts, with some functionality implemented natively. It has good keyboard operation support, and it is expected to be fully operable from the keyboard alone.

The supported systems are Windows and macOS. The note on Linux is worth reading as written: since the Linux user base is smaller, there has been no attempt to compile on that system, but in theory it could be supported. So the desktop client is a Windows and macOS application, and a Linux user is not being served by the client.

The client development commands are:

```bash
# install dependencies
pnpm install

# dev electron (Turborepo auto-builds all dependencies)
pnpm app:dev

# build electron application for production
pnpm app:build
```

The server deployment is a longer sequence, and it separates the backend from the front end:

```shell
# 克隆本仓库
git clone git@github.com:WhiteMinds/LiveAutoRecord.git && cd LiveAutoRecord
# 安装依赖
pnpm install
# 编译所有包（Turborepo 自动处理构建顺序）
pnpm build
# 启动服务端
pnpm -F @autorecord/http-server start
# 启动前端（也可以将前端 build 后通过 nginx 等方案来访问）
pnpm -F @autorecord/web preview
```

That last line is the deployment decision stated plainly. The front end can be built and served by nginx or a similar arrangement, which means the server deployment is a two process setup rather than one binary, and the comment tells you the web package can also be built for that purpose.

The package.json makes the mechanics clearer still. The dev:server script is turbo run build with a filter for the http-server package and its dependencies, followed by starting the server in dev mode, and dev:web is simply the web package's dev script. The app:dev script does the same for the electron package, and app:build adds the electron application build on top. The filter syntax with the caret is what makes Turborepo build the dependency packages first, which is the mechanism behind the comment that Turborepo auto builds all dependencies.

The other root scripts are the standard monorepo set. build and typecheck are turbo run across everything. clean removes node_modules, lib, dist and .turbo directories. The release workflow is changesets, with changeset version and changeset publish, and release runs a build first before publishing.

The pnpm configuration has one detail that is easy to miss and that would bite anyone building this. There is an override pinning mitt to 3.0.1, and an onlyBuiltDependencies list naming electron, esbuild, ffmpeg-static and protobufjs. That list is the set of packages whose install scripts are allowed to run, and ffmpeg-static being on it is the mechanism by which the FFmpeg binary is actually fetched and made executable during install.

## The ffmpeg choice, the roadmap and the licensing question

One technical decision is documented in a way that is more useful than most, and it is in the notes section.

The software uses the fmp4 format for recording by default. The reason given is a trade-off between damage resistance and being able to watch the recording live. If you hit problems with that format you can switch to another one manually.

The reasoning is sound and worth restating, because it explains a choice that otherwise looks arbitrary. A container format that is designed to be written incrementally means a recording that is interrupted leaves a file that is still playable up to the point of interruption, and a format that is finalised on close means an interrupted recording can leave you with nothing. Live viewing is the same property: a fragmented MP4 can be served while it is still being written. The cost of that robustness is usually larger files, which is why the format is a default rather than a hard requirement.

The roadmap is short and honest about the state of the project. Improve the bullet comment player UI. Improve error handling. Deal with some of the TODOs in the code. Provide documentation. Add tests. Simplify the server deployment process. And add internationalisation.

Two of those are worth pausing on. Documentation and tests being on the roadmap for a project at version 4.11 is a statement about what the maintainers think needs work, and the internationalisation item matters more than it sounds because the platforms supported are Chinese and the interface is Chinese.

Now the licensing question, which the README does not spell out but which follows from the facts. The project is under LGPL-3.0. The client is an Electron application distributed to end users as a binary, and the packages are published to npm. The LGPL treats those two cases differently: a distributed application that links the library needs to allow relinking, whereas using the library as a service or through the plugin interface from your own code is a different arrangement. If you are planning to distribute a modified client, that distinction is the thing to check, and the LICENSE file at the repository root is where the terms are.

The practical gap in the documentation is that it does not say which of the packages carry which terms, and the repository listing does not have a separate licence file per package. The @autorecord/manager package and the platform plugins are on npm under the same organisation, so the assumption is that they share the project's terms, and that assumption is worth verifying against the package metadata before you build on them commercially.

## Conclusion

Live Auto Record fits someone who wants unattended recording of streams from Chinese platforms, either as a desktop application for their own use or as a service for a channel that broadcasts regularly. It is the wrong tool if you need a general purpose recording tool for arbitrary RTMP sources, because the platform support is a set of plugins for four specific services, and the wrong choice if you need the desktop client on Linux, since the project says it has not attempted to build on that system. Before deploying the server, read the licensing note, because the project is LGPL-3.0 and the distinction between the client and the packages matters if you redistribute it.

## FAQ

### What does Live Auto Record do and which platforms does it support?

It automatically records live streams and their bullet comments from multiple streaming platforms, with plugins provided for Douyu, Bilibili, Huya and Douyin. It is offered as an Electron desktop client for Windows and macOS, as a server deployment, and as the @autorecord/manager npm package for developers.

### How do I install Live Auto Record on the command line?

Clone the repository, run pnpm install, then pnpm build to compile all packages, then pnpm -F @autorecord/http-server start for the server and pnpm -F @autorecord/web preview for the front end, which can alternatively be built and served through nginx or a similar arrangement.

### How do I use the @autorecord/manager package?

Create a manager with createRecorderManager and a list of provider plugins, add a recorder with the provider id, a channel id, a quality and the stream and source priority arrays, then call manager.startCheckLoop to begin the automatic checks. The platform plugins are added with pnpm add, for example @autorecord/douyu-recorder.

### What recording format does Live Auto Record use and can I change it?

It uses fmp4 by default, chosen for damage resistance and for the ability to watch the recording live. If you hit problems with that format you can switch to another one manually.

## Sources

- [Issues](https://github.com/WhiteMinds/LiveAutoRecord/issues)
- [License: LGPL-3.0](https://github.com/WhiteMinds/LiveAutoRecord/blob/master/LICENSE)
- [README](https://github.com/WhiteMinds/LiveAutoRecord/blob/master/README.md)
- [Releases](https://github.com/WhiteMinds/LiveAutoRecord/releases)
- [WhiteMinds/LiveAutoRecord on GitHub](https://github.com/WhiteMinds/LiveAutoRecord)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/whiteminds-liveautorecord