← Server Guide

Administering LymeScribe Server

Once it's installed and configured, the server mostly looks after itself. This chapter covers the handful of things you'll actually do: attach clients, understand what the queue is doing, apply updates, and read the logs when something's off.

Connecting clients

The desktop app is free on every platform and needs no license of its own to act as a client. Each machine needs two things: your server's address and an API key.

1. On the client machine, open LymeScribe and go to Settings → Server.
2. Enter the server's LAN address and port — for example 192.168.1.100:58994.
3. Paste the API key you issued for that person or device.
4. Click Test Connection, then save and connect.

Issue a separate named key per person or device from the dashboard's Keys page. It costs nothing and means you can revoke one laptop without disturbing anybody else. See Configuration for the key commands and the important caveat about what a key grants access to.

How the queue behaves

The server processes one job at a time. Submissions from every client land in a single shared queue, and the GPU works through it in order. That's a deliberate design: the model wants the whole GPU, and running two jobs concurrently would make both slower rather than either one faster.

Two things bend that order:

• Live dictation jumps the queue. Somebody dictating a paragraph shouldn't wait behind an hour-long recording, so dictation jobs go to the front — and if a batch job is already running, it is suspended, the dictation runs, and the batch job then resumes where it left off.
• Batch time estimates are therefore approximate on a busy server. A batch job that appears to stall is usually one that has been paused for a dictation job, not one that has failed.

The queue lives in memory. Restarting the server — or the machine — discards everything pending and in flight; completed work survives in the server's history archive, and clients notice the restart and recover their own state. Warn people before you reboot mid-day.

Why the first job after a quiet spell is slow

The Python environment that actually runs the model is loaded on demand. It starts up on the first request, stays warm while work keeps arriving, and shuts down once the queue has been empty for a cooldown period (45 seconds by default). That keeps an idle server from holding gigabytes of VRAM hostage all night.

The cost is that the first job after idle pays for environment activation plus loading the model — which on a large model can be tens of seconds, sometimes minutes, before any progress appears. It looks exactly like a hang and it isn't one. The client shows an "environment starting" state while this happens.

Speaker labels are batch-only

Transcribing a recording of a meeting can label who said what. Live dictation never does — speaker labeling is forced off for dictation regardless of what a client asks for, because it needs the whole recording before it can tell voices apart, which is incompatible with text appearing as you speak.

Speaker labeling also needs a valid HuggingFace token on the server and costs extra GPU memory (roughly 1–2 GB on top of the transcription model), which is why the VRAM guidance is higher than transcription alone would need.

Labels come out as Speaker 1, Speaker 2 and so on; naming them is done in the desktop app, per transcript.

The admin dashboard

Browse to http://<server>:58994/admin from any machine on the network and sign in with the admin password you set during setup. From there you can manage API keys, watch the live queue and worker status, review server-side history, check licensing, and read the log stream.

The admin password is separate from every API key. Reset it from the server machine's command line:

LymeScribe.Api admin reset-password

Updating the server

There is no auto-update feed for the server. Unlike the desktop apps, it never downloads or installs anything by itself — a transcription server for an office shouldn't restart itself mid-afternoon. When a new version is published, the dashboard shows a dismissible banner with the version and release notes; that's the whole of the automation.

1. Download the new versioned installer.
2. Run it: on Windows the MSI upgrades in place, on macOS you re-run the pkg.
3. The server restarts on the new version. Settings, license activation, and history carry through — nothing to reconfigure.

Do it outside working hours if you can, since the restart clears the queue. A server with no internet access simply never sees the banner, which is fine — update it by hand whenever suits.

Logs

The server writes a rolling daily log file, lymescribe-YYYY-MM-DD.log, into a logs/ directory in its install location — on the Mac install, /Users/Shared/LymeScribe/logs/. The dashboard also streams the log live, which is usually the faster way to watch a failing job.

Each job's entries carry the name of the API key that submitted it, so "whose job is this" is answerable from the log alone — another reason to give keys meaningful names.

When you're chasing something specific, raise Logging:MinimumLevel to Debug, reproduce, then set it back. Debug output is voluminous and the retention window is measured in days, not entries.

Troubleshooting

There's an API, if you want one

Everything the desktop apps do, they do over a documented HTTP API — submit a file, poll a job, fetch a transcript, read history — plus a real-time channel for progress and completion events. So a script, a cron job, or your own tooling can submit audio to the server without a LymeScribe app in the loop, using the same API keys.

The server publishes a machine-readable OpenAPI document at /openapi/v1.json (it needs a valid API key, like any other endpoint). If you're planning an integration and want the full contract, email webinquiry@iadev.net and we'll point you at the complete reference.

Next

• Configuration — the settings behind the behavior on this page.
• Server Guide home.
• Desktop app guide — the client side of the same system.