Ministral-3-3B: Architektur mistral3 steht nicht in der Liste des
rkllm-Toolkits, dazu FP8-Gewichte -- nie konvertiert. Config auf Llama
umbiegen waere moeglich gewesen, aber ein falsch eingelesenes Modell
haette plausiblen Unsinn produziert.
Phi-4-mini: konvertiert (5,06 GB), laedt aber nicht auf der NPU.
partial_rotary_factor 0.75 ergibt 48 LongRoPE-Faktoren, die Runtime
erwartet starr head_dim/2 = 64. Rockchips "Phi3" meint Phi-3-mini.
SmolLM3-3B: laeuft, in 2 von 3 Faellen schneller als Qwen3, scheitert
aber inhaltlich -- 13 statt 61 Todos, JSON-Schluessel als
Listeneintraege, Englisch-Drift im deutschen Text.
rkllm_server.cpp: Chat-Template kommt jetzt aus der Umgebung
(RKLLM_TMPL_SYSTEM / _USER_PRE / _USER_POST), Defaults = bisheriges
ChatML-Verhalten, mit Qwen3 gegengeprueft. Damit ist der naechste
Kandidat eine Drop-in-Zeile statt einer Neuuebersetzung.
Doku: Changelog 2026-09-29 (4) mit Messwerten und allen Fallstricken,
Kapitel 05 um Architektur-Vorpruefung und Template-Konfiguration
erweitert. Messstrecke: Zeitlimit 45 -> 90 Minuten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017A91sWU5aWrqZ2DWNTLVph
Qwen3.5-4B ist auf der RK3588-NPU 21-45% langsamer und haelt die
JSON-Vorgabe nicht durch: von 61 extrahierten Todos ueber drei
Gespraeche blieben 2 uebrig, dazu 13 Parse-Fehler mit Wiederholungen.
Die Prosa war nicht schlechter, teils genauer -- ausschlaggebend ist
die Formatdisziplin. Modell-Drop-in zurueckgesetzt, Originalanalysen
per restore wiederhergestellt.
rkllm_server.cpp: neuer Schalter RKLLM_SUPPRESS_THINK=1 haengt einen
leeren Denkblock an das Chat-Template. Ohne ihn antwortet Qwen3.5 mit
Gedankengang statt JSON; RKLLMInput.enable_thinking reicht dafuer
nicht. Ohne die Variable bleibt das Template unveraendert.
Doku: Changelog 2026-09-29 (3) mit Messwerten, Bewertung und der
Einschaetzung zu rknn-llm v1.3.1 (fuer uns wirkungslos, weil wir
keep_history=0 fahren), plus Kapitel 05.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017A91sWU5aWrqZ2DWNTLVph
lab/ab-llm.mjs vergleicht zwei LLMs ueber reanalyze-llm (ohne
Neu-Diarisierung), mit snapshot/restore der Originalanalysen und einem
Report aus Tabelle plus Volltext-Vergleich.
tools/rkllm-qwen35/ konvertiert Qwen3.5-4B auf dem PC mit
rkllm-toolkit 1.3.0 (muss zur Board-Runtime passen), Parameter
identisch zum produktiven Modell: w8a8_g128, 3 NPU-Kerne,
max_context 16384.
Doku: Changelog 2026-09-29 (2) mit Recherchestand, Sicherung und
GOTCHAs, plus neuer Abschnitt "Modellwechsel und A/B-Tests" in
Kapitel 05 samt Mermaid-Ablauf.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Neuer Helfer recStamp(r) formatiert created_at als
"Di., 29.09.2026, 14:23 Uhr" und zeigt die Zeile in der .status-line
vor der Analysezeit. Wer aus der Inhaltssuche, einem Projekt-Pin oder
per Direktlink in die Detailansicht springt, hat in der linken Liste
keine markierte Zeile und sah den Aufnahmezeitpunkt bisher nirgends.
Keine Server-/DB-Änderung: /api/recordings/:id liefert created_at
bereits mit. Doku: Changelog 2026-09-29 + Notiz in Kapitel 03.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Wartetext bei status=transcribing lautet jetzt nur noch
"Transkription läuft… lange Aufnahmen dauern." Der Klammerzusatz
"(A76-Takt gegen Überhitzung gedrosselt)" ist auf Wunsch des Nutzers
weg; das Takt-Cap selbst bleibt unverändert aktiv.
Doku: Changelog-Eintrag 2026-09-09 + Notiz im Zustandsmodell (Kap. 03),
inklusive Build-GOTCHA (dist/assets gehörte root -> vite EACCES).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Unit startet Node als User=callrec (uid 1000) und konnte darum keinen
privilegierten Port binden - daher bisher :3000. Mit
AmbientCapabilities=CAP_NET_BIND_SERVICE bindet der unprivilegierte Prozess
jetzt Port 80 direkt, ohne Reverse-Proxy (nginx haette 20-40 MB RAM gekostet,
die neben dem residenten rkllm nicht frei sind). Kein Code-Eingriff noetig:
server.js liest process.env.PORT, das Frontend nutzt relative API-Pfade.
:3000 ist bewusst tot, alte Lesezeichen muessen angepasst werden.
Dazu: Doku-IPs auf aime.local/192.168.1.48 korrigiert (192.168.1.200 war
veraltet) und die Geisteranzeige-Diagnose vom 26.08. in Kapitel 03 + Changelog
festgehalten (verwaister Browser-Reiter zaehlt ewig weiter, fmt() ohne Stunden).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
POST /api/record/stop wartete auf den kompletten loudnorm-Encode: gemessen
~1,4 s pro aufgenommener Minute (#114: 35,5 min -> 50,9 s). Sichtbar war
davon nichts als ein ausgegrauter Knopf; der Reiterwechsel baute den Knopf
per render() wieder klickbar auf und der zweite Klick lief in
"not recording", weil stopAndSave() current sofort auf null setzt.
- recorder.js: encodeMp3() ohne await, schreibt <name>.mp3.part und
benennt erst danach um. MP3_ARGS + "-f mp3" (ffmpeg leitet den Muxer aus
der Endung ab und scheitert an .part).
- web/src/main.js: state.stopping ueberlebt render() -> Knopf bleibt
gesperrt, Uhr friert ein, Toast mit geschaetzter Wartezeit, zweiter Klick
verworfen, "not recording" kein roter Fehler. Player laedt nach, solange
/media 404 liefert (#mp3wait, 5-s-Retry, Abbruch nach 5 min).
- server.js: sweepOrphans erkennt rec_*.mp3.part.
Gegenprobe: 0,033 s / 0,044 s Stop-Antwort, "mp3 fertig" ~2 s spaeter,
64 kbit CBR / 48 kHz / mono ohne Xing-Tabelle, /media 200.
Doku: Kapitel 03 (neuer Abschnitt + Vorher/Nachher-Sequenzdiagramm),
Changelog 2026-08-20.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Pin-Zeilen in der Ordneransicht sind draggable, die Reiter sind Ablageziele.
Ein Drop schickt PATCH /api/projects/:id/pins/:pinId {tab_id}; movePin schreibt
project_pins.tab_id um. Verschoben wird nur die Referenz.
- Zielebene hat die Aufnahme schon: Quell-Pin loeschen statt an UNIQUE uniq_pin
scheitern (merged:true)
- Zielreiter serverseitig gegen den Ordner pruefen, sonst 404
- .ptab-n braucht pointer-events:none, sonst flackert die Ablagemarkierung
Verifiziert gegen die laufende App inkl. 404- und Merge-Faellen; Testdaten
zurueckgesetzt. Doku: Kapitel 10 + Changelog.
Die GUI hielt `recording`/`recStart`/`markers` nur im Browser-State und fragte
den Server nie danach. Nach jedem F5 stand der Recorder auf 00:00, obwohl
parecord weiterlief — und das Kopfband malte den Start- statt des Stop-Knopfes,
die laufende Aufnahme war aus der GUI also nicht mehr beendbar.
`rehydrateRecording()` liest nach dem ersten render() `GET /api/health` und
stellt Laufzeit, Namensmarker und Live-Karte wieder her; Fehler bleiben still.
Nebeneffekt: ein zweites Gerät sieht die laufende Aufnahme ebenfalls.
Doku: Kapitel 03 neuer Abschnitt + /api/health in der Endpunkt-Tabelle,
Changelog-Eintrag 2026-08-10.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Die Identitaet war der NAME. Derselbe Mensch, einmal "Sascha" und einmal
"Sascha Wolf" benannt, existierte zweimal und konnte zwei Cluster benennen
-- Aufnahme #101 (34 s, zwei Menschen) zeigte Michael/Sascha/Sprecher 3/
Sascha Wolf. Der Vornamens-Trick in diar.js hat das ueberdeckt, setzte aber
auch "Markus Ufer" und "Markus Witsch" gleich (Kosinus 0,241).
Neu: persons + person_names (Name = PK, gehoert genau einer Person),
voiceprints.person_id. Mehrere Proben pro Person (max. 8) statt eines
laufenden Mittels; bewertet wird die beste Probe. Score UND Abstand rechnen
zwischen Personen -- vorher rissen zwei Abdruecke desselben Menschen (0,928)
die Abstandspruefung, womit die Zwangsbedingung faktisch aus war.
diar.identityKey bildet Marker-Namen und Abdruecke auf p<person_id> ab.
GUI "Stimmen" zeigt Personen mit Namens-Chips: Namen hinzufuegen/entfernen,
Personen zusammenfuehren, Proben verwerfen.
Altbestand geleert (Dump in backup/), weil lab/vpcos.mjs neben echten
Dubletten (Jens ~ Jens Kuppler = 1,000) auch kontaminierte Abdruecke zeigte:
Johannes lag mit 0,912 an Sascha Wolf, aber 0,115 an Johannes Jeckel.
Verifiziert an #101: Sascha Wolf als zweiter Name derselben Person ->
Re-Diarisierung benennt nur noch Michael + Sascha statt drei Namen fuer zwei
Menschen. GUI mit Playwright geprueft, keine JS-Fehler.
rkllm_server braucht 6,5 GB von 7,74 GB. Blieb daneben ein anderer
Dauerhelfer resident, wurde rkllm beim Laden OOM-getoetet -- bei #101 in
allen 5 Startversuchen, weil das Retry nichts freigab. Ausloeser war der
warme CT2-Whisper-Daemon, den die 2-Sekunden-Aufnahme davor gestartet
hatte. Zweiter Fall: rkllm blieb nach der Analyse fuer immer resident, und
der Suchindex startete e5-small daneben.
gate.js bekommt eine Freigabe-Registry (registerReleaser/freeRam/
killAndWait, verdrahtet in server.js wie setProbe). Vor jedem rkllm-Versuch
und vor dem NPU-Whisper-Lauf werden die anderen Helfer beendet und ihr
Prozessende abgewartet; analyzeRecording gibt rkllm vor dem Suchindex frei.
Alle Helfer starten faul neu.
Verifiziert mit der Abfolge, die scheiterte: 12-s-Clip (CT2-Daemon
resident) -> Analyse #101 laeuft durch (221 s, done), rkllm lud in 22 s,
kein OOM, danach 5,3 GB frei statt 100 MB.
Der sherpa-Diarisierungslauf brauchte RAM quadratisch zur Gesprächslänge
(gemessen 349 MB bei 10 min, 1389 MB bei 20 min, 2643 MB bei 30 min). Die
54-min-Aufnahme #99 riss 5,4 GB, wurde OOM-getötet und nahm wegen
OOMPolicy=stop die ganze App mit — in der GUI "Transkription fehlgeschlagen"
und "failed to fetch".
Die v2-Pipeline verwirft sherpas Labels und nutzt nur die Turn-Grenzen, also
laeuft der Pass jetzt in 600-s-Abschnitten (je +-5 s Kontext) und die Grenzen
werden mit Zeit-Offset zusammengesetzt. Zusätzlich OOMPolicy=continue, damit
ein OOM-getöteter Helfer die App nicht mehr stoppt.
Verifiziert an #99: sherpa-Spitze 363 MB, 726 Turns, 8 Sprecher, Analyse
vollstaendig (done/done).
Aufgefallen beim Nachsehen, warum die GUI bei 29:32 Audio 2h34min Analysezeit zeigte.
1. Ein systemctl restart SIGKILLt alle Kindprozesse, die DB-Zeile blieb aber auf
analysis_status=pending mit gesetztem analysis_started_at. Die GUI zaehlte dadurch
ewig hoch fuer Arbeit, die es nicht mehr gab. db.failStaleJobs() setzt beim Start
pending/transcribing auf error - zum Startzeitpunkt kann kein Job legitim laufen.
2. /api/search/answer lud rkllm und gab es nie frei: 1h48min lang 82,6% RAM belegt,
nur 237 MB verfuegbar. Genau der Zustand, den analyzeRecording und rediarize mit
llm.stopServer() bewusst vermeiden, weil der TitaNet-Helfer daneben an OOM stirbt
(auf #71 seinerzeit 48 Rohsprecher). stopServer() jetzt im finally der Route.
Die Section-Zusammenfassung kommt als "Titel:\nFliesstext"-Bloecke zurueck, wurde aber
als flache Textwand gerendert. renderSummary() setzt Titelzeilen jetzt fett.
Im Renderer statt in der DB, damit es sofort fuer alle vorhandenen Zusammenfassungen
gilt, ohne 22 Aufnahmen je 20 Minuten neu zu analysieren.
Regel /^[^.!?]{3,90}:$/ = kurze, alleinstehende Zeile mit Doppelpunkt am Ende. Gegen
die echten Zusammenfassungen #85/#79/#74 geprueft: 37 Titel erkannt, keine
Fliesstextzeile falsch fett, keine Doppelpunkt-Zeile uebersehen.
Drei vom Nutzer angeforderte Funktionen.
Titel umbenennen: PATCH /api/recordings/:id/title. Neue Spalte recordings.title_locked,
damit eine spaetere KI-Analyse einen von Hand gesetzten Titel nicht wieder ueberschreibt.
Papierkorb: DELETE setzt nur noch deleted_at, nichts wird angefasst. Wiederherstellen,
endgueltig loeschen, Aufraeumlauf beim Boot und taeglich (Boot-Lauf, weil das Board oft
tagelang aus ist). Behebt nebenbei einen Altfehler: das bisherige Loeschen liess die
words-Zeilen verwaist in der DB und die WAV/MP3-Dateien auf der Karte zurueck.
Inhaltssuche: neue Tabelle passages (1689 Zeilen aus 22 Aufnahmen) mit Sprecher und
Zeitfenster je Passage. Trefferliste kommt aus SQL in Millisekunden, die formulierte
Antwort mit Belegen [1][2] wird nachgereicht (Qwen3-4B, ~140 s) - deshalb zweistufig.
Hybrid: MariaDB FULLTEXT + Passage-Embedding + Dokument-Embedding aus Titel/Zusammenfassung
(multilingual-e5-small, ONNX/CPU, taskset A55). Ohne Modell degradiert die Suche sauber
auf Volltext statt auszufallen.
Gemessene Grenzen sind dokumentiert statt geschoent: e5-small trennt auf verrauschtem
ASR-Text schwach (Kosinus-Spanne aller Passagen nur 0,8085-0,8560; eine irrelevante
Passage schlug die richtige Antwort). Dokument-Ebene und IDF-Wertung heben die richtige
Passage auf Rang 11 von 296, aber nicht in die Top-8, die das LLM liest. Naechster Hebel
waere multilingual-e5-base.
Relative Datumsangaben werden deterministisch aufgeloest, nicht vom LLM - ein falsches
Kalenderfenster waere schlimmer als gar keins.
Neu: app/search.js, app/emb.js, app/inference/embed_text.py, docs/09-suche-und-verwaltung.md
Board-Backups: .bak-search
#79 verlor einen von vier Sprechern und lieferte eine 1082-Zeichen-Zusammenfassung.
Diarisierung: ein zweiter, falsch verankerter Marker verschmolz Saschas Cluster
in Merles (Kosinus -0,727). must-link prueft jetzt die akustische Aehnlichkeit,
Anker werden nach Trefferqualitaet gewichtet, und enrolled Stimmen wirken als
cannot-link -- damit ist der Box-Besitzer immer ein eigener Sprecher.
LLM: der Whole-Pass komprimierte das erste Thema weg. Sektions-Pfad jetzt ab
9000 Zeichen, kleinere Chunks, woertlicher Kontext aus dem Vorgaenger-Chunk und
ein gezielter Pruef-Aufruf gegen ueberdehnte Einzelaussagen.
#79: 4 Sprecher, Zusammenfassung ~5300 Zeichen, 7 Themenbloecke.
Regression: #70 -> 4, #68 -> 2, #74 -> 20 Sprecher unveraendert.
SaschaandClaude Opus 5