Posts by torsten lang

  • Wer hat Erfahrungen mit dem AOpen i855GMEm-LFS?

    Hallo zusammen,
    ich habe vor einigen Wochen meinen Haupt-VDR auf Pentium M @1,7GHz mit dem AOpen i855GMEm-LFS umgestellt. Grund ist der, daß das vorher (aus der Not heraus) verwendete P4-System einfach zu viel Wärme fabriziert hat und nicht vernünftig zu kühlen war (gerade in einem kleinen HTPC-Gehäuse). Das alte System lief übrigens mit einem ASUS P4P800S-E Board und einem 2,8GHz P4.

    Ich habe beide Boards mal nackt bei gleicher RAM-Ausstattung gemessen, mein Leistungsmesser stand beim P4 System so bei 130-140W (BIOS) und beim Pentium M System so bei 30-40W. Mit einem passenden Netzteil sollte das beim Pentium M sogar noch ein wenig besser aussehen (das beim Messen verwendete Netzteil war für beide Boards das gleiche und daher für den Pentium M hoffnungslos überdimensioniert).

    Was die Rechenleistung angeht dürfte die verwendete CPU mit meinem vorherigen System gleichziehen.

    Soweit, so gut. Leider gibt es wohl ein Kompatibilitätsproblem mit der full featured Karte, daher würde mich interessieren, wer noch mit diesem Gespann Erfahrungen hat:

    Alle paar Minuten gibt's Aussetzer (Bild und Ton) im Live-Bild, auf der Karte laufende Aufnahmen sind dann an der gleichen Stelle korrupt. Aufnahmen auf der Zweitkarte (TT Budget) sind einwandfrei. Ich habe schon alles mögliche probiert (Treiber 1.0.1, 1.1.1, Firmware 261c und 261d, im Originalzustand oder gepatchte Version (für wahlweisen Betrieb mit auf 4MB RAM gemoddeten Karten), mit ACPI, ohne ACPI mit APIC, ohne APIC. Nur die Positionen der Karten kann ich nochmal durchtauschen (obwohl nach Abschalten des USB-Controllers kein Interrupt-Sharing mehr vorkommt).

    Noch ein paar weitere, wichtige Eckdaten: Es ist der Kernel von der c't-Distri 2.4.27-ctvdr-1 drauf, weiterhin die 1.3.23 er Experimental VDR Version mit passender Konfiguration (da die Patches z. T. Fehler verursacht hatten, z. B. der ShareLNB). Dasselbe System läuft übrigens noch auf einem HP Vectra Board mit 1GHz PIII, hier gibt's diese Probleme nicht. Daher unterstelle ich mal, daß es nicht am VDR oder den Treibern liegt.

    Wie gesagt, wenn jemand Erfahrungen mit diesem Board hat und diese Probleme nicht hat oder hat beseitigen können, wäre ich für einen weiteren Erfahrungsaustausch dankbar.

    Viele Grüße,
    Torsten

  • sharelnb legt epg lahm

    Quote

    Original von blueink
    Hi!

    Gut, dann ist alles klar.

    Ich verwende im Moment die Standartvariante, will aber dann doch die Features der gepatchten nicht missen :)

    Danke!

    blueink

    Wenn Du Dir zutraust, den VDR nebst allen benötigten Erweiterungen selbst zu compilieren: Ich bin mit meinem Zweikartensytsem auch über den Fehler gestolpert und habe vom Entwickler, Matthias Lötzke, vorab einen Patch für den ShareLNB-Patch erhalten:

    Alter Code (Auszug aus dem diff-File):

    Code
    -                                  if ((!Channel->Ca() || Channel->Ca() == Device->DeviceNumber() + 1 || Channel->Ca() >= 0x0100) && Device->ProvidesTransponder(Channel)) {
+
+//ML
+                                  if ((!Channel->Ca() || Channel->Ca() == Device->DeviceNumber() + 1 || Channel->Ca() >= 0x0100) && Device->ProvidesTransponder(Channel) && (!Device->GetBadDevice(Channel) == -1 && Setup.EPGScanTimeout && now - lastActivity > Setup.EPGScanTimeout * 3600) ) {
+//ML-Ende

    Neuer Code:

    Code
    if ((!Channel->Ca() || Channel->Ca() == Device->DeviceNumber() + 1
|| Channel->Ca() >= 0x0100) && Device->ProvidesTransponder(Channel)
&& (Device->GetMaxBadPriority(Channel) == 0
|| (Device->GetMaxBadPriority(Channel) == -1 && Setup.EPGScanTimeout
&& now - lastActivity > Setup.EPGScanTimeout * 3600)) )

    Ich bin momentan ganz froh, einen stabilen Arbeitsstand zu haben und habe leider auch keinen Urlaub mehr und daher chronisch zuwenig Zeit, daher mußte ich den Test des Patches leider erstmal zurückstellen, obwohl er für mich auch überaus interessant ist. Daher wäre es sicherlich sehr hilfreich, wenn es ein paar Freiwillige auf ihren Ein- und Mehrkartensystemen mal ausprobieren würden...

    Viele Grüße,
    Torsten

  • vdrdevel keine epg.data

    Bei mir (Zwei-Karten-System) hebelt der im vdrdevel enthaltene ShareLNB-Patch den EPG-Scan aus. Ich habe den vdrdevel nun selber compiliert ohne den Patch - damit geht's jetzt! Ansonsten waren nämlich nur Daten für Kanäle im epg, die ich auch eingestellt (sprich angesehen) hatte.

    Weiterhin speichert der VDR die EPG-Daten beim Beenden nicht - dafür habe ich im Portal einen Patch gefunden (http://www.vdrportal.de/board/thread.php?threadid=24818&sid=).

    Viele Grüße,
    Torsten

  • EPG Scan erzwingen

    Quote

    Original von clocker
    Dass VDR beim Beenden das EPG vergisst, ist normal. Es wird nur alle paar Minuten gespeichert, nicht jedoch beim Beenden. Mir gefiel das nicht, da habe ich in der vdr.c über

    Code
    cRecordControls::Shutdown();
  cCutter::Stop();

    folgende Zeile ergänzt:

    Code
    cSchedules::Cleanup();

    Ist meines Erachtens nach ein Bug.

    Ich hab's an anderer Stelle als

    Code
    cSchedules::Cleanup(true);

    gesehen und bei mir auch so eingebaut. So wie ich die Sourcen verstehe erzwingt das die Aktion.

    Noch was: Nachdem ich jetzt tagelang dem Problem hinterherjage, daß der EPG-Scan bei mir einfach gar nicht funzt, habe ich die Ursache zumindest etwas eingrenzen können: Schuld ist bei mir der ShareLNB-Patch, obwohl ich im Setup jeder Karte einen eigenen LNB zugewiesen habe. Während auf einem Mehrkarten-System der Scanner normalerweise im Hintergrund arbeitet und die erstbeste freie Karte zum Scannen nutzt, wird dieses Verhalten durch den Patch ausgehebelt. Ich habe daher bei mir den Patch deaktivieren müssen, was insofern schade ist, als daß ich ihn durchaus gebrauchen könnte (zuwenige Leitungen ;) ).

    Langer Rede kurzer Sinn: Ohne ShareLNB funzt der EPG-Scan bei mir wieder!!!

    Viele Grüße,
    Torsten

  • EPG Scan erzwingen

    Quote

    Original von anonymous

    Eine der aktuellen VDR Versionen hat einen EPG Scanner inside [RED = SCAN] im EPG Menu, hab es aber selbst noch nicht probiert, nur gesehen.

    MFG Ronny

    Bin z. Z. mit der 1.3.22 am Testen und es so langsam leid... Ich habe ein Zweikarten-System, per se sollte es also keine EPG-Probleme geben. Fakt ist aber, daß der VDR einfach nicht scannt (hab' die Scan-Zeit auf 1h stehen, wobei bei mehreren Karten wohl nur wichtig ist, daß der Wert >0 ist) bzw. nur den auf der FF-Karte gerade eingestellten Transponder. Das manuelle Anstoßen (ist in dieser Version drin) funktioniert nach meinen Recherchen nur bei Einkarten-Systemen. Bei Mehrkarten-Systemen sollte der VDR eigentlich im Hintergrund die EPG-Daten sammeln, wenn die andere(n) Karte(n) nicht belegt sind.

    Diese Probleme waren beim 1.2.6er jedenfalls ausgemerzt und ich bin ziemlich angenervt, sie nun im 1.3er wiederzufinden (habe schon einen Haufen Aufnahmen dadurch verloren).

    Gruß,
    Torsten

  • Prosieben HD

    Quote

    Original von MR42HH
    iMovie HD nimmt's leider nicht, aber ProjectX. Ist aber fast unbenutzbar langsam.


    Hmmm - kann ich nicht bestätigen. Ich verwende die neueste Version. Auf meinem G5 muß ich mit zwei Platten für Quelle und Ziel arbeiten, damit die Platten das Demuxen nicht ausbremsen (ca. 50MB/s). Aber: Übers Netzwerk ist ProjectX tatsächlich sehr langsam, und bei manchen MPGs auch. Bei den VDR-TSen rennt er aber...

    Gruß,
    Torsten

  • FF+Budget => keine Aufnahme

    Quote

    Original von HomerJ
    Mir fällt gerade ein, dass es bei mir wohl kein ct-spezifisches Problem ist, denn unter linvdr ging die Aufnahme mit der Budger-Karte installert ebenfalls nicht.

    Die Budgetkarte habe ich dann sicherheitshalber mal in einem anderen PC unter Windows getestet, aber sie geht.

    Sehr schade, wollte eigentlich gerne eine zweite Karte drin haben :(

    Meines Erachtens liegt das an den Treibern. Ich habe hier eine alte Nova-CI als Zweitkarte und eine TT 1.5 FF. Mit den alten 1.0.1 Treiber läuft die ganze Geschichte, mit den aktuellen LinuxTV-Treibern kracht's beim Aufnehmen. Ich hatte dieses Problem schon mit zwei grundverschiedenen Mainboards (da ich vom P4-Brateisen auf einen P3 downgegradet habe) nachvollziehen können. Beim aktuellen System (P3) sehe ich beim Laden der Treiber für die Budget eine Meldung "gpio irq unknown type=0 len=0". Kann es sein, daß der neue Treiber den Tuner nicht korrekt ansteuert???

    Mit einer neuen TT Budget gibt's leider mit beiden Treibern Probleme. Dort kommt es beim ersten Laden nach einem Kaltstart zu einem Interrupt Lockup (die Meldungen huschen nur kurz übern Schirm und sind auch nirgendwo gelogt). Lasse ich erstmal szap auf die Karte los, entlade die Treiber und lade sie neu, dann ggf. nochmal szap, dann startet die Geschichte 100%ig.

    Gruß,
    Torsten

  • S-Video und Composite gleichzeitig?

    Quote

    Original von randy
    mit vidmode=2 tut das, da das alles getrennte leitungen sind.

    aber fbas & rgb z.b. tut ned gleichzeitig.

    -- randy

    Hallo,
    also vidmode=2 taugt definitiv nicht für die Y/C-Ausgabe, wenn einzig eine Scart-Buchse montiert wird. Bei konformen Geräten wird im Y/C-Modus nämlich Composite (FBAS) ersetzt durch das Y-Signal (Luma), auf Rot liegt dann Chroma. Bei vidmode=2 ist ein Scart-Stecker dann nicht mehr normgemäß belegbar - Scart sieht nämlich nicht vor, FBAS und Y/C gleichzeitig zu verwenden. Für die diversen Scart-Lösungen sollte also vidmode=3 die richtige Variante sein. Zu sehen ist das ganz leicht, weil im Y/C-Modus der Filter auf dem C-Eingang wegfällt und daher bei einem FBAS-Signal am Y-Eingang des Monitors/Verstärkers heftigste Perlschnur-Effekte auftreten (einfach mal eine Aufzeichnung abspielen und den Navigationsbalken einblenden). Für die diversen aufwendigen Erweiterungsplatinen, die die Signale aufbereiten und dann auf Hosidenstecker, Scartstecker etc. verteilen, gilt diese Aussage so nicht. Hier kommt's auf die Platine im einzelnen an, was denn nun richtig ist.

    Im Zweifelsfalle hilft einfach ausprobieren - aber wie gesagt, bei meiner aktuellen Scart-Billigst-Notlösung war vidmode=3 mein Freund...

    Viele Grüße,
    Torsten

  • Dign 3HE + Lüfterlose CPU Kühler NCU2000

    Quote

    Original von Marinero
    armageddon

    ...


    Nein, derzeit nicht. Das Gehäuse hat hinten Platz für zwei 60 mm Lüfter - zu laut. Ich würde ja gern einen 120 mm Quirl einbauen, aber dann wären wohl Löcher im Gehäusedeckel notwendig, um auch ordentlich Luft fördern zu können X(

    Wirklich zu laut? Ich habe mich mal nach leisen Lüftern umgesehen und bin bei Sunon KDE1206PTB3-OC gelandet. Kugelgelagert und angegeben mit 22dbA. Weiterhin betreibe ich die Teile mit 7V (12V + 5V als Masse), was mit der OC-Version (niedrigere Anlaufspannung) geht - damit sind sie schon sehr leise.

    Allerdings ist der Volumenstrom deutlich geringer als bei anderen Lüftern. Lohnt aber sicher einen Test.

    Viele Grüße,
    Torsten

  • VDR fährt 1x neu hoch, dann ist alles ok.

    Hallo Matthias,
    ich habe das Problem hier auch mit einem neu geschraubten VDR. Das Teil hat zwei Budget-Karten, eine von Hauppauge (Nova-CI, ein Jahr alt) und eine TechnoTrend (futschneu). Die Technotrend fabriziert bei fast jedem Kaltstart diesen Fehler. Es gab schon verschiedene Gerüchte wg. IRQ-Sharing etc. - ich kann nur sagen: Hab' rangiert, beide Karten haben jetzt eigene IRQs ohne Sharing - nutzt nix!

    Reboot ist übrigens nicht notwendig, es reicht, die Treiber zu entladen und neu zu laden. Ich vermute daher mal, daß der neueren Karte irgendwas an der Initialisierung durch den DVB-Treiber nicht schmeckt. Mein (plumper) Workaround im runvdr-Skript:

    Also: Laden - zappen - entladen und nochmal zappen, dann weiter wie gehabt - bei mir im Skript für zwei Karten, wie man sieht. Ich hab' nur den Zweig für die alten Treiber aktualisiert. Scheint bei mir zuverlässig zu gehen. Ob der ganze Zirkus mit der Zapperei erforderlich ist, weiß ich nicht, aber abkacken tut der VDR beim ersten Zugriff aufs frontend - also greif' ich halt mal drauf zu.

    Gib' doch mal Bescheid, ob's hilft...

    Viele Grüße,
    Torsten


    ...

  • Asus P4P800 VM und NVRAM-Wakeup

    Hallo Peter,
    ich habe hier gerade einen neuen VDR zusammengebaut - mit einem ASUS P4P800S-E (Notlösung, weil mein anderes Board - Athlon mit VIA-Chipsatz - massive PCI-Problme hat). Mit nvram-wakeup ist dem Board nicht beizukommen, weil nvram-wakeup zwar die Daten lernen und auch speichern kann, der Wakeup für die Uhr beim Shutdown nicht aktiviert wird. Sprich: nvram-wakeup konfiguriert alles richtig, das Board wacht aber nicht auf.

    Ich habe aber gerade einen heißen Tip bekommen, daß es von e-Tobi eine erste Version eines ACPI-basierten Plugins gibt (vdr-addon-acpiwakeup), die, wie der Name schon sagt, die Einstellungen via ACPI setzt. Bei meinem Board scheint das zu funktionieren, ich muß aber noch ausführlicher testen ;D

    Viele Grüße,
    Torsten

    Quote

    Original von Oestreich
    Hallo an alle,

    ich habe NVRAM installiert und nach Hubertus Anleitung die Dateien erstellt (Einschaltzeiten vom Bios). Danach habe ich die Werte mit guess in die nvram-wakeup.conf schreiben lassen.
    Nach einem Aufruf von nvram-wakeup --debug erscheint folgendes:

    Code
    ...

    Was bedeutet die vorletzte Zeile (addr_stat)???
    Irgendwie funktioniert jier was nicht oder es fehlt ihm was!? Was ist hier falsch???

    Viele Grüße
    Peter

    ;D ;D

  • wie installiere ich die cvs treiber für die dxr3 karte in den c't-vdr ???

    Quote

    Original von cyberthom
    OK, vielen Dank für die Antworten...
    Also wird das make config dazu gebraucht um überhaupt erst einmal eine config datei in den kernel sourcen abzulegen. Dabei ist es dann auch egal, ob man dabei andere Einstellungen benutzt als in dem aktuellen kompilierten Kernel. Das hatte mich halt nur etwas verwirrt. Ich dachte, diese Config muss genau dieser entsprechen, mit der der Kernel kompiliert wurde.
    ...


    Moin moin,
    Kai und ich haben das in 'ner längeren Nachtsitzung ausgeknobelt. Prinzipiell muß der Kernel-Source schon so konfiguriert sein, daß es der Binary-Version entspricht. Genau das scheint bei den c't-Sourcen aber nicht der Fall zu sein. Nach meinem Dafürhalten entspricht die Konfiguration der Kernel-Sourcen des 2.4.24-ctvdr-2 Kernels in der Debian Source-Package nicht dem Kernel im Binary-Paket. Wenn die I2C Funktionalität tatsächlich fehlen würde, dürfte sich der fertig compilierte EM8300-Treiber nicht laden lassen (fehlende Einsprungpunkte im Kernel bzw. anderen Modulen).

    Genau deswegen wird der make config Lauf benötigt. Anonsten stehen die entsprechenden Funktionen beim Compilieren des EM8300 Moduls einfach nicht zur Verfügung. Wichtig ist halt, so nahe wie möglich an der Konfiguration des Binaries zu bleiben.

    Viele Grüße,
    Torsten