Bei mir im Brower unter Windows läuft z.B. https://beedao.zku-berlin.org/hive.html#04 auch auf dem RasPi läuft das leidlich, wenn ich einen Broser starte und die URL aufrufe. Beim autostart aber nicht. Ich vermute die WLAN-connection ist da noch nicht da und der Browser lädt dann (oder auch nicht) den content. Wobei die letzte Fehlermeldung oben ja von Grafana kommt. Eine Idee was das sein könnte?
DevTools failed to load source map: Could not load content for https://swarm.hiveeyes.org/grafana/public/plugins/petrslavotinek-carpetplot-panel/libs/d3-scale-chromatic/colors.js.map: Load canceled due to load timeout
DevTools failed to load source map: Could not load content for https://swarm.hiveeyes.org/grafana/public/plugins/petrslavotinek-carpetplot-panel/libs/d3-scale-chromatic/ramp.js.map: Load canceled due to load timeout
DevTools failed to load source map: Could not load content for https://swarm.hiveeyes.org/grafana/public/plugins/petrslavotinek-carpetplot-panel/css/carpet-plot.css.map: Load canceled due to load timeout
Das trägt noch ein wenig auf, daher ist die gefühlte Ladezeit leider nicht ganz so snappy. Ist es möglich, dass da unter der Haube noch ein Problem besteht?
das kommt davon das ich Preloaden versuche, was aber nicht wirklich funktioniert. Ich kann die Preloader entfernen. “Snappy” wird es aber nie sein, weil ich immer eine aktuelle Version des IFrames generiere und nicht so wie die andere Demo alles auf einmal reinlade. Dafür ist meine Version immer aktuell. Die Frage ist was hier gewollt ist.
Ja, das hatte mir Lars auch schon geschrieben. Er hat weiter nichts gefunden und schreibt:
Habe mich jetzt nochmal über 1 Std lang wundgetestet und kann meinerseits einfach keinen der beschriebenen Fehler reproduzieren.
Einzig Chrome und Chromium (linux und mac) im incognito Modus geben mir
"If you’re seeing this Grafana has failed to load its application files
This could be caused by your reverse proxy settings.
If you host grafana under subpath make sure your grafana.ini root_url setting includes subpath
If you have a local dev build make sure you build frontend using: yarn start, yarn start:hot, or yarn build
Sometimes restarting grafana-server can help"
weiter
Auffällig ist dann noch, das heute morgen das Laden der einzelnen iframes ziemlich zügig ist im Vergleich zu gestern Abend. Habt ihr zwischenzeitlich was neu gestartet?
Afaik hat aber niemand was gemacht oder gab es einen (automatischen) restart in der Nacht?
Bei Hiveeyes - Kotori DAQ funktionieren die eingebetteten Panels derzeit auch nicht. Ich habe dort jeoch noch nicht nach der Ursache geschaut, vielleicht erlangen wir dadurch irgendwelche weiteren Erkenntnisse in dem Bereich.
Grafana Upgrade?
Wir können noch versuchen, auf einer parallelen URL Grafana 7 oder 8 zur Verfügung zu stellen. Vielleicht klappt es damit besser. Grafana 6 hat ja nun doch schon ein paar Jahre auf dem Buckel, in denen sich die Browser ordentlich weiterentwickelt haben.
Ja, hatte ich auch verwendet, ähliches Verhalten wie die von Lars: Im “normalen” Browser geöffnet funktioniert es, über das Skript nicht.
Wenn wir die Dinger 1x laden und dann die nächsten 12 bis 24 Stunden anzeigen wäre das schon ganz gut. Wir zeigen aktuell 14 Tage an, da wird es nicht auffallen wenn ein paar “live” Stunden fehlen und die Rechner müssen nicht ständig im Netz sein – ich weiß nicht wie stabil das vor Ort ist.
Vielleicht habe ich den Übeltäter gefunden, aber noch keine Lösung! Das spezifizierte user profile / path scheint mit unseren Problemen zusammen zu hängen. Ich gebe beim Start von Chromium mit --user-data-dir=/tmp/browser2 einen Profil-Path an, hier der ganze Aufruf:
statt des Pfads oben den default vorhande user angegeben (nur testweise, produktiv brauche ich ja zwei) --user-data-dir=/home/pi/.config/chromium/Default
die config / den Inhalt von --user-data-dir=/home/pi/.config/chromium/Default nach /tmp/browser2 kopiert, um ggf. vorhandene andere defailt-Einstellungen zu verwenden
das Verzeichnis /tmp/browser2 ist da und wurde automatisch angelegt und es stehen auch Dinge drin, mangelnde Rechte, meine ich, sollten es nicht sein.
Irgendwie scheint es als ob der Browser was (temporär) runterladen will und das nicht kann. Allerdings funktionierte das Skript ja mit https://www.documenta.de/ und https://www.zku-berlin.org/ als URLs, nur nicht mit unseren ollen Grafana-Panels.
Hier noch wie ich aktuell teste ich rufe über die bash die eine Skriptzeile auf und schaue dann was auf dem Raspi passiert
pi@raspberrypi:~ $ chromium-browser --app=https://beedao.zku-berlin.org/hive.html#02 --user-data-dir=/tmp/browser1 --kiosk
[10783:10783:0615/120117.215616:ERROR:gpu_init.cc(481)] Passthrough is not supported, GL is egl, ANGLE is
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
pi@raspberrypi:~ $ chromium-browser --app=https://beedao.zku-berlin.org/hive.html#02 --user-data-dir=/home/pi/.config/chromium/Default --kiosk
[10987:10987:0615/120210.277398:ERROR:gpu_init.cc(481)] Passthrough is not supported, GL is egl, ANGLE is
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
pi@raspberrypi:~ $ chromium-browser --app=https://beedao.zku-berlin.org/hive.html#02 --kiosk
Opening in existing browser session.
pi@raspberrypi:~ $ [11140:11140:0100/000000.081315:ERROR:gpu_init.cc(481)] Passthrough is not supported, GL is egl, ANGLE is
Per view-source:https://beedao.zku-berlin.org/hive.html#02 sieht man jedoch, dass das iframe anders geladen wird. Irgendwie scheint JavaScript involviert zu sein.
Dazu kommt, dass scheinbar alle Panels auf einer einzigen Seite untergebracht wurden. Das bedeutet wohl, dass jeweils alles geladen wird, obwohl Ihr doch anstrebt, auf dedizierten Monitoren nur einzelne Panels vollflächig anzuzeigen?
Ich weiß nicht, wozu Ihr bei diesem Anwendungsfall die Einbettungsgeschichte überhaupt braucht? Warum nicht einfach folgendes machen?
Glaube es problem ist, dass Grafana irgendwo in den LocalStorage schreiben möchte, das aber nicht erlaubt ist und Grafana hat keinen schönen “catch” call um das abzufangen.
Jup, könnte mir gut Vorstellen das des der Übeltäter ist. Wenn window.localStorage nicht existiert wird er einen Fehler werfen.
Edit1: Flags in Chromium habe ich nur gefunden für disablen von LocalStorage aber es gibt diese Flag hier --mojo-local-storage “Use a Mojo-based LocalStorage implementation.”, aber keine Ahnung a) was das ist und b) ob sowas helfen könnte.
Was mich wundert, dass es ja funktioniert, wenn ich es “normal” im Browser aufrufe, oder über chromium-browser --app=https://beedao.zku-berlin.org/hive.html#02 --kiosk da funktioniert es ja, nur nicht mit einem spezifizierten --user-data-dir=/tmp/browser1
Das würde ja bedeuten, dass der default user LocalStorage allocaten kann, ein anderer aber nicht. Nun ist die Frage warum nicht? Braucht er besondere Rechte, wo kann man das einstellen … oder ist es “nur” ein bug?
Oder versuche doch einmal, das Profil-Verzeichnis im gleichen Hauptverzeichnis wie “vanilla” unterzubringen, also unterhalb von ~/.config[1]. Ich könnte mir vorstellen, dass irgendwo bei Chrome, oder durch Linux, fortschrittliche Sandbox Funktionalitäten realisiert sind, die einen entsprechenden Zugriff nicht beliebig erlauben. Vielleicht gerade eben unter /tmp nicht.
Muss aber auch nicht sein, auch das sind nur Vermutungen.
Laut chrome://version/ in der Adresszeile von Chromium eingegeben ist der Profile Path /home/pi/.config/chromium/Default selbst wenn ich den explizit spezifiziere via:
Wenn ich statt dessen --user-data-dir=/home/pi/.config/chromium/ verwende (ohne Default) geht es??! Mit --user-data-dir=/home/pi/.config/chromium2/ oder --user-data-dir=/home/pi/.config/chromium/browser1 geht es wieder nicht! --mojo-local-storage brachte nichts.
Agrrr!
[edit] ich hatte gestern schon den Inhalt von /home/pi/.config/chromium/Default nach /tmp/browser1/ kopiert, was nichts brachte. Nun – mit der Erkenntnis von oben nochmal
den Inhalt von
/home/pi/.config/chromium/ (ohne Default) nach /tmp/browser1/
kopiert, und es funktioniert! Boah! Jetzt wäre nur noch schön zu wissen, ob es eine config-Opton ist die gezwickt hat oder tatsächlich eine Datei, die nicht angelegt werden konnte / durfte.
Fein! Andere [1] verwenden ganz einfach ein jeweils neu angelegtes temporäres Verzeichnis als Profilverzeichnis.
--user-data-dir=$(mktemp -d)
So wäre es eigentlich am besten, damit muss a) nichts vorbereitet werden (Profil umkopieren WTF!?) und b) kann auch nix schlimmes kaputtgehen, wenn es beim nächsten Mal ohnehin wieder neu erzeugt wird.
