Posts by wfaust

    Was das Thema Thin Client via DSL 16000 angeht: Der Uplink des DSL 16000 Anschlusses ist deutlich zu langsam um hier irgendwas Live auf dem Thinclient sehen zu können. Du könntest auf dem Server den Stream live neu encoden, doch die Bildqualität wäre dann wirklich sehr schlecht und der Aufwand sehr hoch und der Server müßte ordentlich CPU Power haben. Mit VDSL auf dem Server ist da durchaus einiges mehr machbar und ich benutze es hier. Ansonsten ist es aber nicht einfach, hier eine passende und vor allem zuverlässige Lösung zu finden. Wegen des langsamen Uplinks solltest Du nach einer Lösung suchen, bei der Du die Dateien vom Server auf den Client zum anschauen vorher kopierst.


    Auch ich nutze OpenVPN zur Anbindung des Clients. OpenVPN wiederum ruft beim Aufbau/Ende der VPN Verbindung ein Script zum Mounten/Unmounten des Serverlaufwerkes auf (das Unmounten ist nicht unproblematisch, inbesondere wenn ein Programm gerade auf das Laufwerk zugreift). SMB/CIFS über eine VPN Internetverbindung ist wegen der hohen Latenzen praktisch kaum nutzbar. Das dürfte sich mit SMB V2 Protokoll Support in Zukunft vielleicht ändern (ab Kernel 3.8?). Ich habe einige Alternativen ausprobiert (CurlFTP,...) aber es gab immer wieder Probleme mit der Zuverlässigkeit, Geschwindigkeit oder dem Unicode Support. Recht gut funktioniert hier sshfs zum Mounten des Server Laufwerks. Mit XBMC lassen sich über das sshfs Laufwerk Filme mit einer mittleren Datenrate anschauen, die ca. 80% des Uplinkspeeds ausmachen. Bei VDSL 50 immerhin Aufnahmen mit ca. 8 MBit. Noch etwas besser geht es, wenn Du mit XBMC via FTP direkt auf den Server zugreifst und in XBMC den Buffer für die FTP Verbindung hochsetzt. Dann kann man Aufnahmen mit einer mittleren Datenrate von ca. 95% des Uplinks ohne Ruckler abspielen. Das klappt hier mit DVB-T, den meisten IPTV und privaten Sat SD TV Aufnahmen.


    Reicht die Verbindungsgeschwindigkeit aber wie bei Dir nicht aus, wirst Du vorher die Sachen irgendwie runterladen müssen. Gerade bei mehreren TV Aufnahmen und einem langsamen DSL 16000 Uplink ein sehr langsamer Job. Gerade da die Downloads evtl. länger dauern, bietet sich hier Filezilla an (wie man das Teil unter yaVDR installiert: Fizezilla mit yaVDR 0.4/0.5 ), da Filezilla bei entsprechender Konfiguration auch durch eine Internet Zwangstrennung usw. nicht abbricht und notfalls tagelang ohne Störung läuft. Auch wäre ein Blick auf Tools wie rsync interessant, um den Client und Server automatisch beim Aufbau der VPN Verbindung zu synchronisieren. Man kann z.B. mit rsync automatisch alle Aufnahmen der letzten 10 Tagen immer auf dem Client runterladen lassen, so daß auf dem Client auch eine kleine Festplatte oder ein großer USB Stick reicht.


    Das Raspberry PI mit OpenElec ist sicherlich eine sehr günstige Alternative XBMC zum laufen zu bringen. Aber ob Du mit OpenElec obige Software ordentlich und schnell zum laufen bringst, ist eine andere Sache. Ich würde hier eher mal bei EBay Ausschau nach sowas wie einem Zotac ND22 halten. Kommt Dich ca. 100 Euro teurer, aber Du hast halt praktisch kaum Einschränkungen bei der Software und Geschwindigkeit. YaVDR 0.5 läuft auf dem ND22 hier sehr gut. Das dürften gut investierte 100 Euro sein...

    Morpheus1607 hat recht, die Antworten hier sind bislang wieder wenig hilfreich. Ich habe Filezilla auf meinem yaVDR 0.4 und 0.5 System installiert und mal nachgeschaut, was ich gemacht hatte. Vielleicht hilft Dir folgendes weiter:


    Zuerst werde root und dann installiere das normale Filezilla Paket:


    Code
    1. sudo su
    2. apt-get update
    3. apt-get install filezilla


    Jetzt erweitere die Sidebar updatesicher um einen Filezilla Eintrag:


    Code
    1. mkdir -p /etc/yavdr/templates_custom/etc/wmdrawer/web/
    2. echo "(Filezilla) (filezilla.png) (/usr/share/vdr/menuorg-appswitcher standalone=no app=filezilla)" >/etc/yavdr/templates_custom/etc/wmdrawer/web/11_filezilla
    3. chown root:root /etc/yavdr/templates_custom/etc/wmdrawer/web/*
    4. chmod 644 /etc/yavdr/templates_custom/etc/wmdrawer/web/*
    5. process-template /etc/wmdrawer/web


    Nun kannst Du im VDR Applikationsmenü einen Filezilla Menüpunkt hinzufügen, damit Du Filezilla direkt aus VDR per FB aufrufen kannst. Dazu
    gebe folgende Befehle ein:


    Code
    1. mkdir -p /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml
    2. touch /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml/20_11_filezilla
    3. chown root:root /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml/*
    4. chmod 644 /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml/*


    Editiere die Datei /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml/20_11_filezilla und füge folgende Zeile ein:

    Code
    1. <command name=<?cs call:quote(_("Filezilla")) ?> execute="/usr/share/vdr/menuorg-appswitcher standalone=no app=filezilla &amp;> /dev/null " />


    und rufe dann folgende Befehle auf:

    Code
    1. stop vdr
    2. process-template /var/lib/vdr/plugins/menuorg.xml
    3. start vdr


    Jetzt braucht es nur noch den von VDR und Sidebar aufgerufenen Upstart Dienst. Dazu erstelle eine Datei /etc/init/filezilla.conf mit folgendem Inhalt:


    Das wars. Jetzt solltest Du über die Sidebar oder VDR Filezilla aufrufen können. Falls Du mit Filezilla länger Dateien transferierst und nicht willst, dass dabei YaVDR ausschaltet, mußt Du die Lifeguard Konfiguration entsprechend erweitern:

    Code
    1. mkdir -p /etc/yavdr/templates_custom/etc/vdr/lifeguard.conf/
    2. touch /etc/yavdr/templates_custom/etc/vdr/lifeguard.conf/061_filezilla
    3. chown root:root /etc/yavdr/templates_custom/etc/vdr/lifeguard.conf/*
    4. chmod 644 /etc/yavdr/templates_custom/etc/vdr/lifeguard.conf/*


    und füge folgenden Inhalt in die Datei /etc/yavdr/templates_custom/etc/vdr/lifeguard.conf/061_filezilla ein:

    Code
    1. <?cs if:(vdr.plugin.lifeguard.enable != "false") ?>
    2. cmd filezilla <?cs var:_("Filezilla\ is\ still\ running.") ?>
    3. <?cs /if ?>


    Dann rufe

    Code
    1. process-template /etc/vdr/lifeguard.conf

    auf. Jetzt sollte yaVDR nicht mehr ausschalten, solange Filezilla läuft. Wenn Du längere Transfers in Filezilla startest, stelle einfach ein, daß nach den Transfers Fizezilla beendet wird und dann schaltet auch yaVDR ab. Läuft hier zuverlässig seit einem Jahr.

    Meine Erfahrung mit yaVDR und drei M4N78 Pro Boards:


    Es stimmt, USB ist praktisch kaum brauchbar bei diesen Boards. Bei allen getesteten BIOS Versionen und Boards war wichtig, im BIOS Setup USB NICHT auf Highspeed zu stellen, da dann evtl. der Rechner schon beim Booten im BIOS sich aufhängt und der Bildschirm schwarz bleibt. Nur durch das des Setzen des RTC CLear Jumpers kann dann das Board wiederbelebt werden. Das Abschalten des HighSpeeds ist in der Praxis nicht weiter schlimm, da es nur während des Bootens eine kurze Rolle spielt und der linux usb Treiber später dann doch Highspeed verwendet.


    Bei zwei Boards habe ich bei YaVDR 0.4 oft (nicht immer) endlose USB Fehlermeldungen im syslog und der angeschlossene Nova TD DVB-T USB Empfänger funktioniert manchmal nicht. Das dritte und neuste Board stammt aus einem Asus Reparturtausch und zeigt keinerlei Fehlermeldungen im syslog (identisches BIOS) und auch der Nova Stick funktioniert bislang fehlerfrei. Evtl. hat hier ASUS irgendwas am Board geändert?


    Scheinbar in Abhängigkeit der Resourcen des Systems, scheint USB mal zu gehen... dann wieder nicht. Insofern gut möglich, dass es unter yaVDR 0.4 ging... nun aber nicht mehr. Auch gut möglich, dass wenn Du mal mit den BIOS Setting oder den Steckkarten spielst, es plötzlich wieder geht. Aber wie Paulaner schon geschrieben hat, ein kranker Chipsatz und wohl ein krankes BIOS. Ich schliesse mich daher Paulaner an und empfehle den Kauf einer Steckkarte.

    Bei mir hängt sich seit yaVDR 0.5 ca. 1-2 mal am Tag mein Onky 875 Verstärker auf. YaVDR 0.5 liefert irgendwelche hässlichen Daten und dann gibt es keinen Ton mehr (Bild ist ok). Ich schätze, bei einem anderen Ausgabegerät können die Symptome anders sein und vielleicht gibt es da einen Zusammenhang. Das Problem kann sowohl von VDR als auch XBMC verursacht werden. Programmmwechsel in VDR, Video starten in XBMC oder auch der Wechsel von XBMC nach VDR reicht und der Verstärker wird dauerhaft stumm. Ob Xine oder softhddeivce ist egal. Erst das Aus-/Einschalen des Verstärkers bringt bei mir den Ton wieder. Der Wechsel auf einen älteren 295 NVidia Treiber hat bislang nicht geholfen.

    Vorsicht, hast Du auch geschaut ob smbstatus wirklich eine bestehende SMB Verbindung anzeigt? Wenn ich mich richtig erinnere, lag das Problem nicht darin, ob man smbstatus als vdr User aufrufen kann, sondern ob smbstatus auch dann die bestehende Verbindung erkennt. Scheinbar braucht dazu smstatus entsprechende Rechte. Wie gesagt, hatte den Kram mit den Rechten damals auch nicht so recht verstanden und habe dank funktionierender Lösung nicht weiter gesucht.


    Dann bleibt da noch das Them $TYPE vs $PATTERN. yaVDR gibt normal "locks" an. Wenn $TYPE wie vermutet inkorrekt ist, dann wird der entsprechende Check auch nicht ausgeführt.

    Utiltiy:


    Ich bin auf des SMB-Problem mit Lifeguard erst sehr spät gestossen und die Diskussionen/Lösungen war nicht nur hier im Forum beendet/fertig, zumal ich auch so recht nicht verstanden habe, wieso smbstatus nicht die nötigen Zugriffsrechte hatte. Insofern war das Problem bekannt. Ob es nun auch im Bugtracker gemeldet wurde, weiss ich nicht. Mein Eindruck war aber aus einem Posting, dass es einem der Programmierer des Lifeguard Scripts bekannt war, ihm aber wohl die Zeit fehlte.


    Worum es ging:
    In /usr/share/vdr/shutdown-hooks/S91.lifeguard hatte smbstatus nicht die nötigen Rechte um eine existiernde SMB Verbindung zu erkennen. Damit kann Lifeguard nicht funktionieren. Auch wurde
    bei der case Anweisung am Anfang des smb Abschnitts $TYPE anstatt $PATTERN verwendet.


    Die schnelle und wegen sudoers wohl unschöne Lösung lag darin, $TYPE in $PATTERN zu ändern und sudo vor die smbstatus Aufrufe zu setzen:



    und dann in /etc/sudoers folgende Zeile hinzuzufügen:

    Code
    1. vdr ALL=(ALL) NOPASSWD: /usr/bin/smbstatus *


    Das hatte zumindest hier mit yaVDR 0.4 funktioniert (naja, mit den bekannten Problem, dass nicht immer ein PC die Verbindung korrekt beendet und es dann lange dauert, bis yaVDR ausschaltet). Ich habe es mir nicht genau angeschaut, ob yaVDR 0.5 das gleiche Problem hat und ob nicht z.B. der Aufruf des Scripts geändert wurde. Vielleicht hat jemand anderes Zeit sich das anzuschauen?

    Löwe:


    Das mit dem Lifeguard hat schon bei yaVDR 0.4 so einen Fehler gehabt, der obwohl hier im Forum hinreichend bekannt nie beseitigt wurde. Scheint so, als ob es bei yaVDR 0.5 eher mehr Probleme gibt:


    Bei yaVDR 0.5 ist u.a. die Anzeige im WebConfig falsch. So wird bei mir trotz eingeschalteter XBMC/Samba Option nach dem Speichern/Refresh im Browser die Option als ausgeschaltet angezeigt, obwohl Sie durchaus in lifeguard.conf wie bei Dir eingeschaltet ist. Offensichtlich werden in der WebConfig die vorhandenen Einstellungen nicht korrekt geladen/angezeigt. Als schnellen Fix, entferne einfach die ungewollten Optionen aus der lifeguard.conf manuell.


    Funktioniert eingentlich inzwischen die Samba Einstellung in Lifeguard? Bei yaVDR 0.4 funktioniert die nicht, weil das Script beim Aufruf von smbstatus keine korrekten Rechte hat und daher einen Zugriff via SMB garnicht mitbekommen kann und abschaltet. Man musste erst das lifeguard Script/sudoers leicht verändern, demit es ging. Soweit ich es sehe, ist das damals fehlerhafte Script noch immer in yaVDR 0.5 unverändert vorhanden. Evtl. hat man ja woanders (sudoers) das Problem mit den Rechten behoben. Ich habe einfach die aus 0.4 bekannten Fixes eingespielt.

    Vielleicht hilft ein altes Tutorial zur WLan Installation unter yaVDR:


    http://www.vdr-portal.de/board60-linux/board14-betriebssystem/board96-yavdr/111254-tutorial-wlan-mit-wpa-gui-inkl-sidebar-vdr-applikationsmenü-installieren/


    Die Installationsbeschreibung funktioniert identisch mit yaVDR 0.4 und 0.5. Danach habt Ihr dann eine einfache GUI zum finden/verbinden von WLAN APs. Ich habe so schon mehrere ZBox Rechner zuverlässig zum laufen gebracht (ich wünschte, die normale Ethernet-Schnittstelle in der ZBox wäre ähnlich zuverlässig, sorgt aber immer wieder für Verbindungsabbrüche in gewissen Situationen).

    Gerald: Wo gibt es denn einen kaufbaren USB Empfänger der mit S5 funktioniert ohne dass ich jetzt auch noch basteln oder irgendwelche Treiber installieren muss, die beim nächsten yaVDR wieder nicht mehr gehen? Angesichts der noch schweren Verfügbarkeit und der vielen noch vorhanden ausser mit yaVDR 0.4 funktionierenden LIRC Installationen ist die Aussage nur schwer verständlich. Von damit entstehenden Kosten für Empfänger und auch Fernbedienungen (falls RC5 nicht mehr geht) mal ganz abgesehen.


    Keine_Ahnung: Ok, ich habe wie von Dir empfohlen /etc/udev/rules.d/71-myatric.rules mit
    DRIVERS=="lirc_serial", ACTION=="add", SYMLINK+="fernbedienung"
    erstellt und das Device in /etc/lirc/hardware.conf entsprechend auf /dev/fernbedienung geändert. Klappt auch hier. Evtl. dürfte es Probleme geben, wenn mehr als ein serieller Port verwendet wird, aber das ist hier nicht der Fall. Definitiv die bessere Lösung für serielle Fernbedienungen als rmmod in /etc/init/lircd.conf einzutragen. DANKE :]


    seahawk1986: Das editieren von hardware.conf klappt hier leider nicht, da sich das Device bei ca. jedem zweiten Reboot ändert. Obige udev Regel löst das Problem. Zu Deiner Frage was passiert wenn ich das device entferne: Ich habe mir mal lsmod vor/nach dem rmmod aufgerufen:

    Auch ich habe hier das Problem auf unterschiedlichen Rechner mit Nividia Chipsätzen (nicht nur ION2) und mehrere Tage erfolglos nach einer Lösung gesucht. Manchmal passiert das beschriebene Problem beim Starten eines Filmes in XBMC. Im Log tauchen dann meistens Probleme mit buffer underrun von Alsa oder create context Probleme von PulseAudio auf. Inbesondere das letzte VDR 1.7.22 Update von yaVDR 0.4 hat merkwürdigerweise das Problem in XBMC stark erhöht.


    Laut diversen Postings kann man das Problem wohl durch Beschränken des Audio-Ausgangs auf HDMI Stereo oder Passthrough reduziert werden. Zumindest auf den hier getesteten Rechnern hat dies nicht viel geholfen.
    Ich habe auch Alsa und Pulseaudio aus anderen Quellen upgedated und diverse XBMC Eden Paketquellen probiert. Letztlich konnte ich nur eine spürbare Verbesserung durch Installation des neuesten NVidia Treibers erreichen, wobei das Problem auch dann nicht vollständig behoben ist (es tritt bei mir dann nur noch ca. alle 30 anstatt 6 Filmstarts auf).


    Zum ausprobieren, hier die von mir fürs nvidia Update genutzten Befehle/Pakete (backup vorher machen!):


    Code
    1. sudo su
    2. add-apt-repository ppa:ubuntu-x-swat/x-updates
    3. apt-get update
    4. apt-get dist-upgrade
    5. reboot

    Ich vermute auch steffen_b hat recht und es wird ein weiterer IR Empfänger gefunden und zuerst als /dev/lirc0 geladen. Ich würde mal mit grep lirc /var/log/syslog nachschauen, welches modul für minor 0 (ie. /dev/lirc0) geladen wird. Dieses würde ich dann versuchen irgendwie loszuwerden. Blacklisten hat zumindest bei mir leider nicht funktioniert und ich habe den nötigen rmmod Befehl in /etc/init/lircd.conf hinzugefügt (Siehe auch lirc-device-reihenfolge-beim-booten). Problematisch dürfte es vor allem werden, wenn das gleiche Modul mehrere Empfänger unterstützt und nur ein Empfänger davon korrekt ist.


    An seahawk1986 : Ich weiss, Du bist ein Guru was eventlircd angeht, doch ich konnte in keinen Thread/Dokus eine saubere Lösung für obiges Problem finden. Wo bitte genau meinst Du ist eine saubere Lösung schon beschrieben worden?

    Ich habe mir derzeit damit geholfen, das bei mir störende ir_lirc_codec Modul in /etc/init/lircd.conf mit rmmod zu entladen bevor die in hardware.conf angegebenen Module geladen werden. Mit rmmod ir_lirc_codec verschwinden bei mir /dev/lirc0-2 der IR Empfänger der Sat-Karten. Ein zusätzlicher sleep Befehl war nötig, weil manchmal der serielle Port trotz setserial Aufruf belegt war. Jetzt sieht der load_modules Aufruf in /etc/init/lircd.conf also so aus:


    Code
    1. if [ "$LOAD_MODULES" = "true" ]; then
    2. sleep 4
    3. /sbin/rmmod ir_lirc_codec
    4. load_modules $REMOTE_MODULES
    5. fi


    Nur schön oder updatesicher ist diese vorgehensweise sicher nicht, weshalb ich hier (bislang erfolglos) gefragt habe. Auch im Internet konnte ich nur Fragen aber keine sauber funktionierende Lösung finden.

    Ich habe eine lirc (Atric) IR Empfänger am seriellen Port. Zusätzlich findet das System aber auch 3 ungenutzte IR Empfänger von Nova S2 DVB Karten.
    Das Problem ist, daß die Reihenfolge der gefundenen Geräte sich beim Booten manchmal ändern kann und dann der Atrix IR Empfänger nicht unter
    /dev/lirc3 sondern /dev/lirc0 zu finden ist.


    Daher die Frage, wie kann ich sicherstellen, daß der Atric Empfänger zuerst gefunden wird und damit /dev/lirc0 wird? Oder wie kann ich
    sicherstellen, dass in /etc/lirc/hardware.conf immer das richtige Atric /dev/lirc Device steht? Ich hatte schon versucht, ir-lirc-codec zu blacklisten damit die
    Nova IR Empfänger nicht geladen werden: ohne Erfolg. Kann ich evtl. bei udev verhindern, dass /dev/lircx für die Nova erstellt wird?


    Hier mal eine grep lirc /var/log/syslog Ausgabe:


    Code
    1. 01:35:38 zotac kernel: [ 12.033769] lirc_dev: IR Remote Control driver registered, major 249
    2. Apr 16 01:35:38 zotac kernel: [ 12.597418] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 0
    3. Apr 16 01:35:39 zotac kernel: [ 13.025524] rc rc1: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 1
    4. Apr 16 01:35:39 zotac kernel: [ 13.258527] rc rc2: lirc_dev: driver ir-lirc-codec (cx88xx) registered at minor = 2
    5. Apr 16 01:35:42 zotac kernel: [ 16.818010] lirc_serial: module is from the staging directory, the quality is unknown, you have been warned.
    6. Apr 16 01:35:43 zotac kernel: [ 17.770035] lirc_serial: auto-detected active low receiver
    7. Apr 16 01:35:43 zotac kernel: [ 17.770120] lirc_serial lirc_serial.0: lirc_dev: driver lirc_serial registered at minor = 3

    Kurze Info: Ich habe auf das offizielle unstable XBMC Repository ohne PVR gewechselt (add-apt-repository ppa:team-xbmc/unstable). Diese XBMC Version scheint hier zumindestens
    ohne den schwarzen Bildschirmhänger beim Beenden zu funktionieren. Allerdings fehlt dann z.B. die ION2 Optimierungen der Alexandr Surkov Pakete. Zumindest bislang auf meinem Zotac ND 22 ION2 kein
    merkenswerter Nachteil.

    Inzwischen gab es ja ein Update der alexandr-surkov-xbmc-pvr-natty Pakete. Leider beendet sich auch weiterhin XBMC nicht richtig und
    der Bildschirm bleibt jedes mal schwarz, wenn ich zum VDR Frontend zurückkehren will. Ein Killen des xbmc Prozesses via lircrc oder so
    kommt nicht in Frage, da z.B. so der Rechner nicht von alleine runterfährt. Für mich ist das Problem ein echter Show-Stopper....


    Hat irgendjemand inzwischen eine Lösung für das Problem? Eine Ahnung woran das Problem überhaupt liegt???

    Um einfach per FB das AutoCrop ein- bzw. auszuschalten konnte man bei xineliboutput einfach in /etc/vdr/keymacros.conf z.B. die Grüne Taste mit "Green @xineliboutput Red 4" umbelegen.
    Bei xine scheint es sowas nicht mehr zu geben? Ich kann nur sagen, wie ich es jetzt gelöst habe und hoffe, jemand anderes hat eine einfachere/bessere Lösung:


    • Zuerst mit "sudo su" root user werden.
    • Sicherstellen dass die normale yaVDR Einstellung USE_AUTOCROP=0 in /etc/init/vdr-frontend eingestellt ist.
    • Die Upstart Datei /etc/init/xineautocropswitch.conf mit folgendem Inhalt erstellen:

    • Jetzt muss das VDR System/Befehle Menü um den Eintrag "Xine AutoCrop Switch" updatesicher erweitert werden. Dazu mit

      Code
      1. mkdir -p /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml
      2. nano /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml/86_11_xineautocropswitch


      eine Datei mit der folgenden Zeile erstellen:

      Code
      1. <command name="Xine AutoCrop Switch" execute="/usr/share/vdr/menuorg-appswitcher standalone=no app=xineautocropswitch &amp;> /dev/null " />


      und die Zugriffsrechte einstellen mit:

      Code
      1. chown root:root /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml/*
      2. chmod 644 /etc/yavdr/templates_custom/var/lib/vdr/plugins/menuorg.xml/*

      und aktivieren:

      Code
      1. stop vdr
      2. process-template /var/lib/vdr/plugins/menuorg.xml
      3. start vdr
    • Jetzt sollte das System/Befehle Menü den Eintrag "Xine AutoCrop Switch" aufweisen und funktionieren. Wer wie ich einfach per Grüner Taste beim TV-Schauen Autocrop ein-/ausschalten will, der kann in /etc/vdr/keymacros.conf den Eintrag für z.B. Green ändern und den neu erstellten Menüeintrag aufrufen (evtl. kontrollieren ob der Eintrag wirklich 7 1 6 bei Euch ist):
      Code
      1. Green Menu 7 1 6

    Was fehlt?


    Eigentlich wäre es schöner, wenn das Skript die aktuelle Einstellung von USE_AUTOCROP vorher liest und dann eine neue .override Datei erstellt. Kennt jemand eine elegante Methode (bin kein Linux Script Kiddy ;-)
    Desweiteren frage ich mich, wie ich eine Nachricht auf VDR mittig zentriert ausgebe und wie ich die Anzeigedauer steuer kann.
    Eine Lösung ohne langwierigen Neustart des Frontends wäre schön. Ingesamt erscheint mir das ganze doch im Vergleich zu xinelibout sehr umständlich, aber vielleicht habe ich trotz Suche noch nicht die richtige Anleitung gefunden?

    Dr. n00b, da muss ich doch leider noch einmal Nachfragen: Wenn ich das richtig verstanden habe, wird doch mit untie-packages die Abhängigkeiten zwischen yaVDR Paketen aufgehoben. Mit Deiner Anleitung werden die doch nicht wieder hergestellt? Daher die Frage, was muss ich nach dem ändern der source.list wieder installieren, damit wieder alles "normal" ist? yavdr-essential? Und wie sieht es dabei mit den vorhanden Settings/database aus? VDR Settings behalten und xbmc database löschen?

    Die Frage ist, wie kommt man wieder zurück, wenn es bei yaVDR irgendwann vielleicht eine bessere XBMC Version gibt? Wie sieht es mit VDR Updates nach einem untie-packages aus?
    Kann man einfach auf die alten apt sources zurück und tut dann yavdr essential und/oder xbmc de- und dann wieder neuinstallieren?