Chrome zeigt Image von Mobotix Türstation nicht an

[Sipple]

Servus

Es ist mal wieder Weihnachten, also Zeit einige z.T. alte Probleme anzugehen.

Eines meiner ältesten ist Chrome.
Normalerweise verwende ich Firefox und der macht auf meinem Laptop und den Desktop PCs auch genau was er soll. Keine Auffälligkeiten.
Wir verwenden die Visu aber halt auch auf Android Geräten, z.B. auf dem großen Tablet an der Wand. Dort soll ein Browser mit einem anständigen Vollbildmodus laufen.
In der Disziplin versagt Firefox. Es gibt da natürlich Vollbild, das ist aber sch.... gemacht und für uns unbrauchbar. Chrome hingegen hat einen guten Vollbildmodus auf Android Geräten. Er macht auch bei fast allen anderen kritischen SmartVisu Elementen keine Zicken, spielt auch multimedia.audio klaglos ab (hier völliges Versagen von Apple), aber ein Problem kapier ich nicht. Er zeigt mir das Bild unserer Mobotix T25 Türstation nicht an.

Das Widget sieht so aus und funktioniert nur im Chrome nicht:

{{ multimedia.image('', 'http://admin:xxxxxxxx@192.168.yyy.yyy/record/current.jpg', 'fill', '5s') }}

Das hat noch nie geklappt, egal mit welcher SV oder Chrome Version. SV ist 3.1, SHNG ist 1.8.2, Chrome aktuell 96. In den Einstellungen vom Chrome finde ich nichts was das erklären könnte. Kann natürlich sein, dass es was gibt, aber nicht selbsterklärend ist.

Irgendwer eine Idee?

Gruß, Martin

[Msinn]

Rufst Du die SV über http oder über https auf? Falls https, verweigert Chrome die Einbindung "unsicherer" Inhalte (http).

[Sipple]

Nö, ganz normal http.

[wvhn]

Betrifft das auch Chrome auf dem PC? Wenn ja, rufe mal die Entwicklertools auf. Wenn Du „Anfragen“ und „XHR“ aktivierst, müsste bei der Anfrage nach dem Bild weitere Info erscheinen. Dann wissen wir wenigstens, wonach wir googeln müssen.

Ich tippe auf Cross Origin Gedöns.

[tobiasr]

Kann der Chrome überhaupt Nutzerdaten in der URL? Ich dachte das wäre so grundsätzlich "abgeschafft". Es gab für Windows wohl mal temporär einen Befehlsaufruf, der das temporär unterband, aber der soll wohl auch schon länger weg sein.

[Bonze]

Also, ich hab ne doorbord und ne ipcam, da bekomme ich den stream auch nicht angezeigt, wenn er in der sv eingebettet ist ( am handy und tablet), ..

Vl haben wir ein ähnliches problem?

[macflei]

https://knx-user-forum.de/forum/supp...64#post1632764

Meine Reolink-Kameras sind wie im Link beschrieben eingebunden.
Wird hier auch in Chrome angezeigt (Windows, iOS und Android)

[Sipple]

Betrifft das auch Chrome auf dem PC? Wenn ja, rufe mal die Entwicklertools auf. Wenn Du „Anfragen“ und „XHR“ aktivierst, müsste bei der Anfrage nach dem Bild weitere Info erscheinen. Dann wissen wir wenigstens, wonach wir googeln müssen.

Ich tippe auf Cross Origin Gedöns.

Guten Morgen

Chrome habe ich nicht installiert auf dem PC, aber Edge ist ja standardmäßig vorhanden und der basiert doch inzwischen auf Chromium, oder? Jedenfalls hat der das gleiche Problem. Zeigt das Bild nicht an.
Es geht übrigens gar nicht um den Livestream (den bekommt man wohl mit keinem Browser hin), sondern um ein jpg, welches alle 5s aufgerufen wird. Ich mach dann mal chrome drauf und schaue, ob ich die Entwicklertools angezeigt bekomme.

Edit: Hab ich gemacht und komme nicht ohne Hilfe klar. "Anfragen" und "XHR" finde ich nicht.

Aber das habe ich gefunden:

index.php:1 [Deprecation] Subresource requests whose URLs contain embedded credentials (e.g. `https://user:pass@host/`) are blocked. See https://www.chromestatus.com/feature/5669008342777856 for more details.

Also mag er tatsächlichen die Credentials nicht. Die Mobotix läßt sich aber imho nicht ohne die abfragen.

[Sipple]

Also. Die URL zu dem Mobotix current image in einem extra TAB des Chrome geht direkt. In Firefox, auch extra TAB, fragt er nach einer Bestätigung.
Lasse ich die credentials einfach weg, fragt Chrome mit einer Popup Box nach Nutzername und Passwort, Firefox ebenfalls. Anscheinend nur einmalig. Tja, wie löst man das allgemeingültig? Was ich auf die Schnelle gelesen habe, ist, dass Chrome das wohl wegen einer RFC Spec geändert hat und drauf wartet, dass alle anderen das ebenso handhaben.

[wvhn]

Das in #7 verlinkte php-Skript hat natürlich den Vorteil, dass es die externe Quelle unter Verwendung der Credentials auf den Webserver holt, auf dem smartVISU läuft. Dann braucht der Browser keine Credentials mehr. Einziger Nachteil könnte bei ganz alten Raspberries die Ladezeit sein. Das Bild muss ja beschafft und wieder ausgeliefert werden.

Eure Mithilfe beim Testen vorausgesetzt, könnte ich versuchen, ein allgemein verwendbares php-Skript zu bauen. Hier muss man halt unterscheiden können zwischen URLs der Form "http://admin:xxxxxxxx@192.168.yyy.yyy/record/current.jpg", in denen die Credentials in die URL integriert sind und Requests der Form "http.//192.168.yyy.yyy/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=wuuPhkmUCeI9WG7C&use r=user&password=password", in denen php-gemäße Request-Parameter übergeben werden.

Für's Erste sollte dieses php-Skript quick & dirty für den Fall der integrierten Credentials ausreichen:

<?php

$url = "";


if(!isset($_GET['cam']) || !isset($_GET['url'])) 
	error("failed");

$url = $_GET['url'];

$filepath = tempnam(sys_get_temp_dir(), $_GET['cam']);

if (getImage($url, $filepath)) {
	readfile($filepath);
	flush();
}

// delete the tempfile
unlink($filepath);

function getImage($url, $path) {
	downloadFile($url, $path);
	return true;
}

// read file from remote and write local copy
function downloadFile($url, $path){
	$newfname = $path;
	$file = fopen ($url, 'rb');
	if ($file) {
		$newf = fopen ($newfname, 'wb');
		if ($newf) {
			while(!feof($file)) {
				fwrite($newf, fread($file, 1024 * 8), 1024 * 8);
			}
		}
		else
			error("can't open temp file");
	}
	else
		error("can't open cam url");

	if ($file)
		fclose($file);
	if ($newf) 
		fclose($newf);
}

function error($msg) {
	// delete the tempfile
	global $filepath;
	unlink($filepath);

	header("Content-Type: text/plain; charset=UTF-8");
	die("Error: " . $msg);
}

?>

Dies wird in den Ordner ./pages/<DeineSeiten> gelegt und z.B. camimage.php genannt. Aufruf erfolgt dann mit

{{ multimedia.image('cam01', './pages/<DeineSeiten>/camimage.php?cam=haustuer&url=http://admin:xxxxxxxx@192.168.yyy.yyy/record/current.jpg', 'fill', '1.5s') }}

Der Parameter "cam" dient der Benennung der lokalen Datei, "url" muss die vollständige URL für das Bild enthalten.

Das Skript ist rudimentär getestet. Laden einer öffentlichen Webcam funktioniert, aber ich habe keine Testobjekt mit integrierten Credentials in der URL.

Gruß
Wolfram

[Bonze]

Man könnte das wohl auch mit shng über ne logik machen, muss das bild dann aber im SV speichern, da man ansonsten über den webserver nicht out of the box zugriff hat..

Bei der doorbird hab ich es auch so gemacht, das die bilder lokal gespeichert werden in nem ringpuffer, hat auch die ladezeit erheblich verkürzt..

[Sipple]

Das Skript ist rudimentär getestet. Laden einer öffentlichen Webcam funktioniert, aber ich habe keine Testobjekt mit integrierten Credentials in der URL.

Das Script ist nun auch bei mir zuhause mit einer Mobotix T25 professionell getestet und funktioniert bisher einwandfrei
Desktop Chrome, Tablet und Smartphone.

Aber noch eine vielleicht nicht ganz unwichtige Frage: Die temporäre Datei wird alle x Sekunden neu erzeugt und auf der SD Karte eines Raspi zwischengespeichert?
Da kommt einiges an Schreibzyklen zusammen (bei 5s 17280/Tag). Oder wird die temporäre Datei im Speicher gehalten? Dann ist das harmlos. Ich habe ne SSD an meinem Test-RPI4, da ist das nicht ganz so dramatisch, aber bei SD Karten-Raspis ein Problem.

[tobiasr]

Bei ausreichend Arbeitsspeicher verwendet Linux "seit jeher" primär den Arbeitsspeicher, auch wenn man offiziell auf der Festplatte speichert. Das ist aber im Besonderen für Lesende Operationen von Bedeutung, denn die soeben geschriebene Datei bleibt im Arbeitsspeicher für schnelleres Abrufen erhalten.

Daher wäre es tatsächlich nicht schlecht, eine sog. Ramdisk (tmpfs) dafür herzunehmen. Das Programm tmpfs stellt einen Dateipfad (z.B. /tmpfs) zur Verfügung, welcher im Hintergrund in den Arbeitsspeicher mappt. Hierzu also das Programm installieren, eine Mount-Option per Hand, Startscript oder /etc/fstab hinzufügen und das PHP Script anpassen. Wenige MB sollten ja für genau diesen Anwendungsfall schon ausreichen.

[wvhn]

Sipple daran habe ich ganz ehrlich nicht gedacht.

Ganz so schlimm ist der Verbrauch von Schreibzyklen IMHO aber nicht, da das Bild ja nur dann geschrieben wird, wenn das Widget gerade angezeigt wird. Das Widget verwendet die neue Exit-Methode und löscht den Refresh-Timer beim Verlassen der Seite.

Grundsätzlich kann man sich aber mal Gedanken darüber machen, das Verzeichnis ./temp zu teilen und Dateien mit häufigen Schreibzugriffen (alle php Services wie Wetter, FRITZ!Box, Kalender) auf eine Ramdisk zu legen.

Gruß
Wolfram

[Sipple]

Ok, also nicht so dramatisch wie befürchtet, aber durchaus eine Überlegung wert.
Wenn auch andere Services davon betroffen sind, wäre so eine Ramdisk natürlich hervorragend geeignet.

Mir fehlt da leider das Wissen, aber wäre es nicht möglich, nur eine Art Login einmalig per php o.ä. zu erledigen und dann das Kamerabild von da an wieder direkt vom Browser abzugreifen?

Gruß, Martin