Espuino reagiert nicht mehr

Hallo zusammen,

Ich habe immer mal wieder, aber zum Glück sehr selten, das Problem, dass der Espuino nicht mehr reagiert. Er ist wie „aus“, geht aber auch nicht mehr an. Akku ist voll. Ich muss ihn auseinander bauen um den Akku kurz von der Platine zu trennen, sonst lässt er sich nicht mehr zum Leben erwecken.

Kennt das Problem jemand ?

Vielen Dank

Ich hatte das auch schon manchmal, habe aber bisher keine Systematik feststellen können nach der ich mich auf die genauere suche machen konnte.

Hast du den master Branch installiert oder dev?

@trainbird geht mir auch so mit der Symptomatik. Ich habe die DEV drauf.

Das Problem hatte ich auch. Es trat immer auf, wenn der Akku entladen war. Ich habe die Abschaltspannung angepasst und der Fehler war weg.

Ok. Aber müsste das Problem nicht auch weg sein, wenn ich den Akku lade ? Auf was hast Du die Spannung angepasst ?

Vielen Dank

Leider hat Laden nicht geholfen. Ich musste entweder den Stecker vom Akku abziehen oder den RESET-Knopf drücken

Ah ok. Vielen Dank. Dann könnte es sein. Welche Spannung genau hast Du angepasst und auf welchen Wert ? Weißt du das noch ?

Ich hatte das Problem auch, der Resetknopf hat da auch nicht geholfen. Es gab zwar einen Neustart, der aber nicht die Peripherie neustartet und deswegen aussah, als passierte nichts und die Tasten tun dann auch nichts.

Ich konnte das Problem zum WLAN zurück verfolgen. Es trat nämlich nur in einer Wohnung mit vielen Nachbarn auf, nicht aber in einem Einfamilienhaus oder einem 4-Parteienhaus mit nur 4 sichtbaren Netzen.

Ich habe letztlich WLAN ausgeschaltet und die Tastenkombination zum Ein-/Ausschalten aktiviert. Damit passiert es nicht mehr. Der 2-jährige braucht kein WLAN und um neue Musik aufzuspielen, wird die Box zu einem „sicheren“ Standort gebracht.

Ah, guter Hinweis, bei uns wimmelt es auch vor lauter WLAN … Dann werd ich mal anhängen und logging laufen lassen :thinking:

Da bin ich mal gespannt. Bei mir geht es eigentlich mit der Anzahl der WLANs.

Vielleicht spielt auch noch die Konfiguration mit rein. Bei mir kann sich der Espuino in 4 Netze einwählen, hat also die Daten dafür gespeichert.
Außerdem ist sein eigenes WLAN, wenn er kein bekanntes findet, mit einem langen Passwort versehen.

Und das Problem war in der einen Wohnung wirklich schlimm. Im laufenden Betrieb war er irgendwann einfach tot und man konnte es auch beim Einschalten fast jedes dritte Mal hinbekommen.
Leider aber nicht bei mir zu hause, wo ich das in Ruhe debuggen könnte, sondern bei meinem Neffen zu hause, wo ich nur alle paar Monate mal für ein Wochenende bin und die Zeit dann nicht mit sowas verbringen will.

Ich bekomm es momentan einfach nicht hin, dass es wieder passiert. Mehrere Stunden problemloses abspielen…

Es sind zwei Netzwerke gespeichert und eine Menge funken hier wild herum. Ich hab auch einen repeater am laufen, also es gibt zweimal „das selbe“ Netz.

Kann es eventuell sonst mit der Spannung des Akkus zu tun haben? Also, dass es bei niedrigem Akkustand in manchen Fällen Brown outs erzeugt?
Das kann ich während USB-Logging läuft natürlich nicht testen, aber ich werd beobachten, ob das dann häufiger wird.

Meine Box ist wieder ausgestiegen. WLAN kann ich ausschließen bei mir. Kann mir jemand einen Tipp geben, welche Spannung ich hoch setzen muss damit dass ggfs. nicht mehr passiert ?!

Vielen lieben Dank

für einen Dauerversuch mit Web-Radio, um den Spannungsabfall über Zeit aufzuzeichnen, habe ich alle paar Stunden mal dieses Problem, dass die Box einfriert:

  • Radio Stream ist gestoppt
  • LED ändert sich nicht mehr
  • Tastendrücke werden ignoriert

Über WebGUI lässt sich die Box normal bedienen.
Ein WebGUI-Neustart bringt sie „zurück“.

Im Log sehe ich dann diese Einträge wiederholt
pp:1635:e[31m MP3 invalid frameheadere[0m
I [22000773] info : syncword found at pos 0e[0m
I [22000780] info : MPEG-2.5 Layer IIIe[0m
I [22000780] info : Channels: 2e[0m
I [22000791] info : SampleRate: 48000e[0m
I [22000791] info : BitsPerSample: 16e[0m
I [22000791] info : BitRate: 128000e[0m
I [22000781] info : slow stream, dropouts are possiblee[0m
I [22001277] info : mp3_decoder.cpp:1635:e[31m MP3 invalid frameheadere[0m
I [22004786] info : mp3_decoder.cpp:1749:e[31m MP3, invalid Huffman code wordse[0m
I [22004787] info : syncword found at pos 239e[0m
I [22004798] info : syncword found at pos 0e[0m
I [22004805] info : MPEG-2.5 Layer IIIe[0m
I [22004805] info : Channels: 2e[0m
I [22004806] info : SampleRate: 48000e[0m
I [22004816] info : BitsPerSample: 16e[0m
I [22004816] info : BitRate: 128000e[0m

complettes Error LOG nach Freezet (10,2 KB)

Das der Decoder mal über kaputte frames stolpert, sollte den ESPuino möglichst nicht aus der Bahn werfen. MPEG hat ja einiges an Error Concealment und Error Recovery eingebaut.

Der Use Case WebRadio ist nicht das Problem, aber die Fehlerbehandlung nur über das WebGUI schon. Meine Box hat keinen von außen zugänglichen Reset und auch noch keinen Ausschalter.

Ich sehe, dass im Master ein neuerer Decoder referenziert wird.
GitHub - schreibfaul1/ESP32-audioI2S: Play mp3 files from SD via I2S ; v3.4.2+ set time offset

Es gibt einen issue mit einem Hinweis auf ein (ähnliche?) Problem, dass in v3.4.3 gefixt wurde?

Wie komme ich hier weiter - wer hat ähnliches festgestellt und wer könnte helfen ?
Die Box muss am Mittwoch zum Enkel …

Reicht es vom Master neu zu bauen ?

Der Einzige, der da so tief drin steckt, ist @Wolle.

Ansonsten kannst du natürlich auch in der platformio.ini eine ältere SW-Version der Audiolib pinnen. Wobei man schauen muss: Es gab ja eine Umstellung, bei der die Titelposition nicht mehr in Bytes sondern in Zeit gespeichert wird. Also da musst du ggf. insgesamt auf nen älteren Stand zurück. Nur auf master wechseln behebt auf jeden Fall nix, weil der aktuell auf dem gleichen Stand ist wie dev.

Test jetzt mit Master (ist neuer als mein alter DEV branch)

Error LOG vor Freeze

I [35466980] streamtitle : Deutschlandfunk - Alles von Relevanz
I [35507622] info        : slow stream, dropouts are possiblee[0m
I [35508624] info        : slow stream, dropouts are possiblee[0m
I [35509626] info        : slow stream, dropouts are possiblee[0m
I [35509860] info        : Stream lost -> try new connectione[0m
I [35509861] info        : next URL: "https://st01.sslstream.dlf.de/dlf/01/128/mp3/stream.mp3"e[0m
I [35511236] info        : redirect to new host "https://d131.rndfnk.com/ard/dlf/01/mp3/128/stream.mp3?cid=01FBPWZ12X2XN8SDSMBZ7X0ZTT&sid=33PVVkpsuwf9CwCHIovay18IW5U&token=11rF0evokCI3oi2wiM6BbRlg16S8KiSNFjb9j6cxv...
I [35511247] info        : next URL: "https://d131.rndfnk.com/ard/dlf/01/mp3/128/stream.mp3?cid=01FBPWZ12X2XN8SDSMBZ7X0ZTT&sid=33PVVkpsuwf9CwCHIovay18IW5U&token=11rF0evokCI3oi2wiM6BbRlg16S8KiSNFjb9j6cxvzg&tvf=4IPt...
I [35511856] info        : icy-bitrate: 128000e[0m
I [35511857] bitrate     : 128000
I [35511857] info        : icy-genre:  Informatione[0m
I [35511858] info        : icy-name: Deutschlandfunke[0m
N [35511868] station     : Deutschlandfunk
I [35511869] icyurl      : http://www.deutschlandfunk.de
D [37482038] logo request

N [37482051] serve station logo: 'https://www.google.com/s2/favicons?sz=256&domain_url=http://www.deutschlandfunk.de'
D [37483206] ws[/ws][4] connect
N [37483340] serve station logo: 'https://www.google.com/s2/favicons?sz=256&domain_url=http://www.deutschlandfunk.de'

berichte dann …

Gibt’s das nicht mit http statt https? Speicherintensiv und so… (siehe FAQs).

guter Punkt. aber es gibt wohl nicht alles auf http.
würde das LOG dann anderes aussehen, wenn der Speicher nicht ausreicht und er einfriert?

Ja doch, aber ist halt eine Fehlerquelle weniger.
Aus dem Log oben kann ich auf jeden Fall keinen Fehler erkennen, aus dem ich irgendwas ableiten könnte.

mit laufendem https Stream konnte keine Datei mehr hochgeladen werden; Speicher konnte nicht alloziert werden.

Also Stream gestoppt, Playlist auf http geändert.
Der Dauertest läuft jetzt weiter mit http Streams und aktuellem Master.

Aber die Favicons der Sender werden mit dem aktuellen Master nicht mehr … geladen/angezeigt; egal ob https oder http. Beim vorherigen DEV mit ESP32-audioI2S v4.3.0 wurden die Favicons angezeigt. Weitere Änderungen kann ich nicht erinnern.

N [901200] 'http://st01.sslstream.dlf.de/dlf/01/128/mp3/stream.mp3' wird abgespielt (2 von 2)
N [901324] no cover image for webstream

Werden die Favicons der Sender bei euch in der Steuerung beim Abspielen und der Sendername unter Titel angezeigt?
@Wolle hast du eine Idee?