Idee: VDR für alle durch weitere Standartisierung und Updates via Internet

Hi,

mod
Ich hätte gerne ne Poll -> Topic: Wer liest eigentlich Macavity's Postings!?!

OpenPKG zum Lesen: http://openpkg.gds.tuwien.ac.at/doc/handbook/openpkg.html

ich hab mir gerade überlegt... eigentilch könnte man sowas in den vdradmin integrieren.. das ding scheint mit perl zu rennen... also sollte sowas wie updaten vom vdr ja auch damit möglich sein...

ich werd mir das mal genauer durch den kopf rennen lassen... aber irgendwie sehe ich da nicht wirklich ein problem... einzig und allein dürfte es ein problem geben mit binarys.. wie stellt man sicher, dass die dinger nicht plugin+ irgendein code sind..... und wie stellt man sicher, dass das eingetragene auch wirklich das ist was man will......

und was mir noch so einfällt wenn dann müsste man auch gleich sowas ähnliches wie slackbuild-scripte unterstützen...

73

Zitat

Original von oe6jwf
sehe ich auch nicht weiter problematisch... dann gibts halt ab jetzt auch ein <plugin-name>-<arch>.tgz filechen..

wie gesagt datenbank mit folgenden infos würde schon reichen

ein tablelle mit den plugins
id, plugin-name, plugin-beschreibung, ab-version, bis-version, cfg-link
dann noch eine tabelle mit den downloads...

id, id-des-plugins, typ(z.b src,svn,i386,i586,i686,k6,k7,k8,....), link

Alles anzeigen

Öhm, unter Linux gibt es noch mehr Abhängigkeiten als nur die CPU-Architektur. Wobei man die verschiedenen i386er ja gar nicht unterscheiden müsste.

--> glibc Abhängigkeit
--> gcc Abhängigkeit
--> Linker Abhängigkeit

Das kannst du schnell ganzganz vergessen, für alle möglichen Kombinationen binaries anbieten zu wollen.

Mal ganz abgsehen von Plugins, die von bestimmten Treiberversionen auf dem linux PC abhängen, z.B. pvrinput und pvr350.

darum bin ich ja für build from source... und ein script dazu, das dann genau das alles checkt und ggf. reklamiert/nachinstalliert....

auf einer linux box hat einfach ein gcc installiert zu sein... das ist das größte problem der *buntus.. da kannst ja nichtmal einen grafikkarten treiber installieren weil die normalerweise auch gegen den aktuellen kernel kompilieren....

also sind wir uns schon mal einig, das binary arbeit bedeutet und nicht das ziel unterstützt "jedem seine distri aber allen einen vdr" *g*

73

Mal kurz eingeworfen:

Ich finde das Installscript da schon mehr als praktisch ... das lädt aus dem internet die gewünschte Version z.B. eines Plugins runter und patched ggf. automatisch ...

Geht alles sehr komfortabel und "fast" problemlos.

Problem ist in meinen Augen viel mehr:
Keiner weiß welche Patches man wann braucht bzw. welche funktionieren.

Kurzum gesagt: Es herscht in meinen Augen ein ziemliches Chaos was Plugins, Patches und Abhängigkeiten angeht.
So empfinde ich das.

Wenn sich mehr Leute an so einem Script beteiligen würden könnte man das sogar für alle gängigen Distries (Suse, Ubuntu, Debian, ...) so anpassen, das es wirklich total automatisch läuft und alle patches sowie Abhängigkeiten überprüft und ggf. korrigiert, aktualisiert und anpasst.

Das ist aber eine ganze Menge arbeit, welche beim besten Willen nicht von einer einzelnen Person erledigt werden kann.

Meiner Meinung nach ist dieses Skript die ALLERBESTE Möglichkeite wenn man das Grundgerüst (die Distrie) flexibel halten möchte (nicht jeder mag z.B. SUSE).

MFG
Marco

Macavity , ich kann deine Beitraege sehen , keine Angst.
Bei dem Rest stehst wahrscheinlich auf der Blacklist

Hi,

also ich fände das mit der automatischen Aktualisierung auch für sinnvoll aber wahrscheinlich schwer zu realisieren.

Was ich mir vielleicht vorstellen könnte ein VDR den man beispielsweise auf einer DBox Installieren kann. Sprich wie einige andere Projekte die es schon gibt ein kleines Image das ich auf die Box einspiele und danach läuft das Ding. Wäre vielleicht für Leute gedacht die einfach keine Ahnung und Lust haben sich lange einzulesen und Installationsorgien nicht mögen die kaufen sich einfach eine Box spielen das Image drauf und gut ist´s. Vielleicht gibt es so etwas auch schon?

Damit hätte man den Vorteil das die Hardware auf jeden Fall schon mal bei allen gleich wäre. Da könnte man dann solche fuktionen einbauen und die würden auch funktionieren.

Aber ob ich das will

Olaf, ich weiß du wolltest keine apt-get Sachen lesen, aber ich habe einem Bekannten einen VDR gebaut (vor etwa knapp 3 Jahren) und darauf ctVDR installiert... So alle 6 Monate besuche ich ihn, wir trinken ein Bier und ganz nebenbei mach ich ein apt-get update && upgrade und die aktuellen Pakete (Tobi) rutschen wie von selbst auf die Platte... ich hatte bis dato nie ein Problem, einzig die Senderliste musste ich einmal aktualisieren (mache ich immer manuell, um mich auf etwa 25 Sender zu beschränken...)

Keine Ahnung, welche Super Plugins oder Patches da dann abgehen, aber das Ding funktioniert einfach und erfüllt seinen Zweck... klar, sicherheitstechnisch sollte man das Update (Debian Updates) wohl öfter durchführen, aber... theoretisch kann man das per Script ja auch automatisieren, andererseits "never touch a running system"...

Ich persönlich bastle ja für mein Leben gerne, aber mit Familie und Hausbau bleibt nicht unbedingt viel Zeit dafür... trotzdem, oder gerade deshalb möchte ich meinen VDR nicht hergeben - (Stichwort: zeitversetzes Fernsehen, noad usw. ) Aber jetzt schweife ich wohl etwas ab...

Schöne Grüße & ich lese deine Postings auch sehr gerne!

OpenPKG hört sich ja sehr gut an. Bin mir aber über die Problematik, die hier angesprochen wird, nicht ganz im klaren...

Meine ersten Gehversuche im März 2003 (Welche VDR Version war das eigentlich?) liefen über

[list=1]
[*]Debian + Alles per Hand + 2-3 Tage = Nervenzusammenbruch aber lief lange ganz gut
[*]Debian + Installscript + 2 Tage = ganz gut
[*]Erste CT Distri + 1Tag = Lief "irgendwie" nie richtig
[*]LinVDR + 2-3 Stunden = Super aber nie aktuell
[*]Mahlzeit + 1 Stunde + LinVDRupdater = Perfekt und immer recht aktuell
[/list=1]

So kommt für mich Mahlzeits distri dem geforderten recht nahe. Was hier mM nach fehlt ist eine Organisationsstruktur, die aktuelle Erweiterungen einpflegt und die Arbeit auf mehrere Entwickler & Nutzer verteilt....

Oder sehe ich das zu naiv? Wenn man bedenkt wie wenig Ahnung ich von Linux habe und wie viel Zeit ich damit schon verbraten habe bin ich jetzt dank LinVDR & Mahlzeit doch recht zu frieden...

ähm ich benutz z.b keine vdr distri weil mein vdr-pc mein fileserver ist und der pc mit dem ich tatsächlich schaun tu streamed mir das zeugs her und hat auch keine vdr-ähnliche distri drauf... eigentlich ist alles slackware und package-zeugs interessiert mich da herzlich wenig...

ich stell mir da eher eine datenbank vor wo drinnen steht welche versionen welches plugins man:
1. wo her bekommt
2. welchen vdr brauchen
3. welche cfg-gschichten haben wollen
4. wie zu starten sind
5. was patchen wollen/müssen/dürfen damit man welche zusätzliche funktion bekommt bzw überhaupt funktionieren..
und 6. welche externen dependencies haben

ich bin mir nur gerade noch nicht sicher in wieweit man das verguin kann.. weil ich z.b hab slackware und da ist kein gnome dabei.. d.h die gtk-libs sind da nicht alle verfügbar... die *buntu leute haben meist keine kdelibs dabei... also bleibt eigentlich nur sowas für das komische ftlk über... sprache bin ich mir auch ned sicher.. eine scriptsparache wär da glaubich ganz nett.. ich glaub tcl oder sowas wär da wirklich brauchbar da:

1. einfach
2. hat jeder
3. kann mit ka wievielen widgetsets
4. gibts dafür genug fertige libs
5. ists im prinzip ein aufgebohrtes shell-scripting

naja und wenn man dann openpkg verwenden würde... naja ka ... das ist einfach nicht zurechtgeschnitzt um plugins zu distributieren.. ich seh das wirklich so, dass man da eher sowas wie ein slackbuild/ebuild script machen sollte pro plugin und dann einfach die scripts, mit ner gui versieht...

dann kannst auch cross-compiles starten wennst willst...

73

oe6jwf: kann zwar technisch nicht viel helfen, find die Idee mit der db und dem script klasse ! Gerade weil meine meisten Probleme von den externen Abhängigkeiten herrühren.

ich hab ja im prinzip ja schon sowas.. ich tausch in meinem script einfach die zeilen aus die mir ein plugin runterladen (also alte gegen neue version im wget-script) und dann starte ich das script und schwupps sind beide vdrs wieder auf stand

die sache mit herumpatchen löst man ganz einfach.. man holt sich das archiv mit den build scripts und führt dann nach der reihe aus..

z.b zuerst download.sh dann prebuild.sh dann kommt der eigentilche build und dann noch eine extra-cfg.sh oder wie auch immer.. dann sollten eigentlich alle plugins sich damit installieren lassen...

man muss sich dann noch ein verzeichnis struktur einigen und das wars...

z.b:
/vdr
/vdr/downloads <--- cache für downloads
/vdr/updatescript <-- das lustige update-script
/vdr/vdr1 <--- die eigentlichen vdr-dirs
/vdr/vdr2
/vdr/vdr3
...
/vdr/vdrX

/vdr/old_vdr1 <--- backup vom letzten vdr.. man weis ja nie was alles schief gehn kann
/vdr/old_vdr2
/vdr/old_vdr3
...
/vdr/old_vdrX

ich hab z.b nämlich schon 2 rennen am gleichen rechner und da muss es halt sowas auch können

in den vdr-dirs tut man einfach eine text file rein welche plugins man gerne hätte und schon läuft das zeug

Jeder benutzt seine Distribution und binary Distribution des vdr IST defacto die Distribution ersetzen. Dafür gibt es aber Gen2VDR, ctvdr, Mahlzeit/Linvdr etc pp. und das sollte auch so bleiben! Alles in diese Richtung wäre ne weitere distri - was ich keinem ausreden will aber den Kern nicht trifft.

Ich hatte Olaf eher so verstanden das in der Entwicklung mehr zusammengearbeitet werden soll - Patches irgendwo gesammelt werden. Plugin A nur mit Plugin Version B arbeitet etc pp

Ohne deutsch zu können um hier im Poartal mitzulesen oder gar ohne hier mit zu lesen hat man kein Chance auch nur 50% hinzubekommen. Nen positives Bsp finde ich zB live und epgsearch - da wird miteinander füreinander gearbeitet.

Mir ist auch klar warum es so ist wie es momentan ist - vielleicht könnte man eine Zwischenschicht einführen (CVS/Subversion) wo neue versionen eingecheckt werden, Patches sammelt unabhängig vom Upstream von wo dann alle von der Arbeit profitieren können. Upstream kommt einfacher an die Patches die zur Verfügung gestellt wurden - alle anderen können davon ebenso profitieren.

Im Prinzip also gleiches Problem und gleiche Lösung wie Ubuntus Bazaar (nein ich hab kein Ubuntu und ich lobe es auch nicht ;))

Olaf ist es das was du meintest ?

*gähn*

Immer wieder so n ausgelutschtes Thema.

Ich finde auch das es noch ein langer Weg ist bis zu Olafs Traum :

Ich hatte LinVDR 0.7 auf meinem VDR-Client laufen, lief recht gut.
Mit ein paar Patches sogar mit Digitalton.
Nachdem die FF-Karte den Geist aufgab und eine neue kam musste ich neue Treiber installieren. Da ging der Digitalton nicht mehr.
Neue DVB-Treiber manuell installiert, Digitalton geht wieder.

LinVdrUpdater angestossen : Digitalton geht nicht mehr, DVD brennen geht nicht mehr, Fernbedienung geht nicht mehr.

Beim Server war es ähnlich, mit jedem Update ging irgendwas anderes nicht mehr (fbtv, VDRAdmin), man muss viel basteln bis es wieder ging oder darauf verzichten.

Bei Windows ist es so dass ich bei allen Programmen (Betriebssystem, Virenscanner) Auto-Updates machen kann und das Programm dann u 99% noch läuft.

Ich hoffe mal das mit LinVDR 0.8 oder mit Mahlzeit 4.0 eine stabile Disti kommt die man dann ohne viel Basteleien einsetzen kann.

Grüße Bernd

Zitat

Bei Windows ist es so dass ich bei allen Programmen (Betriebssystem, Virenscanner) Auto-Updates machen kann und das Programm dann u 99% noch läuft.

Ich hoffe mal das mit LinVDR 0.8 oder mit Mahlzeit 4.0 eine stabile Disti kommt die man dann ohne viel Basteleien einsetzen kann.

Man man , was fuer nen Schwachsinn.

Vergleichst du hier die Entwicklungsabteilung, Manpower und das
Budget von MS mit Mahlzeit (1 Mann-Show , Netto-Einkommen < 1 Promille (denke ich mal ;))??!!!

Zitat

Originally posted by Morone

Man man , was fuer nen Schwachsinn.

Vergleichst du hier die Entwicklungsabteilung, Manpower und das
Budget von MS mit Mahlzeit (1 Mann-Show , Netto-Einkommen < 1 Promille (denke ich mal ;))??!!!

vielleicht sollte Bernie7 einfach den Stundensatz von Mahlzeit angemessen erhoehen, damit's schneller geht mit der stabilen Distri?

Zitat

Original von Bernie7
Bei Windows ist es so dass ich bei allen Programmen (Betriebssystem, Virenscanner) Auto-Updates machen kann und das Programm dann u 99% noch läuft.

Na da hast du bisher einfach Glück gehabt, ich habe da schon Einiges erleben dürfen.

Ein kleiner Auszug:
neuer Maustreiber installiert -> Neustart -> BlueScreen -> Neuinstallation/Backup restoren.
Update der Firewall-Software -> keine Internetverbindung mehr -> Neuinstallation/Backup restoren.
Oder sowas: http://www.heise.de/security/result.xhtml?url=/security/news/meldung/95030&words=WGA&T=wga

Die Liste würde sich noch beliebig fortsetzen lassen, wenn dann auch noch Beta-Software/-Treiber im Einsatz sind, erhöht sich die Chance dabei zu sein.

So etwas kann halt immer passieren, ich würde das nicht auf ein System festmachen.

Es ist auch mit wenig Manpower / Budget möglich Autoupdatefähige Software zu schreiben. Ich mache sowas z.B.

Es gibt immer mal Ausnahmen, dann kann man das Update wieder entfernen.

Ich will nur sagen dass bei VDR durch die vielen Distis und Plugins es sehr schwierig ist so eine pflegeleichte Version zu bekommen.

Ich habe für einige Kollegen einen VDR gebaut, der basiert auf LinVDR 0.7 und läuft bestens. Wenn die ein Online-Update laden würden und dann die Hälfte nicht mehr gehen würde wäre das Geschrei groß.

Es wäre schon gut wenn man die ganze viel Arbeit die die Leute in das Projekt VDR stecken besser bündeln könnte um bessere stabilere Version zu bekommen.

Grüße Bernd

PS.: wir haben hier so 20 Rechner die Online Update bekommen (Windows und Linux). Ist seit Jahren noch nie vorgekommen dass nach einem Update was nicht mehr lief. Nur einmal bei einem Kunden.