Dev-Branch

Dieser PR bringt keine Neuigkeiten sondern räumt ein wenig auf,
es werden ca. 240 jetzt überflüssige Codezeilen entfernt:

Bitte Rückmeldung hier ob Alles soweit passt :wink:

2 „Gefällt mir“

Sieht gut aus und läuft erstmal ohne Auffälligkeiten. Wenn noch was auffällt melde ich mich :slight_smile: .

Update:
Gerade kam ziemlich unvermittelt eine Exception mitten im Abspielen eines Liedes:

[ 490210 ]  info        : VBR recognized, audioFileDuration is estimated
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
ERROR: Too many messages queued
E (613672) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
E (613672) task_wdt:  - async_tcp (CPU 1)
E (613672) task_wdt: Tasks currently running:
E (613672) task_wdt: CPU 0: IDLE
E (613672) task_wdt: CPU 1: IDLE
E (613672) task_wdt: Aborting.

abort() was called at PC 0x401319e8 on core 0


Backtrace: 0x400847b5:0x3ffbee5c |<-CORRUPTED

  #0  0x400847b5:0x3ffbee5c in panic_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/panic.c:408




ELF file SHA256: 4b88666cba59c608

E (11849) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0
Rebooting...

Selten was so nichtssagendes gesehen ^^. Ist bis jetzt allerdings erst einmal aufgetreten.
Lag evenutell auch daran, dass ich verschiedene Dateien auf der SD-Karte gelöscht habe, während abgespielt wurde. Konnte es nicht nochmal nachstellen. War vermutlich eher was anderes…
Kommt tatsächlich immer wieder zu komischem Verhalten wenn während dem Abspielen Dateien (eigentlich nicht vom Abspielen Betroffen) gelöscht werden…
Gute Nacht euch allen und einen guten Start in die neue Woche :slight_smile:

1 „Gefällt mir“
  1. Ich habe die WLAN-Implementierung, die dafür sorgt, dass der beste AP verwendet wird eben mal getestet: läuft :+1:. Was ich ja irgendwie gar nicht verstehe: Unten in meinem Arbeitszimmer teste ich normalerweise und da ist die Fritzbox 7490 auf dem gleich Tisch, auf dem auch der Laptop steht. Ergo: Da reden wir von vielleicht 50 cm Abstand und irgendwie so -49 dB. Da hatte ich im Upload etwa 300 kB/s rum. Ich bin dann mal ins Obergeschoss gegangen und folgerichtig hat sich der ESP32 dann mit dem besseren AP verbunden. RSSI ist hier so -65 dB rum. Ergebnis: 450 kB/s. Jetzt lasse ich gerade nochmal einen Upload mit mehreren Files laufen (ohne Neustart zwischendrin) und habe dann nur noch 250 kB/s. Also mal neu gestartet und jetzt bleibt’s bei 250 kB/s. Also das bleibt irgendwie ein Mysterium.

  2. Vor etwa zwei Jahren hat ein großes Refactoring stattgefunden. Dazu gab’s bis heute eine Warnung. Ich denke zwei Jahre sind mal genug, deswegen habe ich das eben ausgebaut.

2 „Gefällt mir“

@biologist Fein das es bei Dir läuft!

Die Unterschiede in der Uploadrate habe ich ja auch und es wurde mir so erklärt , aber irgendwie ist das auch „magic“

Also bei mir sind beide Repeater per Ethernet angebunden. FB7490 ist im EG, ein Repeater im DG und ein weitere Repeater im Keller. Wobei man den aus dem Keller nach oben eigentlich wenig bis gar nicht empfängt. Von daher geht’s eigentlich nur um den Repeater im DG.

Ich weiß nicht woran es noch liegen könnte. Trotz schlechter Signalstärke: -70 dBm erreiche ich konstant 550 KB/s beim Web-Upload und das schon ganz nett :wink:

Weil wir jetzt beim Upload alle nicht benötigten Tasks (LED, Audio & RFID) pausieren ist die Uploadrate reproduzierbar konstant & bietet auch Raum für weitere Verbesserungen. Was fehlt ist das Pausieren von MQTT - weil das läuft noch nicht in einem eigenen Task. Steht an Punkt 5 der Liste geplanter Features. @biologist Auf dieser Liste könntest Du Punkt 1 & 2 als erledigt markieren ? Sicher wird es dazu noch den einen oder anderen kleinere Bugfix geben…

Vielleicht könnte man ja auch markieren, in welchem Branch das jetzt verfügbar ist. Bei „erledigt“ würde ich erwarten, dass das auch im master drin ist.

Moin @moin,
alle geplanten Features beziehen sich auf den DEV-Branch.
Der Master erhält nur Fehlerkorrekturen aber keine neuen Funktionen. Wenn die Zeit reif ist wird die Entwicklerversion zum neuen Master.

Kannst Du wählen was Du möchtest :wink:

1 „Gefällt mir“

Dann ist das ein Missverständnis. Ich hatte den Eingangspost so verstanden, dass ein Feature zunächst im DEV-Branch getestet wird und dann in den master kommt.

Für den DEV-Branch ist die Distanz zwischen dem ESPuino und mir zu groß.

Ja, das ist an für sich auch richtig. Aber hier haben wir aktuell ich sage mal den Sonderfall, dass DEV auf Arduino2 läuft während master auf Arduino1 läuft. Da sind diverse Sachen drin, die man so nicht migrieren kann.
Wir werden mittelfristig auf Arduino2 wechseln und dann sind Master + DEV auf dem Stand. Und dann soll es so laufen, wie du vermutet hast.

Die Aussage verstehe ich nicht :slight_smile:

Erledigt.

Habe dev dazugeschrieben.

2 „Gefällt mir“

Genau diese Verhalten sehe ich bei mir auch! Daher habe ich angefangen alle SD-Karten mit Messungen zu qualifizieren, eine besonders schnelle noch zusätzlich bestellt und werde dann versuchen die Ursache herauszufinden.
Bis jetzt konnte ich auf jeden Fall einiges davon auf die SD-Karten zurückführen, ich melde mich aber in einem separaten Post sobald ich etwas schlauer bin…

Ich habe seit gestern die aktuelle DEV vom 7.6.23 installiert. Bis jetzt läuft alles sehr gut , auch der Wechsel zu einem anderen WlAN , selbst wenn man es bei laufendem Webradio abschaltet wechselt der ESP innerhalb weniger Sekunden zum nächsten vorhanden WlAN und es geht weiter. Getestet mit Fritz!box und Iphone. Super !!!
Playlist cache vermisse ich nicht, alles geht sehr schnell.
Zum Durchsatz : Ich verwende ausschließlich Samsung EVO Plus in 32 GB. Bei verschiedenen Uploads mit unterschiedlichen Dateigrößen komme ich auf etwa 400-450 kB/s bei -68dB. Das ist für mich ok, weil es bei meinen Boxen nur selten gebraucht wird.

3 „Gefällt mir“

Für den Bluetooth-Modus fehlte noch die Einstellmöglichkeit für Gerätename & Pairing-Code. Das habe ich jetzt mal nachgepflegt:

Der neue Bluetooth-Tab ist genauso wie z.B. MQTT/FTP Tab implementiert, also nur sichtbar wenn auch BLUETOOTH_ENABLE mit einkompiliert ist. Gerätename kann jetzt zur Laufzeit eingestellt werden.
Die Änderungen können hier beäugt werden:

Anregungen/Verbesserungsvorschläge gern hier…

4 „Gefällt mir“

Coole Sache!
Ich habe auf GH mal ein paar Kommentare gemacht.

Der Dev-Branch enthält jetzt einige Verbesserungen für die Weboberfläche
Außerdemgibt es eine striktere Prüfung des Hostnamens: Wenn Du „ESPuino!“ wählst kann das Probleme mit dem mDNS-Dienst geben. Vielen Dank an @SZenglein für die Arbeit!

4 „Gefällt mir“

Bzgl. Hostname fällt mir noch was ein. Ich teste hier ja immer wieder Boards und habe mir angewöhnt, die FePo-Boards „espuino-fepo“ zu nennen. Das kann man über die Access-GUI auch problemlos eintragen. Über die Mgmt-GUI jedoch nicht, da Bindestriche hier verboten sind. Das kann man bei Gelegenheit mal rausnehmen, da es völlig ok ist, einen Bindestrich im Hostname zu haben.

Der Hostname wird im Frontend hier validiert. Und jetzt beim Speichern zusätzlich im Backend. Bindestrich in der Mitte sollte funktionieren, ich checke das heute Abend.

Bindestrich in der Mitte ist explizit erlaubt, sonst aber vieles nicht mehr (_,*,:poop:,!,?,etc.) um mDNS Probleme zu vermeiden. Bindestrich an Anfang und Ende sind auch verboten :slight_smile:
Accesspoint und Management haben nun exakt die gleiche Validierung.

3 „Gefällt mir“

Gerade nochmal getestet: Mit dem aktuellen Softwarestand 20230618-1 funktioniert der Bindestrich in der Mitte des Hostnamens

Neu im Release auch: Das aktive WLAN wird in der Liste der gespeicherten Netzwerke hervorgehoben:

Aktuell gibt es noch einen Fehler den ich wohl verzapft habe. Die Einstellung „Start mit besten WLAN“ ist global, ich habe sie aber fälschlicherweise an die Netzwerkliste gehängt. Hier ist der Bugreport und hier der vorgeschlagene Fix dazu. Gern nochmal drüberschauen!

3 „Gefällt mir“