Posts by Der_Pit

ofenheizer wrote:

Hallo jojo61,

keine Ahnung, ob das hier im Thread richtig ist.

Seit einiger Zeit habe ich Probleme, wenn eine Aufnahme an eine letzte Schnittmarke kommt (pauseatlastmark=0). Dann läufz die Aufnahme in Superzeitlupe. Der VDR reagiert auf keine FB-Eingaben wie exit/back oder Stop. Das Log zeigt rein gar nichts.

Erst ein kill des vdr hilft.

Liegt es evtl. an einer der letzten Änderungen im softhdvaapi?

Markus

Display More

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...

Welchen Treiber verwendest du, modesetting oder intel? Modesetting hat kein tear prevention und ist ziemlich anfällig (insbesondere im Multi-Monitor Betrieb)....

Ich hab das Update damals direkt unter Linux gemacht, mit der Linux-Version von Magician, und der Firmware vom gemounteten Iso-Image. Hab die Anleitung aus dem Heise Forum:

http://www.heise.de/forum/heis…nux/posting-3317449/show/

Ansonsten meine ich mich zu erinnern dass die Samsung-SSDs von fwupdmgr unterstützt werden.

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.

Was sind Deine Einstellungen bzgl. Interpolation? Mir ist gestern wieder aufgefallen, dass die Darstellung von SD Material extrem blockig ist (sieht man sogar aus 3-4m, 55" FHD TV).

Mit SATA hab ich keine Probleme, allerdings auch nur eine 'Platte' dran (auch 'ne 840 EVO, an ata1). Wenn ich Zeit hab werd ich mal noch 'ne zweite dran hängen.

M-Reimer wrote:

So wie das aussieht nutzt du immer noch eine "runvdr". Die wird eigentlich garnicht mehr gebraucht.

Ups, interessant. Die nutze ich auch noch. Mir scheint da muss ich mich mal up-to-date bringen. Wie wird denn da jetzt festgelegt welche Plugins mit welchen Parametern gestartet werden?

Hmm, ich dachte ja, allerdings find ich es auf der Projektseite nicht (mehr) im Issue Tracker. Vielleicht war's auch nur hier im Forum eine Diskussion. Ist aber schon 'ne ganze Weile her.

Ich hab derzeit keinen VDR am laufen () um zu checken - aber ich glaube das Programm hat Probleme wenn sich Einträge ändern (Programmverschiebungen etc.). Ich meine mich zu erinnern dass es bedingt mit der Einstellung 'Erstellen' oder 'Mischen' für die Events zu tun hat.

Ja, das Problem hatte ich auch. Man kann zwar was anderes als ein lokales Verzeichnis in den Settings auswählen, aber funktionieren tut's nicht Irgendwie wird der Mount nicht angeworfen wenn das Plugin gestartet wird

Ich hab jetzt einen dauerhaften NFS mount auf dem OpenElec Pi eingerichtet.....

Ja, das geht, so mache ich das.

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...

Hi Wolfi,

Danke für die Info (und Deine Arbeit sowieso).

Ich habe hier nur das Tar-Archiv selbst, da ist dieses Changelog nicht drin(?) - die letzten Einträge dort waren von Johns, 2015 :o

Sollte ja auch gar kein Vorwurf sein (ich packe Tars i.a. auch mit --exclude-vcs)

Hi Stefan,

Die Quellen zum Plugin hatte ich damals (IIRC) aus dem easyvdr repo genommen - leider sind da keine git infos mit drin, kann Dir also leider nicht sagen welches der beiden es ist :o

Ja, der patch muss angepasst werden für diese alte Version, aber er ist wirklich essentiell.

Ich werd mir das Spulen anhand Deiner Beschreibung nochmal genauer ansehen, melde mich dann nochmal.

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.

mamomoz wrote:

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!

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....

Grillbert wrote:

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.

Hi Stefan,

kann ich frühestens morgen abend checken, wenn ich wieder daheim bin.

Was ich aber auch schon gesehen hatte: Wenn ich über Menü den 60Hz Modus erst einschalte, und danach wieder aus, bleibt der duped/dropped Zähler auch stehen (total zählt weiter hoch) - bis zum nächsten Senderwechsel.

OK, irgendwas ist faul mit dieser Version(*). In der Tat gehen die duped frames hoch, und zwar um 60(!) je Sekunde.

Nein, der Fernseher läuft auf 50Hz. Sowohl TV selbst als auch xrandr bestätigen das. Und der 60Hz Modus ist aus.

Wenn ich ihn einschalte gibt's keine duped frames mehr. Dafür aber dropped frames - 10 je Sekunde.... Bei der Darstellung ändert sich aber nix was mir auffallen würde.

Hab das jetzt gerade auch noch mit der neuesten Version von vaapidevice probiert. Dort tritt es auch auf, allerdings sind's nur etwa 25 duped frames pro Sekunde.

(*)gerade gecheckt. Ich hatte das Archiv von easyvdr, aber das ist identisch mit git version c99afc23a53e6d91f9afa (tag 0.7.0)

Hmm, da mir vaapidevice deutlich zu gesprächig war hatte ich den loglevel auf 0 gesetzt. An solche Meldungen kann ich mich aber gut erinnern. Allerdings sind (fast(*)) keine Schwierigkeiten sichtbar, drum hatte ich das ignoriert.

Wenn ich allerdings Menü->Softhddevice aufrufe zeigt das ja unten die verdoppelten Frames an, und die zählen in der Tat rasant hoch.

Kann das was mit dem hohen Audio-Delay zu tun haben? Ich werd mal ein wenig experimentieren...

(*)ich suche gerade nach dem Grund für Ruckler, die ich in einigen Aufzeichnungen, aber auch bei manchen Live-Sendern habe...

Hier noch meine config - ich hab da aber nicht wirklich viel rumexperimentiert. Geladen wird das Modul mit

-P softhddevice -f -d :0.0 -a hw:0,3 -p hw:0,1 -w alsa-driver-broken -v va-api