Posts by Der_Pit

    Hi Leuts,

    ich hab gestern bei meinem VDR den Kanal für WDR HD gewechselt (nachdem da laufend die störenden Hinweis-Laufbänder durch's Bild eiern...).

    Also gewechselt von

    alt_WDR HD Köln;ARD:12421:HC34M2S0:S19.2E:27500:5501=27:5502=deu@3,5503=mis@3;5506=deu@106:5504;5505=deu:0:28325:1:1201:0

    auf

    WDR HD Köln;ARD:11552:HC23M5O35P0S1:S19.2E:22000:101=27:102=deu@3,103=mis@3;106=deu@106:104;105=deu:0:28332:1:1021:0

    Aber: Ich bekomme nur ein schwarzes Bild :(

    Und zwar auf allen 11 Lokal-Versionen von WDR HD, die der Suchlauf so gefunden hat. Karte ist 'ne DVBSky S952 v3, via Unicable an 'nem (glaub ich ) Inverto Quad LNB.

    Funktioniert der Sender bei euch? Irgend ein Tip wie ich das eingrenzen kann?

    Nur zur Info: Dieses (ziemlich nervige...) Problem hab ich auch, IIRC ausschliesslich mit SD Sendern.

    Allerdings läuft bei mir noch ein VDR 2.4.0 mit vdr-plugin-softhddevice-0.7~git20180203, compiliert vor 2 Jahren, auf Celeron J4105 CPU...

    Hab ich so bei mit gemacht, allerdings mit 'ner DVBSky S952 V3 (die V2 ist aber auch Dual-Tuner, oder?). Ich hatte/habe nur ein Kabel, hab den LNB gegen eine Unicable-tauglichen ausgetauscht und das eine Kabel auf den Ausgang angeschlossen. Auf VDR-Seite dann ein T-Stück und die 2 Kabel an die zwei Tuner-Eingänge angeschlossen. Läuft einwandfrei, einer kann aufnehmen, der andere ist frei zum Zappen.

    Ja, das geht, so mache ich das.

    Code
    in /etc/fstab:
    vdrnfofs    /export/NFO   fuse    video=/export/Video,allow_other 0 0
    
    und in /etc/exports
    /export/Video   192.168.55.0/24(rw,no_subtree_check,no_root_squash)
    /export/NFO     192.168.55.0/24(rw,no_subtree_check,no_root_squash,fsid=7)

    Das funktioniert eigentlich ganz gut.

    ABER:

    Entweder aufgrund dieser Konfiguration, oder in vdrnfofs selbst scheint es ein memory problem zu geben. Der vdrnfofs prozess krallt sich nach und nach den gesamten Speicher auf dem Server, bekommt dann anscheinend einen kleinen Schluckauf, den Kodi (läuft auf 'nem Pi3 mit openelec) mit einem Abbruch der Wiedergabe quittiert. Wenn der Speicher wirklich voll ist alle 10-15 Sekunden oder so... :(

    Hmm, gerade mal getestet, bei mir scheint das zu gehen. Ich kann 576i Aufnahmen im Schnellvorlauf ansehen, dann auf 'normal' play gehen, und er spielt da weiter, wo der Schnellauf gerade war - das war doch das Problem, oder?

    Meins ist ein Gemini Lake (Celeron J4105), vaapi 2.1. Ich verwende allerdings noch das ältere softhddevice 0.7 in der git Version vom 3.2.2018 plus dem speedupdown patch (github.com/pesintta/vdr-plugin-vaapidevice/files/2088359/speedupdown.patch.gz). Könnte mir vorstellen dass es an dem liegt? Ohne den war die Darstellung teilweise sehr hakelig, auch bei Live-TV.

    Eine Bitte an Dich: Könntest Du Dein softhddevice mit dem eingebauten Patch hier bitte mal posten? Da ich auch die grab-Funktion brauche ist das bei mir genau derselbe Anwendungsfall, da wir beide ja auch dasselbe Board nutzen (j4105-itx).

    DANKE

    Gruß

    moz

    Hmm, nicht ganz sicher was genau Du brauchst/willst. Ich häng jetzt mal das src.rpm an, da ist originalquelle und patch drin. Im Zweifelsfall (ich verwende Tumbleweed - du vermutlich nicht, oder?) mit 'rpm2cpio rpmfile | cpio -idmv' auspacken und geeignet in deine Quellen einbauen. Mit der kompilierten lib wirst Du vermutlich wenig anfangen können.

    Grummel, rpm will er nicht. Habs ausgepackt und als tar.gz wieder zusammengepackt....

    softhd_sources_pit.tar.gz

    Wow.

    Ich hab den Patch jetzt auch mal bei mir eingespielt. Ich verwende softhddevice in der Version vom 20180203, da ich für mein DFAtmo die dort noch beinhaltete Grab-Funktion verwende, die inzwischen rausgeflogen ist.

    Daher war ein wenig Handarbeit für den letzten Hunk nötig, aber damit ist jetzt in der Tat (nach aktiviertem Sanftanlauf) Schluss mit den dauernden verdoppelten Frames! :tup

    Und nicht nur dieses 'kosmetische' Problem ist vorbei: Die Bildanzeige ist jetzt wirklich deutlich stabiler. Ich hatte immer wieder Mikro-Ruckler des Bildes, am ehesten Auffällig bei langsamen Kameraschwenks auf HD Sendern. Und ganz extrem war mir das beim Durchzappen auf Babestation24 aufgefallen: Dort war vorher wirklich das Bild (viel) zu schnell durchgenudelt und hat dann ein paar zehntel Sekunden angehalten. Auch das scheint jetzt glatt durchzulaufen....

    Nachdem ich meinen VDR jetzt auf MLD 5.4 Testing hochgezogen habe laufen übrigens die UHD Kanäle flüssig direkt aus dem VDR.
    Ausgabe erfolgt über Softhddevice mit Intel Grafik.

    Hmm, muss ich dann wirklich mal probieren mit MLD. Meiner zickt immer noch ziemlich rum. Kann aber natürlich sein dass es am GeminiLake liegt.

    Jep, das isses.

    lspci output