Posts by grmpl

    Hi,
    sorry, dass ich nicht mehr geantwortet habe. Aber das Thema war für mich abgeschlossen und ich hab' vergessen mal wieder reinzuschaun.


    Ich kann den Fehler reproduzieren. Kann sein, dass ich eine Bibliothek vergessen habe. Ich weiß aber nicht, wann ich die Zeit finde, mir das anzusehen. Wie wichtig ist Dir die Fehlerbehebung noch?

    Sorry, ich musste noch mal alles umbauen, weil ich festgestellt habe, dass es Unsinn ist, das komplette Projektverzeichnis zu pushen.
    Es hat ein wenig gedauert, bis ich das jetzt so hinbekommen habe, dass ich zufrieden bin.


    Jetzt sollte es hoffentlich passen, das Projekt ist wieder gefüllt.

    Ich dachte mir doch, dass ich nicht der einzige bin. :]
    Jetzt habe ich mein Android Studio Project mal auf github abgelegt: https://github.com/grmpl/androvdr. Ich hoffe, das passt lizenztechnisch.
    Das apk liegt im Verzeichnis androVDR: https://github.com/grmpl/andro…oVDR/androVDR-release.apk . Ich habe die Versionsnummer hochgezählt, es sollte ein update möglich sein.


    Zwei Änderungen habe ich gemacht:

    • Das ACRA habe ich entfernt: Das sollte Crash-Reports generieren. Aber da sich eh keiner um das Projekt kümmert, weil es beim Crash eh nicht funktionierte und weil es eine "deprecated" Funktion nutzt, habe ich es entfernt.
    • Den Default-Port habe ich auf 6419 umgestellt. Mich hat genervt, immer wieder die 2001 anzupassen. ;D

    Schaut mal, ob alles läuft. Ich kann für nichts garantieren!

    Hi,
    ich hoffe, es passt hier halbwegs rein:
    Hat außer mir sonst noch jemand das Problem, dass AndroVDR auf aktuellen Android-Versionen (bei mir CM13) nicht mehr läuft?


    Ich habe die App neu kompiliert und sie läuft bei mir jetzt wieder. :D
    Ich kann die neu kompilierten apk's auch gerne zur Verfügung stellen - ich möchte sie nur nicht "offiziell" irgendwo hinstellen, weil ich das nur "hingebastelt" habe und keinerlei Erfahrung mit der Veröffentlichung von Apps habe.


    Grüße
    Markus

    Hi Leidensgenossen,
    das vdr-plugin-vnsiserver-Paket aus dem Unstable-Repository würde helfen:
    Kurz nachdem der Quellcode-Abzug zu dem Paket gemacht wurde, hat der Entwickler des Servers eine Korrektur eingebaut, so dass der VNSI-Server jetzt wieder abwärtskompatibel zu 1er-Clients ist.
    Leider kann man das unstable-Paket nicht einfach runterladen und installieren, weil es über fehlende Abhängigkeiten meckert.


    Wenn ihr wie ich deswegen nicht alles auf unstable umstellen wollt, könnt Ihr für das Paket die Sourcen holen, mit dem diff der beiden Versionen patchen, das Paket neu bauen und installieren.
    Damit funktioniert es bei mir und das ganze ging auch auf der langsamen Atom-Büchse in wenigen Minuten.


    Hier eine Kurzanleitung mit den nötigen Befehlen:


    Ich weiß nicht, ob die Lösung elegant ist. Zumindest funktioniert sie und beim nächsten Update darf das Paket ruhig wieder durch ein offizielles Paket aktualisiert werden.

    Sorry, das sollte nicht heißen, dass ich mit der 0.3er nicht zufrieden bin! Ganz im Gegenteil.


    Wundern tut's mich nicht, aber manche Problem erledigen sich mit dem nächsten Release, ohne dass man sie meldet. Die Hoffnung stirbt zuletzt ;-)


    Nachdem sich anscheinend niemand für den Fehler interessiert (keine Antwort auf meinen Thread, keine Ergebnisse mit Google), habe ich mir die Mühe gespart, das bei den XBMC-Entwicklern anzubringen.
    Wenn sich noch mehr mit dem Problem melden würden, dann wäre das natürlich was anderes.

    Hi,
    Dein Kernel erkennt die Fernbedienung, aber die /dev/input/input7 und /dev/input/input8, werden nicht angelegt?
    Du bist Dir sicher, dass Du Deine Ausgabe von /proc... nach dem Einstecken des USB-Empfängers der HAMA-Fernbedienung gezogen hast? ;-)


    Wenn der Kernel das Device erkennt aber keine entsprechenden Input-Devices angelegt werden, dann vermute ich, dass an Deinen udev-Regeln was nicht stimmt.


    Du hast einen Sundtek-Empfänger? Ich könnte mir vorstellen, dass dessen Installationsroutine Deine udev-Regeln durcheinander gebracht hat. Wenn ich mir diverse Postings auf dem Sundtek-Supportportal so ansehe, scheint der dort recht tief einzugreifen.

    Hi,
    nachdem mein VDR recht neu ist, kann ich nichts zum 0.1er sagen. Aber nicht jedes Update macht auch alles besser ;-)


    Wie gesagt: Seit dem aktuellen nvidia-Treiber funktioniert bei mir auch vdpau in HD im VDR.
    Der 190er im vdpau-Repository ist ja nicht mehr der neueste, aber die xine-Bibliotheken sind relativ neu, das passt vermutlich nicht mehr so ganz zusammen.


    Ich habe das x-update-Repository eingebunden:
    deb http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu lucid main
    deb-src http://ppa.launchpad.net/ubuntu-x-swat/x-updates/ubuntu lucid main


    Allerdings eine Vorwarnung, falls Du ein apt(itude) update/upgrade machst: Bei mir stand gleichzeitig ein neuer Kernel zum Update und danach ging erst mal gar nichts mehr, weil die dkms-Pakete irgendwie nicht richtig kompilieren: Bei mir hilft da im Moment nur ein dpkg-reconfigure nach dem Reboot mit dem neuen Kernel. (dpkg-reconfigure alsa-dkms v4l-dvb-dkms nct677x-dkms nvidia-current)

    Ist stoppe ja inputlirc nicht, um den Input bei VDR zu verhindern, sondern um die Devices freizugeben, die inputlirc sonst blockiert.


    Aber Du hast ja recht: Meine Lösung ist nicht so ganz sauber.


    Für alle, die es besser machen wollen, hier die Zusammenfassung was man besser machen könnte (von nicht getestet):
    1) inputlirc ohne "-g" - damit werden die Devices nicht blockiert
    2) inputlirc nicht stoppen, d.h. die start- und stop-Zeilen in 30inputlirc vom Original übernehmen und nicht anpassen:

    Code
    1. start on starting vdr
    2. stop on runlevel [016]


    3) die Tastatureingabe in VDR blockieren (laut steffen_b: XKeySym aus der remote.conf für vdr-sxfe, bei xine in der Keymap alle Tasten auf VOID setzen).

    Hi,
    der Einzige scheine ich nicht zu sein, weil es ein Kumpel nachvollziehen konnte, aber anscheinend interessiert es keinen, oder warum finde ich dazu keinen Thread?


    Problem:
    Ich nutze yavdr 0.2 - stable auf aktuellstem Stand.
    Wenn ich XBMC aus VDR heraus starte und dann eine DVD (egal welche) einlege, dann bekomme ich "unaligned transfer" Meldungen im Kernel-Log und XBMC kann die DVD gar nicht oder nur zum Teil abspielen. Meistens stürzt XBMC beim Abspielversuch sogar ab.


    Der Fehler tritt nur bei dieser Reihenfolge auf. Er tritt nicht auf, wenn ich die DVD einlege während VDR läuft und dann erst XBMC starte. (Obwohl ich im VDR den Automount deaktiviert habe und daher kein Zugriff auf die DVD erfolgt, bis XBMC startet)


    Und er tritt auch nicht mehr auf, wenn ich die DVD wieder auswerfe und neu einlege.


    Ich habe schon versucht, alle Automounter zu dektivieren (cronjob, hal-polling), das hat aber keinen Effekt.


    Irgendwas tut XBMC beim ersten Zugriff auf das Laufwerk, das es durcheinander bringt.
    Wie gesagt: Ein Kumpel konnte das mit komplett anderer Hardware nachvollziehen.


    Weiß jemand was das sein kann?

    Hi,
    kann es sein, dass die xine & Co -Versionen im derzeitigen yavdr-stable Repository nicht richtig zum nvidia-Treiber passen?


    Ich war komplett auf yavdr-stable und hatte Probleme mit HD in VDR: 100% CPU-Last, Artefakte, Tonaussetzer, ...


    Bei normaler Auflösung war vdpau aktiv (paar Prozent CPU-Last) und in XBMC konnte ich auch HD ohne Probleme ansehen. Nur nicht im VDR (egal ob xine oder xineliboutput).


    Der Einzige scheine ich ja nicht zu sein: http://www.vdr-portal.de/board/thread.php?threadid=99906


    Seit ich den aktuellen nvidia-Treiber vom x-update-Repository eingespielt habe, funktioniert es.
    Also scheint die derzeitige stable-Version nicht so recht zusammenzupassen.

    Da steht absichtlich vdr-frontend drin:
    Ich möchte ja, dass sich inputlirc immer beendet, wenn ich einen "externalplayer" aufrufe (XBMC, firefox, terminal,...) und er muss wieder starten, wen ich zurückkomme.
    Und vdr läuft ja dauernd im Hintergrund, nur das frontend wird genau passend gestartet und gestoppt.


    Oder habe ich da einen Denkfehler?
    Es funktioniert zumindest so recht gut, außer dass sich vdr im Log beklagt, dass lirc nicht da ist, wenn das frontend nicht aktiv ist.

    Hi zusammen,


    ich bin zufällig drüber gestolpert, warum meine advancedsettings.xml keinen Erfolg hatte:
    Der Tipp gilt nur für ältere XBMC-Versionen!


    In der aktuellen Version gibt es dieses Setting nicht mehr, stattdessen gibt es in den Einstellungen eine Option "Fernbedienung sendet Tastatureingaben". Wenn man das aktiviert, kann man auch in der virtuellen Tastatur mit den Cursortasten navigieren.

    Danke :-)


    Das mit dem Abschalten der Tastatur in VDR ist natürlich auch eine Möglichkeit. Dann braucht man wahrscheinlich den Start/Stop von inputlirc in Abhängigkeit von vdr-frontend auch nicht. Allerdings hatte ich beim Experimentieren auch eine normale Tastatur am Rechner und war manchmal froh, dass ich damit VDR noch bedienen konnte.


    Und mit dem Gerät hast Du auch recht. Manchmal ist es auch mein USB-DVB-Tuner, der nicht rechtzeitig fertig ist. Ein bekanntes Problem.
    Da ich mich erst mal um die Fernbedienung gekümmert habe und die sporadischen Probleme zweitrangig waren: In welchem dieser vielen Threads dazu findet man eigentlich eine vernünftige Anleitung, wie man das Problem sauber in den Griff bekommt?

    Hama MCE Remote (Ortek VRC-1100): Anleitung für yavdr 0.2


    Hallo,
    nachdem ich jetzt lange gekämpft habe, um meine HAMA-Fernbedienung korrekt einzurichten, und von den diversen Anleitungen hier und anderswo ziemlich verwirrt wurde, versuche ich mal eine richtige Anleitung zu schreiben. ;-)


    Ein paar Anmerkungen vorweg:
    1) Die Fernbedienung ist ein reines USB-HID. D.h. für das Betriebssystem eine Tastatur und eine Maus. Es ist Unsinn, den Treiber lirc_atiusb zu laden, weil der mit dem Gerät nichts anfangen kann! Mich hat das lirc_atiusb in diversen Anleitungen ziemlich verwirrt, weil ich eine ATI schon am Laufen hatte und dachte, das wird ganz einfach mit der HAMA.


    2) Die Fernbedienung ist wie gesagt eine Tastatur, allerdings sendet sie die wirrsten Tastenkombinationen. Leider versteht VDR keine Tastenkombinationen und kann daher einige Tasten nicht von sich aus unterscheiden (wenn eine CTRL-t hat und die andere CTRL-SHIFT-t). Mit inputlirc (und dem Parameter -c) kann man das aber elegant lösen. Also: Vergesst alle Anleitungen, die kein inputlirc nutzen, weil die die halbe Fernbedienung brach liegen lassen.


    4) Manche Tasten der Fernbedienung sind wirklich identisch, also nicht zu unterscheiden: OK/Enter, Info/rechte Maustaste und Play/Pause. Daher kann die Pause-Taste in VDR nicht benutzt werden! (Andere Player, wie z.B. XBMC nutzen die Play-Taste auch als Pause-Taste, VDR unterscheidet hier aber).


    3) XBMC kann im Gegensatz zu VDR auch Tastenkombinationen auswerten. Damit hat man zwei Alternativen:
    a) Man nimmt auch inputlirc für XBMC. Dann kann man die Fernbedienung wie jede andere Fernbedienung konfigurieren. Hab ich aber nicht gemacht.
    b) Man nimmt für XBMC kein inputlirc. Dann muss man in der keymap.xml die Fernbedienung als "keyboard" konfigurieren. Das hat einen Vorteil: Man kann die Mausfunktion der Fernbedienung nutzen und XBMC auch mit Mauszeiger steuern. Ich habe das bei mir mal so gemacht, allerdings bin ich mir nicht sicher, ob das wirklich sinnvoll ist. Da gibt's ein paar Haken dabei (siehe unten).


    Jetzt die Anleitung:
    1) inputlirc einrichten (siehe auch http://wiki.xbmc.org/index.php?title=Hama_MCE_Remote )
    Für die initiale Konfiguration von inputlirc habe ich im Web-Frontend von yavdr inputlirc aktiviert und einen der beiden zur Auswahl stehenden "HID 05a4:9881"-Empfänger gewählt. Dann ist schon mal sichergestellt, dass die Grundkonfiguration stimmt und inputlirc gestartet wird.


    Das reicht aber nicht:
    Die Fernbedienung meldet sich zwei mal beim System: Einmal als Tastatur und einmal als Maus. Ein paar der Tasten gehören dabei zur Maus und ein paar zur Tastatur. Damit man alle Tasten nutzen kann, muss man inputlirc beibringen, beide Geräte zu nehmen. Das kann er zwar aber es ist leider im Web-Frontend von yavdr nicht vorgesehen, daher muss man Hand an die Konfig-Dateien anlegen.


    Die beiden Geräte sind zwei der /dev/input/event*-Geräte. Je nach System sind das andere. In yavdr 0.2 muss man die aber nicht mühsam suchen, sondern kann einfach /dev/input/by-id/usb-05a4_9881-event-kbd und /dev/input/by-id/usb-05a4_9881-event-mouse nehmen (die sollten überall so heißen).


    Außerdem benötigt inputlirc zusätzliche Aufrufparameter, damit es funktioniert:
    -m0: Ansonsten ignoriert inputlircd diverse Tasten
    -c: Dann wird ein CTRL-SHIFT-t nicht nacheinander als Ctrl-, Shift- und t-Event geschickt, sondern nur ein CTRL_SHIFT_KEY_T Event. Nur so kann VDR mit Tastenkombinationen umgehen.
    -g: Die Devices dürfen nur von inputlirc benutzt werden. Ansonsten bekommt VDR das Event von inputlirc und dann noch das Event von der Tastatur und ein "Auf" wird zu zwei "Auf".


    Eigentlich wollte ich beides (Parameter und Geräte) einfach in /etc/default/inputlirc eintragen. Die wird aber komischerweise nicht gezogen (warum??). Daher habe ich /etc/init/remoted.conf angepasst.


    Also: /etc/yavdr/templates_custom/etc/init/remoted.conf/30inputlirc anlegen mit folgendem Inhalt:


    Zum Original (/usr/share/yavdr/templates/etc/init/remoted.conf/30inputlirc) wurde die Zeile "stop on stopping vdr-frontend" eingefügt (Erklärung unten bei XBMC) und die "exec ..."-Zeile angepasst.


    Danach ein "sudo process-template /etc/init/remote.conf" und am besten einen Reboot.


    Das war's eigentlich schon, die Fernbedienung ist für VDR nutzbar. Anpassungen in lircmd.conf oder hardware.conf sind nicht nötig.
    Zum Konfigurieren löscht man entweder (falls vorhanden) die LIRC.*-Zeilen in der /etc/vdr/remote.conf und lernt sie dann beim Starten von VDR an, oder Ihr könnt folgende Zeilen von mir dort einfügen:


    (ist noch optimierungsfähig)


    Ich hab' noch in /etc/vdr/keymacros.conf den Start von XBMC auf die "Homepage"-Taste (ganz oben rechts) gelegt:

    Code
    1. User1 @externalplayer Ok


    Wer wissen will, welche Tasten welche Kombination erzeugen: In meiner keymap für XBMC habe ich das teilweise dokumentiert, ansonsten "irw /dev/lircd" aufrufen und ausprobieren.


    2) XBMC
    Wie gesagt wollte ich die Mausfunktion in XBMC erhalten. Da die Event-Devices von inputlirc mit "-g" aber in Beschlag genommen werden, geht das nicht, wenn inputlirc läuft.
    Ich habe das dadurch gelöst, dass inputlirc mit dem vdr-frontend gestartet und gestoppt wird. Das ist durch die "stop on ..."-Zeile in /etc/init/remote.conf gelöst (siehe oben). Damit wird inputlirc automatisch gestoppt, wenn das vdr-Frontend gestoppt wird und wieder gestartet, wenn er wieder startet. Das hat den Zusatznutzen, dass die Mausfunktion in jedem "externalplayer" von VDR verfügbar ist, auch im Firefox.


    XBMC muss man dann nur die ganzen wirren Tastenkombinationen beibringen. D.h. eine keymap-Datei anlegen und entsprechend editieren.
    Hier meine Keymap (einfach als /var/lib/vdr/.xbmc/userdata/keymaps/hama.xml speichern):


    Will man lieber inputlirc nutzen, dann muss man die "stop on ..."-Zeile aus der remoted.conf entfernen und die lircmap.xml korrekt pflegen. Das habe ich aber nicht probiert.


    Offene Punkte/Schwachstellen:
    1) Manchmal ist inputlirc nicht fertig, wenn VDR schon startet. Dann geht die Fernbedienung nicht. Ich hab' jetzt einfach mal ein "sleep 5" in /etc/vdr.conf eingebaut. Ob das reicht, weiß ich noch nicht. Es ist sicher auch keine schöne Lösung.


    2) Die Info-Taste ist die rechte Maustaste. Die lässt sich in XBMC nicht konfigurieren und daher ist sie in XBMC leider meistens nicht passend als "Info". Liese sich nur durch inputlirc für XBMC lösen.


    3) Die virtuelle Tastatur in XBMC reagiert nicht auf die Cursor-Tasten, egal was man in die Keymap einträgt. Das sollte sich mit einer /var/lib/vdr/.xbmc/userdata/advancedsettings.xml lösen lassen:

    Code
    1. <advancedsettings>
    2. <navigatevirtualkeyboard>true</navigatevirtualkeyboard>
    3. </advancedsettings>


    Er liest die Datei zwar laut xbmc.log, aber die Einstellung hat bei mir leider keinen Effekt. Auch das lässt sich mit inputlirc beheben. Oder man wählt die Tasten mit der Mausfunktion, was aber mühsamer ist.
    Edit: Problem gefunden! -> siehe späteres Posting


    Falls noch jemand weitere Tipps hat (Warum zieht /etc/default/inputlirc nicht? Warum die advancedsettings.xml nicht? Wie sieht die lircmap.xml für XBMC mit lircmap aus?): Ich nehme gerne weitere Tipps an.


    Viel Spass :-)