Beiträge von Schmeing

Seit Kurzem habe ich eine zweite DVB-T Karte (eine Haupauge WinTV Nova-T DVB-T) in meinem Rechner. Seit dem versuche ich, den IR zum laufen zu bekommen. Dabei ergibt sich folgendes Problem:
Mein Kernel (bzw. udev) weist der Karte bei jedem Start ein anderes event-Device zu. Und das auch dann, wenn ich an der Konfiguration und Reihenfolge nichts ändere.
Da für meine erste Karte (basiert auf dem Philips Semiconductors SAA714) ebenfalls ein event-Device für einen IR-Empfänger erzeugt wird (obwohl kein Anschluß vorhanden ist), kann ich das Remote-Plugin nicht mit "-i autodetect" starten, weil er dann mal das eine, mal das andere event-Device als erstes findet. Ein festes "normales" event-Device mittels -i /dev/input/eventX geht natürlich auch nicht. Das ändert sich ja jedesmal beim booten.
Mein Lösungsansatz ist bis jetzt, mittels udev für den IR-Empfänger der Haupauge-Karte ein spezielles Device anzulegen (/dev/input/HaupaugeIR) und dies dem Remote-Plugin mittels der -i Option fest zu übergeben. Dies funktioniert aber nicht, weil die VDR-Installation von e-tobi nur die Standard-event-Devices beim Starten berücksichtigt (in /usr/lib/vdr/remotes-loader.sh). Dadurch meint das Remote-Plugin bei jedem Start, es habe eine neue Fernbedienung entdeckt und müsse die anlernen.
Weiss hier jemand eine Lösung, die nicht darauf hinausläuft LIRC zu installieren oder die /usr/lib/vdr/remotes-loader.sh manuell zu ändern?
Die Lösung mit LIRC fände ich unschön, würde ich aber als letzte Option in Betracht ziehen und die /usr/lib/vdr/remotes-loader.sh ist meines Wissens keine Konfigurationsdatei, d.h. apt merkt beim Upgrade nicht, dass sie geändert wurde.
Meine Systemkonfiguration:

• Betriebssystem: Debian testing
• VDR: 1.4.0 (vdr-experimental 1.4.0-1ctvdr1 von e-tobi)

Michael

Danke, damit funktionierts wieder. Nur scheint gxine den Netzwerk-Patch (noch?) nicht zu verstehen. Na ja, man kann nicht alles haben

Michael

Bei mir ist gestern beim Debian-Update diese Version des Plugins und der xinelib installiert worden. Seit dem habe ich das Problem, dass das Plugin das Verzeichnis /tmp/vdr-xine mit den dazugehörigen FIFOS/Sockets nicht mehr erzeugt. Alles andere scheint zu laufen.
Ich habe auch schon mehrmals versucht, dass Plugin neu zu installieren und den Rechner neu zu starten. Hat alles nichts geholfen.

Ich benutze Debian etch mit der sid Experimental-Distribution von e-tobi.

Gruß
Michael

Nachtrag: Ich finde auch in den Log-Dateien keine Fehlermeldung. Dort steht nur nach jedem Start des VDR einmal:

Zitat

Mar 27 09:53:16 mithrandir vdr: [5352] ERROR: remote control XineRemote not ready!

Aber die Meldung habe ich schon immer gehabt.

Ich hatte seit einiger Zeit das auch von ein paar anderen beschriebene Problem, das tvmovie2vdr meinen VDR zum Absturz gebracht hat. Nach längerer Scuhe habe ich herausgefunden woran das (zumindest bei mir) liegt: Teilweise erzeugt tvm2vdr.pl Event-Einträge in der folgenden Form:

E
T
D
e

Dies ist nicht zulässig, weil sowohl E- als auch T-Zeilen zwingend Argumente haben müssen. Laut Doku MÜSSEN die an den VDR übergebenen EPG-Einträge syntaktisch korrekt sein, das Verhalten bei inkorrekten Einträgen ist nicht spezifizert (meiner Meinung nach ein Designfehler im VDR, er sollte die Korrektheit prüfen und ungültige Eingaben abfangen, aber das ist ein anderes Thema).

Bei allen Zeilen außer E und T hat tvm2vdr.pl geprüft, ob sie leer sind. Der angehängte Patch prüft nun, ob sowohl die E- als auch die T-Zeile Argumente enthalten (aber nicht, ob die Argumente korrekt sind, dazu hat die Zeit noch nicht gereicht ). Wenn eine von beiden (oder beide) leer sind, wird der ganze Event unterdrückt. Für mich hat sich das Problem damit gelöst.

Gruß Michael

Zitat

Original von chelli
Ja, es wird wirklich die Version 0.05-1 von libhtml-template-expr-perl benötigt, da die alte Version nicht mehr mit dem neuesten libhtml-template-perl ( 2.8 ) funktioniert hat. Siehe dazu auch:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345560

Also einfach mal wieder Unstable aktualisieren.

Mit der Version 0.05-1 von libhtml-template-expr-perl aus Unstable läuft es wieder. Danke!

In fünf Tagen, wenn die Version nach Testing gekommen wäre, hätte sich das Problem also auch von selbst gelöst.

Zitat

Das ist auch einer der Gründe, warum Unstable eben Unstable heisst.

Und Testing heißt Testing, weil es eben auch nicht ganz stabil ist

Nochmals Danke an alle, die mir geholfen haben.

Michael

Zitat

Original von Hitman47
Es ist wohl ein Abhängigkeitsproblem.

apt-get install libhtml-template-expr-perl

...

Bei mir ist libhtml-template-expr-perl bereits installiert. Es läuft trotzdem nicht

Zitat

In der sid oder sarge version?

Es ist die Version in sid, vdr-experimental

Zitat

eventuell mal mit --purge deinstallieren, und neu installieren.

Ich habs schon mit und ohne --purge versucht. Bleibt immer das gleiche. Auch ein "Downgrade" auf vdradmin-am hat nichts gebracht.

Michael

Seit einigen Tagen beendet sich der vdradmin bei mir immer nach der ersten Anfrage nach einer Seite. Nach der Paßwortabfrage erhalte ich noch die Kontrollleiste und danach nichts mehr. Ein ps zeigt, dass kein vdradmin mehr läuft.

Wenn ich vdradmind.pl von der Kommandozeile aus starte (mit -nf) beendet er sich ebenfalls nach der ersten Anfrage, und das ohne irgendeine Ausgabe zu machen.

Leider konnte ich keinerlei Log-Ausgaben finden, /var/log/vdradmin.log ist leer und im syslog steht nichts drin.

Ich benutze vdradmin Version 0.97-am3.4.2-2 von e-tobi auf Debian etch.

Vor einiger Zeit habe ich von nvram-wakeup auf acpiwakeup umgestellt. Da der Rechner seit dem aber meistens (zufälligerweise) bereit an war, wenn eine wichtige Aufnahme anstand, habe ich das folgende Problem erst gestern gemerkt, als er eine Aufnahme versäumt hat:
ACPIwakeup schreibt immer die Zeit nach /proc/acpi/alarm, nach der der Rechner in der lokalen Zeitzone aufwachen soll. Wenn sich die locale Zeitzone (z.B. ME(S)Z) aber von der unterscheidet, in der die HW-Uhr läuft (z.B. UTC), wacht der Rechner zum falschen Zeitpunkt auf.

Um das zu korrigieren habe ich das Skript so erweitert, dass man in /etc/vdr/vdr-addon-acpiwakeup.conf angeben kann, dass die HW-Uhr nach UTC läuft. Der Patch ist zwar noch nicht ausführlich getestet, aber er scheint (für mich) zu funktionieren. Das Standardverhalten ist das alte geblieben, aber wenn in /etc/vdr/vdr-addon-acpiwakeup.conf die Zeile ACPI_UT="yes" ergänzt wird, wird die Zeit nach UTC umgerechnet.

Hier ist der Patch:

diff -u S90.acpiwakeup S90.acpiwakeup.gmt
--- S90.acpiwakeup      2005-07-01 16:39:34.000000000 +0200
+++ S90.acpiwakeup.gmt  2005-07-01 16:38:10.000000000 +0200
@@ -16,17 +16,35 @@
 [ -z "$ACPI_REGULAR_DAYS" ]   && export ACPI_REGULAR_DAYS="0"
 [ -z "$ACPI_REGULAR_TIME" ]   && export ACPI_REGULAR_TIME="00:00"
 [ -z "$ACPI_START_AHEAD" ]    && export ACPI_START_AHEAD="5"
+[ -z "$ACPI_UT" ]             && export ACPI_UT="no"


 LOG="logger -t vdr-addon-acpiwakeup "
 TIMER=$1


+
 TimeToString ()
 {
+    if [ "$ACPI_UT" = "yes" ]; then
+       TimeToString_ut "$@"
+    else
+       TimeToString_local "$@"
+    fi
+}
+
+TimeToString_local ()
+{
     echo $(perl -e "(\$s,\$mi,\$h,\$d,\$mo,\$y,\$t,\$t,\$t)=\
        localtime($1); printf(\"%04d-%02d-%02d %02d:%02d:%02d\",\
        \$y+1900,\$mo+1,\$d,\$h,\$mi,\$s);")
 }


+TimeToString_ut ()
+{
+    echo $(perl -e "(\$s,\$mi,\$h,\$d,\$mo,\$y,\$t,\$t,\$t)=\
+       gmtime($1); printf(\"%04d-%02d-%02d %02d:%02d:%02d\",\
+       \$y+1900,\$mo+1,\$d,\$h,\$mi,\$s);")
+}
+
 if [ $ACPI_ENABLED = "yes" ]; then
     # check if we should wake up before the next timer:
     if [ $ACPI_REGULAR_DAYS -gt 0 ]; then

Gruß,
Michael

Ich habe ein Problem mit den neueren Versionen vom Xine-Plugin:
Wenn ich in einer Aufnahme mit Hilfe des Plugins oder vdradmin eine Schnittmarke setze und anschließend versuche, diese Marke zu verschieben, braucht VDR mehrere Minuten, bis er auf die Eingabe reagiert. Das selbe Verhalten zeigt er danach bei allen weiteren Eingaben.

Gelegentlich tritt das Problem auch nach einiger Benutzung auf, ohne dass ich Schnittmarken gesetzt oder verändert habe. Um danach wieder ein normales Verhalten zu erreichen, ist es nötig, den VDR zu beenden und neu zu starten.

Bei Version 0.3.4 des Plugins tritt dieses Problem bei mir nicht auf, aber bei allen neueren Versionen bis einschließlich 0.5.0.