Ich bin mir nicht sicher, wie gut die Vergleiche passen (Helium 14TB), aber besorgniserregend sollte das bei mir alles nicht sein, wenn ich nicht vollkommen auf dem Schlauch stehe.
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:
(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:
Display MoreCode- ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
- 1 Raw_Read_Error_Rate 0x000b 100 100 001 Pre-fail Always - 0
- 2 Throughput_Performance 0x0004 135 135 054 Old_age Offline - 108
- 3 Spin_Up_Time 0x0007 083 083 001 Pre-fail Always - 314 (Average 387)
- 4 Start_Stop_Count 0x0012 100 100 000 Old_age Always - 47
- 5 Reallocated_Sector_Ct 0x0033 100 100 001 Pre-fail Always - 0
- 7 Seek_Error_Rate 0x000a 100 100 001 Old_age Always - 0
- 8 Seek_Time_Performance 0x0004 133 133 020 Old_age Offline - 18
- 9 Power_On_Hours 0x0012 100 100 000 Old_age Always - 151
- 10 Spin_Retry_Count 0x0012 100 100 001 Old_age Always - 0
- 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 21
- 22 Unknown_Attribute 0x0023 100 100 025 Pre-fail Always - 100
- 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 52
- 193 Load_Cycle_Count 0x0012 100 100 000 Old_age Always - 52
- 194 Temperature_Celsius 0x0002 039 039 000 Old_age Always - 40 (Min/Max 13/57)
- 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
- 197 Current_Pending_Sector 0x0022 100 100 000 Old_age Always - 0
- 198 Offline_Uncorrectable 0x0008 100 100 000 Old_age Offline - 0
- 199 UDMA_CRC_Error_Count 0x000a 100 100 000 Old_age Always - 0
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.
-
Build i386 läuft auf Launchpad(PPA) nicht durch,amd64 ist Ok.
An der Stelle muss ich nachhaken:Es gibt ein PPA, das die Streaming-Funktion in Live bereits hat? Wo?Edit: bei EasyVDR gefunden, aber leider nicht für VDR 2.4.1.
-
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:
sind übrigens nicht der Grund fürs Aufwachen, die sind auch aufgetaucht, während das Testscript lief und die Platten weiterhin geschlafen haben.
-
Sicher? Die Platte ist brandneu, sollte ich nicht erstmal 'ne Weile warten, wie die sich einlebt?
Viel verlieren kann ich nicht, bis auf die Aufnahmen der letzten Tage ist noch alles auf der alten Platte.
-
Das Script (ich muss es nachher mal testen, laufen gerade Aufnahmen) dürfte ein Problem haben:
Die Platte wacht auf, nachdem man hdparm -C benutzt hat.
Edit:
Das Script scheint trotzdem zu funktionieren, mal gucken, was 22:00 passiert.
-
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:
Display MoreCode- Apr 16 02:32:25 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is in STANDBY mode, suspending checks
- Apr 16 03:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is back in ACTIVE or IDLE mode, resuming checks (1 check skipped)
- Apr 16 03:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 36 to 50
- Apr 16 03:32:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 50 to 42
- Apr 16 04:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 42 to 37
- Apr 16 05:32:25 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is in STANDBY mode, suspending checks
- 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)
- Apr 16 06:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Prefailure Attribute: 3 Spin_Up_Time changed from 86 to 83
- Apr 16 06:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 37 to 54
- Apr 16 06:32:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 54 to 42
- Apr 16 07:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 42 to 37
- Apr 16 08:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 37 to 36
- Apr 16 11:32:25 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is in STANDBY mode, suspending checks
- Apr 16 12:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], is back in ACTIVE or IDLE mode, resuming checks (1 check skipped)
- Apr 16 12:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Prefailure Attribute: 3 Spin_Up_Time changed from 83 to 81
- Apr 16 12:02:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 36 to 51
- Apr 16 12:32:20 vm-host-001 smartd[818]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 51 to 40
wobei mich vor allem Zeilen wie diese (halbstündiger Schlaf) stutzig machen, da zu der Zeit keine Aufnahmen liefen:
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:
Display MoreCode- Apr 16 13:00:01 vm-host-001 kernel: [71871.622478] lsblk(18758): dirtied inode 35419 (sdc) on sysfs
- Apr 16 13:00:01 vm-host-001 kernel: [71871.622514] lsblk(18758): dirtied inode 35391 (sdc) on sysfs
- Apr 16 13:00:01 vm-host-001 kernel: [71871.622571] lsblk(18758): dirtied inode 48169 (sdc1) on sysfs
- Apr 16 13:00:01 vm-host-001 kernel: [71871.622590] lsblk(18758): dirtied inode 35395 (sdc) on sysfs
- Apr 16 14:00:01 vm-host-001 kernel: [75471.883923] lsblk(19468): dirtied inode 35419 (sdc) on sysfs
- Apr 16 14:00:01 vm-host-001 kernel: [75471.883960] lsblk(19468): dirtied inode 35391 (sdc) on sysfs
- Apr 16 14:00:01 vm-host-001 kernel: [75471.884023] lsblk(19468): dirtied inode 48169 (sdc1) on sysfs
- Apr 16 14:00:01 vm-host-001 kernel: [75471.884043] lsblk(19468): dirtied inode 35395 (sdc) on sysfs
- Apr 16 15:00:01 vm-host-001 kernel: [79071.865083] lsblk(20118): dirtied inode 35391 (sdc) on sysfs
- Apr 16 15:00:01 vm-host-001 kernel: [79071.870732] lsblk(20119): dirtied inode 35419 (sdc) on sysfs
- Apr 16 15:00:01 vm-host-001 kernel: [79071.870841] lsblk(20119): dirtied inode 48169 (sdc1) on sysfs
- Apr 16 15:00:01 vm-host-001 kernel: [79071.870862] lsblk(20119): dirtied inode 35395 (sdc) on sysfs
Auf der VDR (dann mit durchgereichtem SATA-Controller) sieht das so aus:
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.
-
Schade, das hat's nicht gebracht. Das Problem besteht weiterhin.
-
Du meinst das (Anhang)?
Das ist mir tatsächlich nie aufgefallen, wusste nicht, dass das geht.
PS:
Da kann man sogar einstellen, dass er ein paar Minuten Puffer in Aufnahmen hat!
Dachte, dass das nur über VDRAdmin-AM geht. Man lernt nie aus...
-
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:
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
in
Display MoreCodeä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:
Display MoreCodeCode- $ systemctl status vdr.service
- ● vdr.service - Video Disk Recorder
- Loaded: loaded (/lib/systemd/system/vdr.service; enabled; vendor preset: enabled)
- Active: active (running) since Mo 2019-12-23 10:35:26 CET; 4 weeks 1 days ago
- Main PID: 702 (vdr)
- Status: "Ready"
- CGroup: /system.slice/vdr.service
- └─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
Display MoreShell-Script- #!/bin/sh
- . /usr/lib/vdr/config-loader.sh
- VDR_ENV="LANG=$VDR_LANG LC_ALL=$VDR_LANG"
- VDRCMD="$VDR_ENV /usr/bin/vdr $*"
- VDR_ERR=`mktemp -p /tmp vdr-err.XXXXXX`
- while (true) do
- eval $VDRCMD >/dev/null 2>"$VDR_ERR"
- case $? in
- 0)
- exit
- ;;
- 2)
- ERROR=`cat "$VDR_ERR"`
- logger -t runvdr "stopping after fatal fail ($ERROR)"
- exit
- ;;
- esac
- logger -t runvdr "restarting VDR"
- done
in
Display MoreShell-Script- #!/bin/sh
- while [ ! -e '/dev/dvb/adapter0/frontend0' ]; do
- sleep 5s
- done
- while [ ! -e '/dev/dvb/adapter1/frontend0' ]; do
- sleep 5s
- done
- #eigentliches Script
- . /usr/lib/vdr/config-loader.sh
- VDR_ENV="LANG=$VDR_LANG LC_ALL=$VDR_LANG"
- VDRCMD="$VDR_ENV /usr/bin/vdr $*"
- VDR_ERR=`mktemp -p /tmp vdr-err.XXXXXX`
- while (true) do
- eval $VDRCMD >/dev/null 2>"$VDR_ERR"
- case $? in
- 0)
- exit
- ;;
- 2)
- ERROR=`cat "$VDR_ERR"`
- logger -t runvdr "stopping after fatal fail ($ERROR)"
- exit
- ;;
- esac
- logger -t runvdr "restarting VDR"
- done
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.
-
Ja, die Variante nutze ich momentan.
Ist aber eben QnD.
-
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?
-
Guckt euch mal das neue Release an.
Ich habe eine Option "--move-to-title" eingebaut, mit der das ganze dann mit dem Titel gemacht wird.
Wenn man sich den Ordner dann z. B. in vdradmin-am anguckt, kann man die Aufnahmen darin nach Datum usw. sortieren.
-
Ahhh, ich glaube ich bekomme eine Idee, worum es geht.
Kannst du von so einer Aufnahme bitte mal die info-Datei posten?
-
Bei mir hat z.B. die Sendung mit der Maus kein Subheading, was es dann
etwas schwer macht.
Die Frage wäre dann, wonach in dem Fall sortiert werden soll. Nach Datum und Uhrzeit ist's in der Regel schon sortiert.
-
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.
