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.
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…
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!
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 (_,*,,!,?,etc.) um mDNS Probleme zu vermeiden. Bindestrich an Anfang und Ende sind auch verboten
Accesspoint und Management haben nun exakt die gleiche Validierung.
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!
Das war tatsächlich eine Regression, ist also bei einer Änderung kaputt gegangen. So war es von Anfang an geplant.
Der Bugfix ist eingecheckt in 20230620-1
. „Start mit bestem WLAN“ ist jetzt global und kann unabhängig von den einzelnen Netzwerken gesetzt werden:
Ich meine diesem Mysterium auf den Grund gekommen zu sein !
Sehr ausführliches Testen und herumspielen auf vielen verschiedenen SD-Karten und Konfigurationen haben mehrere Gründe identifiziert:
- Chunk-Size beim Schreiben der SD-Karten: Je größer diese sind, desto schneller kann die SD geschrieben werden. 2er Potenzen sind zusätzlich hilfreich für die Performance
- Der Write-Buffer für Files kann manuell erhöht werden um nicht bei 4K zu limitieren
- Alignment-Probleme im Ringbuffer sorgen für erhebliche Performance-Einbusen. Da sich diese nicht zurücksetzten lassen habe ich eine neue Buffer-Lösung ausprobiert.
Habe das mal hier auf diesem Branch eingebaut und komme damit auf konstant ~550 KB/s unabhängig von meiner SD-Karte und ohne Einbrüche in der Übertragung auch bei vielen Dateien (davor war es bei mir genauso wie du es beschrieben hast).
Einzige Änderung dort ist die Web.cpp.
Falls du oder jemand anderes das mal testen will bin ich über Feedback oder mögliche Fehlerbilder dankbar … Je nach dem kann ich daraus dann einen PR erstellen.
Wenn zusätzlich noch Arduino als Komponente verwendet wird und dort entsprechende Einstellungen getroffen werden, sind sogar fast 700 KB/s möglich . Das ist aber separat zu betrachten…
Hab’s gerade im Büro WLAN getestet & es klappt wunderbar! Auf die Schnelle gemessen:
SD_MMC: 520 KB/s, mit Patch 600 KB/s
SPI: 250 KB/s, mit Patch 330 KB/s
Die Upload-Geschwindigkeit ist gleichmäßig, ich konnte keine Schwankungen oder Ausreißer feststellen.
Also ein PR dazu macht schon Sinn!
@Joe91 kannst Du sicherstellen dass die hochgeladenen Dateien binär gleich sind? Ich frage das weil es in der Vergangenheit beschädigte Uploads gab. Habe jetzt nur 1/2 Dateien geprüft - da hat es gepasst…
Ich habe mehrere Ordner binär überprüft und habe von der Logik her nichts weggelassen. Der Fall, der früher dazu geführt hat, kann durch den neuen Ablauf nicht auftreten und einen weiteren (zugegeben nur theoretischen Fall) habe ich ebenfalls verhindert.
Trotzdem kann ich nicht auschließen, dass da jetzt noch was schlummert oder mit dem Speicher was anderes schiefgehen kann.
Aber dann erstelle ich auf jeden Fall einen PR und dann kann dieser ja noch reviewed werden (und ich gehe dabei nochmal über die relevanten Stellen drüber )…
Nebenher verwede ich das so auch weiter auf meinen Systemen und vielleicht finde ich ja noch was…
Edit: PR ist erstellt…
Neues aus dem DEV-Branch:
- Der beschleuinigte Web-Upload ist jetzt verfügbar. Vielen Dank an @Joe91 für Deine Arbeit!
- Weboberfläche und Backend Trennung (Schritt 0), davon sieht man genau nix…
- Kleiner Bugfix für CMD_TELL_IP_ADDRESS: Zuvor wurde die IP vorgelesen als „192 Milliarden 168 Millionen 178 Tausend 101“
Wie ist denn die Stimming zu „Arduino als Komponente“?
Immerhin bekommt man mit dieser Methode bis 700 KB/s Uploadgeschwindigkeit, mehr freien Speicher (Ich bekomme zB. Homekit wieder an den Start) und evt. auch irgendwann WiFi/Bluetooth Koexistenz.
Die Idee wäre zunächst die Möglichkeit zur Umschaltung einzubauen (1 Zeile in platform.ini), dann kann es jeder hier selbst ausprobieren. Standardmässig aber auf jeden Fall deaktiviert.
Gern Eure Meinung dazu!
Das klingt gut.
Ich möchte es auf jeden Fall testen.
Finde die Idee, das deaktiviert vorzubereiten gut!
Allerdings sollten wir nochmal auf die settings schauen, was uns wie wichtig ist und welche Kompromisse wir dort eingehen wollen.
Gerade weil wir hier echte Inkompatibilitäten zur Hardware erzeugen können (und eventuell auch wollen)…
Ganz allgemein sollten wir uns unabhängig davon Mal Gedanken über ein Release-Management machen. Eventuell können wir bald Mal eine art Stable-Version auf dem dev -brach erzeugen, bevor z.B. die Umstellung auf die Komponente rein kommt. Das könnte zukünftig bei Fehlersuchen helfen…
Ist aber nur ein Vorschlag.
Software-revision: 20230624-1
1 Ordner mit 16 Titeln je ca. 5-6 MB fehlerfrei und konstant mit 480-500 KB/s
Super
Das sollten wir auf jeden Fall bald mal tun.
Yepp.Der Master läüft stabil & DEV meiner (unserer) Meinung nach auch. Sollte man parallel anbieten 1.0.0 & 2.0.0 .
Leider sehe ich keinen Knopf in Github um ein Realease zu erzeugen. Zu wenig Rechte oder Release deaktiviert? So stelle ich mir das vor: