Achtung! Unterstützung benötigt!

  • Hallo Forum!


    Wie Ihr ja wohl in der letzten Zeit mitbekommen habt, ist es um Mulimidix zur Zeit recht ruhig geworden. Dies möchte ich ändern. Zur Zeit existiert einfach das Problem, daß viele der Leute, die sich bereiterklärt haben wichtige Teile des Projekts mitzutragen einfach keine Zeit finden sich dem Projekt zu widmen. Selbst Mille, der die Idee zu diesem Projekt hatte, ist bis Ende des Jahres beruflich größten Teils gebunden.
    Da ich selber nicht jeden Aspekt von Mulimidix selber abdecken kann ( ich muss schließlich auch arbeiten gehen), benötige ich dringend Hilfe um das Projekt in einem angemessenen Zeitrahmen weiterzuführen zu können.


    Folgende Engpässe bestehen zur Zeit:
    - Mille gehört das Epia-System auf dem ich Mulimidix kompiliere. Der benötigt das System jedoch auch selber. Ein System selber zu kaufen, habe ich zwar für Weihnachten geplant, aber bis ich das System hier stehen hab, ist es schon Januar -> Kann hier jemand aushelfen?
    - Der VDR entwickelt sich rasand weiter. Leider ist er daher nicht sehr komfortabel zu kompilieren, da immer wieder Inkompatibilitäten zu anderen Programmen auftreten. Bisher wollte Mille sich um diese Problematik kümmern, der fällt aber ersteinmal aus. Zudem besitze ich keiner DVB-Karte noch habe ich Satelit um mich selber dem Problem ordentlich widmen zu können. -> Hat jemand Interesse für Mulimidix den VDR+Plugins zu erstellen, bzw. kann für diesen auch passende rundvr-Scripte programmieren?
    - Die Webseite von Mulimidix ist schon seit langer Zeit nicht mehr aktualisiert worden und ist nicht sehr gut strukturiert. Hierzu wollte Rüdiger Flachs eine Webseite erstellen. Leider konnte auch er bis auf ein paar Konzeptgrafiken nicht viel präsentieren, da er selber vor Arbeit die Füße nicht den Boden bekommt. -> T.Mewes hat hier schon Interesse bekundet.
    - An vielen Stellen müssen für Mulimidix noch Scripte erstellt werden um das System ordentlich verwaltbar zu machen. Zwar haben wir mit der ersten Version schon einiges an Scripten fertiggestellt, diese sind jedoch buggy und müssten dringendst überarbeitet werden. Zudem fehlen noch esentielle Sachen, wie updatefähigkeit der Software -> Jemand Interesse?
    - Dokumentation: Hier ist nun wirklich noch nicht viel vorhanden, dass liegt sicherlich auch an den vielen Veränderungen, die sich bei Mulimidix ergeben haben. Dennoch ist hier großer Nachhol-Bedarf.
    - Beta-Tester: Auch die muß es geben: Leute, die einem sagen, was Gut ist und was Schlecht gemacht wurde. Man selber ist ja bei seinem eigenen Programmen meistens sehr unkritisch.


    Wenn denn solch Grundlegenden Dinge fehlen, ist dann Mulimidix nicht schon tot? Die Antwort ist: NEIN! Ungeachtet dessen, ob ich Unterstützung bekomme oder nicht werde ich an Mulimidix weiterarbeiten; Auch wenn's länger dauert. Jedoch möchte ich, das sich die Anzahl derer, die an Mulimidix aktiv arbeiten, von dem gewaltigen "nur einer" auf "ganz Viele" ändert. ( Komischer Satzbau... aber ich lass es einfach mal so stehen.)


    Wie soll so eine Zusammenarbeit denn aussehen?
    Naja, wer sich groß in das Projekt einbringen möchte, der kann das gerne machen ( siehe Engpässe oben). Ansonsten würde es mir schon reichen, wenn der ein oder andere mal hier und da ein kleines Script schreibt oder eine Kompilieranweisung für das ein oder andere Programm bereitstellen könnte.
    Wenn mal das ein oder andere Problem auftauchen sollte, werde ich mein möglichstes tun um auch jedem Mitentwickler zu helfen.
    Wer also Interesse hat und dabei sein möchte: e-mail an dieter.springer@sysconfig.info

  • Zudem fehlen noch esentielle Sachen, wie updatefähigkeit der Software -> Jemand Interesse?
    --------
    Ihr könnt doch einfach das Installations-Script auf Muli portieren, denke nicht das da groß was angepasst werden müßte.


    Voraussetzungen: lynx, wget, dialog, cvs


    URLs sind in *.cmd hinterlegt, von den Servern wird jeweils ein Index eingelesen, soviel zu Punkto "updates".


    Ansonsten würde es mir schon reichen, wenn der ein oder andere mal hier und da ein kleines Script schreibt oder eine Kompilieranweisung für das ein oder andere Programm bereitstellen könnte?
    ---------
    Kompilieranweisungen und alles andere wurde ebenfalls in den *.cmds hinterlegt, kannst ja mal schauen.


    Hier ein "Modul":



    Allerdings kann ich mir nicht vorstellen, das man alles was in den Scripts steht auch auf Muli installiert bekommt, da es zuviele Sachen sind und man die Depends nur aufgelöst bekommt wenn eine vollwertiege Basis da ist.


    Weißt was ich meine, zbs benötigt Xine und Co unmengen an Lib(s), das selbe gilt für anderer Software.


    Da ja Muli "alles" schon inside haben soll, stellt sich mir die Frage, was mit updates gemeint ist?


    Wie gesagt finde es Sinnlos extra ein Installations Script für Muli neu zu schreiben, weil:


    - sich zu oft etwas software/plugin/patches ändert
    - sich zu oft URLs ändern
    - Oder soll man bei updates der Scripts sich jedesmal Muli komplett neu laden


    Portieren des vorhandenen Installations-Scripts, wäre Sinnvoll:


    In der os_list.txt ein neuer Eintrag für Muli:


    Code
    Debian Linux    2.2    debian-linux    2.2    $etc_issue =~ /Debian.*\s2\.2\s/i
    Debian Linux    3.0    debian-linux    3.0    $etc_issue =~ /Debian.*\s3\.0\s/i
    SuSE Linux	     5.1    suse-linux       5.1
    SuSE Linux	     5.2    suse-linux       5.2
    Muli Linux        ?.?    Any version               *   -f "/etc/MULI "


    Und in den *.cmds, könnte es so kommen:



    Wie gesagt nur ein Vorschlag.


    MFG Ronny

  • Hallo Ronny.


    Danke für deine Antwort.
    Wie gesagt,habe ich bisher mich selber noch nicht mit VDR großartig auseinander gesetzt, da dies eigentlich Mille's Part sein sollte. Nun werde ich das wohl machen müssen.
    Was dependenzen angeht, müsste ich mal schauen, was man da machen kann.
    Mulimidix besteht jetzt schon aus ner vielzahl von libs, da kann die ein oder andere xine-lib ja nicht schaden.


    Grundsätzlich habe ich eigentlich vor für eine bestehnde Mulimidix-Installation auch einen Update-Weg anzubieten. Ich halte dies einfach für den besseren Weg als wie bei der ersten Version einfach ein fertiges System hinzuknallen. Bei Problemen mit dem ein oder anderen Paket kann so schnell Abhilfe geschaffen werden.


    Na dann werde ich mir jetzt mal die Tage den VDR genauer ansehen...


    Bis demnächst

  • Hi,


    mit Update-Systemen kenne ich mich nicht wirklich aus, aber das System von eisfair http://www.eisfair.org funktioniert gut. Evtl. könnte man sich da die eine oder andere Idee holen?


    Was den VDR angeht bin ich mit den Versionen auf meinem Mulimidix-Rechner immer aktuell. Wäre kein Problem, die aktuellen Versionen zu kompilieren/ zur Verfügung zu stellen. Kann aber nicht alles testen (z.B. hab ich kein LCD).
    Was hast Du Dir bezüglich der VDR-Versionen genau vorgestellt?


    MfG,


    skies

  • Hallo skies.


    Danke für den Link...
    werde mir das System mal anschauen.


    Bisher habe ich mit dem VDR reichlich wenig Kontakt gehabt ( ausser Kompilieren nix gewesen ). Daher gehe ich an den VDR ersteinmal unvoreingenommen wie ein Säugling ran.
    Ich selbst habe da keine Ahnung was eine gute Zusammenstellung an Plugins, etc. für den VDR ist. Grundsätzlich möchte ich aber ein System präsentieren können, wo die Plugins, je nach dem welche benötigt werden, hinzugefügt, bzw. entfernt werden können.


    Ich stelle mir das so vor, daß der Basis-VDR installiert wird und man die einzelnen Plugins hinzufügen kann, je nachdem welche gerade Sinn machen.
    Der Endanwender sollte aber nicht erst den VDR kompilieren müssen ( es aber durchaus noch können).


    Ob sich dieses Ziel bewerkstelligen läßt? Keine Ahnung.

  • Hi Dieter.


    Das sollte eigendlich kein Problem sein (was die Plugins angeht). Da kompiliert man einfach alle und kann ja dann via runvdr entscheiden, welche beim VDR-Start geladen werden sollen. Problematischer wird es mit den Patches. Da müssen die Sourcen gepatcht werden. Ich fahre sehr gut mit dem Komplettpatch. Wenn Du allerdings den Benutzer entscheiden lassen willst, welche Patches er haben will, müsste man die einzelnen Patche bereithalten und die auch in allen möglichen Kombinationen testen. Halte ich nicht für sehr sinnvoll. Evtl. könnte man die Option Komplettpach JA/NEIN. einbauen. Dann müsste aber gepatcht und neu kompiliert werden.


    Also die einfachste Lösung wäre Komplettpatch rein und alle Plugins kompilieren. Ein Menü bauen, welches die runvdr ändert und die ausgewählten Plugins startet.


    MfG,


    skies

  • Hi skies.


    Du scheinst da ne Menge Erfahrung mit zu haben.
    Grundsätzlich glaube ich, daß die Entwicklung auch so in die Richtung laufen würde.
    Einige meiner ersten Kompilier-Versuche sind kläglich daran gescheitert, daß ich versucht habe mehrere Patches hintereinander anzuwenden. Der Komplettpatch war der einzige wo ich halbwegs Erfolg hatte.


    Könnte ich dich dazu überreden den VDR für Mulimidix zu erstellen? Da ich ja zur Zeit
    keine Möglichkeit habe den VDR zu benutzen ( kein Sat, keine DVB und kein Geld ), suche
    ich sowieso eine Möglichkeit jemanden zu animieren, der den VDR auch selber benutzen kann. Ich selber bin ja zur Zeit nur in der Lage den VDR theoretisch aufzusetzen.

  • Zitat

    Original von skies
    Hi Dieter.


    Das sollte eigendlich kein Problem sein (was die Plugins angeht). Da kompiliert man einfach alle und kann ja dann via runvdr entscheiden, welche beim VDR-Start geladen werden sollen.


    skies


    Kannst Du das mal Bitte im Detail Erklären, wie ich in einem 1 x eingelesenen Script (hier die runvdr) eine Variable ändere?


    Alle bemühungen das zu Realisieren sind hier gescheitert, Ergebniss war eine lerre runvdr?


    In der inittab steht folgendes:


    vdr:35:once:$MYPATH/VDR/runvdr> /dev/null


    Und nun hersche mal mit sed, perl was auch immer in der runvdr rum! Mit irgend etwas mußt Du ja editieren.


    MFG Ronny

  • Dieter Springer


    Ich stelle mir das so vor, daß der Basis-VDR installiert wird und man die einzelnen Plugins hinzufügen kann, je nachdem welche gerade Sinn machen.


    Klar.


    Der Endanwender sollte aber nicht erst den VDR kompilieren müssen (es aber durchaus noch können).


    Auch klar.


    -----------


    Aber das eine ist mit dem anderen verbunden, wie stellst Du Dir das vor einen Server und alle können sich da fertige binärys laden?


    1. Aufwand -> Nutzen ?
    2. Nie up to date?
    3. Muß gepflegt werden ?
    4. In 3 Jahren kräht kein Hahn mehr dannach ?


    Zum anderen wurdest Du schon einmal darauf hin gewiesen ?


    Und zwar hier: http://www.vdrportal.de/board/thread.php?threadid=5790&sid=


    Großer Aufruf "Wünsche" ....


    Zitat: decembersoul


    Das runvdr Script sollte flexibel gestalltet sein. Es wäre doch nett wenn man mit einem Script ein Plugin (z.B. Games) ein und ausschalten kann.
    Dieses ist in der Version vom "InstallScript" (siehe diese Seite) möglich.
    Dort wird das runvdr Script neu erzeugt ohne/mit der Zeile die ausgeschaltet/eingeschaltet werden soll.


    Naja nicht so ganz, man kann nicht ein Script einlesen lassen und in diesen Variablen ändern, jedenfalls ist es ohne Aufwand zu Realisieren.


    Aber mal zum Punkt, wer klatscht sich schon was auf dem PC wo Sachen von Anno drinnen sind?


    MFG Ronny

  • Hallo Ronny!


    Okay! Hört sich an sich ja auch gut an.
    Mir stellt sich halt die Frage den VDR so zu verpacken, daß gesichert ist, daß ein Anwender sich in keiner Weise mit Kompilieren und möglichen Kompiler-Fehler herumplagen muß. Sicherlich kann bei einem Pre-Packaged-System man nicht absolut up-to-date sein, daher dachte ich ja an eine Update-Routine. Server-Probleme wie zum Anfang des Projekts dürften in der Zukunft nicht mehr auftreten.

  • Ich habe hier nen System mit Epia-800 Board und TT-FF 1.6 Karte und wäre bereit den Kram zu testen! Einzige Bedingung: Mangels TV muss ich die Ausgabe über X basteln. Aber AFAIK gibt es noch keine Distri die das von Haus aus kann, wäre also durchaus interessant finde ich. Bei Interesse: Meine email Adresse steht im meinem Profil.


    Gruß,
    Floh

  • Ronny
    Was den Start des VDR's angeht, denke ich, daß man dieses Problem bestimmt in den Griff bekommen kann. Wenn nicht, dann ist das meiner Meinug eine Art vesäumnis im VDR. Einen technisch machbaren Weg wird es betimmt geben.


    Aber wie gesagt, kenn ich den VDR nicht besonders...

  • Hi Ronny,


    joa, die runvdr auszulesen un dann darin rumzufrickeln ist wohl umständlich. Aber das Config-Script kann die doch jedesmal neu schreiben. So wie ich das verstanden habe, soll der User ja nicht selber darin rumfrickeln, sondern das über ein Konfig-Menü machen.


    Also kann man die runvdr beenden, löschen, abhängig von den Parametern neu schreiben und dann starten (wär mal ein schneller Anfang, geht bestimmt auch noch schöner).


    Soviel zur Theorie...


    Dieter: Wie sieht der Zeitplan aus? Lass uns mal die Details klären, dann werd ich mal loskompilieren..


    MfG,


    skies

  • Zitat

    Original von Dieter Springer
    Ronny
    Was den Start des VDR's angeht, denke ich, daß man dieses Problem bestimmt in den Griff bekommen kann. Wenn nicht, dann ist das meiner Meinug eine Art vesäumnis im VDR. Einen technisch machbaren Weg wird es betimmt geben.


    Aber wie gesagt, kenn ich den VDR nicht besonders...


    Morgen!


    Sehe ich auch so, aber solange an VDR geworkt kann man ja noch hoffen :] , nun ja wir sind zwar nicht bei "Wünsch Dir was", aber ein paar Sachen täten Not.


    - Das man Plugins on/off setzen kann (im Betrieb) wäre wirklich schön, so könnte man sich das ein oder andere Script schenken.


    - Das man explizit angeben muß (runvdr) Plugins-Übergabe will mir auch nicht so recht in den Kopf, jedes andere Programm lädt Plugins auto, wenn sie im Verzeichnis liegen (Denke da an Xine/Mplayer a.s.o.).


    - Eine "Kinder Sicherung" für Sender wäre auch Wünschenswert, das selbe für Aufnahmen, auch hier könnte man Scripts rauswerfen.


    Einiege Punkte von oben wurden schon oft in der ML angesprochen, "C" ist nicht meins, aber möchte meinen das nichts von den Sachen zur Rubrik "nicht machbar" gehören.


    MFG Ronny

  • Hi


    Nochmal zu PLUGINS (ON/OFF), geht doch ohne extra Script (alles in der runvdr (setplugins)), mit symlinks.


    Ist von überall zusammen geklatscht CT's/LinVDR/Forum/ML und CO, die Plugins werden doch eh eingelesen, somit alles was in ../lib liegt.


    Nun läuft es so, das zu ../VDR/PLUGINS/lib noch ein Verzeichnis erstellt wird, hier (+s):


    mkdir -p ../VDR/PLUGINS/libs


    In dieses werden die Plugins einfach gelinkt, VDR bekommt als LIBDIR das neue Verzeichnis mit auf den Weg:


    --lib="../VDR/PLUGINS/libs"


    Über die commands.conf kann man nun easy Links setzen bzw löschen.


    Wie gesagt PHAD Angaben müßte man sich anpassen, geht ja nur ums Prinzip, cool wäre es wenn Plugins bzw. VDR von Haus aus eine Option mitbringen würde, die es erlaubt im laufendem Betrieb ein Plugin aus dem Programm zu nehmen, bzw es zu laden.


    MFG Ronny


    commands.conf:


    Code
    --+ p l u g i n s (on/off)              : echo 'No function, this is a Seperator ?'
         |--- hello                         : export LABEL=hello ; eval $SET_PLUGINS
         |--- osddemo                       : export LABEL=osddemo ; eval $SET_PLUGINS
         |--- sky                           : export LABEL=sky ; eval $SET_PLUGINS
         |--- sleeptimer                    : export LABEL=sleeptimer ; eval $SET_PLUGINS
         |--- status                        : export LABEL=status ; eval $SET_PLUGINS
         |--- xine                          : export LABEL=xine ; eval $SET_PLUGINS


    plugins.conf:



    vdr.conf:



    runvdr:


  • Hallo anonymous ;)


    Danke erstmal für den Beitrag.
    Um die VDR-Anpassungen voranzutreiben, habe ich die Paketentwicklung weitgehend an Andreas Juchem abgegeben. Er hat einfach mehr möglichkeiten direkt am VDR zu arbeiten.
    Ich werde Ihm Bescheid geben, sich die Sachen genau anzusehen.
    Ich denke, daß er die Sachen schon vernünftig umgesetzt bekommt.


    Danke.

  • Hi


    Habe noch eine "order.conf" mit eingebaut zum Plugins sortieren, bei CT's läuft es so ähnlich ab.


    Die runvdr-scripts schauen auch nicht übel aus: http://www.ps.uni-sb.de/~errror/vdr/ falls Ihr noch was sucht.


    MFG Ronny


    commands.conf:

    Code
    --+ p l u g i n s                       : echo 'No function, this is a Seperator ?'
         |--- hello                         : export LABEL="hello" ; eval $SET_PLUGINS
         |--- osddemo                       : export LABEL="osddemo" ; eval $SET_PLUGINS
         |--- sky                           : export LABEL="sky" ; eval $SET_PLUGINS
         |--- status                        : export LABEL="status" ; eval $SET_PLUGINS


    plugins.conf:


    order.conf:

    Code
    # Sequence configuration for Plugins
    #
    # Format: ^plugin
    
    
    calendar
    dvd
    mplayer
    control


    vdr.conf:


    runvdr:

  • Morgen


    Eine Sache wäre noch.


    Nun ist ja schön das das jetzt wie bei CT's ist (auto einlesen der Plugins), habe mir Muli noch nicht angeschaut wie es da funktioniert.


    Jedenfalls müßte man so wie es jetzt ist, bei jedem neuen Plugin einen Eintrag in die commands.conf machen (Stressig), um das Plugin ON/OFF setzen zu können.


    Meine damit, das in einem Rutsch erlediegen zu lassen, macht mehr Sinn (einzieger Nachteil die commands.conf muß gesplittet werden) mit "sed" drinnen "rumherschen" kommt nicht in Frage.


    + eine Variable:


    # rules, this plugins not (on/off) via commands menu
    RULES="[remote][prefermenu]"


    Um Plugins zu "schützen" es wäre zbs Sinnlos das REMOTE PLUGIN ON bzw. OFF zu setzen, wenn man VDR nur mit diesem bedient.


    Eine Abfrage wird überflüssig (ob das Plugin existiert) weil die commands.conf müßte so immer aktuell sein.


    Bei CT's läuft es ähnlich (da wird auch aus mehreren Files eines erstellt) hatte CT's nur mal kurz installiert (nutze es nicht).


    ===============================================
    ===============================================


    $VDR_CONFIG/commands[1].conf (das wäre die wo alles drinnen steht)


    Auf jedem Fall sollte die letzte ZEILE wie folgt aussehen, damit man weiß für was das gut sein soll:

    Code
    ......................
    --+ p l u g i n s                       : echo 'No function, this is a Seperator ?'
    EOF


    $VDR_CONFIG/commands[2].conf (die lassen wir von der runvdr generieren)


    Dannach die files "mergen":


    Schaut dann so aus (commands.conf)

    Code
    ...........
    --+ p l u g i n s                       : echo 'No function, this is a Seperator ?'
         |--- alcd                          : export LABEL="alcd" ; eval $SET_PLUGINS
         |--- audiocd                       : export LABEL="audiocd" ; eval $SET_PLUGINS
         |--- browser                       : export LABEL="browser" ; eval $SET_PLUGINS
    EOM


    ===============================================
    ===============================================


    Komplett:


    commands[1].conf (2te wird ja generiert):

    Code
    --+ v d r                               : echo 'No function, this is a Seperator?'
         |--- ?????????????                 : cmd
         |--- ????????????                  : cmd
         |--- ???????????                   : cmd
    --+ p l u g i n s                       : echo 'No function, this is a Seperator?'


    vdr.conf:


    runvdr:


    Zeitmäßig hauts hin, bis alles eingelesen/generiert wurde, schneller gehts bei CT's auch nicht.

    Code
    real    0m0.419s
    user    0m0.221s
    sys     0m0.185s


    MFG Ronny


    [plugins.conf wurde nicht geändert, siehe ein paar Postings höher]

Jetzt mitmachen!

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