[Ankündigung] sarge/stable in e-tobi-Repository

  • Hallo!


    Demnächst werde ich im Repository einen "stable"-Zweig eröffnen, welcher den jetzigen testing-Stand bekommt.


    Daher meine Frage an euch: Gibt es noch dringende Probleme, die bei den testing-Paketen gefixt werden müssen?


    Im weiteren Verlauf, wird testing dann auf non-root umgestellt und experimental auf vdr 1.3.x. (Kann sich aber noch ein bischen hinziehen - erstmal müssen ein paar andere Baustellen geschlossen werden.)


    Gruß,


    Tobias

  • hi,
    also ich benutze momentan testing, compiliere aber noch selber (*heul* keiner will meinen svdrp-rename patche haben).
    probleme sind mir bisher aber noch keine untergekommen.


    das einzige was ein wenig stört sind die utf-8 dinge. [ich will umbedingt utf8 nutzen]. daher bastele ich immer noch von hand an der runvdr und der plugins-loader.sh rum.


    ich kann also keinen grund nennen warum das ganze nicht stable werden sollte.

  • Also Testing (Bigpatch) läuft bei mir seit reichlich 2 Monaten ohne Probleme. Mit Multipatch habe ich nur einen Tag gearbeitet, weil mir die Umschaltzeiten einfach zu lang waren. Ist aber sicherlich auch kein direkter Bug. Denke also schon, dass Testing Stable werden könnte.


    Bye, gabe!


    Tobi: Ich find dein Repository echt Klasse. Hatte noch nie Probleme und läuft alles Super.

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

    Einmal editiert, zuletzt von gabe ()

  • Ich habe meinen VDR aus den experimental Sourcen kompiliert (Notwendig, da DXR3 keinen AC3oDVB verträgt).
    Das System läuft sehr stabil. Nur die DXR3 macht ab und zu Zicken.

    Asus Pundit-S 2600 - Celeron 2,6 GHz - 512 MB - Samsung 160 GB - NEC DVD-+RW 1300 - WinTV Nova-T (alt) - DXR3 (Creative);
    c't3 - tobi Distri experimental (Sarge)/ VDR 1.4.x + (DXR3 oder em84xx 4MB bin am testen) , Streamdev, LIRC

  • Habe gestern nochmal das aktuelle Testing gezogen (z.B. DVD-Plugin aktualisiert) und ich muss sagen, das DVD-Plugin läuft so stabil wie nie zuvor. Kann jetzt endlich auch das aktualisierte DVB-Paket von Heise und die Firmware 261d einsetzen. Damit lief sonst die vorherige Version des DVD-Plugins nicht stabil.


    Zitat

    Original von Tobi
    Im weiteren Verlauf, wird testing dann auf non-root umgestellt und experimental auf vdr 1.3.x. (Kann sich aber noch ein bischen hinziehen - erstmal müssen ein paar andere Baustellen geschlossen werden.)


    Tobi: Mal eine Frage, wann ist "Kann sich aber noch ein bischen hinziehen"? Würde es sehr begrüßen, wenn vdr 1.3 endlich in den normalen Zweig mit reinkommt. Wie sieht dazu der ungefähre Zeitplan aus? Will aber nicht hetzen. Würde halt nur gerne wissen, wann damit zu rechnen ist.


    Bye, gabe!

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

  • Hi!


    Ich habe mit dem analogtv-Plugin Probleme und habe deshalb die Version von Heise aus dem stable-Zweig(0.9.33) kompiliert. Die funktioniert bei mir wesentlich besser.

    VDR 1.7.15 - Debian Squeeze/Kernel 2.6.32
    Rebach-Gehäuse, Intel Atom330, Extension HD, Technisat Cablestar2

  • slime: Klär mich bitte mal auf, welche Problem du mit utf-8 hast und was du deswegen in runvdr/plugin-loader änderst.


    Ulf: Die Umschalt-Problematik ist schon in Arbeit.


    gabe: Einen genauen Zeitplan kann ich dir nicht nennen. Ins blaue geraten würde ich sagen, dass ich in spätestens 3 Wochen experimental umstellen kann. Testing stelle ich vielleicht schon dieses Wochenende auf non-root um - muss ich mich aber erst mit TomG absprechen.


    tobi_w: Wie äußern sich die analogtv-Probleme? Irgendeine Idee woran es liegen könnte?


    Tobias

  • Hi,


    wenn die testing auf non-root umgestellt wird gehe ich davon aus, dass das Problem mit dem Zugriff auf /proc/av7110_ir als Benutzer gelöst wurden? Wäre ja schön zu hören. :) Oder gibts hinsichtlich dessen noch keine umgesetzte Lösung? Ich denke mal, dass alle die den IR_Port der Nexus-S benutzen sonst auf jedenfall Probleme mit dem non-root VDR bekommen werden.


    Exceeder

    VDR-Zapper - Achtung: Der Link hat sich geändert. Ihr findet den VDR-Zapper nun auf meiner privaten Seite. Die alte Domain ist umgezogen.

  • Zitat

    Original von Tobi
    Ulf: Die Umschalt-Problematik ist schon in Arbeit.


    yep weil Ihr schnell seit,


    kann ich was für euch testen?


    http://www.e-tobi.net/vdr/sarge/testing/binary vdr/bigpatch/
    http://www.e-tobi.net/vdrdevel/sarge/testing/binary vdr/multipatch/


    Gruss ulf

    Samsung UE43RU7479U, Antec Fusion Black, Prime A320m-k, Ryzen3 3200G, 2* DVB-T2,
    Yavdr-ansible auf Ubuntu Server 22.04

    Einmal editiert, zuletzt von Ulf ()

  • Zitat

    Original von Tobi
    Mit dem 2.6'er Kernel ist das Problem mit /proc/av7110_ir gelöst, da man da die Rechte von /proc-nodes ändern kann. Für alle anderen gibt es derzeit nur die Möglichkeit vdr trotzdem als root laufen zu lassen. Das mit dem separaten Schreiben der keymap muss ich erst ausprobieren.


    Das heißt also, dass die non-root-Variante gar nicht kompatibel mit dem Standard-ct-VDR ist, weil da doch ein 2.4er Kernel verwendet wird? Das ist ja Schade!


    Wird der kommende Experimental-Zweig mit VDR 1.3.x auch als non-root laufen und gibt es da dieselben Probleme mit den Rechten?


    Bye, gabe!

    VDR User #928 - Asus P5A * K6-2 450MHz * 256MB RAM * 160GB Samsung SV1604N * Nexus-S Rev2.2 * gepanschtes c't-VDR 3.06 & Tobi's Bigpatch Experimental & Kernel/Treiber c't-VDR 4

  • Zitat

    Im weiteren Verlauf, wird testing dann auf non-root umgestellt und experimental auf vdr 1.3.x


    Kann man davon ausgehen, dass es dann auch wieder das DXR3-Plugin als Paket für 1.3.x geben wird? Weil es das jetzt noch nicht gibt, verwende ich immer noch 1.2.6, würde aber gerne umsteigen, ohne selbst zu compilieren.


    Markus

    MSI-6330, AMD Athlon 1.333@1GHz, 128 MB, 40 GB, wol, nvram-wakeup, Tobi's VDR 1.3.38, dxr3, epgsearch, osdteletext

  • Hi,


    ist aber schade, dass das als non-root läuft man sich den kernel dann zusätzlich noch erstellen muss. Naja sei es drum, für alle die Angst um die Funktionsfähigkeit haben: Tobi hat ja vorgesorgt. :) In der /etc/default/vdr müssen lediglich 3 Zeilen ergänzt/verändert werden, damit alles erstmal als root weiterläuft bis die letzten Probleme behoben sind:

    Code
    OPTIONS="-w 60 --allow-root"
    USER="root"
    GROUP="root"


    Das ist zur Zeit meines wissens nach aber nur im experimental Zeig von Tobi nötig, keine Ahnung was passiert wenn man die Optionen dem testing Zeig zur Zeit mitgibt (der läuft ja zur Zeit noch als root). Also erst verwenden, wenn es soweit ist.


    Exceeder

    VDR-Zapper - Achtung: Der Link hat sich geändert. Ihr findet den VDR-Zapper nun auf meiner privaten Seite. Die alte Domain ist umgezogen.

  • Hallo Tobi


    Im Paket vdr-addon-acpiwakeup 0.0.2 ist noch ein Fehler in der Timereinstellung für autom. aufwachen.
    In der Datei vdr-addon-acpiwakeup.conf ist es egal ob man eine Aufwachzeit eingibt oder nicht, der VDR startet immer 24 St nach dem letztem einschalten.


    ACPI_REGULAR_DAYS=0 und er wacht trotzdem auf


    Danke
    Pit

    Intel 1800Mhz c´t 6.1 VDR 1.6.0 Multipatch (Tobi) Plugin Timelinie Nordlicht-EPG Epgsearch Noad

  • Hallo Pit,


    das ist kein Fehler vom Skript sondern in der ACPI-Implementierung. Beim speichern von Datum/Uhrzeit wird nur die Uhrzeit übernommen, das Datum ist ihm egal. Das bedeutet, wenn du einen Timer für übermorgen 18:00 drinhast, geht er schon morgen um 18:00 an. Du kannst das selber testen, indem du mal ne Zeit für morgen reinschreibst echo "2005-04-23 01:01:01" >/proc/acpi/alarm und dann per cat /proc/acpi/alarm wieder ausliest. Wer täglich nen Timer hat, merkt davon gar nix. Ich habs so umgangen, dass ich ihn regelmässig zu 5:00 aufwecke, dann per cron tvmovie2vdr starte und anschliessend ausschalten lasse, das funktioniert super.
    Ich weiss nicht ob alle Mainboards betroffen sind, aber zumindest sind es viele.


    Gruss, Sebastian

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!