Beiträge von HagenS

    Hallo,


    ich schlage mich schon seit einiger Zeit mit Problemen bei der Initialisierung meines CAM's während der Boot-Phase herum. Dies führt dazu, dass Aufnahmen fehlschlagen - weshalb das Ganze irgendwie schon behindert. Geholfen habe ich mir bisher damit, in solchen Situationen den vdr-Prozess neu zu starten - danach lief es dann i.d.R. ohne Probleme.


    Umgebung:

    yavdr-ansible undter 18.04 Ubuntu mit HWE-Kernel 5.3.0, vdr 2.4.1, ddci-Plugin, eine DD-DVB/C Karte mit angeschlossenem Doppeltuner- und CA-Modul


    Beim Boot werden die Karten sauber gefunden und eingebunden:

    Beim vdr-Start sieht auch noch alles gut aus:


    Aber dann kommt dann das:

    Code
    Jan 25 08:56:28 yavdr vdr[1951]: [2090] DDCI-Err: can't write to CI adapter (/dev/dvb/adapter2/ca0): Eingabe-/Ausgabefehler
    ...
    Jan 25 08:56:56 yavdr vdr[1951]: [1951] CAM 1: not ready, master (empty)
    Jan 25 08:56:56 yavdr vdr[1951]: [1951] not all CAM slots ready after 30 seconds


    Ab dann ist dann nichts weiter zu sehen - vdr schaltet auf einen Sender, wo er das CAM nicht benötigt und alle verschlüsselten Senden sind ab dann "nicht verfügbar".


    Lösung in dieser Situation: vdr-Prozess neu starten - danach klappt alles wie gewünscht.


    Witzigerweise funktioniert es in gefühlt 50% der Fälle auch ohne Probleme, was es leider schwer vermittelbar macht. Ich versuche mir irgendwie mit einem nach Möglichkeit anhand des Verhaltens indizierten Neustart des vdr-Prozesses im Boot-Verlauf zu helfen, aber eine Lösung ist das eher nicht.


    Hat hier noch jemand so ein Problem und wie könnte die Lösung aussehen? Sollte das ddci-Plugin hier vielleicht anders initialisieren oder wo kann ich ggf. noch "dran drehen"...?


    ...Hagen

    Startet er dann - sofern das fehlschlägt - den vdr-service neu? Da sind mir zugegeben die Zusammenhänge noch nicht wirklich klar...

    Macht er nicht - er wartet nur...


    Ich hatte eben sowas hier:

    Nur zur Sicherheit - sollte es anstatt:

    Code: /etc/systemd/system/wait-for-ca@.service
    ExecStart=/usr/bin/logger -t wait-for-ca git device %i

    nicht (aus der wait-for-dvb abgeschaut) eher:

    Code
    ExecStart=/usr/bin/logger -t wait-for-ca got device %i

    heissen?


    Startet er dann - sofern das fehlschlägt - den vdr-service neu? Da sind mir zugegeben die Zusammenhänge noch nicht wirklich klar...

    Ich habe noch ein spezielles Problem im Umfeld des eingesetzten CAM-Moduls.


    Beim Start schlägt manchmal - nicht immer - die Initialisierung des Moduls fehl. Keine Ahnung woran das liegt oder wer genau da ggf. etwas zur Behebung tun müsste oder könnte, aber in so einem Fall führt ein Neustart des vdr-Prozesses eigentlich immer zu einer funktionierenden Umgebung. Blöd ist das deswegen, weil im Zweifel Aufnahmen fehlschlagen, wenn das nicht funktioniert.


    Im Log sieht das SO aus:


    Kann man (bzw. WIE kann man) das abfangen und in einer solchen Situation den VDR neustarten - ähnlich der Lösung, wo auf den Start der DVB's gewartet wird...?

    Nach der Umstellung auf YaVDR ansible (die ziemlich problemlos gelaufen ist - danke an seahawk dafür...!) bleibt aktuell nur eines der bisher vorhandenen Features offen, die momentan den WAF des neuen gegenüber dem Alten ein wenig verschlechtern ;)


    Wie wäre denn der Weg um einen VDR mit zapcockpit Patch zu integrieren, ohne gleich eine komplette Dev-Umgebung auf die Beine stellen zu müssen (und nebenbei noch updatefähig zur restlichen Umgebung zu bleiben)?


    Danke...

    Die automatische Erkennung funktioniert folgendermaßen: Er holt sich alle möglichen Modes für alle verbundenen Anschlüsse. Dann sortiert er die Modes nach den Kriterien Refreshrate, Auflösung und Anschluss unter Berücksichtigung der Variablen preferred_refreshrates, preferred_resolutions und preferred_outputs . Der Anschluss mit dem Mode, der da am besten bewertet wird, wird der primäre Bildschirm, der andere Anschluss wird für seinem besten Mode als sekundärer Monitor konfiguriert. Mit der oben gezeigten Anpassung, sollte ein 4k oder Full-HD TV mit einem 50 Hz Mode als primärer Anschluss gewinnen und der beste Mode im Sinne der Vorgaben auf dem zweiten Monitor wäre dann 800x600@75 Hz.


    Wenn man eine Konfiguration fest vorgeben wollte, könnte man das Template für die /etc/X11/xorg.conf.d/20-intel.conf anpassen: https://github.com/yavdr/yavdr…emplates/20-intel.conf.j2

    Ok - hab jetzt mal Deinen Vorschlag eingebaut und er baut die xorg.conf genau so wie gewünscht. Perfekt. Danke...!

    Versuch mal sowas in der host_vars/localhost (wichtig ist nur, dass der Mode für den primären Bildschirm gegenüber dem Mode für den sekundären Bildschirm in https://github.com/yavdr/yavdr…rary/xrandr_facts.py#L119 bevorzugt wird):

    Ok. Aber wie kann ich das getrennt für die beiden Bildschirme vorgeben...? Das Haupt-Display soll ja bei 4k/50Hz bleiben und nur der "kleine" benötigt eine derartige Spezialbehandlung...

    Sorry falls ich vielleicht die Antwort auf meine Frage in den zurückliegenden 64 Seiten hätte finden können - aber in der Doku stand zumindest nichts darüber...


    Kann ich im Script oder in einer Variable irgendwo die zu verwendende Auflösung für den zweiten Bildschirm vorgeben?


    Hintergrund:

    Mein LCD im Thermaltake, welches ich für Osd2web nutze, wirft folgende Konfig bei der Abfrage aus:

    Code
    root@yavdr:~/yavdr-ansible# xrandr -display :0.1 -q
    Screen 1: minimum 8 x 8, current 1280 x 1024, maximum 32767 x 32767
    DP-0 connected primary 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm
       1280x1024     60.02*+
       1280x960      60.00  
       1152x864      75.00  
       1024x768      85.00    75.03    70.07    60.00  
       800x600       85.06    75.00    72.19  
       640x480       85.01    59.94  
    root@yavdr:~/yavdr-ansible#

    Somit wird korrekt für xorg "1280x1024_60" übernommen. Passt soweit.


    Leider mag das Display damit nichts anzeigen außer "out of sync". Wenn man manuell "800x600_75" auswählt, klappt das. DAS hätte ich gern irgendwo der Installation übergeben ;-).


    Danke...


    ...Hagen


    PS: In der Doku unter yavdr.org ist im Abschnitt 1.3.2 als zu ergänzendes Repo

    Code
    - 'ppa:seahawk1986/vdr-2.4.1'

    angegeben. Damit bin ich auf einen Fehler gelaufen. Als ich dann auf "seahawk1986-hotmail" geändert habe, hat alles prima geklappt...!

    So ist es mir z.B. gelungen wenn kodi läuft das Webinterface von Kodi (Chorus2) in die Anzeige zu integrieren.


    Das würde ich ein echt cooles Feature für osd2web finden, was sicher einige andere Nutzer ebenso sehen würden. Mich hat schon immer ein wenig gestört, dass im LCD beim Wechsel zu Kodi nichts zu dem zu sehen war, was gerade am TV durch Kodi angezeigt wurde (obwohl ja mehr als genug Metadaten in Kodi vorhanden sind)...


    Magst Du das vielleicht zur Verfügung stellen oder darf man sich das vielleicht als Feature für den Horchi-Skin wünschen...?


    ...Hagen

    Hat einer was zu dem "Start mit schwarzem Bildschirm" herausgefunden? Ich habe hier das gleiche Problem - jeder Start unter 4k erfolgt komplett schwarz. Ton läuft, vdr ansonsten auch. Wenn ich nur den X-Server neu starte, fällt vdr mit einem segfault auf die Nase und startet ebenfalls neu. Danach gehts dann ohne Problem...


    ...Hagen

    Na ja - eher nicht so ergiebig:


    Guter Hinweis - führt direkt zum Erfolg. Ich hab das OSD auf 1920x1080 gestellt - danach sah alles wieder ok aus :-). Danke!


    Jetzt muss ich nur noch rausfinden, wieso ein initialer Start unter 4k-Auflösung immer zu einem schwarzen Bildschirm im Softhddevice führt... Der Ton ist zu hören - nur das Bild bleibt schwarz. Nach einem VDR-Neustart ist alles wie gewünscht...

    Hallo,


    ich versuche gerade, meine neue GT1030 mit 4k-Auflösung unter MLD 5.4 Testing zum Laufen zu bekommen. Dabei stelle ich einen merkwürdigen Effekt im OSD fest:


    Unter HD funktioniert alles bestens. Ich nutze erfolgreich Skindesigner, alles sieht gut aus:




    Wenn ich dann aber den Screen auf 4k umschalte (alles andere sonst bleibt gleich), sieht das OSD SO aus:




    Kommt vielleicht softhddevice nicht mit der 4k-Auflösung klar - oder woran könnte es liegen...?


    Gruß...


    ...Hagen

    Hallo,


    ich nutze (auf Basis einer aktuellen MLD 5.4) u.a. das extrecmenu Plugin unter der aktuellen VDR Version. Wenn ich das Aufnahme-Menü öffne, sehe ich eine Art Flackern im OSD. Subjektiv würde ich sagen, dass hier ein (ständiger) OSD-Refresh erfolgt, der sich in besagtem "Flackern" äußert. Ohne das Plugin ist dieser Effekt nicht feststellbar, also gut auf dieses zurückzuführen. Das System bleibt an sich bedienbar, funktional gibt es keine Einschränkungen. Optisch und WAF-technisch ist das Verhalten allerdings eher problematisch ;)


    ...Hagen

    Ok - vielen Dank dafür. Allerdings hats das allein noch nicht gebracht. Am Ende waren folgende Einträge in die Konfiguration erforderlich, weil er - nach dem er den Index anlegen konnte - auch bei den Functions ausgestiegen war:


    Code
    innodb_large_prefix = ON
    innodb_file_format = BARRACUDA
    log_bin_trust_function_creators = 1


    Danke!

    Hallo,


    ich nutze MLD - die aktuelle Version. Dort wurde gerade von MySQL auf Maria-DB gewechselt. Aus anderen Gründen heraus habe ich dann die epgd-Datenbank verworfen. Nach dem Neustart des Dämons schafft er es aber nun nicht mehr, die Tabellenstruktur anzulegen:



    Was kann ich tun?


    ...Hagen

    Die Incorrect string value: '\xE4nderm...' ... kommen aus falsch kodierten info(.vdr) Files in alten Aufnahmen, und bringen das Ganze vermutlich nicht zu Absturz

    Wie finde ich denn die falsch kodierten Files, um den "Schaden" zu beheben...?

    Ich bekomme die Abstürze mit der gleichen Plugin-Version unter MLD 5.4 auch. Im Log steht direkt vorher immer folgendes:




    Vielleicht hilfts ja...