Beiträge von rallye

    sollte eigentlich zumindest das yaVDR-Logo (kurz) zu sehen sein

    leider nein. Das Logo ist am 2. BS nicht aufgetaucht.


    Die Abfrage bezüglich osd2web.service denn in der User-Session liefert


    Code
    mod@HTPC-WZ:~$ sudo -u vdr DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/666/bus systemctl --user status osd2web.service
    ● osd2web.service - Start a kiosk browser on the second DISPLAY if it exists
       Loaded: loaded (/var/lib/vdr/.config/systemd/user/osd2web.service; enabled; vendor preset: enabled)
       Active: active (running) since Sun 2020-07-26 13:36:51 CEST; 9min ago
     Main PID: 1808 (on_vdr)
       CGroup: /user.slice/user-666.slice/user@666.service/osd2web.service
               ├─1808 /usr/bin/python3 /usr/bin/on_vdr -o -c kiosk-browser "http://localhost:4444/skins/horchiTft/index.html?theme=anthraize&onlyView=1"
               └─1812 kiosk-browser http://localhost:4444/skins/horchiTft/index.html?theme=anthraize&onlyView=1

    Was mich etwas nachdenklich macht ist das Wording: Start a kiosk browser on the second DISPLAY if it exists Heisst das, dass ich den kiosk browser starten soll oder ist das einfach unglücklich ausgedrückt ?

    Um das mal genauer einzugrenzen - meinst du damit den TV oder den anderen Monitor, der dran hängt (und aus Sicht des Playbooks der zweite Bildschirm ist)?

    Ich meine den anderen Monitor. Das TV-Bild und der Ton laufen. Der 2te (andere) Monitor ist beim initial Boot (BIOS-Options) aktiv, sonst dunkel.

    In der /var/lib/vdr/.second_display steht: DISPLAY=:0.1

    Ist der X-Server für den zweiten Bildschirm erreichbar?

    Dürfte m.E. erreichbar sein

    Läuft Openbox für den zweiten Bildschirm?

    Code
    mod@HTPC-WZ:~$ sudo -u vdr DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/666/bus                                                                     systemctl --user status openbox-second.service
    ● openbox-second.service - Start openbox on the second DISPLAY if it exists
       Loaded: loaded (/var/lib/vdr/.config/systemd/user/openbox-second.service; ena
       Active: active (running) since Sat 2020-07-25 14:10:34 CEST; 18min ago
      Process: 1828 ExecStartPost=/bin/bash /var/lib/vdr/.fehbg (code=exited, status
      Process: 1827 ExecStartPost=/usr/bin/xset -dpms s off -display $DISPLAY (code=
     Main PID: 1826 (openbox)
       CGroup: /user.slice/user-666.slice/user@666.service/openbox-second.service
               └─1826 /usr/bin/openbox --config-file /var/lib/vdr/.config/openbox/rc

    Danke ! (Für mich leider ein spanisches Dorf ...)

    Leider bringt das keine Änderung. Der 2. BS bleibt dunkel. Ich hab den Denon überbrückt (HDMI-Kabel geht nun direkt zum Panasonic [auch älteres Modell]) und das Playbook nochmals durchlaufen lassen. unten die neue /etc/X11/xorg.conf


    Anbei noch meine alte /etc/X11/xorg-yavdr.conf aus der yavdr0.6.2-Installation. Die war noch mit der GT430-Karte und durch den Denon "durchgeschleift". Diese Config hat damals funktioniert ...,

    Oben die /etc/X11/xorg.conf. Der Hauptbildschirm hängt am HDMI, der 2te Monitor am DVI über einen DVI->VGA - Adapter

    Ich bin noch in den Anfängen mit Ansible ..... Habe Das System mit nur einem Bildschirm aufgesetzt (da ich keinen DVI-VGA Adapter hatte) und bekam normales Fernsehbild. Nun habe ich den Adapter bekommen, den 2ten Bildschirm angesteckt und das Playbook nochmals durchlaufen lassen. Folgendes ist angezeigt worden:

    Aber auch nach einem Reboot bleibt mein 2ter BS dunkel. Was mache ich falsch bzw was habe ich noch nicht gemacht um einen Output zu erhalten ?


    Danke

    Danke für eure Tips ! Ich hab nun bei einer lüfterlosen Pascal 1030 zugeschlagen und diese eingebaut. Über den zuletzt gemeldeten Fehler bin ich erwartungsgemäß problemlos drüber gekommen, doch nun stehe ich beim nächsten Problem:


    Das journalctl -xe liefert folgendes:

    Bitte um Hilfe - was ist diesmal schief gelaufen und wie kann ich es verbessern ?


    Danke

    Natürlich geht mit einer GT430 (GF108), Fermi, VDPAU. Mit ihren 96 Cuda Cores kann die auch problemlos "temporal spatial" ...


    Richtig ist aber, die Karte ist schon vor langer Zeit aus dem regulären Treiber Support raus und wird nur noch mit dem binären Nvidia Legacy Treiber Paket rennen. Aktuellste Version hier ist "390.138" vom 24.6.2020.

    OK, danke. Was heißt das aber nun für mein Problem ? Wie kann ich das lösen ? Neue GraKa ? Und wenn "ja", welcher Typ ?

    Danke soweit mal, Habe Alexander's Tip befolgt und die Zeilen auskommentiert - läuft wunderbar drüber und "erhängt" sich nun später.

    "journalctl -xe" liefert folgendes

    Und bevor die Frage kommt welche GraKa ich habe hier ein lspci


    Danke für die Unterstützung !!!


    LG Joe

    Danke euch allen für eure Beiträge ! Klingt ja doch nicht ganz so als ob yavdr ein "totes Pferd" wäre. Lars : brauchst dir keine Vorwürfe zu machen - immerhin leistest du so wie seahawk1986 einen Support der seinesgleichen sucht. Derweil ist ja mein Server noch nicht "verstorben" und ich hab mir heute einen clone (nur für alle Fälle) gemacht. Die Neuinstallation der FrontEnd-Clients werde ich lt. Anleitungen/Hints/Tips in diesem Fred gelegentlich angehen. Zur Zeit läuft auf dem PC im WZ das MLD recht nett, doch als Ersatz für meinen Server wird's vorläufig nicht reichen.


    Nochmals danke an Euch alle - und an das Entwicklerteam: super Arbeit von euch :tup:tup:tup

    Hallo zusammen !


    Bitte missversteht meinen Post nicht - ich will niemanden zu irgendetwas drängen/nötigen (weder zu Arbeit noch einer Aussage). Doch ich habe mir 2 yavdr0.6-Installationen am letzten Wochenende zerschossen, blöderweise beides meine Clients im WZ und SZ. Ein Wiederaufsetzen bricht (auch mit dem nochmals heruntergeladenen Image) bei der SW-Installation auf beiden PCs immer ab. Nun hane ich mir "auf die Schnelle" einen MLD-Stick kreiert und bin damit eigentlich recht zufrieden. Natürlich habe ich noch nicht viel Aufwand ins Customizing gesteckt, doch mir fällt jetzt schon auf, dass es da an einigen Stellen "hapert". Mein Server ist nach-wie-vor ein yavdr 0.6.1 und wird aller Voraussicht nach auch ein yavdr bleiben, denn ich habe den Server "aufgebohrt" und verwende den PC auch als NAS und zur Datensicherung (hab da mein eigenes Konzept). Auch habe ich das böse Plugin von unserem besten Freund drauf - läuft alles super !!

    Nun habe ich (ohne mich mit dem MLD intensiv auseinandergesetzt zu haben) eine gewisse scheu den Server ebenfalls umzustellen, da ich dort nur ein very-mini-Linux habe und NFS/BU/böses-plugin wahrscheinlich nicht so einfach realisieren können werde. Andererseits befürchte ich, dass - sollte mein Server einmal "eingehen" - ich dort ebenfalls Probleme mit der Neuinstallation haben werde. Und damit habe ich dann ECHTE Probleme, da ich auf meine Daten nicht mehr hin greifen kann und Multimedia ist dann sowieso nur noch über Kofferradio möglich.


    Die Basis von yavdr0.6 ist mittlerweile schon in die Jahre gekommen. Der LTS für das zugrunde liegende Ubuntu läuft in etwas mehr als einem Jahr aus und dann ? Ich habe immer wieder hier im Forum nachgesehen - 0.7 wird fertig, wenn es fertig ist. Ein bisserl was gibt's schon (länger) im GIT. Es fallen im Entwicklerteam immer wieder programmier-Ressourcen aus. Ist alles verständlich, und niemand vom Entwickler-Team bekommt (außer einem gelegentlichen "Danke") etwas für seine Arbeit. Seahawk ist mega-bemüht sein Wissen weiter zu geben und Support zu leisten - ein dickes "DANKE" an dieser Stelle !!! Doch auch blöde Endbenutzer wie ich wollen nicht auf ein totes Pferd setzen. Einige Zeit wird das yavdr schon noch "halten" (e-Tobi wurschtelt sich auch irgendwie noch durch, würde ich mir aber aufgrund des Wartungszustandes derzeit nicht installieren). Aber was passiert dann ? Sollen wir uns langsam um eine neue Distri umsehen ? Oder kommt doch noch in absehbarer Zeit eine neue yavdr-Release ? Ubuntu 18.04 würde sich als Basis anbieten (wenn es irgendwie machbar ist). Kann uns ein Erleuchteter bitte mit etwas Hintergrundsinformationen versorgen, damit wir Endbenutzer unsere Strategie ausarbeiten können ??!


    Danke für die Infos und nochmals: das ist kein Drängen, denn eigentlich macht es keinen Unterschied ob etwas in 3, 6 oder 9 Monaten fertig ist solange wir wissen, dass da wirklich etwas kommt (wie z.B. die Motorradsaison in 3 Monaten 8))

    N'abend, Louis,


    wollte dir nicht zu nahe treten sondern lediglich aufzeigen, dass du darauf schon mal geantwortet hast und der Meinung bist, dass es nicht an deinen Plugins liegt (also irgenwo anders ?( ). Ja, ich versuche es mit tvguideng. Und andere Skins habe ich auch probiert. Leider immer das gleiche Ergebnis


    Danke Joe

    Passiert das auch mit den Standard-Skins? Hier klappt das noch mit estuary4vdr.


    Mit estuary4vdr passiert das bei mir auch (zeigt also nichts an)


    Nutzt du einen eigenen Api-Key? Was steht im Log?


    Ich nutze keinen eigenen Api-Key
    Im Log steht nichts "dramatisches". Nach dem ersten Boot holt er sich aufgrund der IP meine Location und schreibt sie. Danach stellt er fest, dass keine Info im Cache ist und liest forecast.io

    Code
    Oct 18 19:19:56 HTPC-WZ vdr: [3252] weatherforecast: no cached forecast available
    Oct 18 19:19:56 HTPC-WZ vdr: [3252] weatherforecast: fetching forecast newly from forecast.io
    Oct 18 19:19:56 HTPC-WZ vdr: [3252] weatherforecast: calling URL https://api.forecast.io/forecast/9830052ef63efbec84ec0639e9a205d2/48.192,16.3671?lang=de&units=si


    Nach den folgenden boots nimmt er die Daten aus dem Cache (dürften aber keine vernünftigen Daten drinnen sein) :(

    Ich habe mal wegen skindesigner auf die testing-ppas (alle) umgestellt. Unter anderem wird auch weatherforecast von 0.1.1. auf 0.2.0 upgraded. Allerdings werden die Wetterdaten aus dem Plugin (die Location in den Settings schaut vernünftig aus) nicht angezeigt. Im skin blackholefrodo sehe ich nur ein '°C' ohne Wert, beim Aufruf von Weatherforecast aus dem Menü werden ebenfalls keine Werte angezeigt. Stehe ich damit alleine da ?