Posts by kls

    Das ist per se sicher schon mal sehr sinnvoll, weil dadurch auch die SD-Karte geschont wird. Hab ich jetzt gemacht.

    Die Timestamps der Aufnahmen liegen aber immer noch ca. 6 Sekunden auseinander:


    -rw-r--r-- 1 root root 5306215 2022-03-07 16:00:06.462336821 +0100 ldr--18.jpg

    -rw-r--r-- 1 root root 5298119 2022-03-07 16:00:12.772295986 +0100 ldr--12.jpg

    -rw-r--r-- 1 root root 5589197 2022-03-07 16:00:19.082255286 +0100 ldr--6.jpg

    -rw-r--r-- 1 root root 5927507 2022-03-07 16:00:25.392214718 +0100 ldr-0.jpg

    -rw-r--r-- 1 root root 5221041 2022-03-07 16:00:31.722174153 +0100 ldr-6.jpg


    Der Löwenanteil der Zeit geht also anscheinend für die Messung drauf.

    Ist anscheinend ein ganz normales Verzeichnis:


    drwxrwxrwt 9 root root 4096 7. Mär 14:34 tmp


    Code
    1. Filesystem      Size  Used Avail Use% Mounted on
    2. /dev/root       3.5G  1.5G  1.9G  44% /
    3. devtmpfs        333M     0  333M   0% /dev
    4. tmpfs           462M     0  462M   0% /dev/shm
    5. tmpfs           185M  724K  184M   1% /run
    6. tmpfs           5.0M  4.0K  5.0M   1% /run/lock
    7. /dev/mmcblk0p1  253M   49M  204M  20% /boot
    8. tmpfs            93M     0   93M   0% /run/user/500

    Ich war leider die letzten Wochen anderweitig beschäftigt, daher erst jetzt wieder was hierzu.

    SHF : Die Kamera ist die hier: https://www.amazon.de/gp/product/B088NH3ZS5, das Objektiv https://www.amazon.de/gp/product/B07Q46LHHT.


    Bezüglich HDR bin ich inzwischen bei "enfuse" gelandet, was vollkommen unkompliziert "out of the box" funktioniert und recht gute Ergebnisse liefert. Mit diesem kleinen Script erzeuge ich jetzt ganz brauchbare HDR-Bilder:

    Die Ausgabeumleitung bei enfuse ist leider notwendig, da ich keine Option gefunden habe, mit der man seine Geschwätzigkeit bändigen kann.


    Zwischenzeitlich habe ich auch mal das neue "Raspios Bullseye" und damit "libcamera-still" ausprobiert, da dieses angeblich HDR können soll. Was dort gemacht wird ist aber kein "richtiges" HDR (also mit unterschiedlichen EV-Werten), sondern es wird mehrmals etwas unterbelichtet (aber immer gleich) aufgenommen und dann diese Bilder verarbeitet. Im Ergebnis kann sich das nicht mit dem messen, was ich mit obigem Skript erreiche.


    Das einzige, was jetzt noch unschön ist, ist dass die einzelnen Aufrufe von 'raspistill' relativ lange dauern (vermutlich bis Belichtung, Weißabgleich etc. gemessen wurde). Es würde aber eigentlich reichen, das nur beim ersten Mal zu machen und die Werte bei allen weiteren Aufrufen zu verwenden, denn an der Szenerie ändert sich ja so gesehen nichts. Lediglich Bewegungen machen sich halt störend bemerkbar, je größer die Abstände zwischen den Aufnahmen sind.

    Leider wurden dann keine zum löschen Markierte Aufnahmen (.del Dateien) mehr endgültig von der Festplatte gelöscht

    Zu dem Zeitpunkt als die Platte voll gelaufen ist, gab es keine Aufnahmen die gelöscht werden sollen.

    Das heißt dann wohl, dass du erst nach dem Volllaufen der Platte eine Aufnahme gelöscht (also von *.rec nach *.del umbenannt) hast, und die konnte VDR dann nicht endgültig löschen wegen der nicht erstellbaren Lock-Datei, oder?

    Ist es denn so, das der VDR normalerweise aufhört aufzunehmen, bevor die Platte ganz voll ist, also immer etwas Platz frei lässt?

    Die Aufnahme läuft "stur" weiter bis zum Anschlag. AssertFreeDiskSpace() soll dafür sorgen, dass immer mindestens 1GB frei ist. Dafür werden zuerst *.del gelöscht, und wenn es keine solchen mehr gibt, dann die älteste Aufnahme (abhängig von Priorität und Mindest-Lebensdauer).

    Der VDR sollte also auch bei einer komplett gefüllten Platte eine Möglichkeit haben Aufnahmen zu löschen. Auch wenn die Lock Datei nicht mehr angelegt werden kann.

    Als schnellen Fix könntest du das hier mal probieren (ungetestet, unkompiliert):

    cLockFile wird im Core-VDR ja nur zum Locken des Video-Verzeichnisses verwendet, daher sollte das keine Seiteneffekte haben. Für eine allgemeine Lösung bräuchten wir wohl noch einen Parameter, der das Verhalten steuert, damit der Aufrufer auch darauf gefasst ist, dass er den Lock auch ohne Lock-Datei bekommt, wenn die Platte voll ist.

    Aber vielleicht kannst du erstmal das hier testen.

    Nicht ganz. Das Flag gibt an, ob bei dem (nicht-VPS-)Timer die Vor-/Nachlaufzeit zu den im Timer festgelegten Start-/Stopzeiten draufgeschlagen werden sollen. Wird der Timer aus einem Event heraus angelegt, werden seine Zeiten auf die des Events gesetzt und das Flag auf '1' gesetzt. Ansonsten ist das Flag '0' und alles bleibt beim Alten. Eine Event-Zuordnung findet unabhängig davon immer statt.

    Die Zuordnung von Timern zu Events ist nur über die Zeit möglich. Zum einen handhaben die Sender die Event-IDs nicht eindeutig (siehe dazu meine gesammelten Erkenntnisse in eit.c), zum anderen könnte man sonst keinen Timer programmieren, für den es (noch) keinen Event gibt.


    Die Vor-/Nachlaufzeit wird beim Anlegen eines neuen (nicht-VPS-)Timers über den EPG sofort zu den Start-/Stopzeiten des Events dazugeschlagen. Das hat den Vorteil, dass man dem Timer immer genau ansieht, von wann bis wann er läuft. Man könnte natürlich auch den Timer mit genau den Zeiten des Events anlegen und die Vor-/Nachlaufzeiten erst in cTimer::Matches(time_t t, ...) berücksichtigen. Damit würde das ganze CalcMargins()-Gedöns wegfallen und es könnte an einigen Stellen sogar einfacher werden. Allerdings ist dabei zu bedenken:

    - Eine Änderung der Vor-/Nachlaufzeiten im Setup würde sofort auf alle existierenden Timer wirken (was man auch als Vorteil sehen kann).

    - In der Timer-Liste und in z.B. der LCARS-Skin würden nicht mehr die tatsächlichen Start-/Stopzeiten angezeigt, sondern die des Events (was aber bei VPS-Timern auch schon so ist).

    - Es wäre nicht mehr ohne weiteres möglich, einen Timer von Hand so anzulegen, dass er zu einer genau gewünschten Zeit startet/stoppt, da man immer die Vor-Nachlaufzeit ins Kalkül ziehen müsste.


    Meinungen dazu?

    Das wurde notwendig um sicherzustellen, dass der Timer immer dem richtigen Event zugeordnet wird.

    Du kannst das vorherige Verhalten wiederbekommen, indem du folgendes machst:

    Allerdings kann es dann sein, dass Pattern-Timer nicht mehr richtig funktionieren.

    jrie : Kannst du bitte mal diesen Patch probieren?

    Nachdem jetzt alle Versionsstände auf git.tvdr.de verfügbar und dokumentiert sind, neue Versionen nur noch über das GIT verteilt werden, und FTP generell als "legacy" angesehen wird und eher "verpöhnt" ist (Firefox z.B. unterstützt es gar nicht mehr) beabsichtige ich, ftp.tvdr.de abzuschalten. Wer noch was davon braucht, möge es sich bitte runterladen. Wer diesen Server spiegelt, sollte vielleicht das Spiegeln abschalten, um nicht seine lokale Kopie zu löschen, wenn die Dateien auf dem Server verschwinden.


    Wem ein wichtiger Grund einfällt, der dagegen spricht, möge bitte jetzt sprechen, oder aber für immer schweigen ;-).