Beiträge von aragorn

    kurzer Hinweis / Frage, das

    update auf vdr-plugin-softhddevice (0.7.0+git20191002-756-3843047-0yavdr0~bionic) / Original vom 04-Sep
    passt bei mir nicht mehr mit den anthra skins.


    Menüs werden teilweise nicht angezeigt oder aktualisiert, neue Videotext Seiten "überschreiben" die alten, statt sie zu ersetzen, so dass man irgendwann nur noch Buchstabensalat hat usw.

    Wechsel zurück bzw. auf vdr-plugin-softhddevice-vdpau-hevc (welches älter ist) hat das wieder behoben
    verstanden hab ich es noch nicht, was nicht mehr passt.

    falls es nicht schon eine bekannte Erklärung, kann ich ja mal weiter testen am WE

    vg, aragorn

    Ich nutze unter Ansible erfolgreich nvidia "390.116-0ubuntu0.18.04.1" mit "softhddevice openglosd ffmpeg 2.8" und habe einwandfreies Bild und keine Ruckler etc.


    hab's probiert, mit softhddevice geht nur 340.107, und Vorteil von openglosd hab ich noch nicht verstanden.


    noch eine Frage:
    kann man wieder statt "poweroff" wieder "frontend detach" hinter KEY_POWER2 legen ... bzw. an welcher Stelle am besten?

    die Frage danach gab es schon mal, aber es war noch nicht fertig


    was ich versucht habe: KEY_PROG1 statt KEY_POWER2 in rc-hauppauge-custom eingetragen und verlinkt... leider liegt hinter KEY_PROG1 nicht das was ich suche.


    yavdr 0.6 hatte ich /etc/init/vdr-frontend.conf editiert und die beiden vertauscht:


    # Button to de/attach frontend

    # toggle buttons: env key_detach=KEY_PROG1

    env key_detach=KEY_POWER2

    export key_detach

    # VDR's Power button

    # toggle button: env key_power=KEY_POWER2

    env key_power=KEY_PROG1

    export key_power



    jetzt? vielleicht hier irgendwo statt poweroff eine andere Aktion?


    /usr/lib/python3/dist-packages/yavdr_frontend/yavdrfrontend.py könnte ein Kandidat sein, aber vielleicht geht es auch einfacher?

    In https://launchpad.net/~graphic…ield.series_filter=bionic gibt es einen nvidia-340 Treiber, der gegen den Kernel 5.0 baut.

    Hast du schon die Videoeinstellungen fürs Deinterlacing, Helligkeit, Kontrast und ggf. die Studio-Levels angepasst? Das Playbook ändert da bislang nichts an den Vorgabewerten.

    Hi Seahawk,

    der 340er baut. Vielen Dank!


    damit sehen die Menüs normal aus, keine Ghost-Effekte mehr wie beim 430er.


    erstaunlich! - das Bild ist jetzt ohne weitere Anpassungen gut.
    die Videoeinstellungen / setup.conf hatte ich schon übernommen, nun wirken sie sich aus.

    ( wenn mal wieder Zeit ist, versuche ich den 390er ... 384 gibt's nicht im ppa, der ging in 0.6 noch )

    Hab in einem anderen Post die Lösung gefunden. Das Problem ist wohl die GT 730 und der nvidia-driver-430, nvidia-384 oder nvidia-driver-390 Treiber.
    Wenn man den nvidia-340 Treiber installiert, sieht das Menu wieder gut aus und geht auch mit softhddevice-vpp.


    habe hier mit einer GT630 ein ähnliches Verhalten.
    - Menüs werden nicht richtig dargestellt

    - initial war die Bildschirmerkennung nicht gut


    gegen welchen Kernel hast du den nvidia-340 Treiber gebaut?
    geht hier gegen den mit ubuntu 18.04 installierten Kernel 5.0.0-25 nicht.

    die alte und die von ansible automatisch erstellte xorg.conf habe ich mal angehängt.


    mit der alten xorg.cong in das neue System hereinkopiert habe ich wenigsten wieder Vollbild, aber ...

    zusätzlich ist das Bild verwaschen, viel weniger crisp und die Farben sind blass ... nicht nur ein bisschen schlechter, sondern signifikant

    sollte es ausschließlich am anderen Nvidia Treiber liegen, dass das Bild so viel schlechter ist - im yavdr 0.6 System läuft 384, nun 430?


    wie kann ich den einfach austauschen ... der 384 und der 340 bauen nicht gegen den aktuellen Kernel ... wie habt ihr dies hinbekommen?
    gibt es ein ansible Kommando nur für diesen Part?

    habe den vdr mit 18.04 und ansible zum Laufen bekommen - sogar mit Ton.

    allerdings bekomme ich den Atric IR controller seriell nicht eingebunden und auf die +/- Controls auf dem Keyboard reagieren nicht.

    verdammt laut hier... hat jemand einen schnellen Tipp, gehen serielle lirc Devices überhaupt noch?


    Edit:
    Hier mal ein paar Minuten ARD Brennpunkt, bei einem One-Klick-Hoster hochgeladen:
    http://filehorst.de/d/bcaGGuBc

    Vielen Dank, läuft mit dem Celeren G540 und der GT630 halbwegs bei 90-100% - ab und an ruckelt's.
    kodi liegt ruckelfrei bei 90-120% (zwei Kerne)


    Danke an alle Beteiligten für die Weiterentwicklung und das Paketieren!
    Ich könnte höchstens mit Logfiles dienen oder testen, um meine Wartezeit auf den GP108 (falls Nvidia den jemals rausbringt) zu verkürzen. :D

    Ja, softhddevice-vpp-hevc nutzt fürs Decoding in Software nur einen Kern, mein Celeron G540 schafft das auch nicht ganz flüssig. KODI kann mehrere Kerne fürs HEVC-Decoding nutzen, damit sollte die Hardware das eigentlich schaffen können.


    moin - ich habe hier auch eine Kombination G540 / GT630.


    gibt es eine realistische Chance, dass softhddevice-vpp-hevc in absehbarer Zeit mehrkernfähig werden könnte (kenne den Code nicht), oder ist das absehbar eher nicht möglich?
    die CPU aufrüsten auf einen 4-Kerner bringt ja fast nix, wenn doch nur ein Kern genutzt wird...


    OT:
    warte noch auf die DVB-T2 taugliche Empfangs-Hardware ... hat einer von euch auf die Schnelle einen Link mit einem Testvideo im vdr-.ts-Format zum Ausprobieren?

    ... das fällt mir schwer zu glauben.
    Wieso wird Kodi nicht mit einem Update eingespielt.
    (Nach einem Update läuft ja eh' immer nichts und ich muss mich wieder in die Foren begeben ;)


    Aber mal im Ernst, macht ein Update auf Kodi überhaupt Sinn?
    Wer hat es mit den paar Zeilen geschafft und ist zufrieden?


    im Prinzip war/ist es hier so, ohne Garantie.
    Kodi 14.2 läuft nicht ganz rund, ein paar Plugins müsste ich wohl manuell anpassen
    (ich bin da kein Experte, nutze Kodi ab und zu für Musik, Fotos und Handy-Videos, das kann der VDR nicht so gut).


    Ich werde warten auf die nächste yavdr Version, bevor ich da noch Zeit versenke.
    Damit investiert man gleich auch in die neuere Ubuntu LTS Plattform.


    vg
    aragorn

    Ich hoffe mal, ich liege mit dem Board richtig, denn das DH77EB finde ich richtig klasse.


    Hier ist gerade ein DH77EB nach 27 Monaten abgeraucht. Hatte 2 Jahre Garantie.
    Fand ich auch mal Klasse... aber bei dem Neupreis hätte ich mehr Qualität erwartet.

    OK - Karte läuft. Leider unter kernel 3.2 ohne Ton, dafür unter 3.8 ohne Empfang (kein Modul für DD Cine CT).


    Das linux-media-dkms Paket von 08/2012 lässt sich mit dem kernel 3.8 offenbar nicht verheiraten, build bricht mit Fehler ab.
    Hat jemand eine Idee, wie ich ein aktuelleres bekomme (google sollte normalerweise helfen, aber für zielführende Suchbegriffe scheint es heute offenbar zu heiß zu sein)


    vg,
    aragorn

    nein, ich denke nicht.


    LIRC.User1 lässt den X-Server ja leben.


    Es erscheint dann die zuletzt vieldiskutierte Stromsparmodus-Grafik - bei mir mit deutschem Text ;)


    Wieder eine beliebige Taste der FB gedrückt, und ich habe wieder bewegtes Bild, aber keine FB mehr und keinen Ton.


    Und jetzt bin ich in obigem Zustand - der X-Server läuft mit Bild, aber das Plugin weiß nicht mehr so recht was Sache ist.



    EDIT: und sorry - ich bin aus Versehen im falschen Thread gelandet, würde das gerne in den umhängen, welchen ich gestartet hatte:


    http://www.vdr-portal.de/index.php?page=Thread&postID=1142153#post1142153

    neue syslog- Schnipsel:


    Code
    root@vdr:/home/test# svdrpsend PLUG softhddevice deta
    220 vdr SVDRP VideoDiskRecorder 2.0.1; Fri May 10 15:31:49 2013; UTF-8
    900 can't suspend SoftHdDevice already suspended
    221 vdr closing connection
    root@vdr:/home/test# svdrpsend PLUG softhddevice atta
    220 vdr SVDRP VideoDiskRecorder 2.0.1; Fri May 10 15:31:54 2013; UTF-8
    900 can't attach SoftHdDevice not detached
    221 vdr closing connection
    root@vdr:/home/test#


    und da haben wir das Problem:
    Das Plugin (oder seine Umgebung) scheint keinen eindeutigen Zustand mehr zu haben.
    Ich kann es weder detachen, noch attachen. Ein paar Versuche, dann folgt häufig auch ein vdr crash.
    Ein "service vdr restart" in diesem Zustand dauert fast eine Minute, so als würde er auf das Plugin warten, und es nach einem Timeout letztlich abschießen.


    Hat jemand Lust, mir evtl. beim Debuggen zu helfen (noch effektiver wäre umgekehrt -> ich helfe jemandem, der sich besser auskennt...)?


    vg, aragorn

    nein - sehe keine HDMI events bei Ein- oder Ausschalten des TV.


    wenn die FB und der Ton nicht zurückkommen - kann man im syslog daran erkennen, dass folgende Zeilen (nach den VDPAU messages) ganz fehlen.
    Ich habe die Log-Einträge mal per Leerzeilen abgesetzt:



    wenn Ton und FB fehlen, dann fehlt auch der entsprechende Teil im syslog:

    Code
    Apr 30 11:59:58 vdr vdr: video/vdpau: 10bit RGBA format with 16384x16384 supported
    Apr 30 11:59:58 vdr vdr: audio: 'alsa' output module used
    
    
    Apr 30 11:59:58 vdr vdr: [8469] switching to channel 1


    kein Ton, wenn er durch den alsa Teil nicht durchkommt.
    und dann "vergisst" er im nächsten Schritt, die FB einzuschalten - vermutlich, weil er an der Stelle hängt?

    hab ich gemacht - mit 0.6. ändert sich erstmal nichts - vdr crasht oder FB/Ton kommt nicht wieder:



    oder auch:



    vg,
    aragorn

    Warum der VDR und/oder softhddevice da hängen bleiben weiß ich nicht - evtl. kannst du mal versuchen in der device-Section der /etc/X11/xorg.conf.yavdr die Hotplug Events abzuschalten, um da Probleme durch einen Modus-Wechsel zu vermeiden.

    Code
    Option         "UseHotplugEvents" "False"


    Ach ja - ist das softhddevice-Plugin so eingestellt, dass es die X-Ressourcen freigibt wenn es detached oder suspended wird?


    Meinst du das hier:
    "Unterbrechen schließt Video+Audio: Ja"
    "Unterbrechen stoppt X-Server: Nein"



    Die Ursache kann ich jetzt übrigens nachvollziehen:


    Wenn ich das softhddevice detache bei laufender Wiedergabe einer Aufnahme, geht es kaputt wie oben beschrieben.
    Um dieses Verhalten zu umgehen, müsste man die Wiedergabe einen Schritt vor dem Detach stoppen - entweder im Detach-Script oder im Plugin selbst?


    Detache ich während live TV, funktioniert's nämlich zuverlässig.


    vg, aragon