[gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd

haselchen

Naja, naja...fast 1:0 für Dich ...aber nur fast ;)
Mit dem Image machste auch nix verkehrt oder kaputt.
Nimmste Etcher, Image rauf und ab in den Raspi.
Rest passiert von alleine.
Wie beim Container.
Beim "normalen" Linux wäre ich auch verloren.
Ich habe sonst auch alles auf der Synology.
Aber MotionEye auf SDKarte ist wie nen Container.

crunchip

@pedder007 wenn du dir ein backup deiner motioneye config machst, den LXC neu mit bookworm aufsetzt, motioneye installierst und dein backup einspielst, läuft es auch wieder, ohne diese Artefakte

? Offline

@haselchen sagte in Eigenartiges Motioneye Verhalten nach Bookworm Update:

Und Updates brauchste nicht, wozu?

Moin,

bist Du mit dieser Aussage wirklich glücklich?
Wenn ich Dir jetzt sagen würde, dass es in dieser Software einen bösen Fehler gibt, der auch schon ausgenutzt wird, hättest Du dann keine Angst um Deine Daten oder Dein Netz?

Du magst ja Deine Installation so perfekt eingerichtet haben, dass Du nicht von außen angreifbar bist, kannst Du das aber für alle hier mitlesende verantworten?

Also ich, würde mit solchen Ratschlägen wirklich vorsichtig sein, die haben in der heutigen Zeit hier nichts mehr zu suchen, die Welt ist schlecht, Updates gehören zum täglich Brot, sinnbildlich gesprochen ;)
Wird eine Software nicht mehr gepflegt, dann sollte man sich nach einem Ersatz umschauen oder den Entwickler davon überzeugen weiter zu machen.

Das ist meine persönliche Meinung, ich möchte/will hier keine Diskussion lostreten!

VG
Bernd

Armilar

@dp20eic

War auch der Grund meiner Entscheidung...

Lief vorher auf einem Debian Buster/Docker, welcher mit motionEye prinzipiell nur ein Sicherheitsrisiko darstellte...

liv-in-sky

@armilar sagte in Eigenartiges Motioneye Verhalten nach Bookworm Update:

Aber motionEye ist tot!

bei mir nicht - habe aber einen bookworm container installiert und dann motioneye neu gemacht - läuft seit monaten

Armilar

@liv-in-sky

Bezieht sich auch vorrangig der ("meiner Ansicht ebenfalls korrekten") Aussage von @dp20eic

Wenn ich Dir jetzt sagen würde, dass es in dieser Software einen bösen Fehler gibt, der auch schon ausgenutzt wird, hättest Du dann keine Angst um Deine Daten oder Dein Netz?

und ggfs. Sicherheitslücken im (nennen wir es mal hier im Thread) motionEye, welches seit 2,5 Jahren nicht mehr weiterentwickelt oder gewartet wird.

Klar funktionierte das motionEye unter Bullseye noch... Allerdings auch nicht mehr wirklich so flüssig wie bei dir, sondern eher wie im Eingangspost...

Außerdem war es mir wichtig, dass die Streams für einen definierten Zeitraum aufgezeichnet werden und jederzeit abgerufen und eingesehen werden können. Man hängt ja nicht permanent vor den Kameras... - aber sie hängen auch nicht grundlos im Außenbereich...

Sollte sich dann doch jemand (und das ist bereits passiert) unberechtigt auf dem Grundstück aufhalten und Schaden anrichten, so wüsste ich schon gern, wer es war... Da wäre ein einziges oder einzelnes Bildchen auf Telegram oder ein Stream den sich keiner "gegenwärtig" angesehen hat sonst auch nur der Tropfen auf dem heißen Stein.

haselchen

@armilar

Wie gesagt, ich bin auch wieder zurückgewechselt.
Und bezüglich Deines "Flüssigkeitsproblems", da hat sich nichts geändert.
Du bist derjenige, der an der Stellschraube drehen kann. Sprich stärkere Hardware (Arbeitsspeicher, Prozessor) und natürlich auch die Einstellungen in MotionEye selber.
Kann ich definitiv mitreden, denn ich hab dahingegend alles ausprobiert.
Wenn Du natürlich, und ich denke deswegen setzen wir Kameras und die entsprechende Software dazu ein, die fast 100% Sicherheit mit (flüssigen) Videos und Bildern haben willst, dann bleibt vermutlich nur eine kostenpflichtige Lösung. Oder es gibt hier User, die tatsächlich das Maximum aus einer freien bzw. Open Source Software rausholen können.
Aber wie im richtigen Leben, ein Richtig oder Falsch für Alle gibt es nicht.
Das soll hier jeder auf alle Fälle so machen , wie er möchte.

@dp20eic

Diese Aussage war natürlich sehr unglücklich.
Möchte nochmal klarstellen, dass Systeme, die relevant für Kommunikation und sonstigen Verkehr nach außen sind, natürlich in regelmässigen Intervallen auf Stand gehalten werden müssen.
Hier ging es mir ausschliesslich um die Motion Installation.
Da der Raspi bei mir mit dem Image hinter mehreren Switches mit Firewalls , einer FB und am Ende eines Modems hängt und noch per User/PW geschützt ist, ging/gehe ich davon aus , dass der Betrieb dieser Sofware nicht von Updates abhängt.

Hätte ich natürlich in meinem Post klarstellen müssen.

? Offline

@haselchen sagte in Eigenartiges Motioneye Verhalten nach Bookworm Update:

Hätte ich natürlich in meinem Post klarstellen müssen.

Moin,

ich gebe hier im Thread keinen weiteren Kommentar da zu ab, wir können gern einen im Off Topic aufmachen und das da Diskutieren, aber auch das ist schon des Öfteren geschehen und daher halte ich da jetzt meinen Mund :)

VG
Bernd

Armilar

@dp20eic

dito :blush:

Pedder007

@haselchen @Armilar @dp20eic was habe ich da nur losgetreten!? ;-)

Also ich denke hier ist was für jeden dabei und das meine Systeme immer ALLE up-to-date sind und man nicht auf root rum-hobelt, dass habe ich spätestens auch hier im Forum nochmal gelernt, wobei das für mich auch immer schon klar war.
Aktuell kann ich den Bullseye Container ja noch eine Weile updaten und mein ganzes Setup, bis auf evtl. der blöde Saugroboter und der Rasenmäher, kommt hier auch weitestgehend gut ohne Cloud klar. Ich treibe was solche Dinge angeht auch netzwerkseitig schon entsprechenden Aufwand (Unifi mit USG Pro 4 Gateway) mit eigenem IOT VLAN und ggf. zusätzlicher Definitionen, welche Einzelclients oder Gruppen hier nicht mit dem WWW sprechen dürfen, bzw. ggf. gar nicht aus dem VLAN heraus kommen.
Die Awareness dazu ist bei mir über viele Jahre berufsseitig gewachsen und wir hatten hier, in einem 5-Personen Haushalt, bisher noch nicht einen einzigen Malware oder Pishing Fall, weil ich es hier auch ununterbrochen predige ;-)

Also für mich ist alles gut und evtl. können wir am 18.ten ja in Solingen darüber sprechen ;-)

PS.
Und @liv-in-sky , ich werde das auch mal mit einer Neuinstallation versuchen. Entsprechender Bookworm Container steht schon :+1:

haselchen

@pedder007 sagte in Eigenartiges Motioneye Verhalten nach Bookworm Update:

@haselchen @Armilar @dp20eic was habe ich da nur losgetreten!? ;-)

Genauso sollte ein Thread sein.
Vernünftige Erklärungen , Sichtweisen...
So macht Gedankenaustausch Spass!

Mit Solingen muss ich meine Frau noch überzeugen :stuck_out_tongue_closed_eyes:

Armilar

@pedder007 sagte in Eigenartiges Motioneye Verhalten nach Bookworm Update:

Also für mich ist alles gut und evtl. können wir am 18.ten ja in Solingen darüber sprechen

Ich habe es auf dem Plan, kann es aktuell aber noch nicht zu 100% :frowning: zusagen. Aber schön wär's :hugging_face:

Pedder007

@liv-in-sky so, ich habe das nun auch so hinbekommen, wobei ich im Container irgendwie noch eine zusätzliche 'Kinke' hatte.
Meine Berechtigungsstruktur gab es nicht her, dass motioneye sein motion.pid file im Ordner /run ablegen durfte.

Ich habe meinen entsprechenden Workaround dann mal hier:
https://github.com/motioneye-project/motioneye/issues/2780#issuecomment-1789318667
für 'Gott und die Welt' dokumentiert.

Jetzt läufts, auch nach Container-Neustart und ich kann meine Bookworm Umgebung schön aktuell (und sicher ;-) ) halten.

Achso: Und das Geflacker ist damit tatsächlich beseitigt :-) :+1:

crunchip

@pedder007 sagte in [gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd:

Achso: Und das Geflacker ist damit tatsächlich beseitigt

Hab ich doch gesagt

maloross

@armilar sagte in [gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd:

Falls jemand diese Entscheidung trifft, hätte ich sicherlich einige Ratschläge zur Vorgehensweise und zu den Einstellungen

Nutze ebenfalls Motioneye und bin auch nicht mehr ganz so zufrieden damit, daher probiere ich Shinobi aus.
Die Containerinstallation läuft, Bild einwandfrei, ich scheitere aber tatsächlich an der Einbindung in VIS-2. API mit voller Zugriffsberechtigung erstellt, iFrame nach folgendem Schema eingerichtet:

http:// Shinobi-Container:32780 / [API] / embed / [Group-ID] / [Monitor-ID]

Angezeigt wird mir jedoch nur ein graues Feld, wo habe ich den Fehler oder welche Einstellungen muss ich anpassen?

Armilar

@maloross

Unter Home/Monitore:

werden die Monitore aufgelistet

unter "Copy Stream URL" ziehe ich die URL für den Browser
Wenn die im Browser aufgerufen werden kann, ist sie auch im VIS nutzbar

maloross

@armilar sagte in [gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd:

unter "Copy Stream URL" ziehe ich die URL für den Browser

Danke - hatte erst nicht funktioniert, dann habe ich festgestellt, dass als Stream Type "Poseidon" eingestellt war. Jetzt läuft es.
Sieht in der Grundeinstellung ganz gut aus, werde jetzt einmal mit den Einstellungen experimentieren.

FredF

Bei motioneye scheint es weiterzugehen: https://github.com/motioneye-project/motioneye/releases

Pedder007

@fredf danke für den Hinweis, das ist gut zu sehen :+1:

MartinK.

Hallo Freunde, ich hänge mich hier nochmal mir rein, da ich nicht noch einen MotionEye Thema eröffnen möchte.

Habe ME in einem Proxmox super am laufen, jedoch gibt es beim Versand von meinem Snapshot über das Blockly Skript immer ein kleines Problem. Der Snapshot wir fast immer erst nach dem zweiten oder dritten mal des auslösen des Triggers erfolgreich erstellt und an Telegram versendet, obwohl ich Timeouts zum kopieren des Fotos von Kamera zu ioBroker gesetzt habe.

Beim ersten Versuch wird mir immer diese Fehlermeldung im Log ausgegeben.

Es scheint so, als ob irgendwo ein Dienst oder Service erst nach dem 2. Versand aufwacht, und die Snapshot.JPG wird dann erst erstellt.

(MotionEye + ioBroker laufen in zwei separaten LXC-Containern)
Hier ist noch ein Screenshot des Blockly

Hat jemand einen Tip für mich ?
Lägere Timeouts helfen auch nicht ?

Community Forum

NEWS

[gelöst] Eigenartig Motioneye Verhalten nach Bookworm Upd

Support us

931

32.5k

81.8k

1.3m