Files
Aime/docs/07-betrieb.md
T
schakal00783andClaude Opus 5 0aa6a37325 feat(system): System von der SD-Karte auf die eMMC umgezogen
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>
2026-08-03 01:07:26 +02:00

7.1 KiB
Raw Blame History

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-&lt;thema&gt;"]
    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).