Posts by FireFly

  • Hat jemand Erfahrung mit piHole und VPN von der Fritzbox?

    Quote from Dumpfbacke

    Mein VPN Zugriff auf die Fritzbox und alle daran hängenden Geräte (VDR, Homematic, ioBroker etc.) funktioniert nicht mehr.

    Wie ist denn der Weg der DNS-Abfragen? Ich würde mal vermuten, dass die Namen des VDR etc nicht vom PiHole aufgelöst werden, weil der direkt externe DNS abfragt. Dann kann man entweder die einzelnen Rechner im Pihole eintragen oder die Fritzbox beim Pihole als nächsten DNS-Server eintragen.
    Zugriffe über die internen IPs müssten dann jetzt aber schon funktionieren (also IP-Adresse anstatt z.B. vdr.fritz.box). Und du hast auch die richtige IP deiner Fritzbox eingetragen, nicht die 192.178.50.x aus derAnleitung?

  • VDR version 2.7.5 freigegeben

    So wie ich den Patch verstehe würde er nichts beim ersten Schneiden verändern, aber beim Überschreiben einer Aufnahme (zweiter Schnitt) die Fehler und Dauer erst am Ende aktualisieren. Da würde die Anzeige dann "plötzlich" umspringen, oder? Warum sollte man das beschränken und anders behandeln als beim Aufnehmen oder dem ersten Schnitt?

  • VDR version 2.7.5 freigegeben

    Quote from kls

    Würde vielleicht ein UpdateByName() auch genügen (mit dem Patch aus #25)?

    Ich hab's ausprobiert mit

    Code
      if ((Usage() & ruPending) != 0) {
     if ((Usage() & ruCut) != 0) {
        cutter = new cCutter(FileNameSrc());
        cutter->Start();
        //Recordings->DelByName(FileNameDst());
        Recordings->AddByName(FileNameDst(), false);
        Recordings->UpdateByName(FileNameDst());
        }

    was aber leider gar keinen Effekt hat da UpdateByName() an cRecordingInfo::Read() durchgereicht wird, es müsste aber in cRecording numFrames auf -1 eigesetzt werden, was nur im Konstruktor passiert.

  • VDR version 2.7.5 freigegeben

    Mir ist da nochwas in der Aufnahmeliste augefallen:
    Wenn man eine Aufnahme schneidet wird normalerweise während des Schneidens die Dauer der geschnittenen Aufnahme hochgezählt. Ändert man danach die Schnittmarken und scheidet die gleiche Aufnahme nochmals, dann wird nicht nur die Dauer nicht mehr hochgezählt sondern auch nach dem Ende des Schneidens wird weiterhin die Dauer der Aufnahme nach dem ersten Schneiden angezeigt. (Vermutlich betrifft das auch die Anzahl der Fehler in der Aufnahme). Erst nach einem Restart des VDR wird die richtige Dauer der geschnittenen Aufnahme wieder angezeigt.

    Ursache ist, dass die erste geschnittene Aufnahme in der Aufnahmeliste nicht gelöscht wird sondern beim Schneiden nur ein Eintrag hinzugefügt wird (falls er noch nicht existiert). In cCutter::Start() werden zwar die Videodateien des ersten Schneidens gelöscht aber die Aufnahme nicht aus der Aufnahmeliste entfernt. Der folgende Patch löscht die Aufnahme in der Liste bevor die neue hinzugefügt wird:

    Diff
    --- vdr-2.7.5/recording.c       2025-04-16 13:49:13.520577063 +0200
+++ vdr-2.7.5-devel/recording.c 2025-04-18 12:53:29.645557856 +0200
@@ -2056,6 +2066,7 @@
      if ((Usage() & ruCut) != 0) {
         cutter = new cCutter(FileNameSrc());
         cutter->Start();
+        Recordings->DelByName(FileNameDst());
         Recordings->AddByName(FileNameDst(), false);
         }
      else if ((Usage() & (ruMove | ruCopy)) != 0) {

    kls Gibt es eine bessere/elegantere Möglichkeit für das Del/Add oder kannst Du das so übernehmen?

  • VDR version 2.7.5 freigegeben

    kls Ehrlich gesagt habe ich mich gewundert, dass Infos wie FramesPerSecond indirekt über die info-Datei an die Aufnahmeliste übergeben werden.
    Mit Recordings->UpdateByName(recordingName) in cRecorder::Action() erreicht man ja schon die richtige Aufnahme, da könnte man ein cRecordings::UpdateByName(onst char *FileName, const *cRecordingsInfo) draus machen/hinzufügen und die relevanten Infos direkt übernehmen .... (oder nur die u.a. Parameter)

    Edit: es gibt nur drei Stellen, wo Recordings->UpdateByName() augerufen wird:

    • cCuttingThread::HandleErrors(): Setzt Errors
    • cRecorder::Action(): Setzt fps, Width, Height, ScanType, AspectRatio
    • cIndexFileGenerator::Action(): Setzt fps, Width, Height, ScanType, AspectRatio und Errors

    Die Änderungen würden sich also in Grenzen halten und für das UpdateByName() ist jetzt auch schon ein LOCK_RECORDINGS_WRITE gesetzt

  • VDR version 2.7.5 freigegeben

    kls Mit dem Force-Patch funktioniert es wie erwartet: :):thumbup:

    Quote from SHofmann

    Insofern würde ich nur ungern auf den Check verzichten,

    Ich auch, warum sollte man Daten nochmal einlesen, die schon vorhanden sind? Aber das time_t modified ist mit der Auflösung von einer Sekunde zu ungenau, weshalb man das Einlesen in manchen Situation erzwingen muss. Beim Anzeigen der Recording Errors, die auch von cRecorder über die Info-Datei an die Liste der Aufnahmen übergeben werden, sollte die Genauigkeit aber reichen so dass dort kein Force notwendig ist.

    Quote from SHofmann

    Müsste man dann nach einem Write() nicht das Neueinlesen explizit triggern?

    Das wurde ja schon gemacht und auch nur für diese Aufnahme, aber wie gesagt ist der Timestamp der Info-Datei nur Sekunden-genau.

  • VDR version 2.7.5 freigegeben

    Wenn man sich die Zeit ausgeben lässt

    Code
    bool cRecordingInfo::Read(FILE *f)
{
  if (ownEvent) {
     struct stat st;
     if (fstat(fileno(f), &st))
        return false;
+     if (modified)
+        isyslog("Read(FILE) mtime: %ld - %ld = %ld", st.st_mtime, modified, st.st_mtime - modified);
     if (modified == st.st_mtime)
        return true;

    dann wird es klar warum framesPerSecond nicht aktualisiert wird:

    Das time_t modified ist nur sekundengenau, so dass manchmal schon die nächste Sekunde angebrochen ist, aber oft auch nicht und dann die info-Datei nicht neu eingelesen wird.
    st_mtime ist lt. man 3type stat nur ein Alias für die Sekunden: #define st_mtime  st_mtim.tv_sec, man könnte auf struct timespec  st_mtim umstellen, muss dann aber das struct timespec umständlich vergleichen.
    Da ist der Patch mit Force die einfachere und sichere Alternative und mein nächster Test.

  • VDR version 2.7.5 freigegeben

    Auf die Schnelle habe ich jetzt einfach mal den Check auskommentiert:

    Code
      if (ownEvent) {
     struct stat st;
     if (fstat(fileno(f), &st))
        return false;
     //if (modified == st.st_mtime)
     //   return true;
     if (modified) {

    ... und konnte das Problem damit nicht mehr nachstellen. Morgen test ich dann Deinen Patch (der dann ja auch funktionieren müsste) und lasse mir auch nochmal die mtime ausgeben

  • VDR version 2.7.5 freigegeben

    Da geht Dein Patch weiter als meine Änderungen ;) Ich hatte nur framesPerSecond verlagert, aber bei beiden Varianten tritt das Phänomen noch auf.
    Ich habe es jetzt soweit debugged, dass im Fehlerfall zwar die richtigen Werte erzeugt werden, aber das recordingInfo->Write() in cRecorder::Action() später erfolgt als das cRecordingInfo::Read(FILE f) und somit dort nur der Defaultwert 'F 25' drin steht.

  • VDR version 2.7.5 freigegeben

    Quote from FireFly

    Jedes cRecording-Objekt hat ja auch ein cRecordingInfo-Objekt, sollte man dann nicht einfach immer auf cRecordingInfo::FramesPerSecond() zugreifen anstatt die Variable nochmals mitzuführen?

    Das hat leider nichts gebracht - cRecorder und cRecording haben jeweils ein eigenes cRecordingInfo-Objekt und cRecordings soll das Info-File neu einlesen wenn es aktualisiert wurde. Bleibt die Frage warum das (manchmal) nicht funktioniert :(

  • VDR version 2.7.5 freigegeben

    Ich bin gerade auf ein Problem gestoßen, dass bei einigen frischen Aufnahmen die doppelte Spielzeit der tatsächlichen Dauer angezeigt wird.
    - Das Problem tritt auch mit den Standard-Skins (LCARS, Klass. VDR) auf.
    - in der info-Datei steht die korrekte Anzahl FramesPerSecond = 50 drin
    - über NFS bei einem anderen VDR eingelesen wird überall die korrekte Dauer 1:01 angezeigt (nach einem Neustart des VDR sicher auch, aber da laufen derzeit noch Aufnahmen)
    - beim Abspielen zeigt der Balken die korrekte Dauer 1:00:58 an

    Ich denke, das kommt durch das doppelte Vorhalten der Variablen framesPerSecond in cRecording und cRecordingInfo wenn die Frame-Info etwas später kommt und nur in cRecordingInfo gesetzt wird. Die Skins nutzen cRecording->LengthInSeconds() die mit der falschen cRecording::framesPerSecond rechnet, ebenso LengthInSecondsAfterEdit()
    kls: Jedes cRecording-Objekt hat ja auch ein cRecordingInfo-Objekt, sollte man dann nicht einfach immer auf cRecordingInfo::FramesPerSecond() zugreifen anstatt die Variable nochmals mitzuführen? Dann würde ich mal einen Patch bauen

  • Suche Stromsparenden Mini-Computer für Fahrzeuge

    Quote from ranseyer

    Außerdem kann man wohl beim Futro im großen Steckplatz der keine NVMe's kann doch NVMe verwenden, ...

    Der lange M.2 Steckplatz ist für M.2-SATA-SSDs vorgesehen, mit Adapter (wegen den Kodierungskerben) gehen auch M.2-NVMe-SSDs. Am kurzen Steckplatz, der für Wifi/Bluetooth vorgesehen ist, gehen mit Adapter ebenfalls M.2-NVMe-SSDs - habe ich beides in Betrieb mit SSDs der Größe 2280. An beiden M.2-Steckplätzen liegt PCIe 2.0 x1 an, also max 500MB/s. Es gibt irgendwo auch ein Foto, wo jemand in beide M.2-Slots Adapter mit 2280er SSDs gesteckt hat, aber dann überlappen sich diese und sollten besser voneinander isoliert werden.