Beiträge von SHF

    Wenn mal eine kurze Downtime verkraftbar ist, würde ich mir das Raid sparen.


    Zumal bei mir schon mal eine defekte SSD das ganze System blockiert hat, so dass es auch von einem USB-Stick nicht mehr bootbar war.


    Ich mache automatisch, täglich ein Backup auf die eingebaute HDD. Da verliere ich bei einem Ausfall nicht viel.

    Wenn auch das Ersatzdisplay Macken macht, würde ich auf die Platine im Gehäuse tippen.

    Das neue Display war doch wirklich neu und nicht gebraucht?


    Ein Reparaturversuch lohnt sich bei dem Gehäuse IMHO aber.


    Der Fehler sollte eigentlich recht einfach zu finden sein, das sollte jeder Radio und Fernsehtechniker können.

    Versand von Klopper macht aber wenig Sinn und einzeln kann man die Teile nicht testen.


    Du könntest es mal bei einem RepairCafe versuchen, in den meisten grösseren Städten findet sowas inzwischen regelmässig statt.

    Ich denke, die werden sich freuen, wenn mal jemand mit schöner Hardware kommt und nicht nur mit Billig-Schrott ;D.

    Wenn es die Inverter für die CCFL-Röhren sind, die auf der Platine sind hin sind, sind die durchaus reparabel.

    Die sind immer gleich aufgebaut und nicht kompliziert. Für Jemand der sich auskennt, kein grösseres Problem.

    Ist es möglich das die Internetverbindung hergestellt wird ohne Benutzeranmeldung?

    Es müsste sich eigentlich über die Konfiguration des Networkmanager machen lassen, so dass gewisse Verbindungen Systemweit aktiv sind.


    Wie stellt man ab das sich das System nach einer bestimmten Zeit inaktivität auslockt? Habe in den Systemeinstellungen diesbezüglich nichts gefunden.

    Die Energie-Optionen bei den KDE-Systemeinstellungen sind bei Debian in ein extra Paket gewandert (was auch immer die sich dabei gedacht haben). Das könnte auch bei mint der Fall sein.

    Also zum einen solltet Ihr schon korrekterweise vdr-plugin-xineliboutput schreiben, weil vdr-plugin-xine ist ein ganz anderes Plugin von rnissl, seit Jahren nicht mehr weiterentwickelt.

    Wo es ums (VDR-)Plugin ging, steht immer Xineliboutput-Plugin.

    Bei der Fragestellung ist das Plugin aber unerheblich, da das auf die Hardwareunterstützung der Xinelib keinen Einfluss hat.


    Meine Frage bezog sich auf Xine, also xinelib und die darauf basierenden Player xine, gxine, fbxine, vdr-sxfe, vdr-sxfe... , in wieweit die den Hardware-Decoder vom RPI unterstützen.

    Zum anderen gibt es m.E. zwei Ausgabefrontends bei xineliboutput, sxfe für die X11 Ausgabe und fbfe für die Ausgabe ohne X11 ... ?

    Der zur Xinelib gehörende Player /usr/bin/xine(Debian-Paket: "xine-ui") geht auch, wenn man die MRL wie folgt aufruft: xine xvdr://VDR_IP:37890#nonache

    Die Unterstützung kommt bei Debian aus dem Paket "libxine2-xvdr" (Quellpaket: "vdr-plugin-xineliboutput").

    Prinzipiell sollte da jeder auf der Xinelib basierende Player wie fbxine gehen.
    Wenn man auf das OSD verzichten kann gehen alle Player, die einen entsprechenden rtp oder http Stream wiedergeben können.


    Dann gibt es noch das Paket "libxine2-vdr" das stammt aus den Quellen der Xinelib und ist für das alte vdr-plugin-xine.

    In wie weit die beiden kompatibel sind hab ich noch nicht probiert.


    Das vdr-plugin-xvdr ist, hat trotz Namensgleicheit mit dem Protokoll, nichts mit Xine zu tun.

    Es war der Vorläufer des vdr-plugin-vnsiserver zur Anbindung an XBMC (jetzt Kodi). Aktuell noch verwendet bei "robotv" für Android.

    Ob das Protokoll identisch ist oder nicht, konnte ich nicht in Erfahrung bringen.

    Denkbar dass das letztere für mmal nutzbar ist?

    Es ist nutzbar, siehe Post #3.

    Nochmal danke an Seahawk für's probieren!


    Inzwischen habe ich gelesen, dass auch ffmpeg die mmal-Decoder unterstützen soll.

    Da Xine auch ffmpeg als Decoder verwenden kann, könnte es auch über den Umweg gehen.


    PS.: Oder einfach LibreELEC auf dem RPi nutzen und mit dem VDR per vdr-plugin-vnsiserver verbinden ...

    Über Kodi hab ich aber doch kein OSD vom VDR?

    Abgesehen von einer selbst gebauten libxine-1.2, die das mmal-Ausgabeplugin behinhaltet, xorg usw. ...

    Auf meinem "normalen" Computern ging es mit Debian "out of the box". (normale Desktop-Installation + Xine)


    Das das mmal-Ausgabeplugin auf dem RPI nicht aktiviert ist, würde ich als Bug einstufen, weil es noch recht neu ist.


    Wie gut das mit einem laufenden X-Server harmoniert, habe ich nicht ausprobiert.

    I've never tried mmal with X11, it probably doesn't even work with X11. X11 drivers for RPi are too slow for any video playback.

    Anscheinend arbeitet man am RPI nicht wie üblich mit X.

    Da muss ich mich dann wohl erst mal einlesen, wie die grafische Oberfläche realisieren.


    Wird aber irgendwie zu machen sein.

    Notfalls mit Lirc und einem Script, mit dem man zwischen den Anwendungen umschaltet.

    Ist doch im Grunde genommen dann auch fast das selbe oder?

    Nein.

    Das eine ist eine ist ein eigener VDR als Client und das "nur" eine Ausgabemöglichkeit über das Netzwerk.

    Ich suche halt letzteres, da ich so Zugriff auf das OSD habe, als ob ich direkt am VDR sitze.


    Ausserdem ist es super simpel, da man auf dem Ausgaberechner nichts installieren oder konfigurieren muss, wenn man Xine direkt verwendet.

    Code
    1. xine xvdr://VDR_IP:37890#nonache



    @seahawk1986:

    Danke fürs testen und die Aufklärung!
    Das Fazit klingt ja recht ermutigend.


    Der Mediaplayer ist mir nicht so wichtig.

    Ich hatte sowieso überlegt, das direkt auf dem Client über Xine (oder notfalls einen anderen Player) zu erledigen.


    Die Hardwarebeschleunigung sollte auch unter X laufen, oder setzt das die Ausgabe über MMAL auf der Konsole vorraus?


    (wie man Ton vom Hardware-Decoder über HDMI oder den eingebauten analogen Anschluss bekommen kann, habe ich noch nicht herausgefunden, vermutlich wurde das nicht implementiert)

    Einen Alsa-Treiber für den HDMI-Ausgang gibt es und da du Ton über die Soundkarte bekommst, sollte es eigentlich irgendwie gehen.


    Der PI scheint aber wählerisch zu sein, was die EDID des Monitors angeht.

    Wenn man nach kein Ton am HDMI-Ausgang sucht findet man einiges:

    Audio configuration

    Unterstützt Xine den Hardware-Decoder vom Raspberry Pi?


    Ich habe jetzt zwei gegensätzliche Aussagen gefunden:

    xine/xineliboutput does not support the Raspberry Pi's hardware-decoder

    Das erste Zitat interpretiere ich als "ja" und das Zweite als "nein". Beide Quellen sind von diesem Jahr, also recht aktuell.

    Nun bin ich etwas verwirrt und hoffe, mich kann jemand aufklären.


    Meine Idee war, auf RPI-Basis, einen "dummen" Wiedergabe-Client für meinen VDR zu bauen.

    Also nur Xine auf dem RPI, als Frontend für das Xineliboutput-Plugin auf dem VDR.
    Ohne Decoder-Support kann man das Vorhaben aber wohl vergessen, denke ich.

    Damit auch andere was von dem Thema haben, noch meine inzwischen gesammelten Erkenntnisse :


    Zum Thema OLED und Einbrennen bin ich auf einen netten Test gestossen:

    https://www.rtings.com/tv/lear…etention-burn-in-lcd-oled

    Da sind auch gruselige Bilder dabei.

    OLED ist bei mir also raus ;D.


    Die RGB-SCART-Adapter die man bei Amazon billig bekommt, sollte man meiden, die können kein RGB:

    https://www.retrogamingcables.…-HDMI-CONVERTERS-TO-AVOID


    Conrad Electronik bietet aber zwei Adapter an, die RGB können sollen.

    Zu den Adaptern von der Conrad-Eigenmarke findet man natürlich nichts, aber zu augenscheinlich identischen mit anderem Label.

    Laut einiger Tests und Videos im Netz scheinen die auch brauchbar zu laufen. Sogar der Lag soll noch zumutbar sein.

    Preis wäre mit ~50€ für den kleineren auch noch akzeptabel.

    Sollte ich mir so ein Teil zulegen werde ich jedenfalls berichten.

    Das Teil diesseits des Atlantik anzuschliessen wird eine Herausforderung.


    Laut Anleitung S.18 muss man den Pool mit 60A aber absichern. Alternativ 40A, dann kann man Pumpe und Heizung aber nicht gleichzeitig betreiben, was nicht wirklich ideal ist.
    Die in Privathäusern üblichen Unterverteilungen sind mit 32A abgesichert, und die Hauptsicherung in einem Einfamilienhaus hat etwa 65A.
    Das Ding in der Schaltung anzuschliessen zu wollen kann man also vergessen. Die Installation entsprechend aufzurüsten kann man IMHO keine Option, allein was die Kosten angeht.


    Wirklich sinnvoll lässt sich hierzulande die benötigte Leistung eigentlich nur durch 2 oder 3 Phasen a 16A bereitstellen.
    Man wird den Pool also auf europäische Spezifikation umbauen müssen.


    Auf dem zweiten Bild sieht man "5,5kW Heater". Die Heizung allein zieht schon knapp 25A. Die muss man wohl gegen die 3kW-Variante austauschen müssen.

    Dazu evtl. Pumpe und Steuerung.

    Beim Kleinkram könnt ihr Glück haben, das läuft aus Sicherheitsgründen meist mit 12V aus der Steuerung.

    Da wird nichts anderes übrig bleiben, als sich an Importeur wenden.

    Ehe man an jeder Abhängigkeit hängt ...

    Code
    1. apt-get build-dep ffmpeg

    Ist doch ein Debian oder Ubuntu System?


    Den eigentlichen Fehler sehe ich nicht, aber es steht unten was mit "Qt4".

    Das lässt mich vermuten, dass es bei den grafischen Tools wie ffplay hängt.

    Das Bauen müsste man eigentlich irgendwie abschalten können und brauchen tust du sie für deinen Zwecke eh nicht.

    [...] bevor ich mich in die DDR4-Welt und deren gerade (?) hohes Preisniveau begebe[...]

    Schau dir mal das Preisniveau bei den DDR3-Ram an, das ist derzeit ähnlich.

    Die Preise haben sich in ca. 1,5Jahren etwa verdoppelt!

    Verkauf ist also durchaus auch eine Alternative.


    Und gibt es wirklich keine Boards im 50 Euro Bereich, bei denen ich alle vier Speicherriegel nützen könnte?

    Eher nicht, zumindest bei Intel, das ist deren Geschäftspolitik.

    Die günstigen Chipsätze sind begrenzt, was die Schnittstellen angeht.

    Wer mehr Features wie SATA-Ports, PCIe-Lanes oder Ram-Bänke will, soll dafür auch mehr zahlen.


    Letztere Kombi wird mir wohl kaum Vorteile gegenüber dem MSI Board mit Celeron 847 bringen.

    Von der Kombi würde ich Abstand nehmen.


    Ich würde mal bei den Mainboards mit Intel Onboad-CPU schauen.

    Bei den neueren kann die IGP AFAIK h265.

    Die liegen zwar 5€ über dem Preisrahmen, sind dafür aber deutlich schneller als der Celeron 847 und dazu sparsamer.

    USB hat Latenzen, die wieder stören, damit hat dippes ganz andere Probleme. Wer Quali möchte , meidet USB

    Interessant, bei einem hochwertigeren Gerät hätte ich einen ausreichenden internen Puffer erwartet. Mit etwas Zeitversatz könnte man ja leben.


    hier geht es generell um Linear Regler, wo sollten die denn ein Problem mit der Versorgungsspannung haben

    Nein, hier geht es die ganze Zeit um einen Audiodac (in dem typischer Weise ein Konstantstromregler verbaut ist), der laut Themenstarter ein Problem mit der Versorgungsspannung hat.

    Aber egal, da weiter zu diskutieren führt zu nichts.


    Denon oder Onkyo [...] und den dann über S/PDIF vom Hifiberry Digi+

    S/PDIF und das am besten optisch, auf ein gescheites HIFI-Gerät.

    Der Tip ist gut! Manchmal übersieht man einfach das naheliegenste.

    IMHO die beste Lösung, wenn nicht basteln will und es einfach funktionieren soll.

    Kannst du einen empfehlen?

    Wenn ich es richtig verstehe, braucht es beim RPI auch noch diesen Taktgenerator, damit es über I2S sauber läuft.


    Aber wäre eine gute USB-Sondkarte evtl. eine Möglichkeit? (sofern es die gibt, ich kenne mich da überhaupt nicht aus)

    Da hätte man das Taktproblem umgangen und man kauft was Erprobtes, was eigentlich keine Überraschungen bringen sollte.




    na klar, hier -->Expansion Board für Raspberry

    ist das genau so umgesetzt.

    Das ist aber definitiv nicht die genannte Preisklasse.

    Das nette Türmchen allein kommt auf 135$ und das Netzteil nochmal auf 85$, alles Aliexpress-Preise, also +Steuer. Dann noch der RPI und das Gehäuse.

    Wenn das Gerät dann fertig ist, liegt Ende liegt man da also eher bei knapp 300€.


    Mit einem käuflichen Webradio, dass man für ~100€ Bestpreis online bekommt, oder für etwas mehr im lokalen Elektrofachmarkt, hat das nicht mehr viel zu tun.



    Der 78xx war nur als Beispiel für einen simplen Analog-Regler gedacht. Es sollte illustrieren, dass diese sinusförmige Störungen niedriger Frequenz ganz gut ausgleichen können, während dies Sprunghaften Änderungen der Versorgungsspannung Probleme bereiten.

    auffällig ist, das du da zwei Timer (0+2) am laufen hast und einer (0) VPS benutzt.

    Timer 2 wird zugunsten von Timer 0 deaktiviert.

    Diese "Timer 0" kann man hier wohl ignorieren.

    EPGsearch löst die unbeabsichtig beim Vergleich aus.



    So wie ich es sehe ändert EPGsearch den Timer und der VDR deaktiviert ihn daraufhin.

    Dass EPGsearch den Timer auch während der Aufzeichnung aktualisiert, ist beabsichtigt. Bei aufzeichnenden Timern wird, wie in diesem Fall, aber nur die Endzeit geändert (23:10->23:15).


    Auf die Reaktion vom VDR kann ich mir momentan keinen Reim machen, eigentlich sollte das so nicht passieren.


    Man müsste mal probieren, was passiert, wenn man per Hand einen aufzeichnenden Timer über svdrp ändert.


    Mit höherem Loglevel bekäme man heraus, ob das, was EPGsearch an den VDR sendet in Ordnung ist:

    Sieh hier. Unter Debian wird das in /etc/vdr/plugins/plugin.epgsearch.conf eingestellt.