Beiträge von cduerr

Die Hersteller haben meist Webseiten, wo sie schildern, wie sie selbst reklamierte Festplatten erhalten wollen. *DAS* ist das Gegenteil davon. Aber unabhängig davon habe ich auch erfahren müssen, dass die großen Festplatten hinsichtlich Anlaufströmen größere Anforderungen stellen (vielleicht ergab sich ein instabiler Zustand). Nichtsdestotrotz: so verpackte Festplatten nehme ich gar nicht mehr an.

Spaßige Info: Versucht mal, einem DPD-Fahrer, der vernehmbar die Festplatte in dem Karton hin- und herschießt mitzuteilen, dass Ihr die Annahme verweigert. Der gibt (gab) sie einfach einem unbedarften Nachbarn ab, der dachte, er tue mir was gutes. Ziemlich daneben, der Bote.

Zitat von SHF

Der "magische" Befehl badblocks -n -s -v -c 256 -b 4096 -t "random" DEVICE hat es vollbracht. Danach rannte die SSD plötzlich wieder.

das klingt *extrem* nach einem Problem analog wie das schon genannte bei den alten Samsung SSDs (soweit ich weiß, war der Fix damals lt. heise auch nur ein Umkopieren durch diese Samsung-Software).

danke Dir. An anderer Stelle las ich, es könne einfach an der (Laufwerks-)Firmware liegen und ich solle eine andere SSD benutzen.

Hallo,

solange ich focal drauf hatte hat das Schlafenlegen von RAIDz1-Membern mittels hd-idle funktioniert.

Seit jammy nicht mehr, obwohl hd-idle eigentlich läuft. Problematisch ist, dass die Festplatten dicht verbaut sind und eigentlich nur temporär laufen sollen.

Was kann ich tun, um das automatische Schlafenlegen wieder zu haben?

Ein

hdparm -y /dev/sdc
hdparm -y /dev/sdd
hdparm -y /dev/sde

funktioniert. Kann man hd-idle wieder ans Laufen bekommen? Kann der smartd da eine Rolle spielen? Gibt es eine Möglichkeit, beide gleichzeitig laufen zu lassen?

Hallo,

ich hoffe, man kann diese Frage verzeihen:

Ich habe in meinem vdr die mSATA-SSD ausgetauscht (zu SKC600MS/256GB) und jetzt leuchtet die Aktivitäts-LED fast dauerhaft. Nur manchmal geht sie so kurz aus, wie sie eigentlich angehen sollte. System läuft ohne Probleme. Kabel steckt richtig (andersrum leuchtet es gar nicht). Die SSD habe ich schon aus- und nochmals eingebaut, selbes Verhalten. Die alte SSD (Apacer 64GB) erzeugt dieses Problem nicht. Bin ein wenig baff. Das einzige, was mich wundern tut (neben dem Licht an): man kann relativ viel der Kontakte sehen, aber sie ist bis Anschlag drin und sie funktioniert ja auch).

Hat da jemand einen Hinweis, was das sein könnte?

Hallo,

ich möchte ganz lieben Dank sagen und etwas Feedback geben:

-Meinen vdrserver konnte ich ja mit seahawks Hinweis aus #3 und seinen PPA-Webseiten upgraden. (Automatisch war vdr nicht aktualisiert; ich habe dann mit dpkg --list | grep vdr | grep focal die Pakete identifiziert, die ich nach dem do-release Upgrade (mit den neuen PPAs) auf jammy einzeln installiert habe).

-Bei meinem vdr3 hatte ich leider irgendwelche Abhängigkeiten drin (sh. RE: YAVDR für Ubuntu 22.04 LTS). Habe mir eine größere SSD beschafft, die alte Ubuntu-Installation via clonezilla zurückgesichert und eine weitere Ubuntu20.04-Installation unabhängig davon hinzugefügt. Dort habe ich yavdr-ansible nach Anleitung (aber gleich mit seahawk1986-PPAs und hoffentlich diesmal sauber angepasster host_vars/localhost) installiert. Anschließend habe ich noch die Einstellungen des alten vdrs übertragen und eine reccmds.custom.conf nach /etc/vdr/command-hooks kopiert. Bis jetzt schaut es ganz gut aus.

Ich habe jetzt einmal einen Verstärker ausproibert -

Axing BVS12-69N. Lieferzustand (nicht an den Reglern herumgespielt). TV-Ausgang Kabeldose, Adapter Koax-F-Stecker-Kabel, Verstärkereingang, Verstärkerausgang, F-Stecker-Kabel, großer Verteiler (mit 11dB Dämpfung lt. Aufdruck), F-Stecker-Kabel, M4.

Das meint femon:

root@vdrserver:~# svdrpsend -d vdrserver -p 6419 plug femon INFO
220 vdrserver SVDRP VideoDiskRecorder 2.6.6; Fri Mar 22 18:56:03 2024; UTF-8
900-CARD:3
900-STRG:95
900-QUAL:100
900-TYPE:DVB-C
900-NAME:M4
900-STAT:001F
900-SGNL:-39.77
900-CNRA:38.63
900-BERA:0
900 CHAN:Das Erste HD;ARD:314000:C0M256:C:6900:5101=27:5102=deu@3,5103=mis@3,5107=qks@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0
221 vdrserver closing connection

Bei den öffentlichen HD-Sendern hatte ich (bis jetzt) keine Fehler mehr gesehen.

Bei RTL NITRO gibt es leider noch (wenige) Fehler, wobei ich keine Ahnung habe, wie sichtbar die sind.

Habe auch einen w_scan laufen lassen und die Parameter für Nitro sehen eigentlich noch gleich aus. Natürlich QAM256 - vielleicht grenzwertig. Meiner Meinung nach hat Pyur ordentlich herumgeschraubt, schon die Aufnahmengrößen sind massiv verändert (1/4 von vor anderthalb Jahren). Und nicht ohne Einfluss auf die Qualität.

Aber ich verfolg das mal, ich könnte mir vorstellen, dass es im Großen und Ganzen jetzt gehen könnte.

tja, zwei unbeaufsichtigte Aufnahmen später und es gibt schon wieder Fehler, auch auf den schon getesteten Kanälen. Nichts angefasst oder bewegt, nicht einmal rebootet dazwischen - Irre.

Zitat von davie2000

Früher (TM) gabs mal sowas wie Interrupts (IRQs).
Wenn sich zwei Stück Hardware da einen geteilt haben, gabs gern solche Probleme.
Ob das heute noch ein Thema ist, kann ich nicht beurteilen.

ich wüsste nicht, warum die Verteilung zwischen dem einen Boot zum nächsten zwar nicht von mir geändert worden wäre, aber dennoch unterschiedliche Auswirkungen häte haben sollen.

Zitat von rüsseltier

Netzwerk: Ist in deinen Tests zufällig Samba über gvfs am Start? Letzteres ist ein Bremsklotz der Sonderklasse.

ich weiß gar nicht, was Du damit meinst. Getestet habe ich entweder lokalen Durchsatz mittels dd if=/dev/zero oder mittels Dateifreigabe auf dem Mac.

Hallo,

nachdem ich die Software aktualisiert habe, hat sich mit vdr-2.6.6 eine ganz andere Möglichkeit geboten:

Chunks gleicher Größe auf demselben Kanal mit unterschiedlichen Adaptern durchzuführen.

Eigentlich hätte ich gedacht, zu große Dämpfung wäre mein Problem.

Ich meine jedoch, die Regelhaftigkeit "größere Dämpfung = weniger Fehler in der Aufnahme" zu sehen:

hier der aktuelle Zustand mit Axing BVE 40-01 6fach-Verteiler mit 7,5dB-Verteildämpfung
Aufnahme: - generelle Beobachtung: auffällig viele Fehler, egal wo
19:49:15.640 § root@vdrserver:/srv/vdr/video/Verschiebehafenvideo# svdrpsend -d vdrserver -p 6419 plug femon NEXT
19:49:15.660 § 220 vdrserver SVDRP VideoDiskRecorder 2.6.6; Tue Mar 19 19:49:15 2024; UTF-8
19:49:15.759 § 900 Cannot switch device
19:49:15.759 § 221 vdrserver closing connection
19:49:19.077 § root@vdrserver:/srv/vdr/video/Verschiebehafenvideo# svdrpsend -d vdrserver -p 6419 plug femon INFO
19:49:19.098 § 220 vdrserver SVDRP VideoDiskRecorder 2.6.6; Tue Mar 19 19:49:19 2024; UTF-8
19:49:19.219 § 900-CARD:3
19:49:19.262 § 900-STRG:58
19:49:19.262 § 900-QUAL:100
19:49:19.262 § 900-TYPE:DVB-C
19:49:19.262 § 900-NAME:M4
19:49:19.262 § 900-STAT:001F
19:49:19.262 § 900-SGNL:-55.27
19:49:19.262 § 900-CNRA:38.63
19:49:19.262 § 900-BERA:0
19:49:19.262 § 900 CHAN:Das Erste HD;ARD:314000:C0M256:C:6900:5101=27:5102=deu@3,5103=mis@3,5107=qks@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0
19:49:19.262 § 221 vdrserver closing connection

hier der neue Renkforce 3fach-Verteiler mit 6-7,5dB Verteildämpfung
Aufnahme: 8min Clip Das Erste HD Tagesschau, 80 Fehler
20:00:31.531 § root@vdrserver:/srv/vdr/video/Verschiebehafenvideo# svdrpsend -d vdrserver -p 6419 plug femon INFO
20:00:31.553 § 220 vdrserver SVDRP VideoDiskRecorder 2.6.6; Tue Mar 19 20:00:31 2024; UTF-8
20:00:31.675 § 900-CARD:3
20:00:31.718 § 900-STRG:66
20:00:31.718 § 900-QUAL:100
20:00:31.718 § 900-TYPE:DVB-C
20:00:31.718 § 900-NAME:M4
20:00:31.718 § 900-STAT:001F
20:00:31.718 § 900-SGNL:-53.28
20:00:31.718 § 900-CNRA:38.84
20:00:31.718 § 900-BERA:0
20:00:31.718 § 900 CHAN:Das Erste HD;ARD:314000:C0M256:C:6900:5101=27:5102=deu@3,5103=mis@3,5107=qks@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0
20:00:31.718 § 221 vdrserver closing connection

hier nur ein Zwischenstecker zur Kabelverängerung
Aufnahme: 8min Clip Das Erste HD Die Notärztin, 241 Fehler
20:18:05.442 § root@vdrserver:/srv/vdr/video/Verschiebehafenvideo# svdrpsend -d vdrserver -p 6419 plug femon INFO
20:18:05.461 § 220 vdrserver SVDRP VideoDiskRecorder 2.6.6; Tue Mar 19 20:18:05 2024; UTF-8
20:18:05.579 § 900-CARD:3
20:18:05.621 § 900-STRG:86
20:18:05.621 § 900-QUAL:100
20:18:05.621 § 900-TYPE:DVB-C
20:18:05.621 § 900-NAME:M4
20:18:05.621 § 900-STAT:001F
20:18:05.621 § 900-SGNL:-48.02
20:18:05.621 § 900-CNRA:39.27
20:18:05.621 § 900-BERA:0
20:18:05.621 § 900 CHAN:Das Erste HD;ARD:314000:C0M256:C:6900:5101=27:5102=deu@3,5103=mis@3,5107=qks@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0
20:18:05.621 § 221 vdrserver closing connection

hier der große Renkforce-Verteiler mit 11dB Verteildämpfung
Aufnahmen: Das Erste HD, zdfNeo HD, arte HD: je 8min Clips, je ohne Fehler
20:35:43.485 § root@vdrserver:/srv/vdr/video/Verschiebehafenvideo# svdrpsend -d vdrserver -p 6419 plug femon INFO
20:35:43.505 § 220 vdrserver SVDRP VideoDiskRecorder 2.6.6; Tue Mar 19 20:35:43 2024; UTF-8
20:35:43.629 § 900-CARD:3
20:35:43.669 § 900-STRG:62
20:35:43.669 § 900-QUAL:100
20:35:43.669 § 900-TYPE:DVB-C
20:35:43.669 § 900-NAME:M4
20:35:43.669 § 900-STAT:001F
20:35:43.669 § 900-SGNL:-54.00
20:35:43.669 § 900-CNRA:38.63
20:35:43.669 § 900-BERA:0
20:35:43.669 § 900 CHAN:Das Erste HD;ARD:314000:C0M256:C:6900:5101=27:5102=deu@3,5103=mis@3,5107=qks@3;5106=deu@106:5104;5105=deu:0:10301:1:1019:0
20:35:43.669 § 221 vdrserver closing connection

Dadurch bin ich (perverserweise) zurück beim ursprünglichen Verteiler, den ich in der Empfangskette hatte, als ich diesen Thread geöffnet hatte (mit dem Unterschied: ich habe in Erinnerung, dass damals die Muttern nicht arretiert waren).

Ich finde auch, dass das Verhalten in der Aufnahmequalität nicht wirklich mit den Signalparametern angedeutet wird.

Hi,

mein aktualisierter vdrserver hat leider Augenblicke, da liefert weder die NVMe-SSD die nahe 3GB/s, noch das Netzwerk die 220MB/s (nicht einmal 90MB/s)... Ich habe ein Band bei der SSD von 330-620MB/s (ggü. 3,1GB/s normal) und bei der NIC (RTL8125) von 40-90MB/s ggü. 230MB/s normal.

Die Tuner- und die NVMe-Karte stecken jeweils in PCIe-Slots, deren Lanes direkt an der CPU hängen. Netzwerkkarte und eine meist nicht verwendete USB-Karte sowie die ganzen SATA-Geräte hängen am ICH, wobei das Ivy Bridge, PCIe 3.0 und DMI 2.0 sein sollte.

Ich habe die Regelhaftigkeit noch nicht herausgefunden, nach der das Problem auftritt. HWE-Kernel oder 5.15.0-100 spielen keine Rolle.

Die NVMe-SSD ist nach /srv gemountet, SATA-Geräte (darunter ein ZFS-RAIDz1) sind darunter bind mounted.

Ich vermute kein Hardwareproblem, sondern Ubuntu 22.04 oder den gleichzeitigen Zugriff irgendeines Prozesses vs. meinen Tests.

Kann da der Power-Governor eine Rolle spielen? Schedutil ist eingestellt (ist glaube ich auch der Default).

Irgendeine Idee, wie man das Verhalten untersuchen kann oder ist es jemandem gar bekannt? Normalerweise sollte bereits eine SATA-SSD völliger Overkill sein, aber mit dem Verhalten fürchte ich, könnte es mit den Fehlern in Aufnahmen zusammenhängen, die ich beobachte.

Das hier ist schon eine Hardwarefrage: Kann man an der vermuteten Ursache gleichzeitigen Zugriffs vielleicht mit einer leistungsfähigeren SSD (Samsung 980 Pro, derzeit eine Transcend 220S; die Samsung hat 3x mehr IOPS, wobei ich gedacht hätte, 400k IOPS wären bereits ausreichend) "workarounden"? PCIe 4.0 brächte natürlich nichts weiter, gibt's halt nicht, das wäre mir klar.

hm, das habe ich versucht. Den vdr-2.6.6 hat er auch installiert. Dann aber beim apt dist-upgrade ein paar Plugins removed.

Habe ich auch nicht mehr installieren können (Abhängigkeiten). Ich habe vermutlich ein Wirrwarr an installierten Paketen, denn benutzt wurde vdr-2.4.8 und ohne Skinelchihd - ich mache neu, aber auf neuem Datenträger, wo ich den Platz für mehrere Systeme habe. Vielleicht schreibe ich diesmal *endlich* auf, was ich gemacht habe. Verflixt.

(Update: RE: Focal-basierten yavdr-ansible upgraden? Und weil ich das hier in #64 geschrieben hatte: der neu installierte Client-vdr3 (sh. Link) zeigt die Aufnahmegrößen mittlerweile korrekt an.)

Hallo,

ich habe auf meinem vdrserver (headless) das Upgrade (mittels do-release-upgrade) gewagt und später die PPAs von Seahawk hinzugefügt. Läuft.

Auf dem Client bin ich noch bei Focal mit einem vdr-2.4.1. Dort habe ich das Problem, dass mir die Aufnahmegrößen völlig falsch angezeigt werden; ich würde sagen: das ist Faktor 2 zu groß. Ein vom vdr-Client gestartetes Skript zum Schnitt der auf dem Server liegenden Aufnahmen funktioniert zwar prinzipiell, aber die Schnittmarken werden nicht respektiert. Klingt ein wenig wie ein Datenfeld hat sich verändert.

Ist das ein bekanntes Problem? Was sollte ich tun, um das Problem zu lösen?

(Als zweites Problem hat lcdproc wohl seine Konfiguration nicht automatisch anpassen können - was mache ich denn da?)

gute Frage. Eigentlich nicht. Ich kann nur sagen, was ich feststelle

ja, habe ich, aber das Verhalten hat mir nicht wirklich gefallen: das Resultat war ohnehin nicht hilfreich und die Fritzbox wankte in der Darstellung von Heimnetzwerk ständig, der Host verschwand (offline), tauchte wieder auf, war wieder der vdrserver-3 und das alles im Circle. Hatte das auch verbunden mit dem Bearbeiten des Namens in der FB. Habe auch die FB neugestartet.

Am Ende war für das Mounten auf dem Client zielführend, dass der avahi-set-host-name aufgerufen wird.

Ich habe noch einmal die BIOS-Settings mit dem DZ77BH-55K (ich hatte ein Video gemacht) verglichen und mindestens die Änderung CIR aus gefunden. Nach zusätzlichen Wake-Events habe ich auch geguckt, aber ich finde dort nur PS/2 Keyboard Wake (und das ist per Default disabled). Das ist noch aus. Aber obwohl HPET enabled ist hat das Ding jetzt seit kurz nach meinem letzten Posting zuverlässig gebootet/sich heruntergefahren (und blieb auch aus). Was mich noch interessiert: Verhalten nach stromlos machen. Ich hoffe, das Gerät kommt dann hoch, wartet die Inaktivitätszeit ab und fährt dann herunter wie er soll.

das Verhalten scheint reproduzierbar zu sein.

Ich habe mir jetzt ein Script fix-avahi.sh in die rc.local eingebaut, die genau den avahi-set-host-name wie oben setzt und danach den nfs-kernel-server neustartet. Mal gucken, ob das hilft.

Hi,

hatte jetzt - merkwürdigerweise - zweimal den Fall, dass der vdrserver als vdrserver-3 in der Fritzbox auftauchte. Verstehe den Zusammenhang nicht falls es einen gibt; *daran* habe ich nicht gespielt (Ich habe an der Fritzbox allerdings, da der *Mist*-ISP jetzt eine CG-NAT-IP vergibt, IPv6 aktiviert (in der Folge stehen jetzt auch im vdrserver IPv6-Adressen)).

Dummerweise mountet wenn es vdrserver-2 oder -3 ist der Client das NFS-Verzeichnis nicht mehr.

Meine Abhilfe:

-Namen in der Fritzbox editieren

-avahi-set-host-name vdrserver

-systemctl restart nfs-kernel-server

-Reboot vdr3

Gibt es stattdessen die Möglichkeit, den mDNS-Hostnamen fest (über Reboots) zu konfigurieren?

Wie zum Geier kommt es überhaupt zu der Mehrfachbelegung? Kann es an IPv6 liegen? Die Probleme liest man ja z.B. bei Mac/Fritzbox ständig.

Zitat von cduerr

Damit ich ein besseres Gefühl bekomme sollte es nach der nächsten Aufnahme herunterfahren und dann planmäßig für den EPG-Sync wieder starten, damit ich das reproduziertreproduziert nennen kann.

tja, der Rechner hat dreimal korrekt geschlafen und ist wieder aufgewacht und als dann der EPG-Sync um 1 Uhr kam (wozu er auch korrekt aufgewacht ist), bootete er wieder in der Schleife (mit HPET an). Abstrakt, jedenfalls, wenn es doch dreimal ging und zwischendrin nichts verändert wurde. Oder hat sich die Mondfeuchte geändert?

Wahrscheinlich muss ich mit "HPET OFF" auch noch genauer testen.

Sollte man HPET überhaupt einschalten, tut das Not?

Hallo,

ich habe weiter geguckt und heute ein wenig rumprobiert. Leider müssen ja immer mehrere Dinge zusammentreffen - Lust, Zeit, Lücken in den Aufnahmen. Am WOL hat es nicht gelegen. Der Rechner startet dennoch reproduzierbar neu. Die geschriebenen Timer passen allesamt.

Deswegen habe ich heute den Versuch gewagt, HPET im BIOS zu deaktivieren. Damit klappte es auf Anhieb.

Aber wer jetzt sagt "habe ich doch gesagt!" - ich habe es jetzt probeweise wieder aktiviert und es geht auch (tat es auf dem anderen Bord ja auch und ich gehe mal ganz stark davon aus, dass intel keine unterschiedlichen Codebasen hat)! Muss ich das jetzt verstehen? BIOS verschluckt oder was?

Damit ich ein besseres Gefühl bekomme sollte es nach der nächsten Aufnahme herunterfahren und dann planmäßig für den EPG-Sync wieder starten, damit ich das reproduziertreproduziert nennen kann.