Migration lenny/etch 1.6 auf squeeze 1.7.18 (etobi)

    Gibt es irgendwo eine Zusammenstellung wo die -wesentlichen-
    Unterschiede zwischen 1.6 und 1.7 liegen, die bei einer Installation unbedingt zubeachten sind?
    ( ausser implizit in den seitenlangen Readme zu jeder einzelnen Version?)


    Also irgendwie so was:
    Was ist neu bei 1.7.18(squeeze) vs. 1.6.x(lenny)
    1.7.18: UTF-8 Kodierte Zeichensätze (de,en) müssen installiert sein, sonst seltsame Menue
    1.7.18: Neues Format der channels.conf, ((in)kompatible zum 1.6?)(ohne HD: w_scan -fs -s S19E2 -o 7 >> channels.conf)
    1.7.18: Firmware FF TT -fb benötigt, sonst buffer oferflows(?)
    1.7.18: Nur 1 CPU wird unterstützt
    1.7.18: PCI latency timer sollte auf 128 stehen (BIOS)
    1.7.18: FF TT Ausgang nur mit Plugin zum ausgeben verwendbar
    1.7.18: Aufzeichung als TS und nicht PES, ((nicht) mit 1.6 abspielbar?)
    1.7.18: FF TT mod empfohlen
    1.7.18: HD unterstützung
    1.7.18: femon plugin passt sich nicht automatisch der OSD grösse an, sondern bleibt unsichtbar
    1.7.18: osdteletext plugin benutzt irrtümlich die Festplatte anstatt RAM-disk, was zu Klötzchen im Bild und Nicht-Abschalten der Platte führt
    1.7.18: Was noch? setup.conf erweitert um? sources? andere conf?


    Sonstiges:
    1.7.18: Aufzeichungsübersicht ohne Längenangaben(oder ist das ein Patch gewesen?)


    Wo finde ich das?

    Du vermischt VDR, Patches, Plugins, Treiber und Packete. Das kannst du einfach nicht so auflisten.


    Das z.B. deine TV Karte ne andere Firmware braucht, das ist Kernelsache. Da hast du vermutlich einfach nur das Problem das mit dem Squeeze nen neuer Kernel kam, und damit auch nen neuer Treiber für deine TV Karte. Und es ist durchs möglich das der Treiber in dieser Kernelversion einfach mal kaputt ist. Hat aber nix mit dem VDR zu tun.


    >> femon plugin passt sich nicht automatisch der OSD grösse an, sondern bleibt unsichtbar


    Das war schon immer so. Und das selbe Problem haben auch andere Plugins (music, weatherng usw.) die das OSD selber malen.


    cu

    Doch kann ich, siehste ja :)
    Aber ich ziehe eine sachliche Diskussion ohne Unterstellungen und persönliche Anmache vor :)


    Die Liste ist ein Beispiel auf welche Probleme ich getroffen bin. Erstaunlich irgendwo, da es für jeden Bereich
    mehrere Spezialisten geben dürfte, die sagen: "Ja, ist doch das das so und so ist, das weiss man doch, und wer es nicht weiss,
    gehört nichtzu uns und sollte die Finger von so einem System wie xyz lassen und besser mit Murmeln spielen".
    Nein, das weiss nicht "man" sondern nur der Entwickler, der Spezialist, dem es darum so leicht fällt.


    Ich komme aus Anwendersicht. Dem Anwender ist erstmal egal woher das Problem rührt: "xyz geht nicht".
    Ich habe z.B. das Problem das die Schnaptolyse nicht tut wie sie soll, nicht so wie ich es erwarte.
    Da möchte ich dann die Möglichkeiten sehen, die zu dieser Fehlfunktion führen können, oder
    Aufklärung, das ne Schnaptolyse ebend nicht zum schrumbrunnsen geeignet ist.
    Ob es der Treiber sein könnte, die Firmware oder der Kern ist doch für den Anwender erstmal egal
    und kein Grund all diese -natrülich völlig- unterschidlichen Ursache in einer Auflistung zusammeln.
    Er muss einen Punkt haben, wo er ansetzen kann, denn niemand kann alles wissen.


    Für den Entwickler ist das natürlich "unstruktiertes Chaos", weil er mehr vom Einzelnen kommt,
    aber für wen wird VDR gemacht? Selbstzweck der Entwickler, oder auch zum Nutzen von Anwendern?
    Sicherlich beides, denn für einen Entwickler ist es sicher schöner, wenn ein Anwender gut mit dem Ergebnis
    zurecht kommt, und nicht nur der Code eine "innere Schönheit" hat, die sich allerdings nur einigen wenigen
    Spezialisten erschliesst und ggü. dem Anwender durch Funktionsmängel auffällt.


    Ihr Auto macht hinten während der Fahrt Geräusche?
    - Differential
    - Radlager
    - Reifendruck
    - Lauffläche
    - Radaufhängung
    - Fremdkörper
    - Radmutter
    - Drehmomentschlüssel
    - Gummimischung
    - Tankwart


    Das sind völlig unterschiedliche Bereiche die zu diesem Fehlerbild führen können. Ich verstehe nicht,
    wieso man diese nicht in eine Liste packen darf, nur weil es unterschieldliche Fachbereiche betrift?
    Ich würde mich freuen wenn Du Dein Sicht näher erläutern würdest, auch wenn Du es ja schon versucht hast.
    Und ganzbesonders darüber, wenn Du zeigst wie Du Dir vorstellst, das eine Fehler-Suche in einem VDR System systematisch erfolgen hat.

    Zitat von zochi

    Ich verstehe nicht,
    wieso man diese nicht in eine Liste packen darf, nur weil es unterschieldliche Fachbereiche betrift.


    Dürfen darfst du natürlich schon, aber das bringt nix weils einfach nicht zielführend ist.


    Ist so als wenn du vorher in Stadt A mit Auto X gewohnt hast und nun in Stadt B mit neunem Auto Y wohnst. Und dann ne Liste aufmachst warum Auto Y schlechter als Auto X ist:
    - Die Rotphasen der Ampeln sind länger
    - Es gibt wesendlich mehr Schlaglöcher
    - Die Hamburger schmecken schlechter seit ich mit Auto Y ins MCDrive fahre


    Du verstehst ;)




    Naja, das Problem ist das du explizit 1.7.18 davor schreibst und mit 1.6 vergleichst. Aber der VDR (dessen Versionsnummern du ausführst) hat mit den meisten der Punkte einfach nix damit zu tun.


    Du hast du e-tobi Packete für Squeeze, darum gehts. Wobei ich nix dabei fände oldstable Debian zu installieren und dann von e-tobi den 1.6er zu ziehen. Am 1.7er wird aktuell ständig dran rumgebastelt, und viele Probleme dürfen von den VDR Patches kommen.


    Alternativ kannst du auch bei Squeeze bleiben und dann die Probleme Schritt für Schritt lösen.



    Egal wie, jammern hilft eh nicht ;)



    Wobei vieles deiner Probleme überhaupt keine Probleme sind ;) Weil...


    >> 1.7.18: UTF-8 Kodierte Zeichensätze (de,en) müssen installiert sein, sonst seltsame Menue


    Ähm, ja. Und? Für den VDR ab 1.6 nimmt man eh den VDRSymbols Zeichensatz. Und vermutlich liefert den e-tobi eh mit
    http://andreas.vdr-developer.org/fonts/download.html
    Und deutsch utf-8 dürfte das System eh schon ab Installation sein. Und es gibt seit 15 Jahren keine nicht utf-8 kodierten Zeichensätze mehr ;)


    >> 1.7.18: Neues Format der channels.conf, ((in)kompatible zum 1.6?)(ohne HD: w_scan -fs -s S19E2 -o 7 >> channels.conf)
    Und? Warum Channelscan? Der VDR findet neue Kanäle selbsständig. Für den Start schaust du hier http://channelpedia.yavdr.com/html/



    Siehste? Gleich zwei der Probleme eleminiert ;)


    Zitat von zochi

    Aber ich ziehe eine sachliche Diskussion ohne Unterstellungen und persönliche Anmache vor.


    Was habe ich denn schlimmes gesagt?


    Zitat von zochi


    Und ganzbesonders darüber, wenn Du zeigst wie Du Dir vorstellst, das eine Fehler-Suche in einem VDR System systematisch erfolgen hat.


    Schritt für Schrtt an den richtigen Stellen.


    Z.B.
    >> 1.7.18: osdteletext plugin benutzt irrtümlich die Festplatte anstatt RAM-disk, was zu Klötzchen im Bild und Nicht-Abschalten der Platte führt


    Jup, also mal flugs in die Anleitung geschaut und unter /etc/vdr/plugins/plugin.osdteletext.conf (oder so ähnlich) nen Speicherort auf ner RAMDISK eingestellt.
    Da hat e-tobi wohl nen Fehler im osdteletex Packet. AFAIK hat sich da bei Squeeze was gändert, evtl. hat er das da einfach übersehen?


    Das einzige was wirklich problematisch ist sind deiner TV Kartentreiber/Kernelprobleme, da würde ich am ehesten einfach mal nen Kernel selberbauen und versuchen die Basis vernünftig lauffähig zu bekommen. Oder du nimmst einfach den Kernel den du bissher auch hattest auf dein neues System. Weil der lief ja offensichtlich.


    cu

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden