während des Schneidens ruckelt Wiedergabe von Platte

  • Die load steigt an, bleibt aber unter 1. Die Platte ist eine WD10EADS, die zu 85% voll ist.


    hdparm:

    /dev/sdb:

    Timing cached reads: 7734 MB in 2.00 seconds = 3875.16 MB/sec

    Timing buffered disk reads: 312 MB in 3.01 seconds = 103.66 MB/sec


    Ich denke, das ist o.k.

    Der Kernel ist von Ubuntu 19.10. und die Hardware ist der VDR2 aus meiner Signatur.


    Woran könnte es liegen? Oder ist das normal? Einen Film ansehen während ein anderer im Hintergrund geschnitten wird, ist so leider unmöglich.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Das Live-Fernsehen wäre wohl nicht beeinträchtigt beim Schneiden. Es kann auch ein Zeichen der Plattenalterung sein, daß etwa mehrfaches Lesen irgendwelcher Sektoren notwendig war, um fehlerhafte Daten zu vermeiden. Wie sind die SMART-Werte?

    Vielleicht sollte "markad.whileReplaying" doch auf 0 gesetzt werden?

  • Dr. Seltsam

    welchen Disk Scheduler nutzt du ?

    "cat /sys/block/sdb/queue/scheduler"

    Bei Ubuntu ist mq-deadline seit 18.04 Standard und der berücksichtigt keine Disk IO Prioritäten.

    Ich hatte mal ein ähnliches Problem und konnte es lösen, indem ich auf bfq umgestellt habe.

    "sudo echo bfq > /sys/block/sdb/queue/scheduler"

  • Ja, die Schnittfunktion scheint etwas aggressiv mit den Ressourcen umzugehen. Obwohl ich ein recht schnelles System habe, incl. SSD-Cache, treten bei mir beim Schneiden und gleichzeitigem schnellen Vorspulen in der selben Aufnahme auch kurze Hänger auf. Wenn das mit dem Disk Scheduler nicht reicht, kannst Du auch noch mal folgenden Patch probieren: [yavdr-ansible] "Bandbreite beim Schneiden begrenzen". Der gibt den anderen Prozessen etwas mehr Spielraum. Vielleicht hilft das bei Dir ja auch.

    VDR 2.6.6: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 39 Kernel 6.7 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • cat /sys/block/sdb/queue/scheduler sagt:

    [mq-deadline] none


    nach sudo modprobe bfq steht da jetzt

    [mq-deadline] bfq none


    aber es hat keine Besserung gebracht. Es ist auch kein richtiges Ruckeln (das Bild läuft flüssig), aber es kommt im Sekundentakt zu Tonaussetzern. Live-TV ist nicht betroffen.


    Ich verwende nicht das markad-Plugin, sondern schneide manuell mit dem vdr. Den Patch mit dem cCondWait::SleepMs(1); werde ich mal ausprobieren.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Der Scheduler in […] ist der aktive, die anderen sind verfügbar.

    Du musst ihn noch mit ""sudo echo bfq > /sys/block/sdb/queue/scheduler"" aktivieren für /dev/sdb

    Einmal editiert, zuletzt von kfb77 ()

  • ich kriege immer Berechtigungsfehler:


    sudo echo bfq > /sys/block/sdb/queue/Scheduler

    -bash: /sys/block/sdb/queue/Scheduler: Keine Berechtigung


    echo "bfq" | sudo tee /sys/block/sdb/queue/Scheduler

    tee: /sys/block/sdb/queue/Scheduler: Keine Berechtigung

    bfq

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • ja, sollte, geht aber bei mir auch nicht (mehr).

    Das funktioniert: "sudo echo "bfq" | sudo tee /sys/block/sdb/queue/scheduler"

  • Warum sollte

    sudo echo bfq > /sys/block/sdb/queue/scheduler

    nicht funktionieren? Die Fehler von Dr. Seltsam stammen doch sicher, wie bereits geschrieben, von der Großschreibung von 'Scheduler'.


    Code
    vdr ~ # sudo echo bfq > /sys/block/sdb/queue/Scheduler
    -bash: /sys/block/sdb/queue/Scheduler: Keine Berechtigung
    vdr ~ # sudo echo bfq > /sys/block/sdb/queue/scheduler
    vdr ~ #


    Der Umweg mit tee und pipe mit sudo ist möglicherweise schwieriger, aber da erkenne ich keinen Sinn, diesen Umweg zu gehen. Kann mich da jemand erleuchten, warum das nötig sein sollte? Warum über tee?

    Ich gönne mir den Luxus, als root ohne sudo zu arbeiten, daher fehlt mir da die Erfahrung.


    Christian

  • ja, auch das müsste eigentlich gehen, geht bei mir aber auch nicht:

    Server3:~$ sudo su - echo bfq > /sys/block/sdb/queue/scheduler

    -bash: /sys/block/sdb/queue/scheduler: Keine Berechtigung

    Irgendwie verschwinden die root Rechte nach der Umleitung.

  • hopsi

    Über "tee" weil ich dem einen sudo voranstellen kann, bei der Umleitung geht das nicht. Der Weg von mini73 hat früher mal funktioniert, die Erklärung, warum das nicht mehr geht, würde mich auch interessieren.

  • hopsi

    Über "tee" weil ich dem einen sudo voranstellen kann, bei der Umleitung geht das nicht. Der Weg von mini73 hat früher mal funktioniert, die Erklärung, warum das nicht mehr geht, würde mich auch interessieren.

    OK, hab's kapiert. Die User-Shell setzt die Umleitung noch vor dem Rechtewechsel. Dann kann aber das sudo vor dem 'echo' theoretisch weg.


    Christian

  • Klar, mit einer root Shell geht es, aber ich dachte das hätte früher mal auch in einer Zeile funktioniert.

    Aber die andere Variante geht bei mir nicht, bei dir geht sie.

    Server3:~$ sudo echo bfq > /sys/block/sdb/queue/scheduler

    -bash: /sys/block/sdb/queue/scheduler: Keine Berechtigung

  • Bei mir gings, weil ich schon root war. Autsch. Als user geht das auch bei mir nicht, Erklärung habe ich oben schon geschrieben: Die User-Shell setzt die Umleitung noch vor dem Rechtewechsel.


    Sorry for the noise,

    Christian

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!