Posts by Negge

    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?


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


    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.



    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...



    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?!?

    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?!?

    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?

    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... ;(

    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 ....

    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...

    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?

    Hi,


    ich habe ein Problem mit dem VDRseriestimer. Und zwar ist der erzeugte Pfad nicht wie erwartet. Das gilt für alle vdrseriestimer. Der Pfad lautet bspw. "Datei <Flashpoint.de> ähnelt dem Titel <Flashpoint.de> mit einem Abstand von 0 (max 3),verwende Datei </var/cache/eplists/episodes/Flashpoint.episodes>Hash %Config:-------------Bugfixes => noBugfixesCode => noCategory¹²³ ="


    im log steht: executing command 'vdrseriestimer --title 'Flashpoint' --subtitle 'Zum Schutz des Bösen' --date '01.08.13' --time '02:35' --channel 9 --timet '1375317300' '


    gebe ich manuell an der Konsole "vdrseriestimer --title 'Flashpoint' --subtitle 'Zum Schutz des Bösen' --date '01.08.13' --time '02:35' --channel 9 --timet '1375317300" ein, erhalte ich:



    Ist das problem bekannt? Was läuft da schief?

    Eine alternative wäre bspw. ein VDR-SXFE-remote-client auf dem Atom und auf dem Server das Backend mit xineliboutput. So das der Server nur sein Display per Remote auf dem Client darstellt, dann ist das Schneiden kein Problem mehr. So hab ich es inzwischen bei mir am laufen, da ein reiner Client mit Streamdev auf bei mir nicht so das Hihglight war. Du muss am Client lediglich die das template für das xinelibfronend anpassen, das er nicht mehr lokal auf dem xinllinoutput zugreift, sondern auf die IP des Servers. Und natürlich musst du am Server den remote-Zugriff für den Client freigeben. Damit sich das ganze etwas flüssiger bedient, hat sich bei mir am client bewährt "--buffers=300" zu setzen (für frontend).

    Erstmal vielen Dank an die Entwickler von YaVDR. Ich denke ich habe da aber noch einen Bug gefunden


    Wie vielleicht bisher kaum jemandem aufgefallen ist. Unter YaVdr 0.5 fehlen bzw. funktionieren die Senderlogos bei Skinelchi nicht. Beim aktuellen Skin-Elchi hat sich der Ort der Senderlogos leicht verändert. Bisher zeigt ein symolischer Link von /var/lib/vdr/plugins/skinelchi/logos auf /usr/share/vdr-xpmlogos. Für den aktuellen Skinnelchi müssen die Senderlogos Aulösungspezifisch unter hqlogos, 576, 720 und 1080 liegen, also


    /var/lib/vdr/plugins/skinelchi/logos/hqlogos
    /var/lib/vdr/plugins/skinelchi/logos/1080
    /var/lib/vdr/plugins/skinelchi/logos/576
    /var/lib/vdr/plugins/skinelchi/logos/720


    Und zudem in der passenden Auflösung:


    Code
    1. The path to the logos must be supplied without the <logos>-subdirectory. This is added by
    2. skineElchi (as it is done for hqlogos, too)
    3. So logos will be searched for in the following directories depending on the vertical resolution:
    4. 576 (SD): 64 x 48 pixels, max 240 colors: <logodir>/hqlogos
    5. 576 (SD): 64 x 48 pixels, max 16 colors: <logodir>/logos/576
    6. 720 (HD): 104 x 78 pixels, max 240 colors: <logodir>/logos/720
    7. 1080 (HD): 160 x 120 pixels, max 240 colors: <logodir>/logos/1080


    Passende Logos findet man bspw. unter http://www.minidvblinux.de/svn…/plugins/skinelchi/logos/


    Ich hoffe das hilft einigen weiter. Eventuell kann dies ja auch in der nächsten YaVDR-Version korrigiert werden. Kann man eigentlich irgendwo ein Ticket fürs Bugfixing in YaVDR erstellen?


    Beste Grüße

    Nur zu Erkläruung. Das Problem am Netzwerk scheint zusätzliche Last zu sein. Die beiden Rechner hängen zwar direkt am Gibgabit-Switch, aber wenn andere Rechner was auf den Server kopieren oder ziehen (per SMB) dann kommt es zu hängern. Um das zu vermeiden müsste man eine Art QOS haben, wo der Daenstrom für vdr-sxfe / libxine haben im Netzwerk bevorzugt / real time übertragen wird. Ich wüsste jetzt nicht wie man das einrichten könnte. Daher der andere Ansatzt. Ich bin aber für vorschläge offen.


    BTW.: Ich hoffe so langsam blicke ich mit dem HD-Kram hoffe ich mal weiter durch. Die öffentliche rechtlichen übertragen in 720p, also schon progressiv, so dass man für diese gar keinen Deinterlacer braucht und funktioniert das ganze daher so "smooth" mit dem Ion2 ? Da ist also vöölig egal was ich unter Deinterlacing einstelle (momentan temporal). Würde ich also mit dem Ion2-System mit 1080i dann Probleme bekommen und eine potentere VDPAU-Grafikkarte bräuchte ich nur für 1080i-Sender (die es Free-to-air nicht gibt?) ?

    Hi,


    besten dank für den Test. Die Karte hört sich ja super an.


    Du hast ja abgeschätzt, dass die Karte ca. 6-8Watt im VDR-Betrieb Primärseitig ziehen soll. Mit Wandlungsverlusten im 80+-Netzteil wäre das ja Kartenbezogen nur noch etwa 5-6,5W bei der Karte, die der Kühlkörper abführen muss. Die paar Watt müsste man doch auch ohne ein aufwendiges Lüftungskonzeptrein über den Netzteillüfter wegkühlen können, oder hab ich da was übersehen?


    Besten Gruß

    Ich bin da tatsächlich noch recht neu in der Materie.
    Ich hatte bisher nur die "Standard-Einstellungen" unter YaVDR mit meinem Ion2-System (HD: BOB, SD: temporal) und fand das Bild damit schon bei SD vergleichbar zu FullFeatured-Zeiten und HD ist natürlich deutlich besser (wobei das ja nur die Öffentlich-rechtlichen Sender betrifft, hab kein HD+).


    Ich hab jetzt mal auf SD: temporal_spatial, HD: temporal umgestellt. Scheint sogar auch zu funktionieren, trotzt nur Ion2. Oder woran würde ich sehen wenn es nicht geht?!?

    Ich verwende im übrigen LibXine, wobei der vdr und libxine auf dem Server läuft und der Client nur das vdr-sxfe-frontend am laufen hat.


    Client und Server sind über Gigabit verbunden. Ist aber noch nicht augereift, weil manchmal ist die Bedienung der VDR sehr träge, vermuttlich weil da irgendwas im Netzwerk hängt. Daher war die Überlegung eine entsprechende VDPAU-fähige Grafikkarte in den Server zu packen und das Signal üer HDMI-Cat-Extender auf den TV zu schicken.

    Irgendwie gleitet der Thread in ein Schwachsinniges "Warum Frage ich danach" ab. Das Forum ist doch genau dazu da, um sich auszutauschen und Fragen zu stellen / Lösungen zu finden. Wenn ich Lösungen zu Problemen hab antworte ich auch und frage nicht, warum der andere fragt. Ich bin mit meinem VDR-Wissen nicht mehr ganz up-to-date, da ich bisher nur ein Fullfeatured-System hatte. Und da informiere ich mich gerne, bevor ich was kaufe was nicht funktioniert (letzteres passeirt leider oft genug)...

    @Coperhead: Aus dem Hardware-Empfehlungs-Thread hab ich ja die GT610 ( VDR-PC HDTV 2013 Empfohlene Systeme ), wobei der Thread das letzte mal im Februar aktualisiert wurde. Da ist die Frage, ob das noch aktuell ist denke ich berechtigt... ;).


    Ansonten ist der zugehörige Diskussionthread ziemlich ausgeartet. Ebenso hab ich in den Qvdpautest von fnu reingeschaut, wobei mir das auch nur so semi weitergeholfen hat. Ebenso hab ich bei wikipedia zu Nvidia geschaut. Die Bezeichnungen der GraKa von Nvidia ist ja alles andere als trivial nachvollziehbar, ebenso welche Grafikkarte nun worin besser ist...


    TheChief :


    Die GT 630 (GK208 ) mit TDP 25W hört sich recht gut an, hat die denn jemand, und wenn ja welche? Laut Wikipedia gibt es da wohl auch ein alte Version mit dem GF 108 ( http://de.wikipedia.org/wiki/Nvidia-Geforce-600-Serie ). Passiv scheint es da die ZOtac GT630 zone zu geben (preis ca. 50€). Die Zotac GT610 Zone (auch passiv) kostet etwa 40€. Was bringen die denn beispielsweise für Unterschiede am VDR mit VDPAU (dient ja nur als TV-Device, und nicht zum spielen...)...

    Hi,


    momentan hab ich meinen HD-VDR auf nem Ion2-Board als renen Client am laufen (siehe Sig). Ich überlge gerade jedoch, eine Grafikkarte in den Server einzubauen und das Bild dann per HDMI-CAT-Extender über die knapp 25m Cat6-SFTP-Verlegekabel (+Dosen) zum TV im Wohnzimmer zu übertragen. Welche aktuellen Grafikkarten (PCI-E) sind den zu empfehlen und was sind die Vor-/Nachteile. Ton sollte natürlich über HDMI laufen.


    Ich kann mich noch daran erinnern, dass mal (vor einiger Zeit) die die GT210 und GT220 recht interessant waren, vor allem aus Effizienzgründen. In der Hardwareempfehlung stand glaub ich die GT610 (http://geizhals.de/asus-gt610-…sc1-l0uanayz-a782365.html). Ansonsten sollten wohl (hatte fnu glaub ich mal empfohlen) die G210, GT520, GT610 oder GT430 ganz brauchbar sein. Ist das noch aktuelle. Brauch man temporal spatial?

    Dass man den Client mehrfach starten kann/muss, wenn man es braucht, hab ich, glaube ich, im README gelesen, aber mehrere streamdev-Server klingen unlogisch. Das ist sicherlich ein Missverständnis.
    Ich kann z.B. mehrere vlc auf einen streamdev-Server zugreifen lassen und alle zeigen unterschiedliche Transponder, solange genug Karten im Server stecken.


    Ja, stimmt. Auf den Streamdev-Server kann man von mehreren Clients parallel zugreifen.


    Allerdings funktionieren mehrere Streamdev-Client-Instanzen auf dem Client nicht zu der Nutzungsmöglichkeit mehrere devices. Der VDR meldet die anderen devices immer als belegt. Interesanterweise sagt das devstatus-plugin 16 devices. Hängt das mit dem dynamit-plugin zusammen?!?


    Naja, zurück zum Ursprungsthema: Zu der Problematik mit den radio-sendern mit streamdev ist nichts bekannt?