Posts by kfb77

    Die Version 3.0.18 ist auf vdr-plugin-markad verfügbar.

    Heute ist dieser Thread genau 2 Jahre alt. Eigentlich dachte ich damals, das ist mit "ein paar API Calls auf den aktuellen Stand bringen" nach ein paar Wochen erledigt. Das war ein großer Irrtum. Den Sendern fallen laufend neue Dinge ein, die Anpassungen erfordern. Diese Version enthält mal wieder ein paar solch kleinerer Anpassungen.

    Wie man aber an den Versionsnummern sieht, gab es schon lange keine neuen Features mehr. Da bin ich seit ein paar Monaten mit der Umsetzung meiner ursprünglichen Ideen durch und wohl an den Grenzen des für mich (und unseren CPUs) machbaren angekommen.

    Da dieser Thread nach 2 Jahren noch nicht eingeschlafen ist, sind wohl auch immer wieder Probleme zu lösen. Vielen Dank für eure Beiträge, Feedbacks, Bug Reports und Likes. Hinweise auf Dinge, die nicht funktionieren, sind immer gerne willkommen.

    I found frames with only the half of usual duration in this stream (e.g. frame 203 und 204).

    In your tar there was a cut video by markad. In this file the cuts seems to be correct.

    You have "only" the problem, if you use the marks with vdr. Is that correct ?

    Here the result of a first look into your files:

    Code
    1. 0:14:41.06 ( 22030) moved stop mark ( 22030) before logo stop mark ( 22106) at 0:14:06.08, silence detected

    The first logo stop was detected correct at 14:04min and then moved to 14:41min because of a detected silence part. This is not valid because:

    1. Marks should never moved so far away from the logo mark.

    2. 76 frames away should be about 2,5s and not 35s

    3. frame 22030 should not have a timestamp greater than frame 22106.


    I tested your recording with full decoding (--fulldecode) and analyse internal timestamps (--pts). I got:

    Code
    1. 0:14:42.23 ( 22072) 0:14:04.79 <- detected logo stop ( 22072)

    Frame PTS (14:04) could only be bigger than timestamp based on frame count / fps (14:42) if there are frame missing in the recording, but never smaller.

    Something very strange is going on, more in the next days.

    Wenn ich nur den VDR neu starte, endet der Scanprozess sofort:

    Du brauchst den VDR nicht neu zu starten, das wirkt auch auf laufende Prozesse.


    Wie könnte ich bfq dauerhaft verankern ?

    Ich habe es bei mir einfach quick and dirty in die /etc/rc.local geschrieben (ohne sudo bash, nur die letzten zwei Zeilen). Gibt bestimmt auch schönere Lösungen.

    Das File wird es vermutlich nicht geben, einfach erzeugen und die richtigen Rechte setzen:

    Code
    1. -rwxr-xr-x 1 root root 758 Jun 20 11:25 /etc/rc.local

    Standard bei der Prtitionierung von BM2LTS ist ext4 ...... da sollte das Verhalten nicht auftreten ....

    VDR nutzt I/O Prioritätsklassen. Ob diese von der Platte berücksichtigt werden hängt nicht vom Filesystem ab, sondern vom Disk Scheduler.

    Im Debian Universum ist das der Default:

    Code
    1. cat /sys/block/sdX/queue/scheduler
    2. [mq-deadline] bfq none

    mq-deadline berücksichtigt aber keine I/O Prioritätsklassen.

    bfq könnte es.

    Einfach mal testen, ob dies eine Verbesserung bringt (ist nach reboot wieder weg)

    Code
    1. sudo bash
    2. modprobe bfq
    3. echo bfq > /sys/block/sdX/queue/scheduler

    sdX ersetzen mit der tatsächlichen Video Disk.

    Also am einfachsten wäre es, den VDR Container von Debian auf Ubuntu zu wechseln und dann das yavdr Repository von seahawk1986 zu verwenden. Das ist immer sehr aktuell. Da kannst du sogar die ansible Installation Scripte im Container nutzen, die headless Server Scripts laufen da problemlos. Die Nutzung von Container gibt einem ja einfach die Möglichkeit für eine Anwendung ein anderes OS zu nutzen als dein Host.


    Wenn du bei Debian bleiben willst, dann musst du aus den Quelldateien den aktuellen VDR und alle vor dir genutzten Plugins selbst kompilieren.