Posts by mdre

    Die Issues auf github sind erst mal aktiv. Ich kann jedoch nicht versprechen neue Features zu entwickeln. Mein vorrangiges Ziel ist, dass es auch weiterhin funktioniert.

    Es gibt anscheinend schon erste Ansätze davon im Kodi VNSI PVR Client: https://github.com/kodi-pvr/pv…rc/ClientInstance.cpp:380.

    Wie das genau angedacht war kann ich jedoch auch nicht erkennen.


    Auf Kodi-Seite kann man zu jedem Kanal einen Icon-Dateipfad angeben. Das Backend müsste nur die Icons übertragen. So weit mir bekannt bietet der VDR dazu an keine Infrastruktur bzw. Schnittstelle. Man müsste die Zuordnung von Kanal zu Icon selbst implementieren - so ähnlich wie die OSD-Plugins.

    Ich habe das Plugin aktuell mit einem vdr 2.4.6 auf einem Ubuntu 20.04 LTS am laufen. Unter Feedback verstehe ich, dass es sich zB. auch auf anderen Distributionen bauen lässt und funktioniert. Bzw. auch mit älteren VDR Versionen funktioniert

    Änderungen sind erst mal nicht geplant. Ich würde dennoch ganz gerne noch auf Feedback warten. Nicht dass ich durch dem Patch irgendwas kaputt gemacht habe.

    Hallo zusammen,


    nachdem ich über die Feiertage ein wenig Zeit erübrigen konnte, war es an der Zeit meinen VDR zu aktualisieren. Ziel war ein vdr als Backend mit mehreren Kodi Frontends. Als Grundlage dient das allseits bekannte Plugin vnsiserver. Leider hatte ich damit mehrere Probleme:

    • Sporadischer Deadlock im zusammenspiel von VDR und dem Plugin
    • Manchmal 'no data'-Meldung nach dem Umschalten.

    Leider hat FernetMenta seine Arbeit an dem Projekt eingestellt und das Git archiviert. Deswegen gibt es hier einen Fork, der meine Probleme löst:
    https://github.com/mdre77/vdr-plugin-vnsiserver


    Vielleicht findet es ja jemand hilfreich

    Viele Grüße

    Abend,


    Du kannst mit dem Tool nvidia-settings, unter dem Abschnitt "X Server XVideo Settings" einstellen auf welches Anzeigegerät synchronisiert werden soll. Wähle einfach den Beamer und genieße ein Bild ohne Tearing.


    Grüße, Max

    Bei mir hat sie nicht funktioniert.
    Ich hab folgendes probiert:
    - Windows 7 -> kein Empfang
    - Windows XP -> kein Empfang
    - alle Linux Treiberversionen die hier so durchs Forum geistern -> Frontend nicht gefunden / kein Empfang

    Quote

    Original von methodus
    ... so hier:


    Code
    1. #ifdef __cplusplus
    2. extern "C" {
    3. #define class _class
    4. #include <dlna.h>
    5. #undef class
    6. }
    7. #endif


    Dreckig. Aber lässt sich jetzt kompilieren. Wer noch ne Lösung hat: her damit!


    kompilieren wird es nicht, da so aus


    dlna_media_class_t class;
    dlna_media__class_t _class


    wird und somit der Typ nicht mehr passt.

    Quote

    Original von balta
    da mein aktueller Rechner keine serielle Schnittstelle mehr besitzt, habe ich mir heute einen USB <-> Serial Adapter gekauft. Leider bekomme ich lirc_serial mit meinem selbstgebauten IR-Empfänger nicht zum laufen. Hat hier schon jemanden Erfahrungen? Meine google-Suchen lassen mich langsam fragen ob es überhaupt mit einem Adapter geht...
    Grüße


    Der lirc-serial Treiber misst das Zeitintervall zwischen zwei Interrupts. Da es bei USB keine echten Interrupts gibt ist es auch nicht möglich einen seriellen Revceiver an einem USB-TTY Adapter zu verwenden.


    Grüße, Max

    Auszug aus man (2) outb:


    The value argument is passed first and the port argument is passed second, which is the opposite order from most DOS implementations.


    Wenn Du also unter linux programmieren willst (mit outb/inb) zuerst der Wert und dann der Port.


    Gruß, Max

    Hi Oli,


    eventuell fällt es leichter, wenn ich Die ein wenig Background erkläre.
    Diese Chips haben alle eine gewisse Anzahl von Registern (Speicherzellen), die in einen Speicherbereich Deines Rechners eingeblendet werden. In Deinem Fall werden alle Register des IO-Chips in den Bereich um die Addresse 0x2E eingeblendet. Die beiden Funktionen inb(inportb) und outb(outportb) werden nun zum Lesen oder Schreiben an diese Addressen benutzt. Das hat erstmal garnichts damit zu tun etwas auf einem Port auszugeben bzw. einzulesen. Die Reaktion auf das Schreiben auf so eine Addresse hängt damit zusammen welche Funktion das Register hat. In dem oberen Beispiel wird in das Konfigurationsregister des IO-Chips geschrieben. dort kann zB. eingestellt werden ob ein Port ein Ausgabeport ist oder ein Eingabeport - genaueres steht in der Dokumentation zum Chip.


    Du mußt jetzt erstmal den Chip so konfigurieren, damit die Ports die Richtige "Richtung" haben und dann über das richtige Register auf den Port schreiben bzw. lesen.


    Sollte Dir das alles zu aufwendig sein, dann verwende doch einen fertigen Treiber. Dann kannst du die Ports bequem über das Geräteverzeichnis ansprechen.


    Grüße, Max

    Vielen Dank erstmal für die Hinweise und den Patch, beides hat leider nicht funktioniert.
    Ich hab dennoch eine sehr einfache Lösung des Problems gefunden. In der lircd.conf gibt es eine Einstellung für die Toleranzen zur Erkennung eines Tastencodes. Dies sind die Werte eps und aeps.
    eps gibt die maximale relative Abweichung in Prozent an, und aeps die maximale absolute Abweichung.
    Nach der Erhöhung des Wertes eps von 30 auf 60, funktionierte die Fernbedienung wieder ordnungsgemäß - die spikes bleiben jedoch.
    Anscheinend dauert es zu lang oder unterschiedlich lang, bis die Interrupt Service Routine aufgerufen wird.


    Gruß, Max

    Hab die gleichen Probleme mit einem ASUS-M3N78 Board.
    Die Fernbedienung funktioniert nur sporadisch und es tauchen in den Logs die gleichen Meldungen wie oben beschrieben auf:
    lirc_serial: ignoring spike: 1 1 4991c8c7 4991c847 30ac5 d7c9c
    ...


    Ich hab mal mit dem Multimeter nachgemessen:
    es sind 7.8 Volt am seriellen Ausgang, 5V nach dem Spannungsregler.
    vom TSOP kommen 4V zurück -> soweit scheint da alles in Ordnung zu sein


    Ich vermute mal, dass dort irgendwelche übersprechenden Signale diese spikes auslösen.
    ansonsten bin ich auch ziemlich ratlos


    Grüße, Max