Posts by Negge

  • EPGD, Mysql und Fehlermeldung ": Duplicate column name 'imagecount'" ?!?

    Hi,
    der EPGD lief bei mir seit einigen Tagen. Heute gabs kein EPG mehr und das Syslog sagte, "Found dbapi 3, expected 4, please alter the tables first! Aborting now.". Ich hab darauhin " /usr/share/vdr-epg-daemon/mysql/alter/alter.sql" aufgerufen und erhalte folgende Fehlermeldung: "ERROR 1060 (42S21) at line 1: Duplicate column name 'imagecount'" . Was läuft da schief und wie ist das zu reparieren ?!?


    Besten Dank

  • Achtung ! Missbrauchsgefahr bei Fritzboxen

    7490 ist auch gefixxt. Ich hatte auf irgendeinem aktuelleren Pressebericht gelesen, dass wohl auf auf der SSL-Seite der Fritzbox tatsächlich die Usernamen auslesbar waren und dann in einem weiteren Schritt über eine Sichheitslücke der Zugirff auf die Box möglich wurde mit einem Admin-User möglich war. Fernwartung bleibt bei mir nun erstmal aus...

  • Igor-USB und lircd.conf?

    Was ich noch vergessen hatte, irw /var/run/lirc/lircd-lirc0 hatte ich vorher schon gestetsg,. Es lliefert etwas ausgiebigere infiormationen als nur irw, z.B. wird die Lircd.conf-Bezeichnung der gedrückten Fernbedienungstaste mit augebeben:


    bspw bei der Taste OK der Hauppaue FB bei der Taste OK:

    Code
    00000000000017a5 00 KEY_OK Hauppauge_A415-HPG

    und bei der ensprechenden Technotrend-Fenbedienung (wenn in der lircd konfiguriert) auch dort die entsprechende Bezeichnung.
    Im moment ist die Technotrend-Fernbedienung in der Lircd.conf deaktiviert (siehe vorheriger Post), und auch "irw /var/run/lirc/lircd-lirc" gibt bei Tastendrücken auf der Technotrend-Fernbedienung nichts aus (der VDR reagiert aber), bei der Hauppauge Fernbedienung dagegen alles wie erwartet.

  • Igor-USB und lircd.conf?

    HI,


    so ich habe die Technotrend Ferbnedienung in der lircd.conf jetzt komplett auskommentiert. D.h. für LIRC ist die nicht mehr konfigueriert. irw (ohne angabe eines Sockets) gibt auch nichts mehr aus, wenn ich auch der schwarzen technotrend-Fernbedienung einen Knopf drücke, ABER der VDR reagiert immer noch auf die Fernbedienung, allerdings nicht mehr mit doppeleter ausführung der Befehle. Ziehe ich den Igor-USB-Stecker raus dann, reagiert der VDR nicht mehr auf die Fernbedienungen. Um das ganze also nochmal Zusammenzufassen:


    Beobachtung:
    1) ohne eingestecken IgorUSB funktioniert keine Fernbedienung
    2) die silberne Hauppauge Fernbedienung funktioniert über die Lircd.conf und den IgorUSB wie erwartet, nachdem --lirc=/var/run/lirc/lircd zum vdr-sxfe-Aufruf hinzugefügt wurde
    3a) die schwarze Technotrend-Fernbedienung funktioniert auch noch, wenn diese in der lircd.conf garnicht konfiguriert ist
    3b) die schwarze Technotrend-Fernbedienung funktioniert auch, wenn vdr-sxfe ohne den parameter --lirc=/var/run/lirc/lircd gestartet wird.
    4) ist die schwarze Technotrend-Fernbedieung in der lircd.conf konfiguriert und vdr-sxfe wird mit dem parameter --lirc=/var/run/lirc/lircd gestartet, werden die Tastendrücke der schwarzen Fernbedienung vom sowohl von Lirc wie in der lird.conf als auch als von der auswertung nach 3) detektiert, was zu doppelten Tastendrücken bei einfachen aufruf fürht.
    5) Das Verhalten von 4) kann per vdr-sxfe aufgerufenen remote-vdr auf dem server als auch beim xmbc lokal auf dem client beobachtet werden.


    Daraus lässt sich IMHO folgendes ableiten:
    A) Nach der Beobachtung 5) handelt es sich um ein lokales Problem des clients.
    B) Nach 1) werde die IR-Signale vom Igor-USB-ausgewertet
    C) Nach 2) und 4) funktioniert zumindest die konfiguration von lircd.conf korrekt.
    D) Die Signale der schwarze Fenbedienung über den IgorUSB werden offenbar noch an der lircd.conf vorbei an anderer Stelle im System augewertet und an die Programme vdr-sxfe und xmbc übermittelt. Beim vdr-sxfe offenbar so, dass auch der Parameter --lirc=/var/run/lirc/lircd nicht nötig ist.


    Die Frage ist jetzt, wo passiert D), wie kann ich dies einstellen oder ausstellen (damit ich das dann über lircd.conf konfigureiren kann)? Irgenwo muss das ja konfiguriert sein. AHHRRRRGS Irgendwie muss man dem doch auf die Schliche kommen...

  • Igor-USB und lircd.conf?

    lircd.conf:


    Ich sehe da aber auch keine Ursache?!?

  • Igor-USB und lircd.conf?

    Was ich noch übersehen hatte. cat /proc/bus/input/devices liefert folgendes, wobei ich da jetzt nichts sehe was probleme machen könnte...


  • Igor-USB und lircd.conf?

    Ich hab gerade mal xbmc auf dem client gestartet, vergleichbare Problematik. Bei der Technotrend Fernbedienung werden alle tastendrücke doppelt interpretiert, bei der Hauppauge nicht.


    irw


    "ps aux | grep lirc" liefert:

    Code
    root       667  0.3  0.0      0     0 ?        S    22:10   0:12 [lirc_dev]
root       854  0.0  0.0  35028   816 ?        Ss   22:10   0:01 /usr/sbin/lircd --driver=default --device=/dev/lirc0 --output=/var/run/lir /lircd-lirc0 --pidfile=/var/run/lirc/lircd-lirc0.pid /etc/lirc/lircd.conf
root       860  0.0  0.4  69184  9412 ?        S    22:10   0:01 /usr/bin/python /usr/bin/lircd2uinput --lircd-socket=/var/run/lirc/lircd-lirc0
root      1130  0.0  0.0  10692   876 ?        S<s  22:10   0:00 /usr/sbin/eventlircd -f --socket=/var/run/lirc/lircd
root      1131  0.0  0.0   6368   572 ?        Ss   22:10   0:00 /usr/bin/irexec /etc/lirc/lircrc
vdr       4718 15.2  2.3 942880 47548 ?        S<Lsl 23:11   0:19 /usr/bin/vdr-sxfe --post tvtime:method=use_vo_driver --buffers=300 --reconnect --audio=alsa --syslog --silent --tcp --lirc=/var/run/lirc/lircd --nokbd --config /etc/vdr-sxfe/config_xineliboutput xvdr://192.168.1.30:37890
root      5025  0.0  0.0  10896   936 pts/9    S+   23:13   0:00 grep --color=auto lirc

  • Igor-USB und lircd.conf?

    Ist RC5.


    Wenn es daran liegen würde, dann dürfte der VDR ja nicht mit unterschiedlichen Effekten auf diesselbe Taste reagieren (siehe Taste mit der Beschriftung Text, wo am am VDR erkennen kann, dass er mal erst das VDR-Menu und dann den Videitext öffnet. Mal nur der Videotext kurz aufpop (so als hätte man erst die Videitext-Taste und dann die die Menutaste drückt) oder wenn man die Taste mal etwas länger (ca. 1s) festält das Munter zwischen dem VDR-Menu und dem Videotext-Signal hin und her flackert und auch mal das Vdr-Menu am ende offen bleibt. Also das IR-Signal derselben Taste wird also 2mal unterschiedlich bewertet, wobei es in der Lircd.conf (als auch nach IRW) immer dem Befehl KEY_MENU zugeordnet ist. Wird also definitiv 2mal interpretiert, als gäbe es irgenwo noch eine 2te Lirc-Instanz, die IRW nicht sieht, mit unterschiedlicher lirc-config?!?


    Ich hab jetzt auch nochmal testweise das lirc 0.9.0-16 aus das aus dem testing yavdr geupdatet, kein Unterschied...

  • Igor-USB und lircd.conf?

    Die Tastendrücke werden offen nicht über das Kbd übertragen, da mit der Effekt auch noch bei der Option "--nokbd" im vdr-sxfe auftauchen.


    und dann hab ich nochmal das den IgorUSB (bei laufendem vdr-frontend) rausgezogen und wieder eingesteckt


    Ergebnis

    Code
    Aug 14 20:38:05 q150 kernel: [ 3292.600079] usb 3-1: USB disconnect, device number 2
Aug 14 20:38:05 q150 kernel: [ 3292.603168] lirc_igorplugusb[2]: GET_INFRACODE: error -71
Aug 14 20:38:05 q150 kernel: [ 3292.603213] lirc_igorplugusb 3-1:1.0: lirc_igorplugusb[2]: igorplugusb_remote_disconnect done
Aug 14 20:38:05 q150 udevd[5254]: failed to execute '/etc/init.d/lirc' '/etc/init.d/lirc stop udev': No such file or directory
Aug 14 20:38:08 q150 kernel: [ 3295.052058] usb 3-1: new low-speed USB device number 3 using uhci_hcd
Aug 14 20:38:08 q150 kernel: [ 3295.235575] lirc_igorplugusb 3-1:1.0: lirc_dev: driver lirc_igorplugusb  registered at minor = 0
Aug 14 20:38:08 q150 mtp-probe: checking bus 3, device 3: "/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1"
Aug 14 20:38:08 q150 kernel: [ 3295.257118] lirc_igorplugusb[3]: Ing. Igor Cesko, Copyright(c) 2003 IgorPlug-USB (AVR) on usb3:3
Aug 14 20:38:08 q150 mtp-probe: bus: 3, device: 3 was not an MTP device
Aug 14 20:38:08 q150 udevd[5257]: failed to execute '/etc/init.d/lirc' '/etc/init.d/lirc restart udev': No such file or directory


    Verhalten ist so wie zuvor (die Fehlermeldung /etc/init.d/lirc restart ist vermutlich noch ein überbleibsel aus init.d-zeiten, oder?)

  • Igor-USB und lircd.conf?

    So, bin jetzt weiter.


    Mit --lirc ohne Spezifikation kam im Syslog die Fehlermeldung
    Aug 14 19:49:16 q150 lircd-0.9.0[847]: read invalid data from device /dev/lirc0


    mit --lirc=/var/run/lirc/lircd funktionieren die Befehle mit der silbernen Hauppauge Fernbedienung wie erwartet,


    ABER die schwarze Technotrend funktioniert nicht mehr richtig. Um genauer zu sein:
    Bspw. Ein Druck auf die Taste Text, die ja nach Lirc Key_menu zugeordnet ist und vorher den videotext geöffnet hatte, öffnet mal den videotext, und mal das Menu. Ebenso wenn man die Taste 1 drück landet man bei 11. Offenbar bekommt der VDR die Tastendrücke mit der schwarzen TT-Fernbedienung jetzt doppelt übermittelt, einmal so wie zuvor und einmal durch lirc. Insofern hattest du offenbar recht mit deiner Vermutung, das die Tastendrücke von der TT irgenwie an lirc vorbei an den VDR übertragen wurden und auch jetzt noch immer werden. Auf die Fehlerursache wäre ich alleine nicht gekommen, schönen Dank schonmal. Jetzt ist nur noch die Frage, wo die Kommandos herkommen, die an lirc vorbei übermittel werden?

  • Igor-USB und lircd.conf?

    Quote from seahawk1986


    Kannst du das genauer formulieren? Nur das Frontend vdr-sxfe oder ein VDR mit dem xineliboutput-Plugin, streamdev-Plugin und vdr-sxfe als Frontend?


    Quote from Negge

    Hab ich was übersehen?!?


    Weiß nicht, besonders viele Infos zu den restlichen Änderungen an yaVDR hast du ja nicht gegeben - warum muss es denn da überhaupt ein yaVDR sein wenn man nur vdr-sxfe braucht, das bekommt man doch wesentlich "günstiger" auf einem Rechner mit Ubuntu zum laufen...[/quote]


    Auf dem Client mit dem IgorUSB läuft (inzwischen) nur noch das vdr-sxfe-frontend. Das Backend läuft auf dem Server mit xineliboutput. Streamdev fand ich nicht so praktikabel. Und YaVDR deswegen, weil ich den zuerst auch als streamdev-client vorgesehen hatte. Zudem musste ich für die vdr-sxfe-Lösung lediglich das template für das xinelibfronend anpassen, das der client nicht mehr lokal auf dem xinllinoutput zugreift, sondern auf die IP des Servers.(Und natürlich am Server den remote-Zugriff für den Client freigeben). Damit sich das ganze etwas flüssiger bedient, hat sich bei mir am client "--buffers=300" fürs frontend bewährt. Ich hoffe das hilft erstmal weiter? Ansonsten ist die Signatur Hardwaretechnisch Up-to-date.


    Quote from seahawk1986


    Dann hat die Taste in deiner lircd.conf da keinen gültigen Namen - lircd2uinput liefert KEY_COFFE wenn es den Tastendruck nicht so übersetzen kann, das er an eventlircd weitergegeben werden kann.
    Wie leitest du denn die Tastendrücke vom lokalen eventlircd an das xineliboutput-Plugin weiter? Startest du vdr-sxfe mit --lirc falls es keinen lokalen VDR gibt?


    Gute Frage? Bin gerade nicht zu Hause und hab keinen Zugriff auf den VDR, werde ich aber heute abend mal nachschauen. Ansonsten Standard-Einstellung von YaVDR 0.5-stable, ib hab in der conf-Datei für vdr-sxfe-frontend nur die IP angepasst als --buffers="300" zugefügt. Da Fernbedienungsignal an der Server übertragen werden müsste da aber ja schon was drin stehen...


    Quote from seahawk1986


    Sehr merkwürdig - wie sieht die lircd.conf denn genau aus?


    Kann ich heute abend mal posten/anhängen. Aber wie gesagt schein lirc zumindest lokal am client ja zu funktionieren, so wie erwartet und mit irw getestet. Nur das was an den VDR weitergegeben wird, scheint nicht dem zu entsprechen, was in /etc/lirc/lird.conf steht.
    Ich hab auch schon gedacht, dass der bei de, IgorUSB evtl. die /etc/lirc/lircd.conf beim client garnicht berücksichtig. Im Manual (http://www.yavdr.org/documenta…/yaVDR_doc.html#eventlirc) steht ja in dem Eventlircd-Schaubild bei den "lirc-Empfänder über udev", wozu der IgorUSB soweit ich das verstanden hab ja gehören sollte, irgendwie aif /lib/udev/lirc_helper und /usr/dhare/lirc/yavdr-remote/remotes beruht. Wobei ich da auch (noch) nicht ganz blicke wie genau das funktioniert.
    BTW.: Die lirc-Konfiguration auf dem Server sollte ja auch keine rolle spielen, zumindest ist keine Fernbedienung konfiguriert.


    Wie gesagt verstehe ich die Ursache nicht. IRW greift offensichtlich auf die /etc/lirc/lircd.conf zu, und wenn ich was ändere in der lircd.conf, dann ändert sich in irw auch die Ausgabe. Der VDR reagiert aber genauso wie vorher. Daher meine Vermutung, das die /etc/lirc/lircd.conf für diese UDEV-Lirc-Empfänger evtl. gar nicht relevant ist?!? Aber was dann die richtige conf-Datei ist, ist mir unklar?!?

  • Igor-USB und lircd.conf?

    Hi,


    ich hab mal ne Frage zur lirc und dem igor-USB-Empfänger. Prinzipiell funktioniert die Hardware Problemlos, allerding komme ich mit der Einrichtung der Fernbedienung nicht weiter. Kurz zur Info. Der VDR mit dem Igor-Plugin ist ein reiner Client, auf dem nur das xineliboutput läuft. Entsprechend ist am diesem client auch lirc konfiguriert (nicht im WebIF, da der IgorUSB ha so erkannt wird)


    Momentan verwende ich die schwarze Fernberdienung von Technotrend, die bei der S2-3600 dabei war. Damit lässt sich der VDR bedienen, aber nicht alle Tasten machen dass was ich von denen erwarten würde?!?
    Und die silberne Hauppauge Fernbedieung funktioniert gar nicht. Wobei mit irw (bei laufendem VDR-frontend) kann ich bei beiden dern LIRC-Output sehen, so wie er auch in der /etc/lirc/lircd.conf eingestellt ist, aber!:


    Drücke ich auf der schwaren TT-Fernbedienung den Repeat-knopf (links neben der 0), dann öffnet sich das VDR-Menu, irw sagt "98 0 KEY_COFFEE devinput"
    Drücke ich auf der schwaren TT-Fernbedienung die Taste "Text" unter der 0, dann hätte ich gerne dass sich das Menu öffnet, aber es wird der videotext geöffnet und irw sagt "8b 0 KEY_MENU devinput"
    Die anderen Tasten der schwarzen TT-Fernbedienung tun in etwa das was Sie sollen.


    Die silberne Hauppauge Fernbedieng mach garnnichts. irw zeigt aber an, das Lirc etwas empfängt, bspw. bei der taste OK "160 0 KEY_OK devinput", am VDR tut sich aber nichts. Drücke die Taste OK an der schwarzen TT-Fernbedienung nimmt der VDR den tastendruck entgenen. irw zeigt hier auch "160 0 KEY_OK devinput".


    Also laut irw scheint mir die config in Ordnung, aber die Infos die irw erhält scheinen offenbar anders zu sein, als das was an den VDR übergeben wird?!? Hab ich was übersehen?!?

  • Epgsearch / vdrseriestimer führt zu Bildstörungen im Livebild/in Aufnahmen bei suchtimerupdate.

    Ich habe gerade mal einen neuen Suchtimer erzeugt (für "Nicht nachmachen!") und beim anschließenden Suchtimerupdate kam es auch zu einem ganz kurzen Ruckler im Liverbild (ZDF HD). Wobei kein Serietimer mehr aktiv ist. Der Ruckler war auch wesentlich kürzer als mit Seriestimern, aber vorhanden. Ich hab dann nochmal manuell ein weiteres Suchtimer-Update gestartet. Da gab es dann interessanterweise keinen Ruckler. Der Unterschied zwiscen den beiden Updates ist eigentlich nur, dass er beim ersten Aufruf 3 Timer für "Nicht nachmachen!" neu angelegt hat, bei den nachfolgenden nicht. Evtl. ist daher die Problematik die Übergabe der Informaionen an den VDR vom epgsearch geschuldet?!? Und das mit dem seriestimer-addon wesentlich mehr Daten übertragen werden?

  • Epgsearch / vdrseriestimer führt zu Bildstörungen im Livebild/in Aufnahmen bei suchtimerupdate.

    So ich hab jetz mal alle vdrseriestimer %Serie"%in den Suchtimer deaktiviert. Die Bildstörungen treten nicht mehr auf. CPU-Last des VDR steigt beim Update (SD-Kanal im Hintergrund) von 2-5% auf 35-65% und nur sehr kurz (ist mit top kaum zu erfassen, da Updateintervall zu kurz).


    Wenn ich nur einen einzigen Timer mit seriestimers laufen lassen, kommt es zu Bildaussetzter bei epgserchupdate. Zwar kürzer als zuvor mit den etwa 15 Timern vdrseriestimern, aber immer noch deutlich auch mit nur einem einzigen.


    Wie kommuniziert den der Seriestimer mit dem VDR. Gibt es da irgendeinen Flaschenhals, der zu Problemen führen kann. vdrseriestimer ist zwar ein super addon, aber so natürlich im praktischen Einsatz unbrauchbar für mich... ;(

  • Epgsearch / vdrseriestimer führt zu Bildstörungen im Livebild/in Aufnahmen bei suchtimerupdate.

    Ist den nen Celeron G1610 so eine schwache CPU. Zudem wird das Bild auf dem Server (soweit ich das verstanden hab) doch gar nicht dekodiert im xinelibplugin, sondern doch erst auf dem client mit vdr-sxfe, oder? Top sagt ja auch, dass nicht das serriestimer die CPU-Last zieht (5%), sondern der vdr-prozess (ca 50%). Ich vermute daher das da was anderes hängt. Vielleicht bei der Übergabe der Parameter an de VDR?


    Ansonsten ist dein Ansatz natürlich eleganter, direkt den EPG mit den Seriendaten aufzuwerten ....

  • Epgsearch / vdrseriestimer führt zu Bildstörungen im Livebild/in Aufnahmen bei suchtimerupdate.

    Zu Konkretisierung:


    Die Bildaussetzer ergeben sich in den Aufnahmen (also Störung in der Aufnahme) als auch im Live-Bild. Beim Abspielen einer Aunahme gibt es keine Bildaussetzer beim Suchtimerupdate. Der Problematik muss also irgendwo im Signalweg des Eingangssignals liegen. Also entweder werden die Signalübertragung der DVB-S-karten gestört (sind per USB2 angekoppelt, S2-3600) oder die Verarbeitung des TS-Streams.


    BTW: CPUfreq läuft nicht, da ich mit nem Xen-Kernel arbeite...

  • Epgsearch / vdrseriestimer führt zu Bildstörungen im Livebild/in Aufnahmen bei suchtimerupdate.

    Hi,


    ich habe ein (weiteres) Problem mit dem Seriestimer auf dem Server (Siehe Sig). Anscheinend wird eine beim Suchtimerupdate eine so hohe Last erzeugt, dass es zu Bildaussertzern im VDR kommt. Bemerkt habe ich Bildstörungen alle 30 minuten, auf HD-Kanälen dauern die Bildstörungen ca. 10-20s, auf SD 2-10s. Dies gilt für Livebild als auch für die Aufnahmen. Ohne vdrseriestimer bestand das Problem nicht.


    Ich hatte zuerst gedacht, dass man das mit einem besseren Nice-Level für den vdrseriestimer beheben könnte, allerding musste ich dann feststellen, dass dies schon vom YAVDR-Team berücksichtigt wurde (Danke nochmal an die gute Arbeitd es YaVDR-Teams). Der VDR-Prozess läuft ja schon hoch priorisiert auf nice-10, und vdrseriestimer mit super niedrieger Priorität 19.


    Der Server läuft mit xinelibout,. Im normalen SD-Betrieb (frontend läuft nicht auf dem Server) liegt die CPU-Last des vdr-prozesses nach top bei 2-5%. Beim epgsearchtimerupdate


    Epgsearch / vdrseriestimer führt zu Bildstörungen im Livebild/in Aufnahmen bei suchtimerupdate taucht erwartunggemäß der Prozess vdrseriestimer auf, mit einer CPU-Last von 1-5% über 3-5 Sekunden. In etwa gleichzeitig steigt die CPU-Last des VDR-Prozesse auf etwa 45-55% an und es kommt zu Bildfehlern.


    Am nice-Level und zuwenig CPU-Perfomance sollte es also wahrscheinlich nicht liegen?. Nur wieso führt ein Suchtimerupdate nun zu solchen Problemen. Ist da was bekannt. Eigentlich sollte das ja so nicht passieren. Haben andere ähnliche Probleme?