Alles lag auf der SD (System, DB, Aufnahmen, Modelle), die verloetete eMMC lag ungenutzt daneben. SD-Karten sterben im Dauerbetrieb meist ohne Vorwarnung, und Aime schreibt bei jeder Aufnahme WAV + MP3 plus DB und Suchindex. Die eMMC meldet ihren Verschleiss: life_time 0x01, pre_eol 0x01 = unter 10 % verbraucht. Vorher vollstaendige Sicherung der SD gezogen und verifiziert (94.501 Eintraege = find / -xdev, SHA-256-Stichprobe). Drei Erkenntnisse: 1. mkfs.ext4 (e2fsprogs 1.47) setzt orphan_file, was das Incompat-Merkmal orphan_present mitbringt -- U-Boots ext4-Leser verweigert dann das Lesen. Vor dem ersten Start entfernt: tune2fs -O ^orphan_file,^metadata_csum_seed. 2. U-Boot liest boot.scr und armbianEnv.txt von der SD, solange sie steckt -- nachgewiesen, indem die SD-Konfiguration testweise wieder auf die SD-Root zeigte und das Board prompt das alte System hochfuhr. 3. Daher aime-bootsync.service: spiegelt /boot beim Start und beim Herunterfahren auf die SD. Sonst liefe ein Kernel-Update auseinander (neue Module auf der eMMC, alter Kernel von der SD). Faellt die SD aus, greift die vollstaendige eMMC-Bootkette. Ergebnis: / = mmcblk0p1 (aime-emmc), keine fehlgeschlagene Unit, dieselben fuenf Dienste aktiv wie vorher, HTTP 200, NPU v0.9.8, Suchindex 1799/1799. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
7.1 KiB
07 — Betrieb
⚠️ Dieses Repo ist privat; hier stehen LAN-Zugangsdaten. Nicht öffentlich stellen.
Zugänge
| System | Zugang |
|---|---|
| Board SSH | root@192.168.1.200 (WLAN, primär) / root@192.168.1.50 (LAN), PW 123456 |
| Web-GUI | http://192.168.1.200:3000 |
| MariaDB (auf dem Board) | DB callrec, User callrec, PW callrec123 (kein sqlite3/CLI-Client — mysql nutzen) |
| Gitea (diese Doku) | http://192.168.1.199:3000, User sascha |
| App-User auf dem Board | callrec, Code in /opt/callrec |
systemd-Einheiten
| Einheit | Scope | Aufgabe |
|---|---|---|
callrec.service |
system | Node-App (Web-GUI :3000, Aufnahme, Pipeline) |
callrec-btwatch.service |
system | BT-Headset-Auto-Connect (card-aware) |
callrec-perf.service |
system | CPU-Governor performance + A76-Pinning |
aime-usb-audio.service |
user | PipeWire-Topologie beim Boot (callmix, Loopbacks, Remap) |
aime-micgate.service |
user | LADSPA-Noise-Gate-Filter-Chain |
aime-volume-headset.service |
user | Windows-Volume → Headset-Sink (UAC2 numid=7) |
aime-headset-keys.service |
root | H390-Inline-Tasten → Lautstärke |
aime-iphone-route.service |
— | HFP-Routing-Watcher für iPhone-Anrufe. Achtung: die Unit liegt derzeit nicht unter /etc/systemd/system/, nur das Skript /opt/callrec/aime-iphone-route.sh ist da (Stand 2026-08-03, war schon vor dem eMMC-Umzug so) |
aime-bootsync.service |
system | spiegelt /boot der eMMC auf die SD-Karte (Start + Shutdown), siehe Speicher-Abschnitt |
filter-chain.service (PipeWire-Standard) |
user | MASKIERT — würde micgate doppeln |
aime-audio-out / aime-volume |
user | ES8323-Ära, disabled |
Speicher: System auf der eMMC, Bootdateien auf der SD (seit 2026-08-03)
flowchart LR
ROM["BootROM RK3588S"] --> IDB["idbloader + U-Boot<br/>(eMMC, Sektor 64 / 16384)"]
IDB --> SCR{"boot.scr + armbianEnv.txt<br/>zuerst gefunden auf:"}
SCR -->|SD-Karte| KRN["Kernel + initrd<br/>von der SD"]
KRN -->|"rootdev=UUID=3ba18bc1…"| ROOT["/ = eMMC<br/>mmcblk0p1 „aime-emmc“"]
ROOT -.->|"aime-bootsync spiegelt /boot"| KRN
| Gerät | Größe | Rolle |
|---|---|---|
mmcblk0p1 (eMMC, aime-emmc) |
58 GB, 28 GB belegt | / — System, Datenbank, Aufnahmen, Modelle |
mmcblk1p1 (SD, armbi_root) |
118 GB | boot.scr/Kernel/initrd und eine vollständige Kopie des alten Systems als Rückfallebene. Nicht eingehängt — die SD wird im Betrieb weder gelesen noch beschrieben. |
Warum die eMMC: sie ist für Dauerbetrieb gebaut (Verschleiß auslesbar: life_time 0x01,
pre_eol_info 0x01 = unter 10 % verbraucht), die SD-Karte ist der übliche Ausfallpunkt und stirbt
meist ohne Vorwarnung. Aime schreibt viel — jede Aufnahme WAV + MP3, dazu Datenbank und Suchindex.
Der Haken, den man kennen muss: U-Boot liest boot.scr und armbianEnv.txt von der SD-Karte,
solange sie steckt — nachgewiesen durch einen Neustart, bei dem eine auf die SD-Root zeigende
armbianEnv.txt das alte System hochfuhr. Der Kernel kommt also von der SD, das Root von der eMMC.
Ohne Gegenmaßnahme würde ein Kernel-Update auseinanderlaufen: neue Module auf der eMMC, alter Kernel
von der SD.
aime-bootsync.service löst das — spiegelt /boot beim Start und beim Herunterfahren auf die
SD (rsync -a --delete --exclude='*.bak*'), sodass beide Medien denselben Kernel tragen. Stirbt die
SD-Karte, findet U-Boot dort nichts mehr und nimmt die eMMC-Bootkette, die vollständig vorhanden ist.
Beide armbianEnv.txt (eMMC und SD) tragen rootdev=UUID=3ba18bc1-bb8e-4a34-9c61-18a27f2c7adf.
Auf der SD liegt daneben armbianEnv.txt.bak-vor-emmc-umzug mit der alten SD-UUID
ab30e77b-… — wer das alte System wieder booten will, kopiert die Datei zurück.
Wichtig bei einem neuen Dateisystem: mkfs.ext4 aus e2fsprogs 1.47 setzt orphan_file und
metadata_csum_seed. orphan_present ist ein Incompat-Merkmal — ein Treiber, der es nicht kennt
(U-Boots ext4-Leser), verweigert das Lesen. Vor dem ersten Start entfernen:
tune2fs -O ^orphan_file,^metadata_csum_seed /dev/mmcblk0p1 && e2fsck -fy /dev/mmcblk0p1
Wichtige Pfade auf dem Board
| Pfad | Inhalt |
|---|---|
/opt/callrec/*.js |
server / recorder / llm / diar / spk / db / bt |
/opt/callrec/web/ |
Vite-Frontend (npx vite build nach Änderungen an src/) |
/opt/callrec/aime-*.sh |
Setup-/Bridge-/Cap-Skripte |
/opt/callrec/milestones/m1-20260709/ |
Meilenstein-1-Snapshot inkl. MANIFEST.md (Rollback) |
/opt/callrec/*.bak-* |
Datei-Backups je Änderung (z. B. .bak-structsum, .bak-anchor) |
/etc/sudoers.d/callrec-cpucap |
NOPASSWD für aime-cpucap.sh (Thermal-Cap) |
Deploy-Ablauf (von Windows aus)
flowchart LR
DEV["Datei lokal ändern<br/>(pscp vom Board holen)"] --> BAK["Backup auf Board:<br/>cp X X.bak-<thema>"]
BAK --> UP["pscp hochladen"]
UP --> FE{"Frontend<br/>geändert?"}
FE -- ja --> BUILD["ssh: cd /opt/callrec/web && npx vite build"]
FE -- nein --> RESTART
BUILD --> RESTART["systemctl restart callrec"]
RESTART --> VERIFY["Verifizieren: journalctl -u callrec,<br/>GUI-Test, ggf. reanalyze-llm"]
VERIFY --> DOC["Doku + Changelog in Gitea aktualisieren"]
- Windows-Seite: PuTTY-Tools (
plink -batch -pw …,pscp) — OpenSSH-Keys sind nicht hinterlegt. - Node-Syntax vor Upload prüfen:
node --check datei.js.
Troubleshooting
| Symptom | Ursache / Fix |
|---|---|
Zeile hängt auf transcribing |
Absturz mitten in Diarization → GUI „Neu transkribieren“ (/retranscribe) |
| Summary wirkt leer nach Retranskription | GUI muss analysis_status pollen, nicht status — Analyse ist fire-and-forget |
| Board plötzlich aus | Thermik prüfen — Schutzabschaltung; Cap-Skript/Sudoers intakt? (Kap. 01) |
| Zu viele Sprecher | Audio geclippt? (Gain-Staging Kap. 02) Sonst „Analyse neu“ mit gepinnter Zahl |
| Teilnehmer ≠ Sprecher | Teilnehmer kommen aus Diarization; Namen im Sprecher-Editor vergeben |
| Kein far-end bei iPhone-Aufnahme | BT-Gerät Trusted=yes? HFP-Nodes erscheinen nur IM Anruf (Kap. 06) |
| GUI zeigt Quelle ohne Signal | .monitor-Falle — Quelle mit parecord + ffmpeg astats prüfen (Kap. 02) |
pactl load-module module-filter-chain → „No such entity“ |
Filter-Chain ist Core-Modul → Drop-in-Config nutzen (Kap. 02) |
rkllm/Whisper rc=-6 |
RAM-Contention — nicht beide NPU-resident; NPU-Lock beachten (Kap. 05) |
| Analyse „KI Fehler“ bei langen Aufnahmen | Kontext-Überlauf → Chunk-Pfad greift; bei schwachem Ergebnis „Analyse neu“ |
Offene Punkte (Stand 2026-07-16)
- Bedingter Takt-Cap (nur > 15 min Aufnahmedauer) — angeboten, nicht gebaut (~1,4× schnellere Kurzclips).
- Feinabstimmung Mikro/PC-Balance in einem echten Headset-Call.
- Glossar Phase 2: nächtlicher systemd-Timer + large-v3-Kandidaten-Vorschläge mit Bestätigung (verschoben).
- iPhone-Pfad: automatischer Aufnahme-Start + voller E2E-Test (Kap. 06).
- Qwen-1.5B als schnellerer LLM-Kandidat für Kurzclips (verschoben).
- Aufnahme #41 bleibt dauerhaft geclippt (Referenz für den Gain-Bug).