Erweiterung der Weboberfläche

tueddy · 22. November 2021 um 23:11

@tuniii sehr gute Idée!
Damit wäre der Access-Point Modus kein Fremdkörper mehr. Das hat mich gestört das die AP-Oberfläche bisher befremdlich wirkt.
So ein paar Feinheiten machen dann die Arbeit:

Im AP-Modus müsste die Webseite auch auf diesem Karteireiter starten damit man die WLAN Daten eingeben kann
Nach erfolgreicher Verbindung muss diese Seite ausggeblendet werden, oder?

Puuh,es ging in diesem Thread ursprünglich um eine Mini-Erweiterung zum Albumbild und Ihr schiebt hier Alles rein Habe wohl einen falschen Thread-Titel gewählt
Finde es aber super das Ihr Eure Ideen hier teilt!

Christian · 23. November 2021 um 06:57

Den gibt es ja sogar schon.
Mit welchem Framework ist Deine Seite denn gebaut? Ist schick…

tuniii · 23. November 2021 um 07:24

Die Seite ist mit VUE.JS gebaut und für die Optik kommt Pure.css zum Einsatz:
Hier eine Demo: https://demo.wlanthermo.de

biologist · 24. November 2021 um 12:35

@Christian / @tueddy:
Aktuell, und schon seit einer Woche oder so, ist ein PR von @tueddy offen. Ich bin mir jetzt bissl unsicher, wie ich hier vorgehen soll, weil @Christian auch einiges umbaut.

Fragen: Wie kriegen wir das gemerged / wie ist es für euch einfacher?

tueddy · 24. November 2021 um 13:58

Hi Torsten,

von meiner Seite ist der PR fertig und könnte so übernommen werden. Die Änderungen sind ja moderat und erweitern die jetzige Funktionalität nur um einige Punkte.
Ich weiß jetzt einfach nicht was Christian da so genau macht. Einige Erweiterungen klingen interessant, eine Änderung des Protokolls sehe ich aber eher skeptisch…
Warum nicht einfach die Weboberfläche Schritt für Schritt erweitern?

biologist · 24. November 2021 um 14:15

Von meiner Seite ist das ok, da muss @Christian vielleicht nochmal was zu sagen.

Vielleicht überblicke ich es noch nicht, aber im Kern ging es doch darum, dass man den Datentransfer für den Filebrowser segmentieren will, so dass man nicht mehr so viel Speicher en bloc allokieren muss. Und hier kam (@Christian korrigiere mich, wenn ich das falsch sehe) vermutlich ins Spiel, dass die ganze Allokation mit der JSON-Lib bisschen sperrig ist. Wobei man für json ja aber nicht die Lib benutzen muss, sondern es auch „zu Fuß“ zusammenbauen kann (habe ich auch schon gemacht).

tueddy · 24. November 2021 um 21:08

Ich habe mir den Code für den FileBrowser jetzt mal genauer anschaut und muss sagen: Der ist super-duper-optimal implementiert! Schönen Dank an den Autor!
Es wird nur die aktuelle Hierache gescannt und jeweils mit JSON über Websocket transportiert. Gut zu debuggen im Browser und auch relativ schlank. Es können beliebig tiefe Verzeichnisstrukturen transportiert werden.Hier ein Beispiel wie das mit meiner SD-Karte aussieht (ca. 65 Karten/Hörspiele):

Macht 3,5KB an Daten. Ladezeit ca. 1-2 Sek., das liegt aber vermutlich an der SD-Karte (Arduino ListFiles Demo dauert auch etwas länger). Der JSON Dokumentpuffer ist mit 8KB großzügig dimensioniert.
Ich sehe hier absolut kein Problem. @Christian wie viele Dateien hast Du denn im Verzeichnis?

Wo man noch optimieren könnte ist das allokieren des JSON-Objekts. Hier gibt es statische oder dynamische Allokierung. Vielleicht dynamisch?, Warum ist diese Methode im Code auskemmentiert? Es gibt hier Dokumentation auf der Webseite der Bibliothek. Vielleicht mag sich da jemand einlesen? Die verwendete JSON Bibliothek scheint aber für uC Verwendung optimiert zu sein…

biologist · 24. November 2021 um 21:10

Bloß nicht!
Heap-Fragmentierung!

tueddy · 24. November 2021 um 21:11

DynamicJsonDocument doc(2048);

This allocation strategy reduces heap fragmentation.

Also ich verstehe das so das die dynamische Allokierung hier genau das verhindert/reduziert.

biologist · 24. November 2021 um 21:21

Beim Wrover kann man den psram nehmen, das wird auch schon gemacht glaube ich. Ansonsten habe ich das als kacke in Erinnerung und extra deswegen ausgebaut.
Trainiere gerade aufm Rad, aber das musste ich doch loswerden

tueddy · 24. November 2021 um 21:29

So lange es hier kein Problem gibt würde ich das auch 1:1 so belassen!

Christian · 24. November 2021 um 22:13

Also, da ich ja nicht so richtig aus dem Quark komme, müsst ihr nicht warten.
Der aktuelle Stand + die Erweiterung von tueddy ist ja funktionsfähig.

Vorschlag.
Ich frickel in meinem Fork weiter und dann müsste man grundsätzlich entscheiden, ob man überhaupt die Änderung in Richtung gzip im Flash und die Websocket-Verbindung übernehmen möchte. Denn dass macht es inkompatibel zum aktuellen Stand. Aufteilung in HTML / JS / CSS. Ich habe den Fehler gemacht, zu viele Features gleichzeitig zu ändern.

Wenn ja, schließen wir die Feature Lücke zum jetzigen Stand (Tueddy’s Cover hab ich z.B. schon übernommen)
Wenn nein, könnte man (wenn man möchte) Features (Kosmetik) aus meinem Fork „portieren“.

Die Entscheidung, ob man nun ein JSON oder Text-String schickt könnten wir anschließend treffen.

So ist die Idee mal entstanden: Refactoring - #38 von biologist
Und man muss ja auch kein akutes Problem lösen wenn man etwas umstellt

Exakt. Das wäre auch der Ansatz, wenn man lieber JSON anstatt von „per Trennzeichen“ möchte. Manuell Zusammenbauen. Der Aufwand hält sich in Grenzen.
Aktuell: <Command>#<item>*<Value>
JSON: {"<Command>":{"<Item>":"<Value>"}}

@tueddy findet es unsinnig- ich finde es gut - dafür gibt es Forks

tuniii · 24. November 2021 um 22:25

Man könnte das JSON noch etwas verschlanken:

{"n":"Dateiname","d":1}

Aus „name“ wird „n“, aus „dir“ wird „d“ und aus true wird 1.
Auf ein Element macht es nicht viel aus, aber auf ein größeres Array ist es dann vllt. schon spürbar.

Wie @biologist schon geschrieben hat, sollte das statisch bleiben, sodass es auf dem Stack landet. Zum einen ist es schneller und zum anderen kann es sein, dass irgendwann aufgrund von Heap-Fragmentierung keine 8k mehr am Stück frei sind. Dann funktioniert der Browser nicht mehr. Das gab es in der Vergangenheit schon mal.

Christian · 24. November 2021 um 22:38

tuniii:

tueddy:

Macht 3,5KB an Daten. Ladezeit ca. 1-2 Sek

Man könnte das JSON noch etwas verschlanken:
{"n":"Dateiname","d":1}
Aus „name“ wird „n“, aus „dir“ wird „d“ und aus true wird 1.

Ich habe es sinngemäß so verändert:

f=Dateiname

d=Verzeichnis

biologist · 24. November 2021 um 22:42

@Christian Gefällt mir sehr gut deine GUI-Anpassungen!
Ich denke das manuelle Zusammenbauen von JSON wäre doch ein guter Mittelweg. Dann hat man es einheitlich mit JSON und dennoch keinen Lib-Overhead.

Hehe, ich wusste, dass du dich daran erinnern würdest . Ja das Problem brauchen wir nicht nochmal. Die Umstellung auf 8k static war auf jeden Fall gut. Sie war halt nicht perfekt für den Fall, dass zu viele Files übertragen werden. Wobei das nur den Fall betrifft, dass wir keinen PSRAM haben. Ist PSRAM da, dann wird von diesem 64k allokiert:

github.com

biologist79/ESPuino/blob/c856cfe536907235c44ac3a289bca4f481f14d27/src/Web.cpp#L771


      
              // send signal to upload function to terminate
              xQueueSend(explorerFileUploadStatusQueue, &value, 0);
              vTaskDelete(NULL);
          }
          
          // Sends a list of the content of a directory as JSON file
          // requires a GET parameter path for the directory
          void explorerHandleListRequest(AsyncWebServerRequest *request) {
              //DynamicJsonDocument jsonBuffer(8192);
              #ifdef BOARD_HAS_PSRAM
                  SpiRamJsonDocument jsonBuffer(65636);
              #else
                  StaticJsonDocument<8192> jsonBuffer;
              #endif
          
              String serializedJsonString;
              AsyncWebParameter *param;
              char filePath[MAX_FILEPATH_LENTGH];
              JsonArray obj = jsonBuffer.createNestedArray();
              File root;
              if (request->hasParam("path")) {

Wobei ich das nie evaluiert habe, wie performant das im Vergleich ist.

tueddy · 25. November 2021 um 23:03

@Christian Wo findet sich Dein Fork, konnte den hier nicht ausfindig machen. Kannst Du einmal hier den Link teilen?

compactflash · 28. November 2021 um 15:01

Hallo
@biologist @tueddy

Ich habe mich jetzt einige Stunden mit der neuen Version " herumgequält" . Kann es sein dass es beim Abspielen beim Titelwechsel jetzt erheblich länger dauert als mit dem alten WebUi ? Ich habe im SD_MMC-Mode und SPI-Mode lange Pausen bis zu 2-3 Sekunden und beim Start jedes Files knackt es erheblich , so als würde es dauern bis die Musik „einrastet“. Das hatte ich bisher nicht . In der Version von @tueddy vom 19.11. funktioniert es noch . Ich habe zeitgleich auch meine Ordner mit der alten Tonuino-Struktur von 01-99 umgestellt auf z.Bsp.
/Musik/Queen/Greatest Hits/files.mp3
/Storybooks/PawPatrol/Die Zugrettung/files.mp3
Dadurch sind die Zuweisungen natürlich länger . Kann das schaden .
Meine Files hatten alle unterschiedlich Bitraten und ich habe zu guter letzt alles auf 128kbps umgestellt . Jetzt geht es wieder .

Und ja , mein Enkel ist 5 Jahre alt und mag Queen

VG

biologist · 28. November 2021 um 15:05

@compactflash Wann genau kommen diese Pausen denn? Wenn du einen Titelwechsel via WebGUI forcierst? Oder generell?

compactflash · 28. November 2021 um 15:20

Generell , am Anfang und bei jedem Titelsprung , aber massiv und mit lautem knistern . Ich schreib ja „einrasten“ . Ich kann es nicht anders beschreiben, so wie früher beim Suchen einer Radiostation , je näher man kam umso besser wurde es.
Meine Musik hat mindestens 192-320kbps und ich habe es unverändert auf die SD´s kopiert . Ich habe die SD´s nochmals neu formatiert, dann auf 160kbps reduziert immer noch Probleme und mit 128kbps ist es ok .

tueddy · 28. November 2021 um 15:43

@compactflash das soll natürlich nicht sein! Ich konnte solche Aussetzer bisher nicht feststellen.
Treten die Pausen auch auf wenn Du ohne Weboberfläche auf den nächsten Titel springst?
Du könntest auch testweise das Abspeichern des Coverbildes auskommentieren um zu schauen ob es daran liegt… In AudioPlayer.cpp die Funktion

void audio_id3image(File& file, const size_t pos, const size_t size)

auskommentieren. Dannn wird kein Cover gespeichert.
Oder Du schaust einmal auf die SD-Karte (mit dem PC). Wie groß ist die Datei „.cover“?