Commit Graph
3 Commits
Author SHA1 Message Date
D4rkst3r 7e7d04378a Pause fuer YouTube -- und der Bot bleibt draussen, wenn er rausgeht
Deploy / check (push) Canceled after 0s
Deploy / deploy (push) Canceled after 0s
Zwei Befunde aus dem Betrieb.

1. Der Bot ging aus dem leeren Kanal und kam sofort wieder rein.

`stoppen()` hielt erst den Spieler an und loeschte dann aus `laufend`.
`player.stop()` meldet den Leerlauf aber SYNCHRON -- gemessen mit
@discordjs/voice 0.19: der Idle-Melder laeuft mitten in stop(), noch vor
der naechsten Zeile. Er fand den Eintrag also noch, hielt das Ende fuer
"Titel vorbei" und schaltete weiter: naechster Titel oder zurueck auf den
Heimsender. Von aussen genau das gemeldete Bild.

Jetzt wird erst geloescht, dann angehalten. Nachgestellt mit einem echten
AudioPlayer und beiden Reihenfolgen -- die Kontrolle ist dabei die alte
Reihenfolge: sie schaltet nachweislich weiter (1x), die neue nicht (0x).
Ohne diese Gegenprobe koennte der Test etwas ganz anderes messen.

2. Im YouTube-Modus fehlte die Pause.

`pausieren()` gibt es jetzt, ausdruecklich nur fuer YouTube. Ein Sender
laesst sich nicht sinnvoll anhalten: er laeuft beim Betreiber weiter,
waehrend hier die Leitung volllaeuft, und beim Fortsetzen kaeme eine
Konserve, die immer weiter hinterherhinkt. Fuer einen Sender heisst Pause
Stopp -- dafuer gibt es den Stopp-Knopf, und der Pause-Knopf graut aus.

Die verstrichene Zeit rechnet Pausen heraus, sonst liefe der
Fortschrittsbalken nach dem Fortsetzen um die Pausenlaenge voraus.
`verstrichen()` steht an EINER Stelle, die sich Discord-Tafel und Panel
teilen -- zwei Rechnungen waeren zwei Gelegenheiten, die Pause zu
vergessen.

Die Musik-Tafel bekommt eine zweite Knopfreihe: mit der Pause waeren es
sechs Knoepfe, Discord laesst fuenf je Reihe zu. Platz ist reichlich (vier
von fuenf Reihen), und die Trennung ist ohnehin sinnvoller -- oben, was
gerade klingt, unten, was mit der Liste passiert. Nachgezaehlt: 2 Reihen
ohne Liste, 4 mit.

Beim Quellenwechsel wird ausdruecklich fortgesetzt: der Spieler ueberlebt
den Wechsel, und stand er auf Pause, waere der neue Titel stumm gestartet
waehrend der Eintrag "laeuft" sagt.

Nebenbei: mein Feld-Abgleich hielt eine zweite Kopie der Feldliste von
`radioStand()` und driftete beim ersten neuen Feld prompt ab -- er meldete
`pausiert` als fehlend, obwohl die API es liefert. Er liest die Form jetzt
aus der Quelle, statt sie doppelt zu pflegen.
2026-08-28 21:46:24 +02:00
D4rkst3r e6f8e3c3c5 Beim Sender kam die Warteschlange nie dran
Deploy / check (push) Canceled after 0s
Deploy / deploy (push) Canceled after 0s
Im Betrieb gemeldet: Link eingereiht, Bot blieb beim Radio.

`ggfAnwerfen` stieg aus, sobald ueberhaupt etwas lief -- Sender wie Titel.
Der Kommentar daneben sagte "die Liste kommt dran, wenn sie dran ist", und
beim Sender war das schlicht falsch: ein Sender endet nie, es gibt also
kein Idle, das weiterschaltet. Der einzige Idle, den es gibt, ist ein
abgerissener Strom -- und der startet denselben Sender neu. Der Titel
wartete auf einen Moment, der nie kommt.

Damit war auch der Rueckweg unerreichbar: "Liste leer -> zurueck auf den
Sender" setzt voraus, dass man ueberhaupt erst vom Sender wegkommt.

Jetzt uebernimmt ein frisch eingereihter Titel sofort, wenn ein Sender
laeuft. Der Sender ist nicht verloren -- er steht als heimStation im
laufenden Eintrag und kommt zurueck, sobald die Liste leer ist. Ein
laufender YouTube-Titel wird weiterhin nicht unterbrochen.

Die Regel steckte als Bedingung mitten in der Funktion und war von aussen
weder zu lesen noch zu pruefen. Sie heisst jetzt `uebernimmtSofort()` und
laesst sich mit allen drei Eingaben durchspielen -- genau das ist gemacht:
nichts laeuft -> true, Sender laeuft -> true (war vorher false, das war der
Fehler), YouTube laeuft -> false.

Der Quellenwechsel geht jetzt ins Log. Von aussen sieht "YouTube
uebernimmt" genauso aus wie "nichts passiert", und der Unterschied ist
genau der, den es hier zu sehen gibt.

Die Musik-Tafel behauptete "kommt als Naechstes dran" -- korrigiert auf
"uebernimmt sofort".
2026-08-28 14:09:09 +02:00
D4rkst3r 2a0cb1905d Die zweite Tafel: /musik, Warteschlange, Eingabefenster
Eine eigene Nachricht statt ein paar Knoepfe mehr an der Radio-Tafel.
Discord laesst fuenf Reihen je Nachricht zu, vier davon gehoeren dort den
Sender-Menues -- fuer Ueberspringen, Einreihen, Warteschlange und Leeren
ist kein Platz, und ein Sender-Menue zu opfern hiesse, Sender aus der
Auswahl zu werfen.

Der Vorzug ist groesser als die Notloesung: /radio bleibt genau das, was
es war. Wer nie ein Video einreiht, merkt vom ganzen Umbau nichts.

Bei einem Suchbegriff wird bewusst nicht der erste Treffer genommen,
sondern die Auswahl gezeigt: "Sleeping Sun" hat drei Fassungen, und
welche gemeint war, weiss nur wer es getippt hat. Eine Adresse geht
direkt rein, eine Playlist mit allen Eintraegen auf einmal.

Die Abhaengigkeit zeigt nur in eine Richtung: radio-musik.js kennt das
Radio, das Radio kennt es nicht -- es meldet ueber beiAenderung() nur,
dass sich etwas geaendert hat. Ein gegenseitiger Import zwischen zwei
Dateien beisst beim naechsten Umbau.

Gemessen gegen echtes YouTube am 28.08.2026: Adresse landet in der Liste,
Suchbegriff liefert fuenf Treffer und reiht NICHTS ein (Liste nachweislich
unveraendert), kaputte Adresse meldet "Video unavailable" und laesst die
Liste in Ruhe. Die Tafel zeigt Dauer je Titel, Gesamtdauer, Wunschgeber
und die letzte Fehlerzeile im Klartext.

Nicht geprueft, weil es dafuer eine echte Discord-Sprachverbindung
braucht: die Darstellung waehrend etwas laeuft, und das Weiterschalten.
2026-08-28 13:39:46 +02:00