da Ubuntu das Update auf 12.04.3 freigegeben hat und nun xserver und Kernel auf gleichzug zu raring gesetzt hat würde es mich interessieren, ob es sich auf einem 12.04.2 und dem vdr-testing ppa nutzen läßt.
Ja, funktioniert, hab heute Abend einen VDR von einem Kollegen auf eine frische yaVDR 0.5a vom Hybrid-Stick aktualisiert, dessen 0.4 Installation vor Wochen dahin gesiecht war, unter Beibehaltung aller Aufnahmen. Die Installation habe ich ohne weitere Prüfung anschliessend sofort auf testing (VDR 2.0.2) gehoben und vorhin eben noch am Plasma abschliesend die Video-Erkennung via WFE und HDMI Sound geprüft.
Nur der Nvidia 304.88 wollte nicht mit der 3.8 Raring Kernel, daher bin ich beim 3.5er Quantal Kernel geblieben, kein Problem, es ist eine G210 verbaut.
Für neuere Karten, z.B. GK208, werden sich die meisten eh irgendwas 319.32 oder höher besorgen, die problemlos mit dem 3.8er Kernel laufen ...
Regards
fnu
D.h. der essential ist danach erstmal weg. Bei Dir auch? Bzw lies es sich wieder installieren?
Nein, es wurden wie erwartet nur die VDR Pakete aktualisiert, nichts deinstalliert. Preseed hatte schon fast alles von Ubuntu selbst bei der Installation abgearbeitet.
Der nvidia 304.88 läuft bei mir ohne nacharbeiten.
Ja, klar mit dem 3.5er Kernel kein Problem, hatte ich ja geschrieben.
könnte das yavdr-essetials mit fehlendem apt-pinning zu tun haben? so wie es mit yavdr-utils hier beschrieben wird:
[testing]Ton nach Wechsel von XBMC zu VDR weg
habe auch heute 0.5.0a frisch installiert und dann direkt auf testing gewechselt und keine probleme. ist ja auch 12.04.3
root@yavdr's password:
Welcome to Ubuntu 12.04.3 LTSkönnte das yavdr-essetials mit fehlendem apt-pinning zu tun haben?
Glaube ich nicht - das sind Abhängigkeitsprobleme: XBMC hängt z.B. von mesa-utils ab, das mit dem neuen Xorg-Stack entfernt wird, bei den anderen Paketen, die von yavdr-essential als abhängigkeit referenziert werden und zum entfernen vorgeschlagen wurden sieht es vermutlich ähnlich aus.
Ich fürchte mit 12.04.3 gibt es Probleme mit den Treibern für die TT-S2 6400, zumindest geht bei mir mit dem 3.8er Kernel die Karte nicht mehr. Mit 3.5 läuft noch alles wie gewünscht.
NACHTRAG:
media-build-experimental-dkms und linux-media-dkms bricht beim bauen der Treiber ab, siehe anhängendes make.log
HOWTO: Zotac GT630 Zone Edition in yaVDR 0.5 testing
#\> sudo untie-packages
Wäre die Lösung, aber auch danach werden Dich die Abhängigkeiten stressen, am besten nimmer anfassen. Ein falsches de-/installiert und er wirft wieder alles durcheinander und Du muß alles nomm'l installieren, recht eigenartig. Effektiv muß das drauf sein:
#/> sudo apt-get update
#/> sudo apt-get install xserver-xorg-lts-raring xorg
Kann ein Slalom werden, bis man das auch so installiert bekommt, war aber auch bei "xserver-xorg-lts-quantal" schon so.
Und mit dem 3.8er Kernel gibt es kein "ureadahead", d.h. die Kisten starten etwas länger ...
Regards
fnu
Das yavdr-essentials Paket zu beiden xorg-xserver passend zu haben ist vermutlich nicht möglich oder?
Ich denke das wäre schon möglich.
Gerald
gda,
aber vermutlich nicht für mich 
trotzdem mal genau darüber nachgedacht, sehe ich aktuell keinen Nutzen für einen produktiv Einsatz. Mein Haupt System lief auch mit 2.6.32 einwandfrei. Ich habe jetzt trotzdem den quantal Backport genommen und bleibe beim xorg-xserver vom 12.04.
Ich denke irgendwann einmal wird vermutlich eher ein grundsätzlicher Wechsel der Basis (auf 14.04 ?) sinnvoll. Der aktuelle stable ist schon eigentlich der beste den ich seit VDR Nutzung kenne. 
fnu,
danke für den Hinweis mit untie, aber das wird bestenfalls mal was für meinen Bastelserver sein, wenn danach das essentials paket weg ist, erwartet einen mit Sicherheit zukünftig dann ganz andere Probleme. Das ist mir im Wohnzimmer zu unsicher 
Das mit ureadahead ist mir auch aufgefallen. Bei einer SSD macht sich das aber schon deutlich bemerkbar, stellt also einen deutlichen Nachteil dar, denn es geht nichts über kurze Bootzeiten beim VDR. Der Bootvorgang dauert locker 10s länger.
Beim nachlesen bin ich auf preload gestoßen. Das hört sich doch auch sehr interessant an um die Systeme zu beschleunigen, insbesondere wenn man genug Arbeitsspeicher hat?
Und zum Testen könnte man sich ein eigenes bauen. Sourcen ziehen, die eine wichtige Datei anpassen, bauen, installieren...
Oder sind es zwei Dateien? Weiß ich gerade nicht aus dem Kopf, "git grep xorg" wird's dir erzählen. 
Lars
Ja, 14.04 ist vermutlich der nächste Kandidat für eine neue Basis. Die Zwischenreleases machen aktuell keinen Sinn mehr bei den kurzen Supportzeiträumen.
Lars.
Das mit ureadahead ist mir auch aufgefallen. Bei einer SSD macht sich das aber schon deutlich bemerkbar, stellt also einen deutlichen Nachteil dar, denn es geht nichts über kurze Bootzeiten beim VDR. Der Bootvorgang dauert locker 10s länger.
Ja, hier ist der Bug.
Bevor du alles wieder umstellst, teste doch mal das ureadahead Paket von hier.
Gerald
Habe ich mal schnell installiert und auch direkt noch preload dazu
Ja, aber ureadahead macht doch genau das, warum sollte man zwei verschieden Mechanismen installieren, die am Ende das Gleiche machen?
Ja, aber ureadahead macht doch genau das, warum sollte man zwei verschieden Mechanismen installieren, die am Ende das Gleiche machen?
Lt Ubuntuuser Wiki machen die nicht das gleiche.
Preload
ist ein adaptiver, vorauslesender Dämon. Er beobachtet Anwendungen die
ein Benutzer startet, sagt auf Grund einer Analyse dieser Daten vorher,
welche Anwendungen Benutzer starten werden und lädt diese Binärdateien
und deren Abhängigkeiten in den Speicher, damit sie schneller gestartet
werden. Die Geschwindigkeit des Systemstarts wird mit Preload nicht
beeinflusst.Da Preload Arbeitsspeicher benötigt, um den
Programmcode zu speichern, sollte das System auf alle Fälle mehr als 1
GB Arbeitsspeicher haben.Der Geschwindigkeitszuwachs kann bis zu
55 % betragen. Dies ist allerdings nicht gleich nach der Installation
feststellbar. Preload braucht ein paar Tage bzw. ein oder zwei Wochen,
bis eine verlässliche Statistik erstellt wurde. Diese Statistik nutzt
Preload, um den Code der entsprechenden Programme in den Speicher zu
laden....
Vergleich zu ureadahead
Ureadahead schreibt Dateien, die beim Systemstart gelesen werden, vor
deren Verwendung in den RAM. So können diese Dateien schneller gelesen
und so der Systemstart beschleunigt werden. Ureadahead unterscheidet
zwischen mechanischen Festplatten und SSDs. Bei mechanischen Festplatten
wird zuerst eine Liste aller benötigten Dateien erstellt und gemäß
ihrer physikalischen Position sortiert. Diese Dateien werden dann beim
nächsten Systemstart der Reihe nach gelesen. Dank der Sortierung läuft
der Lesevorgang fortan sequenziell ab, wodurch die Leseköpfe sich
weniger bewegen müssen und der Datendurchsatz erhöht wird. Ureadahead
und preload wirken kooperativ und behindern sich gegenseitig nicht. Sie
können problemlos miteinander eingesetzt werden.Lt Ubuntuuser Wiki machen die nicht das gleiche.
Ja und nein, danke das Du die Erklärungen rausgesucht hast.
An sich sollen sie das Gleiche bewirken, benötigte Dateien proaktiv schon im Memory zu haben. Sie wirken aber an unterschiedlichen Stellen und können daher nebeneinander existieren. "ureadahead" beim Bootvorgang, "preload" im laufenden Betrieb. Letzteres also eher gut für Desktops, weil es für einen schicken Read-Ahead basierend auf dem Nutzerverhalten sorgt. Weiß nicht ob das bei einem VDR wo quasi immer wieder das Gleiche geladen, benutzt wird einen Vorteil bringt ... berichte mal.
Regards
fnu
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!