Chatraum sichtbar machen, Kurzwelle aus dem UKW-Chat filtern - #17
Merged
Merged
Conversation
Martin, 2026-09-29, mit Bild: "im chatroom 144 sind kurzwelleneinträge, bitte kontrolliere ob dieser chat auch wirklich den raum ändert." Zwei getrennte Dinge. **Der Raum.** Gesetzt wird er beim Login (LOGINC|...|chat_id|, bestätigt mit LOGSTAT|100|chat_id|). switchRoom() schickt dagegen "/CHAT 144" -- das steht so in der wtKST-Doku, die dieser Client selbst als "not verified live" kennzeichnet, und ist bis heute nicht nachgeprüft. Statt weiter zu glauben, wird jetzt gemessen: On4kstClient liest die chat_id aus jeder eingehenden CH|/CR|-Zeile und meldet sie als roomObserved(). Im Chatkopf steht beides nebeneinander -- welcher Raum angefordert wurde und aus welchem die Zeilen kommen. Weichen sie ab, war der Wechsel wirkungslos, und man sieht es sofort. Live zeigt es derzeit: "Raum 144 angefordert, Zeilen kommen aus Raum 2" -- Raum 2 ist der 144/432-Raum, das passt, gesetzt hat ihn das Login. **Die Kurzwelle.** Die Zeilen im Bild trugen CLU, nicht KST: sie kamen vom DX-Cluster, der weltweit alles spottet, auch 1,8 und 7 MHz. In einem UKW-Contest kann einen das nicht erreichen -- genau der Fall, den der Filter abdecken soll. Spots, deren Band der aktive Contest nicht kennt, bleiben jetzt draußen. Eine Chatzeile OHNE Frequenz bleibt (über die sagt die Frequenz nichts), ein unbekanntes Band ebenso, und unter "alle Zeilen zeigen" ist alles weiter einsehbar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Martin, 2026-09-29: "bitte kontrolliere ob dieser chat auch wirklich den raum ändert." Nein, tat er nicht: switchRoom() schickte "/CHAT 144" aus einer Doku, die dieser Client selbst als ungeprüft führt. Einen Raum setzt bei ON4KST nur das Login (LOGINC|...|chat_id|, bestätigt mit LOGSTAT|100|chat_id|). Also meldet sich der Client jetzt mit der gewünschten Raumnummer neu an. Am Prüfstand belegt: nach switchRoom(3) kommt beim Server "LOGINC|...|3|" an, die folgenden Zeilen tragen Raum 3, und roomObserved() meldet ihn. Derselbe Raum noch einmal löst KEIN zweites Login aus, sonst risse jeder Bandabgleich die Verbindung ohne Not ab. Dabei zwei Fallen: - Ein connectToHost() auf einem Socket, der gerade zumacht, wird stillschweigend verworfen -- der Socket ging brav in ConnectingState, beim Server kam aber nie etwas an. Der Neuaufbau hängt jetzt am disconnected-Signal, und abort() steht mit im verzögerten Teil. - Der PRÜFSTAND selbst war kaputt: der Mock-Server schrieb alles, was nach dem ersten CK| ankam, nur noch in einen Puffer und parste es nicht mehr. Ein zweites LOGINC sah er nie. Er hätte jeden Raumwechsel für kaputt erklärt, egal wie richtig der Code ist. Das Menü führt die Räume jetzt unter ihrer chat_id (1 = 50/70, 2 = 144/432, 3 = Mikrowelle, 4 = EME, 5 = Kurzwelle). Belegt ist davon nur die 2; ob eine andere Nummer den erwarteten Raum trifft, zeigt nach dem Wechsel der Chatkopf. Dazu eine Mitschrift für die Fehlersuche: CP_KST_MITSCHRIFT=<pfad> schreibt jede Protokollzeile roh mit. Ohne die Variable passiert nichts. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Live erlebt am 2026-09-29: nach etlichen Neustarts blieb die
Statusleiste grau und der Chat leer -- bis zum nächsten
Programmstart. Der Grund stand im Code: JEDER Login-Fehlercode außer
100 galt als endgültig ("stop hammering it"). Gedacht war das gegen
falsche Zugangsdaten, es trifft aber genauso den vorübergehenden
Fall: Sitzung noch offen, Server überlastet, Netz kurz weg. Mitten im
Contest ist ein stiller Chat schlimmer als ein Versuch alle paar
Minuten.
Welcher Code was bedeutet, ist nicht belegt (nur 100 = Erfolg), also
wird nicht geraten, sondern langsam weiterprobiert: erster neuer
Anlauf nach einer Minute, dann verdoppelnd bis zehn. Kein Hämmern,
und der Chat kommt von allein wieder, sobald der Grund weg ist.
Prüfstand mit Gegenprobe: der Mock weist den ersten Login ab, danach
muss ein neuer Anlauf anstehen; mit der alten Fassung steht keiner an
und der Test ist rot.
Dabei ein eigener Fehler im Prüfstand: allein gelaufen war er grün,
in der Reihe rot. Der neue Anlauf wird erst gestellt, wenn die
Leitung wirklich unten ist -- sofort danach zu prüfen war ein
Zeitfehler im Prüfstand, nicht im Programm. Jetzt wartet er darauf.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Martin, 2026-09-29, mit Bild: "kann nicht anklicken". Das ganze Raummenü hing an "angemeldet", und angemeldet war er gerade nicht: ON4KST war an dem Morgen schlicht nicht erreichbar (aus seiner eigenen Shell: "connectx to www.on4kst.org port 23001 failed: Operation timed out"). Gerade dann will man den Raum wählen können. Jetzt gilt die Wahl für den nächsten Anlauf -- und der wird sofort genommen. Dazu ein Eintrag "Jetzt neu verbinden" im selben Menü, ebenfalls immer anklickbar: bei einem stillen Chat muss man nicht mehr das Programm neu starten. Away / Wieder da / CQ bleiben gesperrt, solange keine Verbindung steht; die brauchen sie wirklich. Der Prüfstand für das Menü sah bisher nur nach, dass die Einträge DA sind. Genau das war die Lücke -- sie waren da und ließen sich nicht anklicken. Er prüft jetzt beides. Dazu ein Prüfstand für den Weg selbst: getrennt Raum 3 gewählt, und der Server sieht einen Login für Raum 3. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
oe5sos
added a commit
that referenced
this pull request
Sep 29, 2026
PR #17 (Chatraum, Kurzwellenfilter) ist inzwischen auf main, und dieser Zweig hatte an denselben Stellen gearbeitet -- GitHub meldete CONFLICTING und startete deshalb gar keine Prüfung. Zusammengeführt statt eine Seite wegzuwerfen: der Mock kann jetzt beides, einen Login abweisen (aus #17) und die Leitung kappen (von hier). test_on4kstprotocol läuft mit allen zwölf Fällen beider Zweige, die volle Suite mit 108/108. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Martin, 2026-09-29, mit Bild: „im chatroom 144 sind kurzwelleneinträge, bitte kontrolliere ob dieser chat auch wirklich den raum ändert."
Der Raum
Gesetzt wird er beim Login (
LOGINC|…|chat_id|, bestätigt mitLOGSTAT|100|chat_id|).switchRoom()schickt dagegen/CHAT 144— das steht so in der wtKST-Doku, die dieser Client selbst als „not verified live" kennzeichnet, und ist bis heute nicht nachgeprüft.Statt weiter zu glauben, wird jetzt gemessen: der Client liest die
chat_idaus jeder eingehendenCH|/CR|-Zeile. Im Chatkopf steht beides nebeneinander — welcher Raum angefordert wurde und aus welchem die Zeilen kommen. Weichen sie ab, war der Wechsel wirkungslos.Live zeigt es: „Raum 144 angefordert, Zeilen kommen aus Raum 2" — Raum 2 ist der 144/432-Raum, das passt; gesetzt hat ihn das Login.
Offen: ein belegter Raumwechsel bräuchte ein erneutes Login mit der gewünschten
chat_id. Belegt ist nur2 = 144/432; die übrigen IDs sind nicht bekannt und werden hier nicht geraten.Die Kurzwelle
Die Zeilen im Bild trugen
CLU, nichtKST— sie kamen vom DX-Cluster, der weltweit alles spottet, auch 1,8 und 7 MHz. Spots, deren Band der aktive Contest nicht kennt, bleiben jetzt draußen. Chatzeilen ohne Frequenz bleiben, unbekannte Bänder ebenfalls, und unter „alle Zeilen zeigen" ist alles weiter einsehbar.107/107 grün.
🤖 Generated with Claude Code