Mein Problem hat sich noch nicht erledigt. Ich fasse nochmal alles zusammen was ich gemacht habe.
Fehlerbild
Seit ca. 10 Tagen nach dem Flash einer neuen DEV tritt bei mir folgender Fehler auf.
Nach dem Reboot des ESPuino und es läuft keine Musik kann ich mit dem Browser auf den ESPuino zugreifen und alles einrichten, auch Karten zuordnen und OTA-Update. Läuft schon Musik, egal ob von SD oder Webradio ist kein Zugriff mehr möglich. Manchmal bleibt der ESPuino dann auch stehen.
Bin ich schon connected und lege eine Karte auf oder starte Musik über den Browser kann ich noch einige Fuktionen , z. Bsp. Lautstärke einstellen. Der Fortschrittsbalken wird nicht mehr aktualisiert und dann bleibt der ESPuino stehen.
Im Monitor stehen Meldungen ERROR: Too many messages queued. Alles läuft dann nur noch sehr träge und machmal gibt es einen Reboot.
Ich habe dann einiges ausprobiert, zuerst natürlich auf eine funktionierende Version zurück.
Ich probiere viel aus und verwende immer die .zip Dateien und habe immer einige auch ältere auf meinem iMac. Ab und zu lösche ich dann die älteren Sachen. Egal was ich kompiliere alles hat den gleichen Fehler und das obwohl ich es ohne Full Clean gemacht habe um die Libs nicht zu aktualisieren.
Ich habe noch eine Firmware.bin von Oktober gefunden. Per OTA geflasht und es funktioniert.
Dann meine alte Hardware und eine originalen Lolin-D32-Pro versucht…ohne Erfolg.
Als nächstes mit Windows und mit meinem alten iMac probiert…ohne Erfolg.
SD-Karte neu formattiert…hilft nicht und ohne SD-Karte kompilieren auch nicht.
Reboot Fritzbox und anmelden am Gast-WLan…auch nicht.
Torsten hat mir freundlicherweise eine firmware.bin mit meinen Settings erstellt…ohne Erfolg.
Ohne meine Settings mit den originalen Einstellungen aus Github…ohne Erfolg.
Jetzt weiß ich nicht mehr weiter.Es muss einen gemeinsamen Nenner geben, den ich noch nicht gefunden habe.
Hat jemand noch eine Idee?
Die Fehlermeldung kommt vom Webserver-Socket. Darüber sendet der ESPuino Befehle an die Weboberfläche. Die Warteschlange ist relativ klein max 32 Nachrichten. Wenn die vollläuft könnte Feierabend sein (Warum eigentlich?). Jetzt neu hinzugekommen ist der Trackfortschritt. Im ersten Commit wurden noch recht viele Nachrichten gesendet, jetzt nur noch alle 250ms. Das wurde am 26.11. behoben. Wenn Du in der Weboberfläche auf Info klickst sollte Deine Sofwarerevision ein neueres Datum anzeigen. Evt. nochmal auf den neuesten Stand flashen?
Um den Fehler einzugrenzen: Wenn Du Wiedergabe gestartet hast und den Tab in der Weboberfläche wechselst vom Player weg z.B. auf RFID/Allgemein/Tools. Läuft die Queue dann noch voll? Weil Trackfortschritt wird nur gesendet wenn der Player-Tab offen ist.
Außerdem könnte man im Webbrowser mit Strg+Umschalt+I die Konsole öffnen. Dort sieht man die Nachrichten ankommen. Gibt es dort irgendwelche Fehlermeldungen?
Habe Update auf 30.11.2023 gemacht , hatte das noch nicht gesehen.
Es hat tatsächlich mit dem Tab Steuerung zu tun . Solange ich den bei laufender Musik nicht öffne scheint es normal zu laufen.
Nach Reset kann ich connecten und noch alles machen.
Läuft Musik ändert sich das.
Gehe ich auf Steuerung läuft die Musik weiter. Keine Fortschrittsanzeige mehr und manchmal Fragmente des Covers. Der connect hängt. Drehe ich am Rotary gehen am Neopixel alle LEDs an und bleiben es auch bis zum nächsten Titel. Ich habe alle MP3 in 160 kbps und habe heute einen Ordner in 128 geändert, Fehler bleibt.
Ein neuer connect ist nicht möglich auch wenn das Musikstück zu Ende ist nicht, oder nach Taste Pause.
Die Konsole geht dann auch nicht mehr.
Anzeige im Monitor sieht bis auf ERROR: Too many messages queued normal aus.
Das erklärt aber nicht warum bei mir auch alte Versionen nicht mehr funktionieren, und das anscheinend nur bei mir. Und wieso läuft es mit einer firmware.bin vom Oktober und die aktuelle firmware.bin von @biologist nicht.
Ich hatte ja schon alle meine Versuche aufgelistet und jetzt fällt mir nichts mehr ein. Am Sonntag besuche ich einen Freund der auch Platformio benutzt . Dort werde ich es an seinem Equipment nochmal versuchen.
Das habe ich auch seit wenigen Wochen recht selten, aber immer mal wieder. Aber habe noch keine Regelmäßigkeit feststellen können, wann das kommt.
Ich habe zwar nicht so krasse Probleme wie du, aber hin und wieder verabschiedet sich einfach die wifi-Verbindung des esp. Das passiert vor allem oder sogar nur dann, wenn man über die Weboberfläche gerade darauf zugreift (hier sehe ich gewisse Überschneidungen zu deinem Problem). Da ich die Weboberfläche früher nur sehr selten benutzt habe, weiß ich nicht, ob das schon immer so war, oder ob meine wifi-hardware sich bald verabschieden wird.
Habt ihr denn eine absolut stabile wifi-Verbindung mit dem esp, insb. bei Verwendung des Webui in letzter Zeit, oder zickt der manchmal?
Leider wird die Verbindung des wifi nicht automatisch wiederhergestellt, das geht derzeit nur manuell oder per restart. Vielleicht könnte man das softwaremäßig umsetzen, dass eine verlorene wifi-Verbindung versucht wird wiederherzustellen.
Komisch ist bei dir aber definitiv, dass es auch mit den alten Versionen nicht mehr funktioniert… Ich wünsche dir viel Erfolg beim Fehlerfinden.
Ich habe meine zweite Box jetzt auch hoch gezogen auf „20231124-1-DEV“ ohne erase flash oder sonstiges. Hab kaum Probleme. Wenn ich auf Steuerung gehe, sieht man wie das Cover ruckelig lädt, aber die Box läuft weiter. Ich habe das Problem mit den „Too many messages“ nur bei manchen MP3s. Die kann ich aber auf der WebIf von Hand auch nicht starte. Da stürzt die Box sofort ab. Wenn sie aber in der Zufallswiedergabe dran kommen, werden sie komischerweise abgespielt. Dann kann bricht aber das WLAN ab. Bei mir scheint es an defekten MP3s zu liegen. Ich muss jetzt mal schaun ob ich die nochmal durch ein Programm jage. Wüsste aber leider nicht durch welches. Kann mir jmd da eins empfehlen?
Ich komme etwas später zur Party, aber ich kann hier aufklären, da ich mir die Task-Auslastung am Wochenende angesehen habe.
Die Taskauslastung funktioniert über counter: Einen globalen counter der ab dem Start hochgezählt wird und für jeden Task einen Counter, der signalisiert, wie viel Leistung dieser Task benötigt hat.
Die Prozentrechnung funktioniert, indem die Tasklaufzeit durch die Gesamtlaufzeit geteilt wird. Diese Werte werden aber nie zurückgesetzt, sind also der Durchschnitt über die gesamte Laufzeit.
Startet der ESPuino, läuft erstmal keine Musik und der mp3 task ist bei nahezu 0. Startet jetzt eine Wiedergabe, nähert er sich nur langsam seinem Momentanwert an.
Wird dann später die Wiedergabe pausiert, sinkt der Durchschnitt dementsprechend auch nur sehr langsam.
Wenn man es genau wissen will, muss man sich den globalen counter und task-counter an zwei Zeitpunkten mit festem Abstand anschauen und die Differenz bilden. So kann man z.B. nur die letzten 10s betrachten.
@SZenglein Danke für die Erklärungen, da kann man mit der Taskmessung schon mal besser umgehen. Vielleicht schafft es auch jemand das Messintervall anpassbar zu machen?
Aber auch so haben wir schon ein ungefähres Wissen über die Taskauslastung…
@compactflash Nach wilden hin- und herklicken habe ich den Fehler „Too many messages“ jetzt auch nachstellen können. Die Websocket-Echtzeitbenachrichtungen können instabil werden und damit die gesamte Box. Es gibt dazu auch zahlreiche Issues. Ich werde jetzt wie auch bei den anderen Methoden den Trackfortschritt über beides Socket und Rest-API verfügbar machen. Ein erster Test mit HTTP statt Socket-Übertragung sieht vielversprechend stabil aus…
Übrigens hat @wolle in den letzten 24 Stunden superviel gefixt & anscheinend bereits alle hier gemeldeten Probleme behoben. Auch hakelnde WAV-Dateien scheinen kein Thema mehr zu sein… Gebt ihm viele
Da klingt ja schon mal vielversprechend. Wobei ich noch sehr skeptisch bin weil es nicht erklärt warum bei mir ältere Versionen nicht mehr laufen. Im Moment sieht es so aus als würde es mit Webradio halbwegs laufen , mit SD nicht. Nach ein paar Sekunden ist Ende. Aber immer nur wenn ich schon connected bin. Neu connecten geht in beiden Fällen nicht.
Ich muss gestehen, ich habe gar nicht gewusst, dass es den /stats Endpunkt gibt. Ich habe mir die Statistiken in /info ausgegeben. Naja, dadurch weiß ich nun wenigstens, was die ganzen Zahlen bedeuten. Außerdem kann ich euch folgenden Code-Snippet
präsentieren:
Findige Frontend Freunde könnten sich nun ein Javascript Programm schreiben, welches das JSON alle paar Sekunden abfragt, die Differenz zum letzten Wert bildet und je nach Motivation die aktuelle Auslastung oder einen Graphen anzeigen.
Das wäre was für „meinen“ Manager (WPF Windows App) dann könntwe sowas gut abfragen und auch darstellen…
Wäre natürlich cool wenn das komplett im Browser laufen könnte…
@tueddy und @Wolle ihr seid die Größten alles wieder ok
nachdem ich es am Sonntag bei einem Freund mit komplett anderem Equipment versucht habe und es auch nicht funktioniert hat , hatte ich nicht mehr viel Hoffnung dass ich es noch vor Weihnachten zum laufen bringe. Vor allem weil bei mir gar nichts mehr lief und hier andere, wenn überhaupt, anscheinend nur minimale Probleme hatten.
Vielen Dank an Euch und an alle die mitgewirkt haben.
ich habe dieses Problem leider auch (Version 20231217-1-DEV, gleiches mit dem master-Branch). Mit dem veralteten Arduino1-Branch funktioniert alles ohne Probleme. Die Symptome sind wie folgt:
Solange keine Wiedergabe läuft, funktioniert das Web-Interface ohne Probleme.
Solange kein Web-Zugriff erfolgt (Browser geschlossen), ist die WLAN-Verbindung stabil, d.h.: anpingen bleibt möglich.
Tracks von der SD-Karte laufen in jedem Fall ohne Probleme durch (> 3 Minuten).
Unmittelbar mit dem ersten Web-Aufruf per Browser bricht die WLAN-Verbindung zusammen. Der /stats-Endpunkt kann manchmal abgerufen werden, manchmal funktioniert aber auch das nicht. Über die serielle Konsole kommt keine (Fehler-)meldung. Bedienung über den Rotary Controller oder RFID-Tags bleibt möglich.
PN5180 mit Deep Sleep (scheint aber irrelevant zu sein?)
Problem tritt mit und ohne Akku auf
Software/Bootlog:
I [70] Maximale Inaktivitätszeit wurde aus NVS geladen: 10 Minuten
D [89] PN5180 firmware version=4.1
D [93] RFID-Tags koennen jetzt gescannt werden...
D [121] RFID-Tags koennen jetzt gescannt werden...
N [122] Port-expander gefunden
N [125] Interrupt für Port-Expander aktiviert
I [125] Zyklus für Batteriemessung fuer Neopixel-Anzeige aus NVS geladen: 10 Minuten
I [138] Unterer Spannungslevel (Batterie) fuer Neopixel-Anzeige aus NVS geladen: 3.00V
I [139] Oberer Spannungslevel (Batterie) fuer Neopixel-Anzeige aus NVS geladen: 4.20V
I [151] Spannungslevel (Batterie) fuer Niedrig-Warnung via Neopixel aus NVS geladen: 3.40V
I [163] Spannungslevel (Batterie) fuer Kritisch-Warnung via Neopixel aus NVS geladen: 3.10V
E [166] Lautstärke vor dem letzten Shutdown wird wiederhergestellt. Dies überschreibt die Einstellung der initialen Lautstärke aus der GUI.
I [176] Initiale Lautstärke wurde aus NVS geladen: 8
I [187] Maximale Lautstärke für Lautsprecher wurde aus NVS geladen: 20
I [188] Maximale Lautstärke für Kopfhörer wurde aus NVS geladen: 3
N [198] Lautsprecher eingeschaltet
I [199] Maximale Lautstärke wurde gesetzt auf: 20
I [252] Initiale LED-Helligkeit wurde aus NVS geladen: 8
I [252] LED-Helligkeit für Nachtmodus wurde aus NVS geladen: 2
_____ ____ ____ _
| ____| / ___| | _ \ _ _ (_) _ __ ___
| _| \__ \ | |_) | | | | | | | | '_ \ / _ \
| |___ ___) | | __/ | |_| | | | | | | | | (_) |
|_____| |____/ |_| \__,_| |_| |_| |_| \___/
Rfid-controlled musicplayer
N [328] Software-revision: 20231217-1-DEV
N [329] Git-revision: 3bd6443-dirty
N [329] Arduino version: 2.0.11
N [339] ESP-IDF version: 4.4.5
N [339] Wakeup was not caused by deepsleep: 0
N [340] Versuche SD-Karte im SD_MMC-Modus (1 Bit) zu mounten...
D [350] SD card type: SDHC
N [350] SD-Kartengröße / freier Speicherplatz: 3724 MB / 3684 MB
I [361] FTP-User wurde aus NVS geladen: esp32
I [362] FTP-Passwort wurde aus NVS geladen: esp32
I [364] Hostname aus NVS geladen: espuino
N [366] SSID 0 von NVS geladen: xxx
N [561] Versuche mit WLAN 'xxx' zu verbinden...
D [645] Freier Heap-Speicher nach Setup-Routine: 109120
D [645] PSRAM: 4191947 bytes
D [645] Flash-size: 16777216 bytes
E (3086) wifi:Association refused temporarily, comeback time 1024 mSec
N [2987] Verbunden mit WLAN 'xxx' (Signalstärke: -54 dBm, Kanal: 13, MAC-Adresse: xxx)
N [2987] Aktuelle IP: 10.9.4.37
N [2999] Synchronisiere Uhrzeit via NTP...
N [3011] mDNS gestartet: http://espuino.local
N [3019] HTTP-Server gestartet.
N [5204] Datum/Uhrzeit empfangen von NTP-Server: 18.12.2023, 15:24:40
Geänderte Konfiguration gegenüber den Standardwerten:
Hallo @fox, Vielen Dank für Deinen super genauen Fehlerbericht!
Leider sind wir damit in der Ursachenfindung noch nicht weiter, ich konnte den Fehler noch nicht gut reproduzieren und bekam nur sporadisch mal einen Abbruch.
Aber das hatte ich schon bei alten Master mit Arduino1 ab und an.
Der Titel dieses Thread könnte etwas verwirren, weil:
Bricht das WLAN ab oder reagiert der Webserver nicht mehr? Das könntest Du einmal testen mit einer Karte die Webradio abspielt. Spielt sie weiter ist es wohl der Webserver (meine Vermutung). Der Webserver könnte lahmgelegt werden bei zu wenig verfügbaren Heapspeicher (Speicherleck?) oder voller Auslastung durch den Audiotask.
Was man nochmal schauen könnte ob die Websocket-Verbindung unerwartet geschlossen wird. Das wird in der Weboberfläche kurz angezeigt „Verbindung zu ESPuino verloren, Seite neu laden“. Wenn’s zu kurz ist über Strg+Umsch+I die Konsole des Browsers anzeigen lassen. Kommt dort eine Fehlermeldung?
Wenn es doch ein WLAN Abbruch ist dann würde ein neuer Build mit diesem aktivierten Flag helfen (Detailierte Logausgabe):
Habe jetzt keine weiteren Ideen wie man das noch eingrenzen könnte…
Leider muss ich mich nochmal melden. Ich habe mit der akt. DEV wieder die Probleme mit Webserver. Bei mir läuft Webradio weiter aber kein Zugriff. Bin ich schon connected kann ich noch fast alles machen , z.Bsp. auch Titel/Radiostation vor und zurück , Pause, alles jedoch ohne Cover.
Mit der DEV vom 8.12. klappt alles und da Weihnachten naht werde ich es dabei lassen und die Boxen meiner Enkel werden mit dem Stand vom 8.12. nach Kanada gehen.
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…
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:
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.
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 Ich werde das ganze weiter beobachten.
alles wieder ok
Ich werde das ganze weiter beobachten.