Posts by Negge

    Oder wie schon vorgeschlagen "mechanisch" und ohne Löten wäre der hier http://www.pollin.de/shop/dt/N…Endschalter_XZ_8_108.html oder der hier http://www.pollin.de/shop/dt/N…Endschalter_XZ_8_112.html . Kabel rein, anklemmen und gut...


    Der Endschalter XZ-8/112 ist ip64, aber das Gummi um den Stößes vorn sollte man hin und wieder mit Silikonspray bearbeiten, sonst wird der etwas hakelig. Wenn man den geschützt (z.B. im Haus) irgenwo montiert, kann man das Gummi um den Stößel auch ein wenig wegschneiden, dann reagiert der deutlich flinker (z.B. Als Türkontakt für Licht in einem Abstellraum, Dachboden... )

    Soll denn die Aufnahme auf dem Server oder auf dem Client laufen? Wenn auf dem Client, dann landen die Aufnahmen natürlich auf der HDD vom Client und dieser muss genug Tuner vom Server zur Verfügung gestellt bekommen, wie von Seahawk erwähnt. Wenn der Server sich darum kümmmern soll, braucht man am Client soweit ich mich entsinne das plugin extrecmenu, um am client das externe recoding-menu vom server einzubinden (Server Timer).
    Hat man hauptsächlich nur einen Vdr-Client und möchte eigentlich nur den Server bedienen, kann das auch noch anders lösen, indem man das frontend vom vdr-server per remote-frontend auf dem client darstellt. Dann braucht man kein Streamdev. Muss allerdings ein wenig Handarbeit an die config-scripte anlegen, weil letzteres so direkt in yavdr nicht vorgesehen ist.

    Hi,


    danke für die Hilfe. Genau das war es. "vdr" lief auf dem neuen Client nicht und damit war die pre-start-Bedingung nie erfüllt. Danke für die Hilfe. :tup


    Ich hätte da auch basierend meiem Problem hier ggf. noch eine Anregung für das WFE. Man kann ja im WFE bei "cutsom configuration" durchaus den vdr aus "disabled" setzen, und trotzdem ein frontend auf enabled setzen . Eventuell könnte man da dann ja noch einbauen, dass er dann die pre-start-Bedingung "WAIT_FOR=vdr" automatisch deaktiviert (wobei man die Dateien/templates ja sowiesow per Hand anpassen muss, da man dem frontend ja sagen muss zu welchem remote-vdr er sich verbinden muss). Nur so als Anregung (Code-Vorschlag siehe unten, soweit ich die Syntax verstanden hab. Die else-Bedingung kann man natürlich auch ganz weglassen...).


    Code
    .../vdr-frontend.conf/15_pre-start-start
    
    
    <?cs if:(vdr.backend != "disabled") ?>
    start wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:
    <?cs else ?>
    # start wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:
    <?cs /if ?>


    Danke für die gute Arbeit. :tup

    Hi,


    an den anderen hab ich nur bei lirc etwas per "template_custom" geändert. Sonst alles original yavdr. Und dieselben templates laufen auch dem anderen Client ja auch problemlos? "initcl list" zeigt in (siehe oben Zeile 9, vdr-frontend stop/pre-start, process 1094), das das vdr-frontend nach dem booten offenbar nicht gestartet wurde?!?


    Der Hinweis vom mini73 ist aber gut. An dem alten Client hatte ich das damals zuerst mit dem lokalen VDR getestet, der lief also/kann prinzipiell laufen (auch wenn der nix zu tun hat). Bei dem neuen Client hab ich den VDR auf dem Client nie eingerichtet.
    Der VDR scheint ja auch auf dem neuen Client nach "initcl list" nicht zu laufen (oder wird der per rc-script gestartet, heute abend mal checken). Ich muss ja zugeben, dass ich den Upstart-Krams bisher noch nicht ganz durchblickt hatte/habe.
    Im Prinzip kann ja in meinem Fall in meinem cutom-template das "start on started vdr" raus, oder? Und viel wichtiger die Bedingung "wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1" sollte auch raus, oder? (heute abend mal testen).
    Verständnisfrage: die Bedingung "start on stopped openbox-tools" started das fronted nachdem "stop xbmc" (falls xbmc läuft)? Weil XBMC im Fenstermanger openbox läuft?

    ~# initctl list (direkt nach dem boot)


    Code
    cat /etc/init/vdr-frontend.conf################################################################################## ##   The following configuration file is generated automatically by the yaVDR    ##     system. Don't change this file as every update of yaVDR will overwrite    ##         the local changes. Instead put your required customizations           ##       into /etc/yavdr/templates_custom/ based on the original templates       ##                      under /usr/share/yavdr/templates.                        ##                                                                               ##            http://www.yavdr.org/developer-zone/template-overview/ ##                                                                               ##                                                                               ################################################################################### yavdr-frontend - Starts vdr frontend#description     "yavdr-frontend"author          "Steffen Barszus <steffenbpunkt@gmail.com>"env HOME=/var/lib/vdrexport HOMErespawnstart on started vdr or stopped openbox-tools or started sound-device \         or vdr-frontend-restartstop on stopping vdr or stopping openboxpre-start script# wait for vdr, Xorg (after wm is running) and the sound devices to be loadedstart wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:start wait-for-job-state WAIT_FOR=sound-device TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1 ||:start wait-for-job-state WAIT_FOR=openbox-tools TARGET_GOAL=stop WAIT_STATE=waiting WAITER=vdr-frontend WAIT_FOREVER=1 ||:# dont start if some other application is runningif [ -e /tmp/.standalone ]; then   vdr-dbus-send /Remote remote.Disable ||:   exit 1fiend scriptnice -10#setuid vdr#setgid vdr#env XINE_BUFFER_LOG=1env USE_AUTOCROP=0export USE_AUTOCROPscriptexport DISPLAY=:1`dbget vdr.tempdisplay`export __GL_SYNC_TO_VBLANK=1export __GL_SYNC_DISPLAY_DEVICE=`/usr/bin/dbget system.x11.display.0.device`HUDOPTS=""XINELIBOUTPUTOPTS="--post tvtime:method=use_vo_driver --buffers=300 --lirc=/var/run/lirc/lircd-lirc0 --reconnect --audio=alsa --syslog --silent --tcp "CONFIG="--config /etc/vdr-sxfe/config_xineliboutput"exec sudo -u vdr /usr/bin/vdr-sxfe $HUDOPTS $XINELIBOUTPUTOPTS $CONFIG xvdr://192.168.1.30:37890end script

    Hi,


    also das Syslog ist unauffällig. Scheinbar wird weder das "vdr-Frontend" noch "xbmc" beim hochfahren gestartet (ergo kein Fehler, aber auch keine Startmeldung wie beim anderen System). Die Konfiguration ist etwas speziell, weil der/die Client nicht auf den lokalen vdr/xineliboutput zugreifen, sondern auf remote auf das xineliboutput des vdr-Servers (yavdr-headless). Die modifizierten configs aus /etc/yavdr/templates custom/ wurden entsprechen vom alten client auf den neuen übernommen (ebenso wie das server-wake-script). Fernbedienung fehlt noch in Details (andere Empfänger-Hardware), aber ein Problem nach dem anderen...


    WIe gesagt, eigentlich funktioniert dasmit den Konfig's ja auch. "start xbmc" und dann "stop xbmc" => frontent wird gestartet und funktioniert. Also kann da an diesen Konfig-Dateien eigentlich kein Fehler sein. ABER: Beim booten sollte er ja eigentlich automatisch xbmc oder das vdr-frontend mitstarten. Im WFE hab ich auch mehrmals die Ausgabe-Einstellungen geändert. Funktioiert leider nicht. Irgenwo verschluck er sich also, dass er ein frontend beim boot-Process startet. Nur wo und warum?!? :wand

    Hallo


    ich bin gerade dabei meinen vdr-client om wohnzimmer gegen eine leisere Version auszutauschen. Ich habe die Konfiguration soweit möglich/sinnvoll kopiert, aber beim neuen habe ich nach dem booten nur einen blinkenden Maus-cursor auf dem TV. Gebe ich dann per ssh “start xbmc“ ein, funktioniert xbmc. Gebe ich dann “stop xbmc“ ein, habe ich auch das vdr-frontend-bild. Wo könnte das hängen, dass er direkt zum vdr-frontend durchbooted? Bin ratlos?


    Danke und Gruß

    Um mir mal selbst zu anrworten. Alernative, die zu funktionieren scheint. Rsyslog.conf logging so anpassen:


    Code
    :msg, contains, "pctv452e: I2C error -121"  ~
    *.*;auth,authpriv.none<><------>-/var/log/syslog
    
    
    :msg, contains, "pctv452e: I2C error -121"  ~
    kern.*<><------><------><------>-/var/log/kern.log


    Und die zugemüllte console kann man in der /etc/sysctl.d/10-console-messages.conf abschalten mit


    Code
    kernel.printk = 2 4 1 7


    --


    Nachtrag:


    Unter Ubuntu 18.4 mit Yavdr-anisble die Datei


    /etc/rsyslog.d/30-pctv452e.conf


    mit Inhalt:

    Code
    #I2C-Fehlermeldungen pctv452e im Log unterbinden
    :msg,contains,"pctv452e: I2C error -121"  stop

    erzeugen und danach den rsyslog-daemon neu starten:

    Code
    service rsyslog restart


    Ggf. mit "tail -f /var/log/syslog" prüfen ob alles geklappt hat (beenden mit Strg+c).

    Um diesen alten Thread nochmal hochzuholen. Ubuntu/yavdr0.5 nutzt ja rsyslog. Wenn ich den obigen code jeddoch in die /etc/rsyslog.conf eintrage, dann erhalte ich folgende Fehlermeldung. Funktioniert also leider nicht?!?


    Hallo,


    die Fernbedieung ist eine RC-5, die Standard Hauppaupe von den FullFeatured damals (die silberne). Hab aber auch andere FBs gestestet (die sonst an ihren Geräten funktionieren). Da blinkt nix und weder bei cat "/dev/hidraw0" noch bei "irw /var/run/lirc/irmplircd" wird bei Fernbedienungdrücken irgenwas angezeigt.


    Wie kann ich denn checken ob was an dem IR-Teil kaputt ist? Oder ist die Firmware nicht richtig darauf geflasht?!? Oder hab ich was falsh angeschlossen. +;GND;n.c.;IR der oberen Pinleiste wenn man von hinten darauf guckt ist doch richtig, oder?!?

    Besten Dank für schonmal für die Rückmeldungen:


    ranseyer: Also alle 3 Pakete sind installiert (hängen auch von den addon-Paket ab...)


    @seahawk:


    ich hab dann meine udev-regel wieder gelöscht. Ich hatte auch nochaml den USB-Port gewechseltl. Hängt jetzt nacgh lsusb an

    Code
    Bus 002 Device 002: ID 16c0:27d9 VOTI

    und es wird ein hidraw0-device erzeugt.


    Nach dem booten sagt dmesg folgendes:



    Raus-reinstecken liefert:


    dmesg:


    Ein device "/dev/hidraw" gibt es es jetzt auch. Ein cat /dev/hidraw0 (ist das eintige hidraw-device) liefert beim drücken auf Fernbedienungen aber nichts...


    Auch leuchtet an dem usbasp die rote led dauerhaft, aber nichts flackert (hatte irgenwo gelesen die grüne led solle flackern?).


    Ich hab jetzt auch 3 TSOPs getestet, den beigelegten 1756, nen 34136 und nen 173x vom avboard (nach tauschen von GND und + am Stecker, avboard hat Belegung GND;+;n.c;IR, die V2 Platine nach anleitung ja +;GNG;n.c.;IR). Was kann ich noch testen? :wand

    Hallo


    irgenwie bin ich wohl zu blöd das Teil zum laufen zu bekommen. Hab unter yavdr das yavdr-addon-irmp installiert und ir_control findet das Teil auch:


    ir_control -V:

    Code
    ir_control 1.0.0 (20.05.2012)
     IRMP: 2.2.3


    Da kein HIDRAW* erzeugt wurde, hab ich die UDEV-Rule von hier irmplircd für USB IR Remote Receiver (based on irmp)
    eingefügt:

    Code
    "KERNEL=="hidraw*", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05df", RUN+="/bin/mkdir /var/run/lirc", RUN+="/usr/local/sbin/irmplircd /dev/%k", RUN+="/bin/ln -s /var/run/lirc/lircd /dev/lircd""


    HIDRAW0 wird nun auch erzeugt, aber weder cat /dev/hidraw0 zeigt nichts an. Zudem verschwindet das hidraw0 nach einiger Zeit wieder.


    lsusb zeigt das device an:


    Code
    Bus 003 Device 002: ID 16c0:27d9 VOTI


    bzw. lsusb -s 003:002 -v


    Das ganze ist gesteck auf nen Asus At5-ion-T Deluxe unter aktuellem yavdr (0.5a mit updates). Kann mir da jemand weiterhelfen?


    Beste Grüße

    Also mhddfs packt die Platten der Reihe nach voll. Also erst die erste, wenn voll dann die nächste etc. Normalerweise landen so die Daten einer Aufnahme immer auf der selben Platte, wenn genug Platz vorhanden ist. Funktioniert auch soweit gut (bei mir mit 4 Platten). Performance ist wohl schlechter, aber auch mit mehreren Aufnahmen parallel ist das immer noch mehr als ausreichend schnell. Einziher Haken. Wenn ich eine Aufnahmen lösche, kommt es zu kurzen Bildstörungen im VDR (die dann leider auch in der Aufnahmen sind). Ursache ist mir noch nicht ganz klar, hängt aber vielleicht mit dem MHDDFS und den USB-DVB-S2 zusammen, die ich verwende? Alternativ zu MHDDFS gäbe es auch noch UnionFS oder AUFS (advanced union FS), das man wohl vergleichbar zu MHDDFS einrichten kann. Es ist allerdings komplexer und kann auch mehr als MHDDFS. Aber da es wohl kernel-module gibt, soll die performance besser sein als bei MHDDFS. Habs noch nicht getestet. MHDDFS läuft wie gesagt...

    Nur so als weitere Option. Wie wäre es denn mit einen USB2 DVB-S2 Adapter? Braucht keinen Platz im Gehäuse, kann bspw. unterm Schrank hinterm/ unterm Schrank liegen und dann hast du noch ein paar mehr Optionen was das Mainboard angeht. Und mal wenn du mal hier im "Flohmarkt" schaust -> Gebraucht ist meist günstiger als neu wenns ums Geld sparen geht.

    Aha, beim Skin Rendering bring eine aktuellere Grafikkarte nichts?!?


    Also bei mir läuft auf dem ION2 auch gar keine VDR-Instanz, sondern nur das frontend (sprich Grafikausgabe über vdr-sxfe ). Der VDR selbst läuft auf der der VDR (backend, xineliboutput) selbst läuft auf dem Server.
    Die CPU im ION2 sollte also relativ wenig zu tun haben. Wobei ich den Elchi-Skin nutze, der ja auch recht genügsam sein soll. Eine potentere Grafikkarte bringt also keinen Vorteil?

    Hi,


    die GT630 (GK208) scheint ja ne recht gute Option für nen VDR-Ausgabedevice zu sein. Ich hab hier nen At5ionT mit nem Ion2-Chipesatz, mit dem der VDR auch ganz passabel läuft. Was wären denn die Vorteile der GT630. Das Board hat nen PCI-E x4-Slot. Laufen da überhaupt GT630 Grafikkarten. Und was Nachteile,höherer Strombedarf?, oder eventl. sogar ein niedrigerer.

    Hi,


    ja ein Update war gelaufen. Hatte wohl auch den EPG-Daemon geupdated (unbedarft wie ich war). Jetzt steht der auf Hold in der vorher funktionierenden Version.


    Nach einem "epdg-dropall" sowie "epg-tool del-db", "epg-tool del-u", "epg-tool new-db" und "epg-tool del-u" scheint der epgd nach neustart nach log auch sauber zu laufen macht sauber ein EPG-Update.



    Aber der VDR will (nach dem Restart) dennoch nicht mit epgd zusammen?

    Code
    Mar 20 08:18:00 vdr-server vdr: EPG2VDR: Statement 'insert into vdrs set uuid = ?, inssp = ?, updsp = ?, name = ?, version = ?, dbapi = ?, lastupd = ?, nextupd = ?, state = ?, master = ?, ip = ?;' with (11) in parameters and (0) out bindings prepared
    Mar 20 08:18:00 vdr-server vdr: EPG2VDR: Statement 'update vdrs set updsp = ?, name = ?, version = ?, dbapi = ?, lastupd = ?, nextupd = ?, state = ?, master = ?, ip = ? where uuid = ?;' with (10) in parameters and (0) out bindings prepared
    Mar 20 08:18:00 vdr-server vdr: EPG2VDR: Found dbapi 3, expected 4, please alter the tables first! Aborting now.


    Nix EPG :wand ... ?!?