Beiträge von HTPC-Schrauber

So nebenbei: Es ist ein Irrtum, das der Athlon XP stromsparender ist als der Athlon 64. Mit aktiviertem C&Q braucht der A64 nur bei voller Auslastung mehr. Wenn man ihn auf die Leistung des Athlon XP drosselt, dann braucht er generell weniger.

Ja, wenn die Dose nichts zu tun hat. Aber Du hast doch den VDR laufen.

Unabhängig davon, ein Last-Wert um 2 Prozent ist doch nichts. Also an hoher Auslastung wirds sicher nicht liegen.

Hast Du die Hardware irgendwie verändert? Neues Netzteil oder so?

Nein, bitte kein Asrock. Ich hatte mal zwei davon. Das hat mir für alle Zeiten gereicht.

Für empehlenswert halte ich Gigabyte (hab selber ein). Richtig gerne nehm ich Epox, aber die sind nicht so billig und inzwischen komischerweise schwer zu kriegen.

Wie hoch ist 2 HE?

Mit nem Standardkühler wird wahrscheinlich nichts, wenn Du keine ausreichende Höhe hast.

Aber warum überhaupt?
Ich hab in meiner Windose einen Arctic Cooling auf nem Athlon 64 3200+ (kein EE). Den Lüfter hab ich zusätzlich sehr weich entkoppelt. Das Ding ist im Normalbetrieb nicht zu hören. Die Festplatte ist lauter als der Lüfter.

Ich denke, es wird wohl eine Satelco bei mir werden.
Aber sicher bin ich noch nicht.

Irgendwo hatte ich mal gelesen, das es wohl auch von der Satelco ne neue Version gibt, die nicht richtig läuft. Aber ich finds nicht mehr wieder.

Ich hab aber eh noch ein bißchen Zeit. Im aktuellen VDR hab ich eh ne alte C-1500 drin. Die neue soll in den großen HTPC. Der hat jetzt noch ne FloppyDTV, mit der ich eigentlich höchst zufrieden bin. Aber sie läuft eben nicht unter Linux. Und mit Windows fang ich auf dem Teil nicht nochmal an. Das war nervtötend genug.

Jedenfalls werd ich noch ne Weile abwarten und dann zuschlagen. Und wenns nicht läuft, dann muss ich sie halt zurück schicken.

Nach viel forschen und probieren bin ich einen Schritt weiter:
Die Denkpause kommt offenbar vom CAM. Jedenfalls passiert das nur bei verschlüsselten Sendern. Bei unverschlüsselten ist das Bild sofort da. Mir ist das bisher nur nicht aufgefallen, weil bei uns eh fast alles verschlüsselt ist.

Kann man da was dagegen machen?
Ich kann mich nicht erinnern, das das z.B. unter Kaffeine oder MythTV so lange gedauert hat.

Welchen Load-Wert meinst Du? User, System oder Nice?

Ich habs gefunden. Ganz blöder Fehler.

Und zwar:
In meinem Kernel sind Treiber für die serielle Schnittstelle einkompiliert (kein Modul). Deswegen muss ich sie mit setterm deaktivieren, bevor ich das Lirc-Modul lade. Nun den setterm hatte ich in der rc.local.
Leider wird die rc.local erst ausgeführt, wenn das Netzwerk komplett oben ist. Deswegen ging Lirc immer nicht, wenn er vorm Netzwerk starten sollte.

Ich hab das jetzt geändert und jetzt hauts auch wunderbar hin. VDR startet jetzt direkt nach syslog-ng und lircd. Früher gehts glaub nicht.

Ach so, noch just for Info: Ich hab kein EasyVDR mehr. Ich setzen inzwischen Archlinux ein.

Was die 10 Sekunden angeht, da hast Du mich falsch verstanden. Der Senderwechsel an sich dauert bei mir unter einer Sekunde. Hin und wieder kommt es mal vor, das danach asynchron ist. Ich hab aber nochmal drauf geachtet. Spätestens wenn das OSD wieder verschwindet ist es auch wieder synchron. Von daher find ich das nicht so schlimm. Und, wie gesagt, ist nur manchmal.

Die Artefakte beim Umschalten kommen vom Hardware-Decoder. Deswegen hab ich das bei mir inzwischen ohne Hardware-Decoder laufen. Dann hab ich keine Artefakte und das Umschalten geht schneller.
Ist auch von der CPU-Last nicht so wild. Ich war erstaunt.
Mit Hardware-Decoder hatte ich um die 30 % CPU-Last. Ohne den Hardware-Decoder komm ich inzwischen so auf runde 45 %. Manchmal weniger. Mehr eigentlich nicht. Kommt auf den Bildinhalt an. Ich hab nochmal die ganzen beteiligten Treiber und Libs neu umgewandelt mit optimierten Einstellungen für Pentium3 und mit SSE. Das brachte mich dann auch diese Werte. Ich finds eigentlich OK so.

Was mich übrigens wundert:
Der Hardware-Decoder scheint unter X viel besser zu funktionieren. Ich hatte da mal nen VDR mit xineliboutput aufgesetzt mit XvMC. Da dümpelte der Rechner nur noch bei unter 10 % CPU-Last rum.
Leider gibts ja auch unter X keine Field-Parity. Das kann nur DirectFB mit den richtigen Treibern.
Und deinterlacen will ich nicht. Das kann unser LCD wesentlich besser.

Wann 24 Bit Farbe in Softdevice kommen soll, keine Ahnung. Aber ich werd das verfolgen. Mal ins aktuelle CVS schauen. Ich hab im Moment die 0.0.4 im Einsatz. Aber CVS ist ja da schon weiter.

EDIT: Hab grad nochmal im Softdevice CVS nachgelesen. Also es sind immer noch nur 15/16 Bit möglich.
Aktuell seh ich nur xineliboutput, um zu mehr Farbtiefe zu kommen. Hast Du das schonmal ausprobiert? Xineliboutput klingt eh irgendwie vielversprechend. Ich hab bei Softdevice noch das Problem, das ich ihn nicht dazu kriege, das Bild so auszugeben, wie es ist. Er macht immer ne 4:3 bzw. 16:9 Skalierung. Mein TV kann aber 4:3 mittels SuperZoom auf 16:9 aufblasen. Den Modus kann ich mit Softdevice gar nicht richtig nutzen. Entweder 16:9 stimmt nicht oder 4:3 geht nur ohne SuperZoom. Xineliboutput hat eine Einstellung, wo immer das Bild einfach ausgegeben wird, wie es ist. Damit könnte man die Funktionen vom TV nutzen. Muss ich mir bei Gelegenheit mal anschauen.

Bei mir auch nicht.
Was hattest Du für eine Sync-Variante? Ich hatte mit sik manchmal Probleme. Jetzt hab ich usleep drin. Manchmal ist es für ein paar Sekunden nach dem Senderwechsel nicht syncron. Aber spätestens nach 10 Sekunden stimmt alles.

Ich hab grad noch gefunden, woher die Farbabstufungen kommen. Und zwar im Softdevice-Plugin. Bei den TODOs steht drin, das es zur Zeit nur 15/16 Bit Farbe kann. Daher kommt das. Volle Farbauflösung wäre 24 Bit.

Also ich hab den cle266 nicht mit einkompiliert. Wenn ich mit dfb:cle266:viatv kompiliere, dann funzt es trotzdem mit Beschleunigung.

Was hast Du in Deiner directfbrc drin?
Ich hab da sogar das disable-module=cle266 drin.

Ich würd kein Sockel 754 mehr aufbauen.

Ich würde zu einem AM2 greifen. Board z.B. mit nVidia 6100 Chipsatz. Der hat Grafik drin und die Boards selbst sind recht sparsam.
Dazu einen SingleCore Athlon 64. Da Du ja sagst, das die Leistung nicht so ausschlaggebend ist. Den kann man dann noch undervolten. Wobei das etwas Glückspiel ist. Alternativ eine EE-Version, da ist garantiert, das er mit geringerer VCore läuft. Kleinster EE ist glaube der 3500+.
Verglichen mit Deinem alten Athlon ist der ja immer noch hyperschnell. Deswegen kann man gleich noch den Multi beim Booten reduzieren und die Core-Spannung noch weiter senken. Z.B. mit 1 GHz und VCore 1,0 Volt (sollte mit nem EE kein Problem sein). Mit nem dicken Kühlkörper geht der dann auch recht problemlos passiv.

Die Mobile-CPUs sind reizvoll. Ich würds aber trotzdem nicht machen. Meines Wissens haben die keinen HeatSpreader drauf und sind deswegen flacher als die normalen. Demensprechend geht da auch nicht jeder Kühlkörper. Und so sehr viel sparen kann man glaub gegenüber nem EE dann auch nicht mehr.

Ich hab gestern nochmal getestet. Ich kann jetzt auch Loopback und WLAN getrennt starten. Lustigerweise scheint sich Lirc am WLAN festzukrallen. Wenn ich das WLAN nicht vor Lirc starte, dann meint Lirc, er hat keinen Zugriff auf /dev/lirc0. Starte ich das WLAN vor Lirc, klappt alles.
Das soll einer verstehen ...

Jo, den Spruch hatte ich auch irgendwo mal gesehen. Genial.

tr500: Ich hab auch fast alles selber gebaut. Aber den DirectFB aus Bequemlichkeit nicht. Naja, jetzt hab ich es. Aber wie ich an Deinem Beispiel sehe, kann ich da noch einiges abschalten.
Der cle266 Grafiktreiber und Unichrome zusammen ist aber eigentlich auch noch zu viel. Normal sollte einer von beiden tun. Wobei mir noch nicht klar ist, warum es überhaupt zwei gibt. Von den Features her sind sie nahezu gleich. Und der unichrome läuft auch auf nem CLE266. Komisch das ...

Nicht, das ich wüßte. Außer halt hinterher löschen.

Setz mal noch CPPFLAGS = CXXFLAGS.
Manchmal hilfts.

Hmm, muss ich mal ausprobieren. Stimmt, VIA hatte ja kürzlich neue Treiber released.

Composite und RGB liegen gleichzeitig an. Das ist richtig.
Nur Composite und S-Video gleichzeitig ist unmöglich, weil dieselben Leitungen dabei benutzt werden.

Ich fürchte allerdings, das eines nicht gehen wird:
DirectFB macht in Verbindung mit deren viafb Treiber ne nette Geschichte: Und zwar synchronisiert es die Ausgabe der Halbbilder. Deswegen gibts da auch ohne Deinterlacer keine Kammartefakte und dergleichen. Ich fürchte fast, das das mit dem VIA-Treiber nicht mehr klappen wird. Aber das wird sich zeigen.

Wie sieht die CPU-Last aus? Geringer?

Ich hab übrigens gestern noch etwas experimentiert. Die Denkpause nach dem VDR-Start bis ein TV-Bild kommt, hab ich mehr als halbieren können. Bisher warens bei mir ja so 10 Sekunden. Manchmal mehr. Jetzt kommt das TV-Bild noch bevor das OSD verschwindet. Also innerhalb der ersten 5 Sekunden.
Das lag anscheinend an DirectFB. Ich hatte das DirectFB-Paket von Archlinux übernommen. Jetzt hab ich mal selber kompiliert. Dabei kam ich dann drauf, das DirectFB im Originalpaket statisch gelinkt wird. Mir fällt zwar nicht ein warum. Aber gut. Ich habs jetzt dynamisch. Außerdem hab ich sämtliche unbenötigte Funktionen raus genommen. Also z.B. die X11-Unterstützung. Brauch ich ja nicht. Und noch einiges andere. Nur die Grafiktreiber sind momentan noch komplett drin. Aber da werd ich auch nochmal dran gehen. Vielleicht läßt sich ja noch die ein oder andere Sekunde rausschinden.

Öhm, keine Ahnung. Remote Plugin hab ich noch gar nicht ausprobiert.

Ich hab einen Atric Empfänger. Geht der damit?

Hi,

ich bin gerade an den letzten Optimierungen meines Digitainers.
Soweit läuft alles gut. Nun sollte der Startvorgang noch etwas beschleunigt werden. Deshalb wollte ich den VDR so früh wie möglich starten.
Da ich ne Fernbedienung brauche, muss vorher LIRCD laufen.
Soweit so gut.
Aber als ich die Startreihenfolge so einstellte, das LIRCD und VDR vor NETWORK gestartet werden, meldet Lirc immer 'Could not get file information for /dev/lirc0'.
Starte ich NETWORK vor Lirc gehts.

Braucht Lirc das Loopback device?

Das wird nämlich im NETWORK-Script erst gestartet. Dumm daran ist, das außerdem das WLAN gestartet wird. Und das dauert recht lang. Ich wollte das eigentlich erst nach VDR haben.

Wenn das so ist, dann müßte ich die Startscripte von Archlinux auseinander nehmen.

Oder kann man irgendwie Lirc erst nach VDR starten? Jetzt bekommt dann nämlich VDR nichts mehr von Lirc mit.

Grüße

Die Frage ist, läuft es auch stabil?
Bisher hab ich da nichts gutes vom VIA-Treiber gehört.

Also grundsätzlich liegen die besagten Abstufungen eigentlich in den TV-Standards begründet. Es ist da so, das die Helligkeitsinformationen mit voller Bandbreite übertragen werden und die Farbinformationen nur mit halber Bandbreite. Deswegen können Farbverläufe so aussehen. Besonders gut sichtbar in dunklen Bildbereichen. Mir fällt das teilweise auch bei DVD-Playern auf. Beim PC wird das Problem noch durch dessen Besonderheiten verstärkt. Und zwar arbeitet ein PC üblicherweise im RGB-Farbraum, statt in YV12 oder YUY2. Fernsehstandard ist übrigens YV12. Die Genauigkeit ist bei YV12 die gleiche wie bei YUY2. Allerdings ist der interne Aufbau anders.
Aber zurück zum Problem: Das Video ist also YV12 codiert. Der PC wandelt es nun nach RGB. RGB hat zwar eine höhere Genauigkeit als YV12, allerdings passen die Farbräume nicht genau zusammen. D.h. man hat Verluste. Und weils so schön war, wir das Bild für die Ausgabe dann gleich nochmal zurück nach YUY2 oder YV12 gewandelt, was nochmal Verluste mit sich bringt. Dann werden die Abstufungen wirklich sichtbar. Leider.
Im Videoschnittbereich ist es möglich, völlig ohne Konvertierungen zu arbeiten. Die Software ist darauf ausgelegt. Windows kann das seit VMR9 auch bei der Videoausgabe.
Bei DirectFB und Softdevice sind mir die Konvertierungsschritte noch nicht ganz klar. Aber mindestens DirectFB konvertiert nach RGB. Leider kann man da auch nicht wählen. Es lässt ja beim Unichrome nur AiRGB zu.
D.h. das ist wahrscheinlich etwas, womit wir einfach leben müssen. Jedenfalls fällt mir nicht ein, was man dagegen machen könnte, außer die Treiber umzuschreiben.