Beiträge von Blitz2

  • Versionsvielfalt c't-vdr / Debian

    andreas_h


    Du hast sicher Recht, daß Tobi und Tom das Übersetzen der Plugins weitestgehend automatisiert haben. Aber wie Du ja auch schreibst, gibt es immer einige Problemfälle. Aus der Erfahrung mit einigen Softwareprojekten weiß ich aber, daß die letzten 5% (die Problemfälle) oft 90% der Arbeit bedeuten.


    Worauf ich eigentlich hinaus möchte, ist, daß User die neueste c't Augabe kaufen, versuchen die CD zu installieren und feststellen, daß es nicht geht. Ein Problem ist, daß es zu viele mögliche Hardware- und Softwarekombinationen gibt.
    Die Hardwarekombinationen der User kann man nicht minimieren. Wohl aber die Softwareversionen.
    Die Chance das eine Software sauber läuft, erhöht sich je mehr Leute diese Software auf verschiedener Hardware testen.
    Hat man nun aber 45 verschiedene Kombinationen aus Patchlevel/Repositories/Debian-Versionen ist die Gefahr sehr groß daß ein Problem erst mit der nächsten c't-CD erkannt wird, die dann von einer Vielzahl von unerfahrenen Nutzern installiert wird.
    Hat man nur wenige Repositories (z.B. 18 oder 20) könnte man die Zahl der Tester pro Version erhöhen und vielleicht die Fehler noch einmal minimieren.
    Ein Plugin wird vielleicht von Experimental zu testing und dann zu stable durchgereicht und trifft dann plötzlich erst auf einen nforce Chipsatz (o.k. kein gutes Beispiel) und funktioniert dann nicht.


    Gruß Jörg

  • Versionsvielfalt c't-vdr / Debian


    Ich meinte, daß sich die Anzahl der Benutzer pro Version erhöht und man damit eine größere Vielfalt an verschiedener Hardwareausstattungen und Nutzeranforderungen erhält.
    Sicher ist Multipatch/Bigpatch nur eine Version, aber alle Plugins müssen für beide übersetzt werden, was ja quasi die doppelte Arbeit bedeutet.


    Gruß Jörg

  • Versionsvielfalt c't-vdr / Debian

    Moin,


    ich bin begeisterter c't-vdr-Nutzer und möchte mich an dieser Stelle für die hervoragende Arbeit von Peter Siering, e-tobi, TomG, dem Debian-Team und natürlich Klaus Schmiedinger und den Plugin-Autoren für die super Arbeit bedanken.


    Ich habe mit Programmierung unter Linux leider keine Erfahrung und kann daher immer nur aus Sicht des Users schreiben. Aus Bequemlichkeit und mangelnder Zeit nutze ich nur fertig kompilierte Pakete.
    Dabei ist mir die große und (aus meiner Sicht) verwirrende Vielfalt an Paket-Repositories aufgefallen.


    Ich habe hier mal versucht eine Übersicht zu erstellen: (Stand 21.05.2005).


    Debian woody:


    vdr 1.0.0-1 plain - Debian-Team


    vdr 1.2.6-15 stable ac3 - heise
    vdr 1.2.6-15 stable ct - heise
    vdr 1.2.6-15 stable elchi - heise
    vdr 1.2.6-15 stable elchiac3 - heise
    vdr 1.2.6-15 stable elchiosdpip - heise
    vdr 1.2.6-15 stable elchiosdpipac3 - heise
    vdr 1.2.6-15 stable plain - heise


    vdr 1.2.6-24 testing ac3 - heise
    vdr 1.2.6-24 testing ct - heise
    vdr 1.2.6-24 testing elchi - heise
    vdr 1.2.6-24 testing elchiac3 - heise
    vdr 1.2.6-24 testing elchiosdpip - heise
    vdr 1.2.6-24 testing elchiosdpipac3 - heise
    vdr 1.2.6-24 testing plain - heise


    vdr 1.2.6-25 stable bigpatch - e-tobi
    vdr 1.2.6-25 stable multipatch - e-tobi


    vdr 1.2.6-27 testing bigpatch - e-tobi
    vdr 1.2.6-27 testing multipatch - e-tobi


    vdr 1.2.6-27 experimental bigpatch - e-tobi
    vdr 1.2.6-27 experimental multipatch - e-tobi


    vdrdevel 1.3.17-9 testing standard - TomG
    vdrdevel 1.3.17-9 testing multipatch - TomG


    vdrdevel 1.3.24-1 experimental standard - TomG
    vdrdevel 1.3.24-1 experimental multipatch - TomG



    Debian Sarge:


    vdr 1.2.6-12 plain - Debian-Team


    vdr 1.2.6-27 stable elchi - heise
    vdr 1.2.6-27 stable elchiosdpipac3 - heise
    vdr 1.2.6-27 stable plain - heise


    vdr 1.2.6-29 testing elchi - heise
    vdr 1.2.6-29 testing elchiosdpipac3 - heise
    vdr 1.2.6-29 testing plain - heise


    vdrdevel 1.3.15-2 devel multipatch - heise (?TomG?)


    vdr 1.2.6-28 stable bigpatch - e-tobi
    vdr 1.2.6-28 stable multipatch - e-tobi


    vdr 1.2.6-28 testing bigpatch - e-tobi
    vdr 1.2.6-28 testing multipatch - e-tobi


    vdr 1.2.6-34 experimental bigpatch - e-tobi
    vdr 1.2.6-34 experimental multipatch - e-tobi


    vdrdevel 1.3.17-9 testing standard - TomG
    vdrdevel 1.3.17-9 testing multipatch - TomG


    vdrdevel 1.3.24-1 experimental standard - TomG
    vdrdevel 1.3.24-1 experimental multipatch - TomG



    Debian Sid:


    vdr 1.2.6-13 plain - Debian-team


    (Ich hoffe hier nicht zu viele Fehler gemacht zu haben. Wer sich berufen fühlt darf gerne Korrekturen vornehmen.)


    Und nun zu meinem Anliegen:
    Ich denke das eine derartig große Anzahl an Repositories nicht nötig ist. Einige werden wahrscheinlich nur von einer verschwindend geringen Anzahl von Usern genutzt. Ich nutze z.B. vdrdevel 1.3.17-9 testing multipatch von Tom und schalte nie auf den normalen vdr um.
    Dies soll kein Gemecker sein, sondern nur ein Gedankenanstoß. Bei einer geringeren Anzahl erhöht sich die Zahl der User und damit der Tester. Eine Weiterentwicklung könnte schneller vorankommen und Fehler schneller ausgebügelt werden.
    O.K. mit der Umstellung von Sarge auf Stable entfallen über kurz oder Lang die Hälfte der Repositories. Es bleiben meiner Ansicht nach aber immer noch zu viele übrig.
    Ein weiterer Punkt ist die Arbeit der Paketbetreuer. Bei einer geringeren Anzahl könnte man die Arbeit vielleicht bündeln und verringern.


    Ich möchte die Leistungen hier auf keinen Fall schmälern, sondern nur einen Gedankenanstoß liefern. Ich als Linux-Laie kann sowieso nur wenig zur Weiterentwicklung des c't-vdr bzw. den Debian Paketen beitragen.


    Grüße Jörg

  • multischalter / sat frage

    Moin,


    beagle: Natürlich kann man bei diesem Multischaslter auch ein terristrisches Signal einspeisen.


    Zitat

    ZITAT SATFUCHS:
    Der neue KOMPAKT-LINE OCTO 98 S Multischalter dient zur Versorgung von 8-Teilnehmern mit SAT-ZF und terrestrischem Signal. Es können zum Beispiel: Zwei Vollbänder der Satelliten Astra (Low- und High-Band) + Eutelsat (Low- und High-Band) oder vier beliebige Satelliten mit jeweils zwei Polarisationsebenen oder 8 beliebigen Polarisationsebenen verteilt werden. Zur Verteilung von terrestrischen Signalen steht ein weiterer Eingang Verfügung.


    Gruß Jörg

  • Radio Bremen TV

    Moin,


    der Eintrag funktioniert.
    Leider sendet Radio Bremen noch keine brauchbaren EPG-Daten (6.5.2005).


    Har schon jemand ein Senderlogo entworfen?


    Gruß Jörg

  • [UPDATE] sarge: noad testing: siehe text

    Hallo Tom,


    nur noch einige Anmerkungen:


    Zitat


    1. Du willst vdrdevel-addon-noad installieren - hier ging es aber um die Veröffentlichung von vdr-addon-noad.


    OK, ich habe die Thread-Überschrift nicht richtig gelesen. :wand: Die Formulierung ist aber auch nicht ganz glücklich.


    Zitat


    2. Die neue Version vdr-addon-noad gibt es nur in vdr/sarge/experimental, was nicht in deiner sources.list steht.


    Stimmt, allerdings liegt in testing ein Paket mit selber Version:
    http://www.e-tobi.net/vdrdevel…ddon-noad_0.5.2+1_all.deb
    Ist das so richtig?


    Zitat


    3. vdrdevel-addon-noad ist von vdr-addon-noad abhängig, damit das noad-Programm nur einmal in /usr/bin installiert wird.


    OK, verstanden


    Auf diesem Wege noch einmal vielen Dank für die viele Arbeit die Ihr euch mit den Paketen macht. :applaus


    Viele Grüße


    Jörg

  • [UPDATE] sarge: noad testing: siehe text

    Moin,


    beim Versuch noad zu installieren, erhalte ich:


    Code
    Die folgenden Pakete haben nichterfüllte Abhängigkeiten:
  vdrdevel-addon-noad: Hängt ab: vdr-addon-noad (>= 0.5.2) aber 0.4.2-5 soll installiert werden
E: Kaputte Pakete


    vdr-addon-noad-ist bei mir in dieser Version vorhanden:


    vdr-addon-noad_0.4.2-5_i386.deb


    Ist daß nur bei mir so, oder oder sind im Paket falsche Abhängigkeiten?


    Eine Abhängigkeit zwischen vdr- und vdrdevel-Paketen leuchtet mir im Moment nicht ein, oder mache ich einen Gedankenfehler?


    Gruß Jörg

  • Nexus-S + Skystar2 --bei start der Timeraufnahme-> exergency Exit

    Hallo rudibert,


    Ich bin auch gerade am ausprobieren.


    Der Cronjob wird in /etc/crontab eingetragen:



    Der Eintrag in der letzten Zeile ist der entscheidende. Ich habe hier zum probieren mal 12.38 eingetragen. * bedeutet: Jeder.
    (dom = day of month, mon = month, dow = day of week)


    Gruß Jörg