WLAN abbruch bei auflegen von Karte

Allgemein
41

Hallo Dirk,

ich habe es soeben getestet:

  • Beim Aufruf der ESPuino-Webseite bricht ein Webstream nach wenigen Sekunden, vermutlich dem Puffer, zusammen. Ausgabe der seriellen Konsole (Debug-Level 6):
# Anmerkung: Hier ist die Wiedergabe bereits abgebrochen
I [69829] info        : slow stream, dropouts are possible
I [70830] info        : slow stream, dropouts are possible
I [71831] info        : slow stream, dropouts are possible
I [72832] info        : slow stream, dropouts are possible
I [72925] info        : Stream lost -> try new connection
I [72926] info        : Connect to new host: "http://[...]"...
[ 72948][V][ssl_client.cpp:321] stop_ssl_socket(): Cleaning SSL connection.
I [72948] info        : buffers freed, free Heap: 66180 bytes
[ 73210][I][WiFiClient.cpp:253] connect(): select returned due to timeout 250 ms for fd 48
I [73211] info        : Request http://[...]...
N [73232] station     : 
I [73232] streamtitle : 
I [73232] icyurl      : 
N [74926] Ende der Playlist erreicht.
  • Ist die Webseite einfach nur offen, ohne eine Aktion dort auszuführen, bleibt das WLAN bestehen, eine Fehlermeldung wird nicht angezeigt (auch nicht in der Webentwickler-Konsole). Der Websocket scheint also nicht die Ursache zu sein.
  • Die Ausgabe der seriellen Konsole mit Debug-Level 6 enthält zu dem Zeitpunkt, zu dem die Webseite aufgerufen wird und das WLAN abstürzt, leider keinerlei Informationen…

Der Crash scheint im übrigen mit den gesendeten Header-Feldern zusammenzuhängen - ob mit dem Inhalt oder der Länge, kann ich leider nicht sagen. Rufe ich die ESPuino-Seite per curl ohne jegliche Header auf, dann tritt der Fehler deutlich seltener (aber trotzdem) auf. Sende ich das volle Firefox-Header-Paket mit (Beispiel s.u.), dann tritt der Fehler nahezu immer sofort auf. Getestet habe ich das mit einer while-Schleife, bis die Verbindung eben weg war:

# Fehler sehr selten bzw. relativ lange bis zum Fehler
curl 'http://espuino'
curl 'http://espuino/' -H 'Accept-Encoding: gzip, deflate'

# Fehler tritt relativ schnell bzw. häufig auf
curl 'http://espuino/' -H 'Connection: keep-alive'

# Fast immer sofort
curl 'http://espuino/' -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:120.0) Gecko/20100101 Firefox/120.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8' -H 'Accept-Language: de,en-US;q=0.7,en;q=0.3' -H 'Accept-Encoding: gzip, deflate' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Upgrade-Insecure-Requests: 1'

Da der Fehler dennoch zufallsbehaftet zu sein scheint, braucht es vermutlich eine genauere Debug-Ausgabe…

42

Ich weiß nicht, ob es die selbe Ursache ist.
Ich hatte zuletzt ein Stottern in der Mp3 Wiedergabe, wenn ich im Webinterface die Steuerungsseite offen hatte.
Jedoch nur am Rechner (Chrome), am Mobiltelefon mit dem Firefoxbrowser lief es.
Sobald man den Browsertab oder den Tab im Webinterface gewechselt hat hörte das Stottern auf.

Es lag eindeutig an dem Browsertab. Ich habe dann den ESPUINO neu gestartet. Im einem neuen Browsertab lief der ESPUINO ohne Probleme, bei dem Problemtab kam es sofort zum Stottern. Erst ein Refresh dessen hat das Problem gelöst.
Leider hatte ich den Serial-Monitor nicht laufen. Der Log im Webinterface sah wie folgt aus:

Fehler
Fehler1133×853 115 KB

Außerdem gab es permanent folgende Meldungen:
fehler2

Verwendete Software ist:

Software-revision: 20231213-1-DEV

Ich konnte es dann leider nicht direkt nachstellen, ich vermute, dass man da einige Zeit im Tab verweilen muss.

43

Im Player-Tab der Weboberfläche wird ja jetzt der Trackfortschritt angezeigt. Zunächst habe ich den Fortschritt über das Websocket gesendet (PUSH). Das hat aber genau die obigen Probleme verursacht.
Ab dem 04.12.2023 holt sich der Browser den Fortschritt einmal pro Sekunde über HTTP-GET (PULL). Das wurde vor zwei Wochen ab Version 20231204-1-DEV umgestellt. @joker Deine Fehler sehen so aus als ob sie vor der Umstellung auftraten.
Es könnte aber auch sein das es dieses Issue ist?

Wenn in der Browser-Konsole die Meldung „ws[ws] error (1002) Invalid UTF-8 in text frame“ erscheint wird das Socket nach Fehler geschlossen & über einen Timer neu geöffnet. Daher kommen die Toast-Meldungen „Verbindung unterbrochen. Bitte Seite neu laden“ und anschließend „Aktion erfolgreich ausgeführt“

Die Fehler von @fox scheinen davon unabhängig zu sein. Hier schmiert wohl der Webserver bzw. TCP-Task ab.

1 „Gefällt mir“
44

Habe jetzt mal wieder den neuesten dev-Branch (d04f652 Merge pull request #294 from freddy36/webfiledur) getestet, und siehe da: Auf einmal funktioniert alles wieder, und flüssig noch dazu. Komisch, aber mich freut’s :slight_smile: Ich werde das ganze weiter beobachten.