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.

    VDR 1: Silverstone LC20, Cougar A300/R, Asrock J4105B-ITX, WinTV DualHD, WD10EACS; Atric-IR-Einschalter. SW: Xubuntu 20.04 per SSD. Für den Produktiveinsatz leider nicht zu gebrauchen.
    VDR 2: ACT-620, Asrock B75 Pro3-M, Celeron G540, passive GT1030, Cine CT V6, KNC-One DVB-C, Atric-IR-Einschalter. SW: Xubuntu 20.04 per SSD. Mein zuverlässiges Arbeitspferd.

  • 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?

    --
    vdr User #2022 - hdvdr2: Lenovo SFF M83, Intel(R) Core(TM) i5-4670S, 12 GB Ram, ubuntu-focal, softhddevice-cuvid
    ddbridge-6.5 mit 2xDVB-S2 und (Flex) 2xDVB-C/T Tunern, nvidia-GF720 SFF passiv (nvidia-450.80), System SSD btrfs,

    snapper, 8TB HDD XFS/cow /srv/vdr, yavdr-ansible-2.4.3-patches, vdr-epg-daemon mit Frodo-plugins, Kernel 5.9.1-lowlatency

    vdradmin-am, live+webstreaming, vdrmanager (Smartphone als FB), ffmpeg-4.3.1-libfdk_aac, vdr-plugin-hbbtv. Folding@home läuft auf CPU.

  • 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.4.4: ASUS Prime X470-PRO, Ryzen 7 2700, 32GB, 6TB HD, GT630, Fedora 32 Kernel 5.8 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

  • 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.

    VDR 1: Silverstone LC20, Cougar A300/R, Asrock J4105B-ITX, WinTV DualHD, WD10EACS; Atric-IR-Einschalter. SW: Xubuntu 20.04 per SSD. Für den Produktiveinsatz leider nicht zu gebrauchen.
    VDR 2: ACT-620, Asrock B75 Pro3-M, Celeron G540, passive GT1030, Cine CT V6, KNC-One DVB-C, Atric-IR-Einschalter. SW: Xubuntu 20.04 per SSD. Mein zuverlässiges Arbeitspferd.

  • 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

    VDR 1: Silverstone LC20, Cougar A300/R, Asrock J4105B-ITX, WinTV DualHD, WD10EACS; Atric-IR-Einschalter. SW: Xubuntu 20.04 per SSD. Für den Produktiveinsatz leider nicht zu gebrauchen.
    VDR 2: ACT-620, Asrock B75 Pro3-M, Celeron G540, passive GT1030, Cine CT V6, KNC-One DVB-C, Atric-IR-Einschalter. SW: Xubuntu 20.04 per SSD. Mein zuverlässiges Arbeitspferd.

  • 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
    1. vdr ~ # sudo echo bfq > /sys/block/sdb/queue/Scheduler
    2. -bash: /sys/block/sdb/queue/Scheduler: Keine Berechtigung
    3. vdr ~ # sudo echo bfq > /sys/block/sdb/queue/scheduler
    4. 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.

    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