Beiträge von PmK

    Hab auch eine Unifi G3 hier seit 3 Jahren hängen. Funktioniert tadellos, meldet sich wenn sich was bewegt, lässt sich super konfigurieren, hab auch eine in der Firma auf dem Dach und hier wird ein Raspberry 1 als Videoplayer verwendet. Das funktioniert jetzt auch seit einem Jahr tadellos.

    Hallo kamel, also ich hab das auch schon durchprobiert und das macht keinen Unterschied ob mit oder ohne GPU-Accel. Irgendwie scheint Skindesigner beim Absturz aus welchem Grund auch immer auf meinem Raspbian aber ein Problem mit dem OSD-Layer zu haben so das dieser nach dem Neustart nicht mehr angezeigt wird. Laut Logs sieht man auch immer das der animator-thread gestartet und beendet wird. Das verhalten hab ich mit dem LCARS nicht. Der Fehler mit dem i/o throttle ist aber immer noch mit der selben Häufigkeit vorhanden wie vorher. Ich bin schon am überlegen ob ich nicht minisatip mal als Zuspieler probiere Übergangsweise. Hab eh TVheadend auf dem Server laufen und der regelt auch meine Aufzeichnungen.. ergo bräuchte ich VDR dann dort gar nicht mehr.

    Ok.. Also noch mehreren Tagen testens hab ich folgendes Fazit. Ohne vdr-patches, ohne skindesigner aber mit epgsync, svdrpservice, rpihddevice und streamdev hab ich immer noch die i/o throttle Fehler beim Umschalten. Das gute ist jetzt, das ich nicht mehr neu starten muß. Anscheinend scheint beim Absturz mit Skindesigner irgendetwas nicht wirklich bereinigt zu werden weshalb dann das OSD nicht mehr geht. Das passiert mit dem LCARS-Skin mal nicht mehr.

    Der Fehler tritt ziemlich selten auf aber eigentlich IMMER nach dem Umschalten. Es kommt dann auch kein Bild mehr sondern der buffer läuft voll und dann wars das..

    Grüsse, PmK

    Ok. ich werd das mal so ausprobieren ob der vanilla vdr läuft. Heute früh wars wieder soweit.. selber Fehler i/o throttle activated und dann watchdog expired. Das ganze auch beim ersten Umschalten nachdem er die ganze Nacht lief und auch ein Bild gezeigt hat.

    Also den Locking-Fehler hab ich nicht mehr.

    Allerdings ist das Problem mit dem fehlenden OSD immer noch da.

    Ich hab heute die ganze Zeit folgenden Fehler in den Logs gehabt:


    Code
    Feb  8 14:13:37 raspberrypi vdr: [418] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
    Feb  8 14:13:41 raspberrypi vdr: [418] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
    Feb  8 14:13:45 raspberrypi vdr: [418] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz
    Feb  8 14:13:49 raspberrypi vdr: [418] rpihddevice: set HDMI audio output format to 2ch PCM, 48.0kHz


    Dann hat meine Frau eingeschalten und beim ersten Umschalten kommt dann dieser Fehler:


    Danach ist das OSD wieder weg und ich muß erst ganze System neu starten.

    Streamdev-abort-Patch hab ich angewendet. Derartige Fehler wie den oben mit dem output-Format hab ich sonst nie im Log.

    Kann da jemand helfen?


    Grüsse, PmK

    Mach ich natürlich sofort. Ich geb dir dann morgen oder übermorgen mal Bescheid ob das funktioniert. Nach dem ersten Start geht das immer eine Weile gut und erst wenn der vdr ne Weile lief kommt der Fehler bei mir.

    1000 Dank schonmal für die schnelle Hilfe!

    Ich hol den Thread nochmal hoch. Ich hab regelmässig immer noch bad locking order. Diesmal aber wie es scheint vom VDR selbst.

    Verwendet wird der 2.4.1. Gibts dafür irgendwo nen Patch oder kennt das Problem jemand? Passiert eigentlich immer wenn man nach längerer Laufzeit den Kanal mal wechselt. Plugins hab ich streamdev, rpihddevice, epgsync, svdrpservice und skindesigner

    Nach dem Absturz hab ich dann kein OSD mehr und muß den ganzen Raspberry neu starten das es wieder läuft..

    Ich verwende den zapcockpit-patch vom skindesigner.. kann der evt. diesen Fehler provozieren?


    Die Problematik mit dem Umschalten und dann kein Bild hab ich bei mir auch. Passiert bei mir immer wenn der VDR z.B. über Nacht durchlief (RPI ist 24/7) und ich dann früh TV einschalte und umschalten will. Das ganze Thema VDR und Raspberry mit aktuellen Versionen ist irgendwie seit geraumer Zeit ziemlich unbefriedigend. Ich hab jetzt auch mal die GPU-Unterstützung ausgeschalten seit ein paar Tagen und das scheint bei mir schonmal etwas zu helfen.


    Grüsse, PmK

    Also eigentlich schau ich viel 1080p auf dem Pi4 und hab da mit dem 18er Kodi keine größeren Probleme. Ab und an hab ich da zwar schon ein "stottern" gesehen aber völlig unbrauchbar war das deshalb nicht gleich..

    Also nach einigen Tagen testen kann ich bis jetzt folgendes sagen:

    Vorher hatte ich nach den Abstürzen immer wieder kein OSD mehr auf dem Raspberry und musste das Teil dann neu booten. Das hab ich bisher mit beiden Patches nicht mehr gehabt.

    ABER:

    Ich bekomm jetzt immer noch nach längerer Laufzeit (RPI läuft 24/7) wenn man einschaltet den selben Fehler siehe unten.

    Filesystem ist bei mir ext4, Recordings-Verzeichnis hängt per nfs4 im System.


    Hallo nanohcv, laut dem was ich so gefunden habe sollten diese Patches eigentlich im GIT eingepflegt sein. Ich schau aber gleich mal ob da vieleicht doch noch was fehlt.


    Edit:

    okayy.... der Deadlock Fix ist drin, der andere patch allerdings nicht. Jetzt bin ich gespannt ob das ein für alle mal ein Ende hat mit diesen komischen Abstürzen.. Danke nanohcv!!

    Hallo Jungs,

    mein VDR läuft jetzt langsam aber sicher halbwegs stabil. Nur ein Problem plagt mich noch.

    Es kommt immer wieder mal vor (Vorzugsweise wenn man nach längerer Zeit mal umschaltet), das ich folgenden Fehler im Log habe und der VDR abstürzt.

    Das passiert mir 2-3x am Tag.

    Im Forum hatte ich gesehen das es dafür eine Anpassung des Streamdevs gab. Ich verwende allerdings die Version aus dem git -> https://projects.vdr-developer…vdr-plugin-streamdev.git/


    Gibt es noch irgendetwas was ich hier tun kann?


    Grüsse, PmK



    Bei Watterrot schau ich so gut wie immer nur wegen den Silentstepsticks für 3D-Drucker da sie ja sehr eng mit Trinamic zusammenarbeiten aber den ganzen anderen Elektronik-Kram gibts bei semaf electronics oder bei aliexpress (für die geduldigen) dann am Ende doch günstiger.