Beiträge von Oswald-Kolle

    TheChief: Es läuft ja auch - klappt wie erwartet (muss mich aber wohl noch ans "helle, wechselnde Licht" hinter dem Fernseher gewöhnen...


    Habe in die udev-Regel einen "tail - Befehl" eingefügt - so klappt es auch automatisch... Trotzdem seltsam - vor allem, weil ich auch ohne den tail Befehl am Arduino "irgendetwas" ankommen sehe (wegen der blinkenden LED) - aber dieses nicht vom Arduino ausgewertet werden kann...


    Existieren eigentlich svdrpsend Befehle um das seduatmo auf "feste Farbe", "detached" und "atmo" zu stellen? Dann würde ich mir da nen Fernbedienungscode drauf programmieren...

    Moin zusammen!


    Ich bin nun auch dazu gekommen mit einem Arduino Mega 2560 ein Ambilight zu basteln... Prinzipiell funktioniert es - aber nun mein Problem dabei:

    Es funktioniert nur, wenn ich vorher / parallel dazu ein "tail -f /dev/ttyUSB0" ausführe - also die "Schnittstelle" vorher nochmals von Hand aktiviere/anspreche...


    Woran kann das denn wohl liegen?

    Ansonsten kommt theoretisch auch am Arduino etwas an - die tty-LED blinkt zumindest. Aber wenn ich versuche dieses Signal auszulesen, hängt der Arduino sich weg -- habe es auch über eine zweite serielle Verbindung probiert mitzuloggen - scheint aber nichts "richtiges" anzukommen - bis ich mit dem tail die Schnittstelle anspreche....

    Moin zusammen!
    Ist es ggfs. möglich, die Plugins "svdrpservice" und "remotetimers" auch zu aktualisieren und in xenial mit auf zu nehmen?


    Für xenial (16.04) muss ich zur Zeit noch das "ppa:yavdr/unstable-vdr" und "ppa:yavdr/unstable-main" nutzen - was auch okay ist, aber dort fehlen halt die beiden plugins... Oder wo bekomme ich die sonst (kompatibel) her?

    Moin zusammen!


    Da scheinbar ja mehrere von Euch mittlerweile Proxmox einsetzen, habe ich da mal eine Frage zu:
    -Welche capabilities muss ich dem Container weiterreichen, damit vdr als vdr laufen kann (und nicht als root)


    Per google bin ich auf diese drei gestoßen:
    CAP_SYS_TIME, CAP_SYS_NICE, CAP_NET_RAW


    Allerdings reichen diese alleine scheinbar nicht aus?!
    Gesetzt natürlich mit "vzctl set 100 --capability sys_time:on --save" im host und der Container hinterher neu gestartet...


    Ein strace auf vdr ergibt unter Anderem
    "access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)"
    (Das ganze log ist vermutlich unnötig, wenn es jemand so hinbekommen hat?!)


    Gbt es da vielleicht jemanden, der das soweit ans Laufen bekommen hat?


    Achso - ich habe in meinem Host den SAT-IP-Server (minisatip) laufen - und muss somit nichts an hardware and den/die Clients weiterreichen...
    VDR läuft soweit auch, allerdings als root - und das wollte ich eigentlich nicht (zumal in der conf-Datei steht, dass vdr nicht (mehr) als root laufen kann...
    [edit] Scheinbar funktioniert es nicht (mehr) mit dem vzctl - zumindest auf meiner Testkiste gibt es eine Fehlermeldung

    Code
    vzctl set 102 --capability sys_time:on --save
    [b]Directory /proc/vz not found, assuming non-OpenVZ kernel[/b]
    CT configuration saved to /etc/vz/conf/102.conf

    Okay - der xserver läuft somit also "parallel" zur regulären VDR / Kodi Ausgabe?
    Hab da ehrlich gesagt "Angst", das System zu zerlegen, wenn bei diesen Zusatzinstallationen was schief geht... :(


    Gibt es mit den VDR-Boardmitteln ggfs. die Möglichkeit ein Bild anzuzeigen? So wie die Bilder der EPG-Infos zum Beispiel?
    Ich stelle mir das dann ggfs. so vor: "svdrpsend XXX ShowPic.jpg" und das Ganze für ein paar Sekunden... So wie die MESG Darstellung - nur halt als Bild?

    N'Abend zusammen!


    Ich habe nochmal ein kleines Problemchen... Ich habe bisher immer auf meinem Wohnzimmer-VDR per xhost+ Anwendungen aus dem Netzwerk zugelassen, sich auf meinen Fernseher zu öffnen.
    Wie mache ich das bei MLD? xhost ist nicht bekannt - und "einfach so" werden keine Anwendungen von extern zugelassen...


    Mein Anwendungsfall: Es wird ein Foto aufgenommen (an einem anderen PC) und dieses direkt für ein paar Sekunden auf dem TV gezeigt.

    Das war es wohl.... :)
    Nun kann ich die richtig - so wie erwaret - einbinden :)


    Danke!!!


    Wieso ich in den Freigaben die fsid mit angebe kann ich nicht mehr sagen - hatte wohl mal seine Gründe....
    Vorher ging es bei mir immer, da ich diese fsid sonst nirgends angegeben hatte - erst beim neuen Raspi.


    Hast mich auf jeden Fall vor der Verzweiflung gerettet ;) DANKE!

    Vom älteren yaVDR aus gab es nie dieses Phänomen... Da funktionierten die NFS-Einbindungen immer so wie erwartet...

    Code
    Teil der /etc/exports
    /mnt/NAS                           192.168.0.33(secure,rw,async,fsid=0,nohide,no_subtree_check)
    /srv/vdr/video.00               192.168.0.33(all_squash,anonuid=666,anongid=666,secure,rw,async,fsid=0,nohide,no_subtree_check)
    /srv/vdr/video.00               192.168.0.34(secure,rw,async,fsid=0,crossmnt,no_subtree_check)

    N'Abend zusammen!


    Habe ein neues Phänomen gefunden... Mein MLD 5 steht noch auf stable!


    Wenn ich per "mount -t nfs xx:/yy" ein Verzeichnis von meinem Server mounte, klappt das auch perfekt - so wie erwartet.
    Jetzt das Phänomen: Ich kann kein zusätzliches, ANDERES Verzeichnis mounten! Egal wie der Befehl aussieht, es wird in das neue Zielverzeichnis nur das zuerst eingebundene erstellt!


    Beispiel:

    Code
    mount -t nfs 192.168.0.111:/srv/vdr/video.00 /media/video0/
    mount -t nfs 192.168.0.111:/mnt/NAS /mnt/NAS/
    
    
    df -h
    192.168.0.111:/srv/vdr/video.00
                              3.5T      2.3T      1.1T  67% /media/video0
    192.168.0.111:/srv/vdr/video.00
                              3.5T      2.3T      1.1T  67% /mnt/NAS


    Oder andersrum:



    Woran könnte das denn wohl liegen?!