Posts by fallobst

    SMART Prefailure Attribute: 3 Spin_Up_Time changed from 86 to 83

    SMART Prefailure Attribute: 3 Spin_Up_Time changed from 83 to 81

    Jetzt ist sie wieder bei 83:

    Code
    1. 3 Spin_Up_Time 0x0007 083 083 001 Pre-fail Always - 314 (Average 387)

    (wobei worst so nicht hinhaut🤔, müsste doch 81 sein, oder?)



    https://www.computerwissen.de/…ameter-im-ueberblick.html


    Auf jeden Fall würde ich mal die SMART Werte anzeigen lassen und über diesen Parameter nachlesen.

    Das habe ich jetzt auch mal gemacht und denke, dass ich heute Nacht beruhigt schlafengehen kann:

    Ich hab' mir noch kurz was gescriptet, das mir das Schlafverhalten aufzeichnen sollte. Mal gucken, wie es morgen aussieht.

    Inzwischen sieht's gut aus, die Platte hatte einen ruhigen Tag.

    Auf jeden Fall würde ich mal die SMART Werte anzeigen lassen und über diesen Parameter nachlesen.

    Werde ich nachher nochmal machen, momentan schläft sie zum Glück. Zuletzt (gestern) sah alles gut aus


    Ich habe hier auch so eine alte WD Platte extern über USB, smartd meldet dort auch hin und wieder fallende Spin-Up Werte.

    [...]

    Wenn es dann im Raum noch kühl ist (Heizung Nachtmodus) scheinen die Lager sehr zählebig zu sein.

    Das ist eine WD Elements, die ich von ihrem Gehäuse "befreit" habe. Zuletzt war die ordentlich unter Dauerlast, erst zum Testen (noch im Gehäuse), dann zum Übertragen der Aufnahmen. Gestern kamen dann zusätzlich Experimente wegen der Schlafmodi hinzu (wurde oft schlafengelegt), außerdem ist die Platte in einen Wechselrahmen im Keller gelandet, wo die Temperatur anderes sein dürfte, gerade wenn die Platte länger geschlafen hat.

    SmartD habe ich übrigens deaktiviert und bisher schläft die Platte brav (momentan über das Testscript von davie2000).


    Das automatische Schlafenlegen über hd-idle funktioniert auch, laut dem Script wurde sie heute Nacht wegen einer Aufnahme geweckt (was auch so ein sollte), schlief heute Morgen aber wieder. Ich lasse jetzt aber trotzdem nochmal das Script laufen, um die Situation weiter zu beobachten.


    Meldungen wie diese:

    Code
    1. Apr 16 13:00:01 vm-host-001 kernel: [71871.622478] lsblk(18758): dirtied inode 35419 (sdc) on sysfs

    sind übrigens nicht der Grund fürs Aufwachen, die sind auch aufgetaucht, während das Testscript lief und die Platten weiterhin geschlafen haben.

    Servus!


    Ich möchte meine Festplatte gerne außerhalb der Fernsehzeiten schlafen legen, die wacht aber leider immer wieder auf.

    Die VDR ist eine Ubuntu 20.04 Qemu-VM, die die Festplatte entweder direkt durchgereicht hat (dann läuft das Stromsparen über den Host) oder gleich einen ganzen SATA-Controller bekommt, wobei die Stromsparmechanismen dann über die VM laufen.

    Das Stromsparen läuft über hd-idle, da die Festplatte hdparm -S nicht zu unterstützen scheint, hdparm -Y schon (HDD stammt aus einer WD Element)


    In der VM geben die Logs für die Festplatte folgendes aus:

    wobei mich vor allem Zeilen wie diese (halbstündiger Schlaf) stutzig machen, da zu der Zeit keine Aufnahmen liefen:

    Code
    1. Apr 16 05:32:25 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is in STANDBY mode, suspending checks
    2. Apr 16 06:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is back in ACTIVE or IDLE mode, resuming checks (1 check skipped)


    Nun habe ich mit "echo 1 > /proc/sys/vm/block_dump" das Überwachen der Festplattenzugriffe gestartet.

    Das sieht auf dem Host (Debian 9) so aus:

    Auf der VDR (dann mit durchgereichtem SATA-Controller) sieht das so aus:

    Code
    1. Apr 16 16:00:01 vdr-server-001 kernel: [ 2135.181940] lsblk(2168): dirtied inode 20759 (sdd) on sysfs
    2. Apr 16 16:00:01 vdr-server-001 kernel: [ 2135.182037] lsblk(2168): dirtied inode 20790 (sdd1) on sysfs



    Mich irritiert dieser regelmäßige stündliche Zugriff auf beiden System. Kann sich da jemand einen Reim drauf machen?

    An der Stelle möchte ich mich auch mal bedanken, zumal VDR vermutlich das Projekt war, das mich endgültig in die Linux-Ecke getrieben hat.

    "Hier" läuft VDR inzwischen als haushaltsübergreifend genutzter Server in einer VM mit PCIe-Passthough, eine tolle Sache!

    Im Frühling oder Sommer steht das Upgrade von Ubuntu 16.04 auf 20.04 an.

    Servus!


    Der Kodi-Rechner (VDR-Client1) wacht mit dem TV aus dem Standby auf und schläft auch mit ihm wieder ein.

    Nach einigen Tagen hängt er sich nach dem Standby allerdings auf, wenn er die EPG-Daten aktualisieren will. Dann hilft nur, in den PVR-Einstellungen die Daten zu löschen oder den Rechner neuzustarten.

    Beim Neustart lösche ich die Daten vorm Starten von Kodi, sodass das Problem behoben ist:

    Code
    1. $ cat start_kodi.sh
    2. rm /home/kodi/.kodi/userdata/Database/Epg11.db
    3. rm /home/kodi/.kodi/userdata/Database/TV29.db
    4. kodi

    Auf Dauer nervt das natürlich. Gibt es eine Möglichkeit, das zu automatisieren bzw das Problem zu beseitigen?

    Wenn ich ein Skript "/usr/lib/vdr/dvbwait" mit den beiden Schleifen erstelle und


    Code
    1. $ cat /lib/systemd/system/vdr.service
    2. [Unit]
    3. Description=Video Disk Recorder
    4. [Service]
    5. Type=notify
    6. ExecStart=/usr/bin/vdr
    7. Restart=on-failure
    8. RestartPreventExitStatus=0 2
    9. [Install]
    10. WantedBy=multi-user.target

    in


    ändere, könnte es klappen, oder?


    Edit:

    Ach nee, so "&&"-Geschichten mag systemd nicht. Also sollte ExecStartPre es tun, oder?

    Bei den meisten Distributionen gibt es kein runvdr mehr. Mit Systemd wird es aber ganz ähnlich gemacht.

    systemd habe ich hier auch:


    Code
    1. $ systemctl status vdr.service
    2. ● vdr.service - Video Disk Recorder
    3. Loaded: loaded (/lib/systemd/system/vdr.service; enabled; vendor preset: enabled)
    4. Active: active (running) since Mo 2019-12-23 10:35:26 CET; 4 weeks 1 days ago
    5. Main PID: 702 (vdr)
    6. Status: "Ready"
    7. CGroup: /system.slice/vdr.service
    8. └─702 /usr/bin/vdr


    Also wird runvdr ignoriert?

    Servus!


    Bei einer VDR gibt es das Problem, dass die VDR schneller als die DVB-Treiber startet.

    Ich habe, abgesehen vom Dynamite-Plugin, eine relativ einfache Idee, wie man das lösen könnte, bin mir aber nicht sicher, ob ich da einen Denkfehler habe.


    Reicht es, die "/usr/lib/vdr/runvdr" von

    in

    zu ändern?


    Ich frage lieber vorher mal nach, weil es zum einen nicht um meine VDR geht und ich zum anderen nicht weiß, wie "haltbar" die Lösung ist, falls sie denn überhaupt funktioniert.

    Hallo,


    wenn ich mich per ssh -X mit einem Ubuntu-Rechner verbinde, kann ich auch mit sudo X-Applications öffnen (z. B. timeshift-gtk).

    Ich bekomme das aber einfach nicht mit Debian hin. Da funktionieren X-Applications über ssh nur als normaler User.

    Hat da jemand einen Tipp?

    Das Programm funktioniert bei mir inzwischen recht zuverlässig.

    Ich nutze es, um Aufnahmen zu sortieren (nach Staffeln, Tatort-Ermittlern usw.) und Abos in MediathekView richtig auf der NAS einzusortieren, wofür ich jeweils Bash-Skripte geschrieben habe, die das Programm nutzen (Beispiele sind im GIT-Repository enthalten). Für das MediathekView-Skript habe ich auf meiner NAS einen Cronjob erstellt, sodass das Updaten der Abos und das Einsortieren vollautomatisch ablaufen.

    Momentan nutze ich DEBs, um das Programm auf meine NAS und meine VDR zu bringen.


    https://github.com/cadivus/tvrecinfo