Posts by torsten lang

    Hallo zusammen,
    ich habe hier eine originale aufklappbare Activy 300 Fernbedienung mit Tastatur und ein kompatibles Modell (Q-Sonic, mit deutscher Tastatur) von Pearl. Ich habe gesehen, daß es für Lirc entsprechende Konfigurationsdateien gibt (http://lirc.sourceforge.net/remotes/fujitsu_siemens/KWR3020), allerdings habe ich bereits ein AV-Board mit IR-Empfänger und kein Interesse, jetzt noch zusätzliche IR-Empfänger und parallel eine zweite IR-Lösung (LIRC) zu installieren.

    Weiß jemand, ob es prinzipiell möglich ist, die FB vollständig über den IR-Empfänger einer Technotrend Budget oder Full Featured Karte zu nutzen?

    Was momentan gehen würde ist die Nutzung der Multimedia-Tasten, evtest liefert da entsprechende Events, bei Benutzung der QWERTZ/Y Tastatur passiert aber rein gar nichts.

    Viele Grüße,
    Torsten

    Moin Oliver,
    ich werd's nochmal ausprobieren, allerdings habe ich (ein wenig voreilig) schon "aufgeräumt". Ich denke, ich nutze die Gelegenheit dann tatsächlich mal, um das gesamte System zu aktualisieren. Dann kann ich nämlich wenigstens "schmerzfrei" an dem System experimentieren.

    Beim letzten Update hatte ich einfach keine Not mehr, noch großartig Kernel und Module oder VDR selbst zu compilieren, daher habe ich die Sourcen auch nicht auf der Platte und habe die betreffenden Versionen auch nicht mehr bei Debian gefunden. Das hat mir bei den Tests in den letzten Tagen ein paar Kopfschmerzen bereitet.

    Langer Rede kurzer Sinn: Ich werde das im Laufe der kommenden Woche nochmal testen, wenn ich das System mal wieder auf einem aktuellen Stand habe.

    Interessant wären jetzt natürlich mal ein paar weitere Rückmeldungen von anderen Usern...

    Viele Grüße,
    Torsten

    Hallo Oliver,
    grundsätzlich funktioniert das - ganz großes Lob! Ich habe jetzt einfach wieder mit meinem alten Kernel 2.6.29 getestet. Beim Live-Bild (Olympia) mit DD-Ton habe ich noch sporadische Aussetzer im Ton. Ich werde mir das noch etwas genauer anschauen - dazu muß ich aber die beiden VDRs mal komplett durchtauschen, da mein Receiver leider nur für einen der Beiden noch 'nen Digitaleingang über hat.

    Nur mal aus Neugier: Du schaust Dir dann in der Firmware den Audio-Datenstrom an, um zu bestimmen, ob der Datenstrom korrigiert werden muß oder nicht? Weil: Hilfe vom Treiber bzw. VDR bekommt die Firmware ja jetzt nicht mehr.

    Für mich ist die Lösung in der Firmware insofern sehr angenehm, weil ich erstmal kein umfangreiches Update machen muß.

    Viele Grüße,
    Torsten

    Moin Oliver,
    da ich erstmal an mir selbst zweifele, habe ich alles gaaanz sauber neu übersetzt und eingespielt. Keine Änderung.

    Auffällig ist, daß bei der Wiedergabe einfach die letzte vom Live-Bild her gesetzte Einstellung für den SpdifSwitch bestehen bleibt, sprich hatte ich im Live-Bild Dolby-Wiedergabe, funktionieren die Dolby-Tracks beim Abspielen, hatte ich einen PCM-Track, dann funktionieren nur die bei der Wiedergabe.

    Ich habe als allererstes mal das Debugging des av7110 Moduls eingeschaltet. Was ich sehe ist folgendes:
    Wenn ich im Live-Bild zwischen PCM und Dolby Tracks wechsele, erhalte ich die folgenden Einträge im Log:

    Beim Abspielen von Aufnahmen kommt nur so etwas:

    Code
    Feb 26 21:48:27 tuxbox2 kernel: [ 1680.356080] dvb-ttpci: dvb_audio_ioctl(): av7110:f65cc000, cmd=40086f0e

    Die cmd=6f08 müßte, wenn ich den Aufbau der ioctls richtig interpretiere AUDIO_SET_BYPASS_MODE sein, während cmd=40086f0e AUDIO_SET_MIXER ist.

    Ich habe mal versucht, die Aufrufe der IOCTLs im VDR ein wenig nachzuvollziehen. Wenn ich das anhand des VDR 1.6, auch wenn der nicht mehr aktuell ist, nachvollziehe, dann wird der Aufruf hier ausgelöst:

    device.c

    dvbdevice.c

    Code
    void cDvbDevice::SetDigitalAudioDevice(bool On)
    {
      if (digitalAudio != On) { 
         if (digitalAudio)
            cCondWait::SleepMs(1000); // Wait until any leftover digital data has been flushed
         digitalAudio = On;
         SetVolumeDevice(On || IsMute() ? 0 : CurrentVolume());
         }
    }

    Meines Erachtens liegt hier der Hund begraben. Es wird nur der Mixer, nicht aber der Audio Bypass angesprochen. Mag sein, daß das bei den aktuellen VDRs behoben ist.

    Ehe ich allerdings hier ans Experimentieren gehe, muß ich wohl doch erstmal ein Upgrade durchziehen. Das wird allerdings nicht von jetzt auf gleich gehen...

    Viele Grüße,
    Torsten

    Moin Oliver,
    also, ein erster kurzer Test hat ergeben, daß es tatsächlich klappt - der Verstärker bleibt bei PCM stumm und wird bei AC3 aktiv!

    Danach habe ich mir mal den IOCTL angeschaut. Quick und dirty habe ich daraufhin mal eine dynamische Umschaltung nachgerüstet, das sieht dann so aus:

    Für die Live-Wiedergabe funktioniert das auch. Aber nicht bei Aufnahmen. Wird hier die Audiospur anderweitig umgeschaltet?

    Viele Grüße,
    Torsten

    Moin Han,
    da bei mir auch in nächster Zeit der Umstieg auf HDTV bei meinem Selbstbau-VDR ansteht, habe ich mir al die Alternativen angeschaut und jetzt auch Deine Anleitung entdeckt.

    Zum Kapitel über smb ein Hinweis:

    cifs ist nicht einfach eine neue Version von smbfs, sondern eine Neuentwicklung. Übergangsweise waren beide in den Kernels verfügbar (auf der Samba Homepage gibt's zum neuen CIFS-Client 'ne ausführliche Info: http://fi.samba.org/samba/ftp/cifs…lient-guide.pdf).

    Was mich persönlich an dem neuen Client nervt ist, daß es keine Möglichkeit mehr gibt, die Codepage vorzugeben. Angeblich soll die automatisch erkannt werden, das klappt aber nicht!

    Da mein Server durchgängig UTF8 verwendet, die VDRs aber z. T. noch ISO8859-1, ist diese Option für die Anpassung der Zeichensätze erforderlich. Daher benutze ich bis auf Weiteres noch das smbfs.

    Ansonsten: Gute Arbeit - mal schauen, wann ich selbst mal einen HDTV-VDR in Angriff nehmen kann...

    Viele Grüße,
    Torsten

    Quote

    Original von UFO
    Derzeit wird der SpdifSwitch für eine Rev 2.3-Karte bei der Initialisierung des Treibers aktiviert.
    Ich vermute, daß dies falsch ist und er nur bei DD-Ton aktiviert werden sollte.
    Könnte man im AUDIO_SET_BYPASS_MODE-Ioctl machen (wird von VDR aufgerufen).


    Bist Du ganz sicher, daß es so rum sein müßte? Das hieße ja, im Moment wäre es bei DD richtig und bei PCM falsch. Wenn der SpdifSwitch momentan dauerhaft aktiv ist, müßte doch bei DD inaktiv richtig sein. Momentan funktioniert bei meinem Verstärker PCM, während er bei DD stumm bleibt (und nur 44,1kHz anzeigt).

    Quote

    Original von UFO
    ...

    Um dies zu korrigieren, brauche ich nur jemanden,
    - der das Problem hat
    - der Patches einspielen, kompilieren und testen kann

    Bis sich jemand findet, bleibt einfach alles, wie es ist. :schiel

    CU
    Oliver


    Also,
    von mir aus gerne. Kernel-Header etc. muß ich mir erst wieder besorgen (da war beim letzten Update einfach keine Not mehr), ansonsten ist alles auf der Kiste drauf.

    Wichtig für mich (weil Produktivsystem): Momentan arbeite ich mit einem VDR 1.6 und dem alten DVB-API. Ist das aus Deiner Sicht ein No-Go? Ich würde momentan ungern alles umstellen wollen, zumal auch die Inbetriebnahme meiner PVR-350 immer etwas hakelig war (wie gesagt, beim letzten Update lief dann IVTV endlich mal "aus der Box" und ohne alles selber zu bauen) und ich auch (zumindest für SD-Material) bis auf Weiteres der Abwärtkompatibilität wegen nicht auf TS wechseln will. Sofern es den von Dir genannten Audio-IOCTL schon gab und der VDR ihn bedient (habe ich einfach noch nicht nachgeschaut), dann sage ich mal "denn man los".

    Ansonsten sehe ich mich nicht direkt als Anfänger, in der Fa. hab' ich meistens Kernels selber bauen (und patchen müssen), wenn der Chef zu neue Hardware gekauft hat und auf meinem Debian Heimserver mit seinen diversen Gästen ist auch vieles Marke Eigenbau (vor allem weil im SATA-Umfeld immer noch Fehler gibt, die bei der Verwendung von Port-Multipliern böse zuschlagen können).

    Ehe ich aber Treiber baue vielleicht mal eine Idee, um erstmal mit möglichst wenig Aufwand zu testen, ob wir überhaupt weiterkommen: Kannst Du mir zum Testen eine Firmware bauen, die den SpdifSwitch dauerhaft inaktiv schaltet? Dann könnte ich Dir zumindest schon mal eine Rückmeldung geben, ob es damit überhaupt geht (denn dann müßte ja PCM stumm bleiben und sich bei DD was tun).

    Viele Grüße,
    Torsten

    Hallo,
    die Firmware war die aktuellste, die ich (ich glaube auf Deiner Seite) gefunden hatte, müßte FA2624 gewesen sein (ich check's heute abend nochmal), die genaue Treiberversion kann ich bei der Gelegenheit ebenfalls nochmal checken.

    Was das selbst übersetzen angeht - ich habe schon länger nicht mehr aktiv an meinen VDRs "geschraubt", ich müßte also mal schauen, ob nach den letzten Upgrade-Aktionen noch alles drauf ist, was ich brauche. Vor allem ist es lange her, daß ich entsprechende Packages im Kernel-Bereich (also Kernel selbst und Module) selbst gebaut habe, da muß ich erstmal mein Know-How wieder etwas entstauben (oder Du gibst mir als Stichwort nochmal ein paar warme Worte dazu).

    Wie sähe es denn eigentlich grundsätzlich mit der SW-Architektur aus? Was macht die Firmware, was der Treiber? Oder anders gefragt: Stellt die Firmware nur die Schnittstelle bereit, um das entsprechende GPIO-Bit anzusteuern, und der Treiber bedient das dann? Und wie erhält der Treiber wiederum die Info, was er machen muß (geht das dann ohne Hilfe der Applikationssoftware)?

    Fragen über Fragen - aber ich habe mich mit den Treiber-Innereien bisher einfach zu wenig auseinandegesetzt.

    Viele Grüße,
    Torsten

    Hallo zusammen,
    ich krame diesen Thread mal wieder vor, weil ich leider einer von denen bin, deren Receiver Ärger mit DD macht (Yamaha DSP-A3090). Gibt es denn aktuell eine Firmware und einen Treiber, der die TT FF 2.3 voll unterstützt?

    Ich habe hier zwar erfolgreich den Budget-Patch nachgerüstet (und das EEPROM gepatcht), aber wie ist das bzgl. DD bei der 2.3?

    Bei DD schaltet mein Yamaha jedenfalls auf 44.1kHz und schaltet dann stumm.

    Viele Grüße,
    Torsten

    P. S. Leider hilft die Foren-Suche aufgrund der Abkürzungen und Versionsnummern nicht wirklich weiter...

    Quote

    Original von real_schorsch
    Wir haben da lange Tests laufen lassen, ob bei normaler Nutzung was verloren gehen kann. Tut es nicht. Es gibt AFAIK ein Problem mit AMD-Dual-Core bei der AVG2, das lässt sich mit einem Bios-Update lösen.

    Ansonsten kann es bei HD durchaus auch Übertragungsfehler sein. Die BER-Anzeige ist da deutlich unempfindlicher. Und "quasi-error-free" liegt bei ~10^-11, das ist immerhin ca. ein unkorrigierbarer Fehler pro Stunde bei HD-Datenraten. Starte mal reelvdrd von Hand im Terminal. Da sollten die Discontinuities ausgegeben werden. Wenn bei der Video-PID die Sprünge um 7 sind, ist ein Netzwerkpaket mit 7*188=1316Bytes verloren gegangen. Keine Sprünge und trotzdem Fehler oder andere Abstände sind Empfangsprobleme.

    Moin Schorsch,
    ich habe das mit der frisch aufgesetzten Box mal gemacht, aber keine Störungen beobachtet. Daher meine Frage: Wie bekomme ich die Continuity Fehlermeldungen im Normalbetrieb im Log festgehalten? Dann hätte ich nämlich wenigstens mal eine reelle Chance, Fehler in Aufnahmen (so sie künftig noch oder wieder auftreten) mit den entsprechenden Meldungen im Log abzugleichen und nach der Ursache zu forschen.

    Viele Grüße,
    Torsten

    Quote

    Original von real_schorsch
    > Übrigens: Wenn ich den reelvdrd starte, dann beendet der wohl den laufenden
    > VDR (soweit OK), der rappelt dann aber mit einem coredump weg (sicher nicht OK).

    Naja, fahr erstmal den "normalen" vdr runter: "/etc/init.d/reelvdr stop"

    Dazu noch ein Nachtrag: Ich habe den daemon gestoppt und den reelvdrd dann auf der Konsole gestartet (als root) und konnte damit zumindest auch bei mehreren gleichzeitigen HD Aufnahmen (DasErste HD, ZDF HD, arte HD, BBC HD), keine Fehler in der Log-Ausgabe sehen. Mal schauen, wie es in den Aufnahmen ausschaut. Beim anschließenden Stoppen des reelvdrd von Hand (^C) gab's übrigens wieder 'nen Dump.

    Viele Grüße,
    Torsten

    Quote

    Original von real_schorsch
    > Übrigens: Wenn ich den reelvdrd starte, dann beendet der wohl den laufenden
    > VDR (soweit OK), der rappelt dann aber mit einem coredump weg (sicher nicht OK).

    Naja, fahr erstmal den "normalen" vdr runter: "/etc/init.d/reelvdr stop"

    OK. Wußte nicht, daß das geht (zumindest erinnere ich mich, daß ich da früher immer komische Effekte hatte). Von meinen Selbstgebauten VDRs her war das schon klar.

    Gruß,
    Torsten

    Quote

    Original von real_schorsch
    Wir haben da lange Tests laufen lassen, ob bei normaler Nutzung was verloren gehen kann. Tut es nicht. Es gibt AFAIK ein Problem mit AMD-Dual-Core bei der AVG2, das lässt sich mit einem Bios-Update lösen.

    Ansonsten kann es bei HD durchaus auch Übertragungsfehler sein. Die BER-Anzeige ist da deutlich unempfindlicher. Und "quasi-error-free" liegt bei ~10^-11, das ist immerhin ca. ein unkorrigierbarer Fehler pro Stunde bei HD-Datenraten. Starte mal reelvdrd von Hand im Terminal. Da sollten die Discontinuities ausgegeben werden. Wenn bei der Video-PID die Sprünge um 7 sind, ist ein Netzwerkpaket mit 7*188=1316Bytes verloren gegangen. Keine Sprünge und trotzdem Fehler oder andere Abstände sind Empfangsprobleme.

    Um alle Seiteneffekte auszuschließen, habe ich gestern abend mal ein Factory Image eingespielt und dann auf Testing umgestellt. Zumal ich gesehen hatte, daß es zum Jahreswechsel ein großes SW-Update gegebn hat, wo auch auf eine aktuellere Ubuntu-Distri umgestiegen wurde.

    Ich werd's mal mit diesem Stand beobachten.

    Übrigens: Wenn ich den reelvdrd starte, dann beendet der wohl den laufenden VDR (soweit OK), der rappelt dann aber mit einem coredump weg (sicher nicht OK).

    Gruß,
    Torsten

    Quote

    Original von Moorviper
    realtek rulez

    Naaaajaaaa - ich würde es eher so formulieren, wie ich es zu meiner Uni-Zeit bei den Adaptec SCSI-Controllern gemacht habe: "Sie funktionieren wenigstens" (das war das Beste, was ich sagen konnte).

    Ich weiß nicht, ob es bei den aktuellen GBit-Chipsätzen von Realtek immer noch so ist, aber bei den älteren Karten (100MBit) gab es m. W. ziemlich torfnasige Restriktionen beim Alignment der TX-Buffer, was den Netzwerk-Treiber fast immer dazu gezwungen hatte, die Daten nochmal umkopieren zu müssen. Was dann zu (deutlich) erhöhter CPU-Last bei starker Netzwerk-Auslastung führt.

    Nee - also meine Favoriten zu 100MBit-Zeiten waren eindeutig DEC Tulip Chipsätze und bei GBit ist es z. Z. Intel Pro 1000.

    Zugegeben, in meinem Server habe ich (weil Intel gerade nicht erhältlich war) auch 'ne PCIe Realtek-Karte verbaut. Wie Gesagt, sie funktioniert halt.

    Gruß,
    Torsten

    Quote

    Original von Razorblade
    Soweit ich weiß ist der RTL8211C nur der physische Connector um Medium (PHY) und hat nichts mit dem Treiber zu tun.
    forcedeth ist der Name des Netzwerktreibers für nvidia Chipsatz-integrierte Netzwerkfunktion (wobei immer noch ein externer PHY zum Einsatz kommen muß.)

    Soll heißen: Soweit ich weiß benutzen alle ION Boards den internen Netzwerkchip und verwenden unter Linux deswegen den Forcedeth Treiber. Der PHY (in diesem Fall von Realtek) ist nur insofern relevant, als dass der Treiber ihn auch "kennen" muß, das ist bei dem 8211 aber schon seit einer Weile der Fall.

    schorsch hatte auch schon von Problemen mit forcedeth-angesprochenen Chips berichtet und wenn man mal danach googelt, findet man nicht gerade Lobgesänge.

    Da ich es bei mir (Zotac IONITX-B aus einer sehr früheren Baureihe) nicht ohne massive Drops mit dem Netceiver zum Laufen bekomme habe, habe ich per USB eine Netzwerkverbindung nachgerüstet, das ging dann besser...

    Hallo zusammen,
    für meinen Heimserver hatte ich ein ASRock Board mit NVIDIA-Chipsatz rausgepickt, das zusammen mit einem 35W-Prozessor von AMD einen sehr günstigen Verbrauch im Leerlauf haben sollte - der onboard-LAN Anschluß (forcedeth Treiber) ist praktisch unbrauchbar bei GBit Ethernet. Ich habe ihn jetzt im Einsatz, um die DSL-Anbindung zu machen, das funktioniert soweit, und fürs GBit-Netz eine PCIe-Karte nachgerüstet. Soviel zu meinen Erfahrungen damit...

    Gruß,
    Torsten