Posts by Negge

Hardware: Intel DH77KC, Celeron G1610, 8GB RAM, 2x 5TB HDD, 2x WD 2TB HDD; 1x 64 GB SSD (root), System Ubuntu 18.4 / YaVDR ansible headless

Hi,

danke das du da nochmal nach geschaut hast. Werde ich beizeiten testen.

Beste Grüße

Hi, ich hab aufgegeben und es jetzt anders gelöst. Das Image von YaVDR0.5 läuft jetzt wieder auf dem Client. Geht und ist weniger gefrickel. Nur der Server ist jetzt neu (vor allem wegen dem EPG-Daemon). Trotzdem danke für die Hilfe.

Hi,

danke nochmal für deine Hilfe.

root@q150:~# irw /var/run/lirc/lircd --> läuft, aber kann ich Tasten drücken wie ich will, passiert nichts. Mit Strg-C abbrechen.

Zudem habe ich im Aufruf von vdr-sxfe bisher immer den Parameter --lirc=/var/run/lirc/lircd-lirc0 mitgegeben. Jetzt habe ich das gerade mal ohne den Parameter probiert, aber die Fernbedienung funktioniert dennoch so fehlerhaft wie oben beschrieben --> Also offenbar nicht über diesen Lirc-Socket?

--------

Zudem ist mir nach dem Reboot aufgefallen, dass die Fernbedienung direkt nach dem Reboot doch nicht direkt funktioniert. Die Keytable wird zwar geladen, aber wohl nicht richtig?!?. Erst nach einem ir-keytable -w /etc/rc_keymaps/igorplugusb geht sie (hatte ich vermutlich beim rumtesten dann immer mal gemacht). In der /etc/rc_maps.cfg steht igorplugusb rc-hauppauge /etc/rc_keymaps/igorplugusb drin. Und nach dem booten gibt

nach dem ir-keytable -w /etc/rc_keymaps/igorplugusb wird offenbar das Protokoll RC-5 aktiviert?

Naja, weitere/andere Baustelle mit dem automatischen laden des RC-5-Protokolls, erstmal müssetn die Tastendrücke auch richtig an den VDR weitergeben werden...

Hi,

die Ausgabe von "lsusb -v" liefert für das Device:

Nach umbennen von

/lib/udev/rules.d/98-lircd.rules in /lib/udev/rules.d/98-lircd.disabled

wird die Fernbedieung initialisiert und funktioniert: Teilweise, so wie oben beschrieben. Es werden nicht alle Tasten an den VDR uebermittelt.

Mit ir-keytable -t hab dann nochmal die erkannten Codes der Fernbedienung getestst:

Bsp.: an VDR übermittelte Taste "vol+"

Bsp.: an VDR NICHT übermittelte Taste "Ch+"

Weitere beobachtungen:

Bei Taste Play hält der VDR das Live-Signal an ? (als ob Taste Pause gedrückt wurde):

Auf die Taste Pause reagiert der VDR nicht:

Und die Taste Exit/back auf der Fernbedienung beendet das vdr-sxfe-frontend wie auf die "ESC"-Taste auf der Tastatur (Ich hab den Client im Testbetrieb inzwischen wierder so eingerichtet, dass der Client greift per VDR-SXFE auf den den VDR auf dem VDR-Server zugreift).

Hallo Seahawk,

noch mal danke für die Hilfe, ich habe das so gemacht wie von Dir vorgeschlagen. Bin erst jetzt dazu gekommen weiter zu testen, und funktioniert leider nicht?!?

Wenn ich mittels systemctl mask --runtime --now eventlircd.{socket,service} eventlirc maskiere, dann geht's wie oben beschrieben (nicht alle Tasten werden erkannt) . systemctl mask --now lircd.{socket,service} hatte ich vor einem Reboot ebenfalls ausgeführt, also müsste lircd ja auch maskiert sein? Bring auch nichts wenn ich ein systemctl mask --runtime --now lircd.{socket,service} mache, es werden immer noch Signale von der Fernbedienung erkannt.

Es gibt übrigens eine Datei "/var/run/lirc/lircd-lirc0" . Hat die damit was zu tun?

Ich hab ansonsten noch einsystemctl mask --now eventlircd.{socket,service} probiert und rebootet, nach dem Reboot geht die Fernbedienung nicht, auch nicht mehr nach einem ?systemctl mask --runtime --now eventlircd.{socket,service} wie zuvor?!? Jetzt braucht es erst wieder ein ir-keytable -w /etc/rc_keymaps/igorplugusb -t, dann geht die FB am VDR wieder???

Hallo Seahawk,

nochmal danke für die Hilfe. Also ich habe die entsprechende rc-Keymap nach deiner Anleitung erzeugt:

cat /etc/rc_keymaps/igorplugusb

und in /lib/udev/rules.d/98-lircd.rules habe ich auch die 2 Zeilen

auskommentiert, damit udev den nicht zuordnet.

Nach dem Reboot hat der VDR auf die FB-Signale dennoch nicht reagiert.

Ich hab dann nochmal getestet:

sudo su

systemctl mask --runtime --now eventlircd.{socket,service}

ir-keytable -w /etc/rc_keymaps/igorplugusb -t

An der ssh-Konsole kann ich erkennen, dass er die Tastendrücke zuordnet , am TV kann ich allerdings erkennen, dass der VDR nur auf einige Tastendrücke reagiert (Zahlen 1-9, hoch, runter, rechts, links, VolUp/Down, ).Allerdings nicht: OK, Back, Menu, ChanUp/Down an der Fernbedienung nicht funktioniert (nur Tastatur).

ir-keytable -w /etc/rc_keymaps/igorplugusb -t

Hallo seahawk1986, danke für deine Antwort. Folgendes Resultat:

Scheint also irgendwie erkannt zu werden?

Hallo,

ich musste yaVDR05 nach Jahren problemlosen betriebes updaten, vieles funktioniert auch schon, aber z.B. funktioniert die Fernbedienung noch nicht und ich komme da nicht weiter. Der Igor-USB wird erkannt, die lirc.conf der Fernbedienung vom alten VDR ist unter /etc/lirc/lircd.conf.d gespeichert. Leider funktioniert es nicht....

dmesg | grep igor:

?!?

dxwilli : Schon eine Lösung gefunden? Habe das selbe Problem, auch noch yavdr 0.5...

Also http://winmerge.org/ ist ganz praktisch...

Oder wie schon vorgeschlagen "mechanisch" und ohne Löten wäre der hier http://www.pollin.de/shop/dt/N…Endschalter_XZ_8_108.html oder der hier http://www.pollin.de/shop/dt/N…Endschalter_XZ_8_112.html . Kabel rein, anklemmen und gut...

Der Endschalter XZ-8/112 ist ip64, aber das Gummi um den Stößes vorn sollte man hin und wieder mit Silikonspray bearbeiten, sonst wird der etwas hakelig. Wenn man den geschützt (z.B. im Haus) irgenwo montiert, kann man das Gummi um den Stößel auch ein wenig wegschneiden, dann reagiert der deutlich flinker (z.B. Als Türkontakt für Licht in einem Abstellraum, Dachboden... )

Soll denn die Aufnahme auf dem Server oder auf dem Client laufen? Wenn auf dem Client, dann landen die Aufnahmen natürlich auf der HDD vom Client und dieser muss genug Tuner vom Server zur Verfügung gestellt bekommen, wie von Seahawk erwähnt. Wenn der Server sich darum kümmmern soll, braucht man am Client soweit ich mich entsinne das plugin extrecmenu, um am client das externe recoding-menu vom server einzubinden (Server Timer).
Hat man hauptsächlich nur einen Vdr-Client und möchte eigentlich nur den Server bedienen, kann das auch noch anders lösen, indem man das frontend vom vdr-server per remote-frontend auf dem client darstellt. Dann braucht man kein Streamdev. Muss allerdings ein wenig Handarbeit an die config-scripte anlegen, weil letzteres so direkt in yavdr nicht vorgesehen ist.

Hi,

danke für die Hilfe. Genau das war es. "vdr" lief auf dem neuen Client nicht und damit war die pre-start-Bedingung nie erfüllt. Danke für die Hilfe.

Ich hätte da auch basierend meiem Problem hier ggf. noch eine Anregung für das WFE. Man kann ja im WFE bei "cutsom configuration" durchaus den vdr aus "disabled" setzen, und trotzdem ein frontend auf enabled setzen . Eventuell könnte man da dann ja noch einbauen, dass er dann die pre-start-Bedingung "WAIT_FOR=vdr" automatisch deaktiviert (wobei man die Dateien/templates ja sowiesow per Hand anpassen muss, da man dem frontend ja sagen muss zu welchem remote-vdr er sich verbinden muss). Nur so als Anregung (Code-Vorschlag siehe unten, soweit ich die Syntax verstanden hab. Die else-Bedingung kann man natürlich auch ganz weglassen...).

Danke für die gute Arbeit.

Hi,

an den anderen hab ich nur bei lirc etwas per "template_custom" geändert. Sonst alles original yavdr. Und dieselben templates laufen auch dem anderen Client ja auch problemlos? "initcl list" zeigt in (siehe oben Zeile 9, vdr-frontend stop/pre-start, process 1094), das das vdr-frontend nach dem booten offenbar nicht gestartet wurde?!?

Der Hinweis vom mini73 ist aber gut. An dem alten Client hatte ich das damals zuerst mit dem lokalen VDR getestet, der lief also/kann prinzipiell laufen (auch wenn der nix zu tun hat). Bei dem neuen Client hab ich den VDR auf dem Client nie eingerichtet.
Der VDR scheint ja auch auf dem neuen Client nach "initcl list" nicht zu laufen (oder wird der per rc-script gestartet, heute abend mal checken). Ich muss ja zugeben, dass ich den Upstart-Krams bisher noch nicht ganz durchblickt hatte/habe.
Im Prinzip kann ja in meinem Fall in meinem cutom-template das "start on started vdr" raus, oder? Und viel wichtiger die Bedingung "wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1" sollte auch raus, oder? (heute abend mal testen).
Verständnisfrage: die Bedingung "start on stopped openbox-tools" started das fronted nachdem "stop xbmc" (falls xbmc läuft)? Weil XBMC im Fenstermanger openbox läuft?

~# initctl list (direkt nach dem boot)

Hi,

also das Syslog ist unauffällig. Scheinbar wird weder das "vdr-Frontend" noch "xbmc" beim hochfahren gestartet (ergo kein Fehler, aber auch keine Startmeldung wie beim anderen System). Die Konfiguration ist etwas speziell, weil der/die Client nicht auf den lokalen vdr/xineliboutput zugreifen, sondern auf remote auf das xineliboutput des vdr-Servers (yavdr-headless). Die modifizierten configs aus /etc/yavdr/templates custom/ wurden entsprechen vom alten client auf den neuen übernommen (ebenso wie das server-wake-script). Fernbedienung fehlt noch in Details (andere Empfänger-Hardware), aber ein Problem nach dem anderen...

WIe gesagt, eigentlich funktioniert dasmit den Konfig's ja auch. "start xbmc" und dann "stop xbmc" => frontent wird gestartet und funktioniert. Also kann da an diesen Konfig-Dateien eigentlich kein Fehler sein. ABER: Beim booten sollte er ja eigentlich automatisch xbmc oder das vdr-frontend mitstarten. Im WFE hab ich auch mehrmals die Ausgabe-Einstellungen geändert. Funktioiert leider nicht. Irgenwo verschluck er sich also, dass er ein frontend beim boot-Process startet. Nur wo und warum?!?

Hallo

ich bin gerade dabei meinen vdr-client om wohnzimmer gegen eine leisere Version auszutauschen. Ich habe die Konfiguration soweit möglich/sinnvoll kopiert, aber beim neuen habe ich nach dem booten nur einen blinkenden Maus-cursor auf dem TV. Gebe ich dann per ssh “start xbmc“ ein, funktioniert xbmc. Gebe ich dann “stop xbmc“ ein, habe ich auch das vdr-frontend-bild. Wo könnte das hängen, dass er direkt zum vdr-frontend durchbooted? Bin ratlos?

Danke und Gruß

Um mir mal selbst zu anrworten. Alernative, die zu funktionieren scheint. Rsyslog.conf logging so anpassen:

Und die zugemüllte console kann man in der /etc/sysctl.d/10-console-messages.conf abschalten mit

--

Nachtrag:

Unter Ubuntu 18.4 mit Yavdr-anisble die Datei

/etc/rsyslog.d/30-pctv452e.conf

mit Inhalt:

erzeugen und danach den rsyslog-daemon neu starten:

Ggf. mit "tail -f /var/log/syslog" prüfen ob alles geklappt hat (beenden mit Strg+c).

Um diesen alten Thread nochmal hochzuholen. Ubuntu/yavdr0.5 nutzt ja rsyslog. Wenn ich den obigen code jeddoch in die /etc/rsyslog.conf eintrage, dann erhalte ich folgende Fehlermeldung. Funktioniert also leider nicht?!?