Die Flash-Belegung ist um ca. 1.3 kbytes grösser geworden (ggü. Dev).
Wenns ins Flash passt, sollte es kein Problem geben.
Der RAM-Verbrauch sollte sich nicht geändert haben, wir haben ja nur das HTML-File angepasst. Lediglich das Ausliefern der HTML-Datei wird minimal länger dauern. Allerdings ist 1.3 KB bei über 80 KB wohl vernachlässigbar.
@biologist Kannst Du etwas mehr Informationen liefern?
Ev. einen Screenshot und die Konsole des Webbrowsers?
Ich schaue morgen nochmal. Das sah aus wie der Screenshot, den ich weit oben mal hatte, wo es Probleme mit jsdelivr gab.
In die Konsole habe ich geschaut: Da waren keinerlei Fehler oder Warnungen zu sehen. Trat so wohl mit dem Handy als auch mit dem Laptop auf.
Also die neue Weboberfläche läuft auch mit einem Board ohne PSRAM. Ich hab’s getestet mit Lolin D32 anstelle von D32 Pro, ansonsten gleiche Einstellungen. Wenn Musik abgespielt wird ist man schon arg an der Speicher-Grenze, aber das war vorher auch schon so:
@CaCO3 Flash-Speicher macht uns überhaupt keine Probleme, es werden im Moment nur 30% verwendet. Problematischer ist RAM/Heap (siehe oben) und vor allem IRAM, hier kompiliert es mit allen Features nur mit Arduino als Komponente. Passt also…
Warum bei @biologist teils die Texte fehlen, keine Ahnung 
Browser Cache einmal geleert?
Ach was weiß ich 
.
Aber wenn’s bei dir läuft dann passt’s ja, auch wenn’s speichertechnisch ein Ritt auf der Rasierklinge ist.
Zum Verständnis um vielleicht Richtung Verbesserung überlegen zu können: Was macht uns denn da beim Speicher zu schaffen? Ist die Größe des HTML ein Problem? Oder die Menge an Abfragen/connections?
Das Problem ist folgende Zeile:
Wenn ich das passend einkürze, dann läuft es. Allerdings kann ich so ziemlich nix abspielen (das mp3-Beispiel von @moehrexxl mit der Doorbell ging jedoch). Also kann ich nicht empfehlen, ESPuino ohne PSRAM zu verwenden. Es kann jedoch sein, dass das auch mit der Bitrate zu tun hat: Vielleicht hat man mit 128 kBit/s keine Probleme.
Der Punkt ist, dass die Audiolib in den letzten Jahren deutlich mehr unterstützt, dies sich jedoch auch im Speicherbedarf niederschlägt. Glaube der Wechsel auf Arduino2 ging (wenn ich das richtig in Erinnerung habe) auch bisschen in die Richtung, wir haben jedoch mittels Arduino als Komponente versucht, das Ganze noch etwas zu verschlanken. Möglich, dass da noch Optionen schlummern, an denen man noch drehen kann.
Ich meinte konkret beim Webinterface. Dachte, dass das eine Referenz auf potential gewesen wäre.
@biologist Vielleicht kannst Du mal erklären, wieso aus deiner Sicht die Grösse und der Inhalt der Webseite (resp. dieser Branch) einen Einfluss auf den Speicherbedarf (also RAM) haben soll. Das macht für mich keinen Sinn, denn:
P.S. Die Benutzerführung des File-Uploads finde ich nicht sehr intuitiv. Aber das schaue ich mir später in einem separaten Branch an.
Das war früher eine Lamda-Funktion. Die ging aber durch die Minifizierung kaputt, weshalb wir das schon in einem früheren Branch umgebaut haben: Cleanup UI (#327) · biologist79/ESPuino@c5e117a · GitHub
Ich hatte es kürzlich auf einem pro getestet und es lief. Jetzt habe ich es, ohne es vorher nochmal auf nem pro zu testen, ohne PSRAM getestet und es lief nicht. Wir hatten hier schon Tod und Teufel, was irgendwo reingespielt hat. Behauptet habe ich gar nix. Da ich mir die (gefühlt) 2^12 Commits nicht einzeln angeschaut habe, ist mir nicht vorher aufgefallen, dass da fehlerhafter Js-Code in deinem BS-Branch ist.
Ein Blick auf den PR zeigt, dass der PR nichts an der Firmware selber ändert:
Diese Zeile wurde nicht von mir eingefügt, sondern bereits vor 3 Monaten in use natural sort by freddy36 · Pull Request #296 · biologist79/ESPuino · GitHub
Ich fand die Zeile auch befremdend, aber ich kenne nicht alle Features von javascript deshalb habe ich sie so belassen à la „never touch a running system“.
Gut, ist jetzt auch wurscht - wir haben ja rausgefunden, was das Problem ist.
Fakt ist: Es läuft (mit und ohne PSRAM), jedoch ohne PSRAM so mehr oder weniger speichertechnisch auf der letzten Rille. Und nein, damit sage ich nicht, dass das an BS5 liegt, sondern das ist eine allg. Feststellung.
OK, ich werde mal schauen, ob ich diese fancy Zeile ersetzen kann.
Als Erläuterung siehe Punkt 2 in How the Question Mark (?) Operator Works in JavaScript. Es ist ein neues Feature, welches erst in 2020 eingeführt wurde. Nur schon aus dem Grund sollte man es (noch) nicht verwenden. Gut möglich, dass jemand noch einen älteren Webbrowser hat.
So, habs im neusten commit umgebaut: Web UI Enhancements by caco3 · Pull Request #328 · biologist79/ESPuino · GitHub
@CaCO3 Vielen Dank für den schnellen Fix, das ist ja gar nicht Deine Baustelle gewesen. Aber beim Testen treten dann auch mal Probleme auf die von ganz anderer Seite kommen
Also ich hatte nie Darstellungsfehler mit FireFox, Chrome, Safari und MS-Edge Habe mir gerade den DuckDuckGo Browser installiert und da klappt es auch fein!
Ich möchte noch gern die Ursache verstehen:
Lag es jetzt an diesem Lambda Syntax oder könnte in einem bestimmten Browser der Ausdruck sortMode = window.settings.playlist.sortMode; zwischendurch „undefined“ sein, z.B. „playlist“?
@biologist Hast Du noch Darstellungsproblem?
P.S.: In einem Fall dauerte das Laden vom CDN sehr lange, da gibt es wohl immer noch Störungen.
Ich habe mir nicht angeschaut, wo das window.settings.playlist.sortMode erstellt/befüllt wird.
Aber ich sehe, dass es beim Laden der Seite noch undefined ist.
Erst wenn die Ordner/Dateiliste geladen wurde und ein Ordner ausgewählt wird, funktioniert es.
Ich vermute, das das mit dem ?-Operator ein Workaround ist, den man sicher hätte schöner lösen können. Ich wills aber nicht ändern, falls ich etwas übersehe.
Habt ihr euch schon mal überlegt, einen Modus einzuführen, bei welchem man diese Dateien alle vom Device aus ausliefern könnte? Diese Dateien könnte man dann auf die SD-Karte legen und via Webbrowser ausliefern.
Man müsste das HTML file zur Buildzeit umschreiben, aber das wäre nicht so eine Sache.
Dafür könnten wir dann einen Modus anbieten, der auch ohne Internetverbindung funktioniert.
Das wäre vermutlich sogar ohne Änderung der Firmware möglich, die Dateien müssten einfach in einem Ordner auf der SD-Karte liegen.
Und die URL wäre dann etwa wie http://musikbox.local/explorerdownload?path=%2Fbackup.txt.
Es würde beim Laden der Webseite einmalig mehr Last der MCU auslösen, aber danach wäre kein Unterschied mehr spürbar.
Nee, das passt jetzt alles.
Zu „ohne PSRAM“ noch einen Nachtrag: Also Files mit 128 kBit/s kriege ich abgespielt aber der Rest (weiß jetzt nicht, ob’s 192 oder 320 war) läuft nicht.
Das hatte ich eben auch.
Wir haben das immer mal andiskutiert. Ich war nur immer bisschen skeptisch, ob das nicht problematisch ist, wenn man da ggf. mehrere Requests parallel hat. Aber ja: Wirklich getestet wurde es (glaube ich) noch nicht und das ist auch letztlich der Grund, weswegen die Access-GUI quasi abgetrennt ist: Zu diesem Zeitpunkt kann man diese Files aus dem CDN halt nicht abrufen. Wenn man das hinkriegt, das von lokal auszuliefern, dann könnte man sich die Trennung sparen. Wäre schick.
Es sind halt aktuell ne ganze Reihe von Quellen, das müsste man halt zu einem großen Brocken vereinigen. Sowas wie Webpack stand mal im Raum, aber letztlich hat den Punkt niemand wirklich versucht umzusetzen.
Noch eine formelle Sache: Ich würde dich bitten, den PR nochmal bisschen zu „ordnen“, bevor wir das mergen. Weil das sind brutal viele Commits und das ist später in der History unübersichtlich.
Ich werde das ev. mal ausprobieren.
Hmm, das habe ich bereist einmal gemacht, deshalb ja dieser neue PR und Branch. Aber es ist ein Riesenaufwand. Und ich bin ehrlich gesagt nicht motiviert, da nochmals viel Zeit zu investieren, zumal eine Aufteilung extrem schwierig ist und nicht viel bringt.
Mach doch einfach ein Squash beim Mergen, dann erscheint es als ein einzelner Commit.
