Beiträge von sprut

  • ACPI-Fehler bei Shutdown

    OK
    ich habe jetzt wieder die Files genommen, die beim burn-plugin-installieren eingespielt wurden, aber die Rechte verändert. Bei /usr/lib/vdr/vdr-shutdown.wrapper habe ich die Gruppenzugehörigkeit auf vdr gesetzt und die Bits zum Setzen der Nutzer-ID und Gruppen-ID beim Ausführen gesetzt. Genauso waren die Rechte auch für die originale Datei gewesen. Nun lässt sich der VDR per Fernbedienung abschalten.


    Nach wie vor klappt aber das Abschalten nach einer Autotimeraufnahme nicht. Offensichtlich gibt es da einen Unterschied. Das Abschalten nach einer Autotimeraufnahmne wird offensichtlich durch /usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper ausgelöst.
    Auch dieses File wurde bei der burn-plugin-Installation erneuert. Die Gruppenzugehörigkeit war hier immer schon root, aber es fehlen der neuen Version die beiden Bits zum Setzen der Nutzer-ID und Gruppen-ID beim Ausführen
    Diese habe ich jetzt manuell gesetzt. Und nun schaltet er sich auch wieder von allein ab.


    Bleibt zu klären, warum bei den neu eingespielten Files die beiden Bits nicht gesetzt sind !

  • ACPI-Fehler bei Shutdown

    Tschuldigung für die späte Antwort, aber ich bin in der Woche auf Dienstreise, und muss meiner besseren Hälfte dann einen lauffähigen VDR da lassen. Nichts geht über einen hohen WAF.


    Vor der Burn-Installation hatte ich keine zusätzlichen Pakete installiert. Als einzige zusätzliche Software habe ich mir den midnight commander installiert, aber das war vor der burn-installation, und danach lief auch alles eine Woche lang.
    Es sind per default aktiv:

    • vdr-plugin-dbus2vdr
    • vdr-plugin-dynamite
    • vdr-skin-anthra-1920-fse
    • vdr-tft-anthraize
    • vdr-tft-pearlhd
    • vdr-tft-standard

    Dazu kam nun auch vdr-plugin-burn.


    Das mplayer-plugin ist noch nicht installiert. Beim Versuch der mplayer-Installation hatte ich mir ja die letzte Installation "zerschossen", deshalb warte ich damit, bis das Problem lokalisiert ist.


    Es hat sich durch die burn-installation nicht nur die Gruppenzugehörigkeit geändert. Die Files haben andere Datums und der vdr-shutdown-wrapper hat auch eine andere Größe. Da muss doch irgentwie eine andere Version eingespielt worden sein.


    Hier mal das log der burn-plugin installation. Da passiert eine ganze Menge:


    Code
    Start-Date: 2014-11-14  14:00:23
Commandline: apt-get -y install vdr-plugin-burn
Install: libmjpegtools-1.9:amd64 (1.9.0-0.5ubuntu7, automatic), vdr-tftng-standard:amd64 (0.0.7-2yavdr5~precise, automatic), sharutils:amd64 (4.11-1, automatic), liboro-java:amd64 (2.0.8a-8, automatic), ttf-dejavu-extra:amd64 (2.33-2ubuntu1, automatic), genisoimage:amd64 (1.1.11-2ubuntu2, automatic), libtntnet12:amd64 (2.2.1-0yavdr0~precise, automatic), libquicktime2:amd64 (1.2.3-4build2, automatic), bc:amd64 (1.06.95-2ubuntu1, automatic), java-common:amd64 (0.43ubuntu2, automatic), default-jre-headless:amd64 (1.6-43ubuntu2, automatic), project-x:amd64 (0.91.0-0yavdr0~precise, automatic), openjdk-6-jre-lib:amd64 (6b33-1.13.5-1ubuntu0.12.04, automatic), libatk-wrapper-java:amd64 (0.30.4-0ubuntu2, automatic), dvdauthor:amd64 (0.7.0-1.1build1, automatic), openjdk-6-jre-headless:amd64 (6b33-1.13.5-1ubuntu0.12.04, automatic), libmp3lame0:amd64 (3.99.3+repack1-1, automatic), default-jre:amd64 (1.6-43ubuntu2, automatic), libcommons-net-java:amd64 (1.4.1-5, automatic), vdr-plugin-graphtftng:amd64 (0.4.10+git20140301-0yavdr5~precise, automatic), tzdata-java:amd64 (2014i-0ubuntu0.12.04, automatic), libatk-wrapper-java-jni:amd64 (0.30.4-0ubuntu2, automatic), libgraphicsmagick++3:amd64 (1.3.12-1.1build1, automatic), gawk:amd64 (3.1.8+dfsg-0.1ubuntu1, automatic), growisofs:amd64 (7.1-10, automatic), transcode:amd64 (1.1.5-0ubuntu10, automatic), libdv4:amd64 (1.0.0-3ubuntu1, automatic), ttf-dejavu:amd64 (2.33-2ubuntu1, automatic), libsigsegv2:amd64 (2.9-4ubuntu2, automatic), mjpegtools:amd64 (1.9.0-0.5ubuntu7, automatic), libcxxtools9:amd64 (2.2.1-1yavdr0~precise, automatic), ca-certificates-java:amd64 (20110912ubuntu6, automatic), imagemagick:amd64 (6.6.9.7-5ubuntu3.3, automatic), dvd+rw-tools:amd64 (7.1-10, automatic), libcommons-net1-java:amd64 (1.4.1-5, automatic), vdr-plugin-burn:amd64 (0.2.2-6yavdr4~precise), vdr-genindex:amd64 (0.1.3-1ubuntu1, automatic), openjdk-6-jre:amd64 (6b33-1.13.5-1ubuntu0.12.04, automatic), libnss3-1d:amd64 (3.17.1-0ubuntu0.12.04.1, automatic), libgd2-noxpm:amd64 (2.0.36~rc1~dfsg-6ubuntu2, automatic)
Upgrade: vdr-plugin-dummydevice:amd64 (1.0.3-0yavdr13~precise, 1.0.3-0yavdr26~precise), vdr-plugin-xine:amd64 (0.9.4-8yavdr2~precise, 0.9.4-13yavdr8~precise), vdr-plugin-skinpearlhd:amd64 (0.0.1+git20120905-4yavdr0~precise, 0.0.1+git20120905-5yavdr14~precise), vdr-plugin-restfulapi:amd64 (20130306232035stable-0yavdr0~precise, 20140820184027stable-0yavdr0~precise), vdr-plugin-xvdr:amd64 (0.9.5.git20120414-0yavdr2~precise, 0.9.9.git+20140521-1yavdr1~precise), vdr-plugin-dbus2vdr:amd64 (20130306232004stable-0yavdr0~precise, 20140725085917stable-0yavdr0~precise), vdr-plugin-iptv:amd64 (0.5.2-0yavdr7~precise, 2.0.3-0yavdr4~precise), vdr-plugin-epgsearch:amd64 (1.0.1.beta1~git20121031-2yavdr0~precise, 1.0.1.beta5~git20130911-3yavdr4~precise), vdr-plugin-dynamite:amd64 (20130306232020stable-0yavdr0~precise, 20140725091235stable-0yavdr0~precise), vdr-plugin-softhddevice:amd64 (0.5.2.git.20130303.1729-0yavdr1~precise, 0.6.1rc1.git20140218-0yavdr4~precise), vdr-plugin-live:amd64 (0.2.0.99+git20120326-2yavdr0~precise, 0.3.0+git20130915-6yavdr2~precise), graphtft-fe:amd64 (0.3.6-3yavdr0~precise, 0.4.10+git20140301-0yavdr5~precise), vdr-plugin-channellists:amd64 (0.0.4-26yavdr7~precise, 0.0.5-1yavdr4~precise), vdr-plugin-xineliboutput:amd64 (1.0.7+cvs20120830-5yavdr2~precise, 1.1.0-22-g1d98107-1yavdr4~precise), vdr-plugin-pvr350:amd64 (1.7.4-0yavdr7~precise, 1.7.5-1yavdr4~precise), vdr-plugin-wirbelscan:amd64 (0.0.7-3yavdr9~precise, 0.0.7-3yavdr22~precise), vdr-plugin-markad:amd64 (0.1.4.git20130102-0yavdr0~precise, 0.1.4.git20140218-0yavdr4~precise), vdr-plugin-streamdev-server:amd64 (0.6.0.git20121102-0yavdr6~precise, 0.6.1.git20140518-0yavdr1~precise), vdr:amd64 (1.7.27-8yavdr0~precise, 2.0.6-6yavdr1), vdr-plugin-menuorg:amd64 (0.4.5-2yavdr1~precise, 0.5.1-9yavdr1~precise), vdr-plugin-text2skin:amd64 (1.3.2+git20120530-4yavdr9~precise, 1.3.2+git20130504-2yavdr0~precise), vdr-plugin-femon:amd64 (1.7.17-0yavdr7~precise, 2.0.0-1yavdr4~precise), vdr-plugin-graphtft:amd64 (0.3.6-3yavdr0~precise, 0.4.10+git20140301-0yavdr5~precise), vdr-plugin-extrecmenu:amd64 (1.2.2.git20120627-1yavdr4~precise, 1.2.4-git20140820-0yavdr0~precise), vdr-plugin-dvbhddevice:amd64 (1.7.27-8yavdr0~precise, 2.0.6-6yavdr1), vdr-plugin-dvbsddevice:amd64 (1.7.27-8yavdr0~precise, 2.0.6-6yavdr1)
Error: Sub-process /usr/bin/dpkg returned an error code (1)
End-Date: 2014-11-14  14:01:37



    Nun noch was Merkwürdiges.
    Als ich mich jetzt in den VDR einlogte, lief der bereits (noch), worüber ich erst mal nicht nachdachte - vielleicht lief ja gerade ein Timer. Während ich diese Daten aus dem VDR kopierte wart ich einen Blick in das Syslog, und musste folgendes sehen:


    Code
    Nov 22 13:48:57 hdvdr vdr: [9493] dbus2vdr: calling shutdown-hook-wrapper /usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper /usr/share/vdr/shutdown-hooks "1416683400 22863 2 \"Bella Block~Bella Block\" 0"
Nov 22 13:48:57 hdvdr shutdown-wrapper: [9495] dbus2vdr-shutdown-wrapper: asking shutdown-hook /bin/sh /usr/share/vdr/shutdown-hooks/S90.acpiwakeup
Nov 22 13:48:57 hdvdr vdr-addon-acpiwakeup: Setting ACPI alarm time to: 2014-11-22 19:05:00
Nov 22 13:48:57 hdvdr vdr-addon-acpiwakeup: No writeable /proc/acpi/alarm or /sys/class/rtc/rtc0/wakealarm found. ACPI needed!!!
Nov 22 13:48:57 hdvdr shutdown-wrapper: [9495] dbus2vdr-shutdown-wrapper: result(1) = ABORT_MESSAGE="ACPI not installed, shutdown aborted!"
Nov 22 13:48:57 hdvdr vdr: [9493] dbus2vdr: result(224) = ABORT_MESSAGE="ACPI not installed, shutdown aborted!"
Nov 22 13:48:57 hdvdr vdr-frontend[1438]: vdr not ready for shutdown: 992:


    Das ist erst mal fast der gleiche Fehler, obwohl der alte Wrapper im Einsatz ist.


    Hintergrundinfo:
    Der VDR hatte sich gestern manuell (power taste an der lirc-Fernbedienug) abschalten lassen. Er war nachts für eine Autotimer-Aufnahme aufgewacht, und kann sich nun nicht selbst abschalten. Ich habe den angeschlossenen TV eingeschaltet, das Frontend war detouched - soweit normal. Ein Druck nauf OK (Fernbedienung) und das Frontend wurde aktiv (normal). Ein Druck auf die power-Taste der Fernbedienung , und der VDR schaltet sich völlig normal aus.
    Es macht also einen Unterschied, ob sich der VDR selbst nach einer Timeraufnahme ausschalten will (geht nicht) oder ob man das per Fernbedienungskommando macht (geht).


    Kann sich darauf jemand einen Reim machen ?

  • ACPI-Fehler bei Shutdown

    Ich muss wohl das copypasten noch etwas üben, tschuldigung.


    Hier nun die Files in /usr/lib/vdr nach der Installation vom ISO ohne zusätzliche Plugins:



    Und das sind die Files nach dem das Burn-Plugin eingespielt wurde:



    Nach meinen Erfahrungen von voriger Woche ist das aber nicht Burn-Spezifisch. Damals hatte ich versucht, in meine vorige (lange nicht up-gedatete) yavdr 0,5 -Installation das mplayer-plugin zu installieren. Dann trat das Problem zum ersten mal auf.
    Wahrscheinlich wird bei diversen Plugin-Installationen der vdr-shutdown.wrapper aktualisiert. Der scheint das Problem zu verursachen.

  • ACPI-Fehler bei Shutdown

    Ich habe es noch mal auf ein File eingegrenzt, das das Verhalten verursacht. Es ist, wie erwartet, /usr/lib/vdr/vdr-sgutdown.wrapper.
    Alle anderen Files dieses Verzeichnisses habe ich wieder mit den Versionen ersetzt, die im Rahmen der Burn-Plugin-Installation eingespielt wurden. Die haben keine negativen Auswirkungen.


    Kopiere ich in das Verzeichnis die vdr-shutdown.wrapper Verion, die nach der Installation vom Iso dort vorhanden war, dann fährt der VDR korrekt herunter.
    Kopiere ich dorthin aber die Version, die bei der Burn-Plugin-Installation eingespielt wurde, dann gibt es den oben beschriebenen ACPI-Fehler.


    Das Verhalten ist voll reproduzierbar.


    Die problematische Datei ist:


    -rwsr-s--- 1 root vdr 6088 Mär 11 2013 vdr-shutdown.wrapper

  • ACPI-Fehler bei Shutdown

    In ein länger nicht "geupdatetes" yavdr 0.5-system installierte ich ein Plugin, daraufhin ließ es sich nicht mehr abschalten, da angeblich ACPI fehlte. Da ich den Fehler nicht fand, machte ich mit einer frischen Insatallation weiter.



    1. Installation mit yavdr64 0.5.0a.hybrid
    2. kopiere aus der alten Yavdr 0.5 Installation nur die Kanalliste und die Konfiguration der Fernbedienung (LIRC).
    3. keine weiteren Plugins!


    Das System läuft eine Woche problemlos.


    4. ich mache ein Backup der Systemdateien auf eine USB-Platte


    5. Ich installiere das Burn-Plugin, das eine ganze Reihe von Paketen nachzieht.


    Beim Ausschalten per Fernbedienung kommt nun eine Meldung, das ACPI fehlt, der VDR schaltet nicht ab.
    In syslog findet sich:

    Code
    Nov 14 14:24:00 hdvdr vdr: [1080] executing '/usr/lib/vdr/vdr-shutdown.wrapper 1416000480 29040 2 "heute-show~heute-show" 0'
Nov 14 14:24:00 hdvdr vdr-shutdown: executing /usr/share/vdr/shutdown-hooks/S90.acpiwakeup as shell script
Nov 14 14:24:00 hdvdr vdr: [1080] saved setup to /var/lib/vdr/setup.conf Nov 14 14:24:00 hdvdr vdr-addon-acpiwakeup: Setting ACPI alarm time to: 2014-11-14 21:23:00
Nov 14 14:24:00 hdvdr vdr-addon-acpiwakeup: No writeable /proc/acpi/alarm or /sys/class/rtc/rtc0/wakealarm found. ACPI needed!!!
Nov 14 14:24:00 hdvdr vdr-shutdown: Shutdown aborted by /usr/share/vdr/shutdown-hooks/S90.acpiwakeup with exitcode 1


    Offensichtlich schlug der Schreibzugriff von /usr/share/vdr/shutdown-hooks/S90.acpiwakeup auf /sys/class/rtc/rtc0/wakealarm wegen fehlender root-Rechte fehl.


    Code
    root@hdvdr:/var/log# ll /sys/class/rtc/rtc0/wakealarm
-rw-r--r-- 1 root root 4096 Nov 14 14:17 /sys/class/rtc/rtc0/wakealarm


    Starte ich manuell mit root rechten /usr/lib/vdr/vdr-shutdown, dann schaltet der VDR ab.


    Ein Vergleich der Files in /usr/lib/vdr/ im aktuellen System mit den Files vom Backup (vor der Burn-Installation) zeigt, dass hier neuere Files mit abweichender Grösse eingespielt wurden.


    Files nach der Installation von CD:


    Files nach Burn-Plugin Installation


    Ich kopiere die alten Files vom Backup zurück in das System und reboote.


    Nun lässt sich der VDR wieder per Fernbedienung abschalten.


    Vermutlich hat sich was an der Art geändert, mit der vdr-shutdown.wrapper das vdr-shutdown script aufruft, und da get dann wohl setuid verloren ??
    Wie lässt sich das Problem sauber beheben, denn er wird ja wohl bei jeder Plugin-Installation wieder auftreten.

  • Sprung bei Pause Play (gelöst)

    Zitat von seahawk1986

    Spricht etwas dagegen das dann auch so im Webfrontend einzustellen?

    Nein.
    Und, du hast die Problemstelle gefunden. Sobald der analoge Ton abgeschaltet ist scheint das Problem verschwunden zu sein. Sowohl mit nur-TOSLINK wie auch mit HDMI-loop-through trat der Fehler nicht mehr auf.
    Für mich hat sich das Problem damit erledigt. Danke.

  • Sprung bei Pause Play (gelöst)

    Hallo
    erst mal vielen Dank für die 0.4.0. Nach etlichen Jahren LinVDR und dann freeVdr soll nun yaVDR mein Wohnzimmerstandard werden. Innerhalb kürzester Zeit war das System lauffähig, es gibt aber noch zwei Probleme, die sich negativ auf den WAF auswirken, und deshalb geklärt werden müssen.


    1) (gelöst)
    Tastendrücke der Fernbedienung (Lirc mit RS232) werden oftmals doppelt ausgeführt, was das Navigieren in Menüs verkompliziert. Ich habe Lirc mit der Fernbedienung nicht neu angelernt, sondern in meiner jahrealten lircd.conf nur die Namen der Tasten angepasst.


    2) (gelöst durch Abschalten des analogen Audioausgangs)
    Wird eine Wiedergabe mit der Pausentaste unterbrochen, und dann mit der Play-Taste fortgesetzt, dann funktioniert das in ca 30% der Versuche nicht korrekt. Stattdessen erscheint kurz "noSignal" und dann wird die Wiedergabe zwar fortgesetzt, aber dabei werden mehrere Minuten übersprungen. Ich habe einen syslog-Auszug angegangen, der den Start einer Wiedergabe mit mehreren Pause-Play-Sequenzen zeigt. Zwei mal trat dabei der beschriebene Effekt auf. Das dürften dann die Meldungen um 19:08:22 und 19:08:38 sein. Was könnte die Ursache sein? Der Effekt ist übrigens unabhängig davon, ob man die Fernbedienung oder das WebFrontend benutzt.

  • 2 x Skystar HD 2 wollen nicht laufen

    Hallo


    ich habe die Skystar HD2 und die Technotrend S2-3200 unter dem aktuellen freeVDR2.1b getestet. Während die Technotrend wie üblich einwandfrei läuft, hatte ich mit der Skystar HD2 deine Timeout-Probleme. ("frontend timed out..." im log jeweils 9 Sekunden nach dem Umschaltbefehl)


    Beim Kanalwechsel war es reine Glücksache, ob der neue Kanal eingestellt wurde, oder ich nur schwarzes Bild (no signal) bekam. Bei Kanälen geringer Datenrate schien es besser zu funktionieren als z.B. bei ARD/ZDF. Ob der zusätzliche Stromstecker angeschlossen war, hatte keinen Einfluss.


    Ich habe gestern die aktuellen liplianin-Treiber aus yaVDR eingespielt, und damit tritt das Problem bei mir nicht mehr auf.


    Im Unterschied zu Dir:
    Ich habe stets nur eine Karte eingesetzt gehabt. auch als Einzelkarte lief die Skystar nur manchmal. Deshalb muss mein Problem mit deinem nicht identisch sein. Ein Blick auf die Treiber lohnt aber bestimmt.

  • Neue VDPAU-Pakete

    Danke,


    jetzt läuft das System nit vdpau und einer alten Nova-DVB-S-Karte.


    Die TechnoTrend Skystar HD2 zum Laufen zu bekommen wird wohl schwieriger werden.

  • Neue VDPAU-Pakete

    Hallo


    ich versuche seit gestern meinem neu zusammengestellten HD-VDR Leben einzuhauchen.
    apt-get update liefert leider am Ende folgendes:


    Zitat

    W: Konnte http://e-tobi.net/vdpau-xine1.1-vdrdevel/dists/lenny/Release nicht holen Unable to find expected entry backports/binary-i386/Packages in Meta-index file (malformed Release file?)


    die sources sind:

    Zitat

    deb cdrom:[c't Debian VDR Distribution 7.0]/ stable contrib main non-free
    deb http://www.debian-multimedia.org/ lenny main
    deb http://ftp2.de.debian.org/debian lenny main contrib non-free
    deb http://e-tobi.net/vdr-experimental lenny base vdr-multipatch
    deb http://e-tobi.net/vdpau-xine1.1 lenny base backports vdr-multipatch
    deb http://e-tobi.net/vdpau-xine1.1-vdrdevel lenny base backports vdr-multipatch


    Vielleicht hat jemand eine gute Idee.

  • Mahlzeit-ISO 4.0beta2

    Zitat

    seid Ihr mutig?
    Dann könnt Ihr http://drseltsam.device.name/vdr/testing...l-2.6.25.11.tgz testen.


    Danke Dr. Seltsam


    Der Kernel läuft im Wohnzimmer-VDR. Die Änderung am poweroff.pl war aber nötig, damit acpi funktioniert.
    Ich lasse das erst mal 1..2 Tage mit der ungemoddeten FF-Karte (Rev 1.5) laufen, danach teste ich mit der gemoddeten FF-Karte (Rev. 2.1). Ich mache sicherheitshalber kleine Schritte, um den WAF nicht zu gefährden, ist ja schießlich der Wohnzimmer-VDR.

  • Mahlzeit-ISO 4.0beta2

    Der gepatchte Standart-Treiber sollte es tun.


    Hallo Dr. Seltsam


    hast du deinen Compiler schon warm laufen lassen? Mein Lötkolben ist nämlich schon wieder kalt. Der Mod war eine ziemlich fipseliege Sache, die man bei FF-Karten der Versionen 1.3 bis 2.1 wohl nicht generell empfehlen kann, erfordert Erfahrung und gute Nerven. Mit den Versionen 2.2 und 2.3 der FF-Karte ist er aber wohl problemlos durchzuführen.
    Ich warte dann sehnsüchtig auf deine gepatchtes v4l-dvb-hg für den 2.6.23.9.

  • Mahlzeit-ISO 4.0beta2

    Zitat

    Dr. Seltsam schrieb
    wenn ein LinVDR-User so einen Mod durchgeführt hat und einen Treiber braucht, kann ich aber gerne mal auf "Einzelbestellung" ein gepatchtes v4l-dvb-hg durch den Compiler jagen.


    Ja bitte bitte bitte.
    da ich unter Mahlzeit keine Entwicklungsumgebung installiert habe, und Deine header nicht besitze, um den Treiber dagegen zu compilieren würde mir das sehr viel helfen.
    Den Mod mache ich am Wochenende. Dann brauche ich ja eigentlich nur noch das zu deinem Kernel passende das gepatchte Kernelmodul dvb-ttpici.ko, wenn ich das richtig sehe.
    Ich nutze den Kernel, den der Linvdr-Updater z.Z. für Mahlzeit4.0b2 verteilt. Da ich das sofort im Wohnzimmer-VDR einsetzen werde, kann ich dann auch schnell Feedback geben.

  • Mahlzeit-ISO 4.0beta2

    Hallo Dr. Seltsam,


    ja, dass sieht wirklich noch nicht gut aus. Ich hoffe mal, dass die full-ts-Leute demnächst den Standard-Treiber patchen.
    Danke für die schnelle Info.

  • (erledigt) Mahlzeit und full_ts ??

    Der "Flaschenhals" beiner FF-Karte wird langsam zu einem echten WAF-Problem. Ich habe zwar neben der FF-Karte noch eine Budget-Karte im System, aber meine Frau schafft es lässig, immer beide Karten mit Aufnahmen zu beschäftigen. Dabei gerät dann die FF-Karte leider auch z.B. an ARD-Kanäle, die im Rahmen der "Qualitätsoffensive" die Datenrate der FF-Karte überfordern.


    Die schnellste Lösung ist der Full-ts-Mod, der aber ein gepatchtes dvb-ttpci-Kernelmodul erfordert.


    Hat jemand einen aktuellen Kernel für Mahlzeit 4.0beta2 mit full-ts-Mod-Unterstützung compiliert, oder kann der vielleicht in die offizielle Mahlzeit4.0beta2 aufgenommen werden??


    sprut