RPI mit VDR Erfahrungen ?! und Fragen

  • weil hier was im Milli bis Mikrosekundenbereich passiert. In diesem Bereich bricht ja nicht die Spannung schlagartig zusammen und alles ist gleichzeitig stromlos. Einige Teile werden durch die sinkende Spannung schon funktionslos, während andere Teile noch ihre Arbeit machen, wenn ich während des Betriebes den Stromstecker ziehe. Da muss nichts passieren - kann aber, je nachdem, was betroffen ist.

  • Letztlich kann keiner mit Gewissheit etwas sagen weil keiner die SD-Controller im Detail kennt. Ich halte es genauso für unwahrscheinlich das der plötzliche Stromausfall schadet wie ich es für unwahrscheinlich halte, dass die billigen SD-Karten ein Wear-Leveling machen.

  • primär ist es nicht der Punkt billig oder teuer, sondern Consumer oder Industrie SD Karten. Zwischen denen gibt es gewaltige Unterschiede. --> http://www.cactus-tech.com/en/…grade-vs-commercial-grade


    Und das ist nicht nur der erweiterte Temperaturbereich für draußen, sondern auch Schreibzyklen, Wear Leveling und teilweise auch puffern der Betriebsspannung. Aber das macht sie sekundär auch astronomisch teuer. Wir müssen für vergleichbare Karten ( CF 1Gb) über 80 Euro bezahlen. Normale Karten jedoch laufen nur ein paar Wochen (getestet).

  • Tscha, eigentlich war ich ja fan davon, dass der client moeglichst standalone ist, also dachte ich daran, die SD readonly zu machen, so dass ich dann so einen client auch schoen per ssh troubleshooten kann, selbst wenn mal irgendwas mit dem server/netz/svdrp/etc schief geht.


    Jetzt lese ich aber gerade den thread zum VDR 2.3.1 wo ja wohl vieles fuer multi-VDR installationen vereinfacht wird, aber wie praktiziert man den umstieg von 2.2.x auf 2.3.x in einem multi-VDR produktivsystem mit hohen WAF requirements ?


    Bei mir ist es halt ein zentraler VDR server, der auf verschiedenen Boot-partitionen verschiedene VDR versionen hat. Damit kann man immer sehr schoen per chroot an der naechsten Linux/VDR/etc. version arbeiten, oder dann schnell wieder die "alte" Version booten, wenn dann doch unerwarteterweise nach einem Monat mit einer neuen Installation dort ein Problem auftaucht, etc. pp . Ja klar, mehrere Server-PCs (neu/alt) waere prima, aber dafuer muss ich erstmal meine DVB-S2 tuner und LNBs amortisiert haben und auf SAT-IP umsteigen, ansonsten geht das nicht wirklich.


    Aber zurueck zum client: Gemischter 2.2.x und 2.3.x Betrieb wird da nicht viel Spass machen, und auch nicht erlauben, die Vorteile von 2.3.x richtig auszufahren. Also will man eigentlich eine einfache Moeglichkeit ahben, das komplette System zwischen 2.2.x und 2.3.x hin und her zu schalten. Auf dem Server ist das ein reboot mit anderer Rootpartition (aufzeichnungen usw sind auf einer separaten partition). Aber wie sieht's mit den ganzen RPI's im Haus aus ?


    Antwort: wenn die RPIs ihre VDR installation aktiv ueber netboot vom server laden, dann geht das ganz einfach. Einfach die RPIs rebooten wenn man den Server rebootet hat. AM besten automatisiert. Und jede VDR server installation hat ihre eigene passende, NFS exportierte rootdirectory fuer die clients.


    Und mit cross-compile umgebung auf dem server hat man auch die einfachere moeglichkeit die RPI installationen zentral schnell u patchen.

  • Auf dem Server ist das ein reboot mit anderer Rootpartition (aufzeichnungen usw sind auf einer separaten partition). Aber wie sieht's mit den ganzen RPI's im Haus aus ?


    also bei mir siehts so aus, das ich pro Client immer mehrere SD-Karten habe. Eine läuft produktiv, eine ist backup, eine immer zusätzlich mit altem stable Stand usw. So kann ich was neues ausprobieren, habe backup und Rückfallebene. Und bei den billigen Karten mache ich mir auch keine Sorgen über den Ausfall. Ich habe jeweils Ramlog installiert, sodass die Masse an Schreibaktivitäten dorthin geleitet wird. Die RPIs laufen bei mir zwar nicht durch, jedoch einige Stunden täglich und das schon einige Jahre.

  • Bei dem Raspberry von dem ich geschrieben habe, handelt es sich um einen Aufbau mit sehr genau definiertem Aufgabenbereich. Hier war es relativ einfach für die wenigen Programme, die hier involviert sind, rauszufinden was die gerne wo schreiben würden und denen jeweils beizubringen das sie auf eine RAM-Disk zu schreiben haben, weil eben garnichts permanent geschrieben werden soll. Die ermittelten Daten werden jeweils nur flüchtig gesammelt und täglich komprimiert via Mobilfunk an einen entfernten Server geschickt. Allerdings habe ich hier auch nicht den Fall, dass sehr oft einfach so Strom abgeschaltet wird. Das passiert nur bei unvorhergesehenen Stromausfällen, die wir in Deutschland ja eher selten haben. Ich bin selber überrascht, dass der Raspi schon über ein Jahr Uptime drauf hat und ich bin umso gespannter wie lange das noch gut gehen wird.


    Bei einer Art "Media-Client" würde ich vermutlich eher eine der mittlerweile zahlreichen Anleitungen zum Thema "Wie hänge ich meine Root-Partition via USB dran" befolgen um dann eine echte SSD in einem USB-Gehäuse dranzuhängen. Die SD dann wieder Read-Only nur mit dem für's Booten nötigen Kram. Jede halbwegs hochwertige SSD ist an der Stelle einer SD-Karte um Längen voraus.

  • Wie geschrieben. Standard SD im Raspberry 24/7 schon über ein Jahr ohne Ausfall. Allerdings eben Read-Only.


    Semi-OT:
    Also ich kann das mit der Stromversorgung wirklich nur unterstreichen. Wir nutzen einen Pi um Temperaturen im Beobachtungsraum zu loggen. Im ersten halben Jahr sind uns mind. 3 Karten flöten gegangen, auch sehr hochwertige. Vor 2 1/2 Jahren haben wir auf neue 2A Netzteile umgestellt, und seitdem ist (ohne weitere Änderungen) nicht ein einziges Problem aufgetreten, trotz 24/7 und rw-mount mit fleissig Schreiboperationen....

    VDR2: ASRock J4105-ITX, DVBSky S952, openSUSE Tumbleweed, VDR 2.4.7

    softhddevice/vaapidevice, DFAtmo, xmltv2vdr, tvscraper, tvguideng, VDRAdmin-AM (alles git, aber alt)

Jetzt mitmachen!

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