Posts by SHF

    Die Anzahl der continuity Fehler der Aufnahme. Sehr hilfreich, wenn man Aufnahmen manchmal erst viel später anschaut, um gleich zu wissen, ob sie OK sind.

    Das hatte ich vor einer Weile vor per Script machen zu wollen und leider kein Feld für den allgemeinen Gebrauch in der info-Datei gefunden.


    Evtl. könnte man sich ja ein Zeichen für Plugins überlegen?

    +1 (s.O.)


    Alternativ die könnte man auch die Kommentar-Zeilen (#) beim Schnitt mitnehmen. Damit könnte man auch was anfangen.

    Wenn man sich schon die Mühe macht, ein Kommentar in der info einzufügen, dann will man es normalerweise auch drin behalten.


    Es wäre schöner, wenn der @ Tag mehrfach vorkommen darf.

    IMHO keine gute Idee.

    Die @-Zeile wird derzeit aus dem Aux.Feld vom Timer erzeugt. Wenn sich ein Programm drauf verlässt, gibt's Chaos.


    Ich hab jedenfalls von der Zeile lieber die Finger gelassen, nicht dass es mit EPG-Search Probleme gibt.

    Sorry, dass ich mich erst relativ spät zurückmelde.

    Dito sorry, ich hab die Antwort übersehen.

    Positionen 5W und 23.5E sind schon mal gestrichen, da Unicable I nach SHF sowieso nur 2 Positionen unterstützt und

    um die Gefahr böser Überraschungen zu vermindern. Da Unicable I älter als Unicable II ist, hoffe ich dass es ausgereifter ist.

    Problem ist IMHO eher, dass derzeit nicht viele nicht viele Endgeräte Unicable II unterstützen.


    Wenn ich richtig gegoogelt habe, kosten sie ungefähr 150 Euro :-/ . Diese Summe wäre wahrscheinlich besser in einen professionellen Satinstallateur investiert.

    Den du dann aber auch im Fehlerfall erneut beauftragen müsstest.


    Beim Monoblock reichte die Stromspeisung des Receivers. Anhand der vorausgehenden Erläuterungen verstehe ich es so: beim Quad Monoblock braucht der Receiver immer nur das gerade benutzte LNB des Monoblocks mit Strom zu versorgen; bei zwei Unicable LNBs jedoch, müssen beide ständig aktiv auf Signale horschen, ob ein Receiver ihre Dienste benötigt und gegebenfalls die Daten des gewünschten Transponders liefern.

    Das Problem ist, dass einfach nicht zu sagen ist, welcher LNB wann wie viel Strom zieht. Daher muss man vom schlimmsten Fall ausgehen.


    Der Quard Monoblock braucht meist etwas mehr als ein einfacher LNB. Er ist aber so ausgelegt, das er an einem Receiver läuft. Das ist ja der normale Anwendungsfall.

    Ich glaube mich aber Fälle zu erinnern, wo diese Monoblocks an den alte FF-Karten auch mal Probleme machten.


    Eine Idee wäre vielleicht Splitter und Combiner in eine Wasserdichte Dose zu stecken; somit blieben nur die F-Stecker am LNB im Regen.

    Das ist mehr oder weniger zwingend, falls man nicht spezielle Outdoor-Versionen verwendet.


    Aber ausser Regen gibt es auch noch Kondenswasser und UV-Strahlung, die der Installation zusetzen können.

    Die "Dose" sollte also schon was taugen ...


    Mein erster Gedanke war auch, die Stromeinspeiseweiche müsste zwischen Combiner und Splitter, damit die Receiver an den 4 Koaxkabel davon profitieren.

    Das ist richtig.


    Ich bin mir nicht sicher, was du mit den zwei Splittern meinst; ich nehmen an du wolltest folgendes sagen: von den 4 Koaxkabeln, die mir zur Verfügung stehen, werden 3 benutzt, um Receiver zu versorgen und der vierte, um den Strom einzuspeisen. Die 3 Receiverkabel gehen an einen Splitter draußen der sie verbindet; dieser Splitter und der 4. Koaxkabel mit dem Strom gehen an einen zweiten Splitter, der sie verbindet; dieser zweite Splitter geht an den Combiner...


    In der Zwischenzeit frage ich mich dann, warum ich den 4. Koaxkabel mit dem Strom nicht einfach an den ersten (vom Zimmer aus gesehen) Splitter mit den anderen 3 Koaxkabeln verbinden kann. Außerdem, muss ich überhaupt ein Koaxkabel für die Stromeinspeisung reservieren? Vor dem Combiner kommt sowieso alles zusammen; warum also nicht einfach die Stromeinspeiseweiche zwischen einem Receiver und einer Satsteckdose anbringen. Übersehe ich vielleicht etwas?

    Das eine Kabel nur zur Fernspeisung zu verwenden ist wohl geschickter.



    Wenn es Platzmässig aussen machbar ist, würde ich einen fernspeisbaren Multischalter bevorzugen.

    Das sollte aber unbedingt ein Modell für den Ausseneinsatz sein und ich würde es auch nur Wetter geschützt montieren.

    warum nimmst Du nicht einen Einkabelmultischalter bsw. den hier --> http://jultec.de/JPS1701-16.html

    Guter Fund.

    Der sieht ja fast so aus, als ob das Gehäuse einigermassen wetterfest ist. Leider steht nichts in der Anleitung

    Das hat jetzt zwar etwas länger gedauert, da ich ich das Plugin doch noch nicht drauf hatte.


    Aktuell geht mit der "jw9" aber folgendes:


    Angezeigt werden können die folgenden Ereignisse:

    Code
    1. static const char * OutputFunctionText[]= {"Off", "On", "Recording DVB1", "Recording DVB2", "Recording DVB3", "Recording DVB4", "Replay", "DVD", "MPlayer", "MP3", "MPlayer + MP3", "User1", "User2", "User3"};

    Die Liste ist IMHO nicht ganz ideal. Sachen wie "MUTE" und generell laufende Aufnahmen fehlen leider.


    Zuordnung zu den LEDs, in deinem Fall Icons, geschieht im Menü unter OutputNumber.


    Die Zuordnung LED -> Icon aus dem LCDproc-Manual:


    0 Play
    1 Pause
    2 Record
    3 Message
    4 Mail (at-symbol)
    5 Mute
    6 WLAN tower
    7 Volume (the word)
    8…12 Volume (decimal 0…28)
    13…14 WLAN strength (0…3)



    Viel Spass beim testen.

    Der Code ist seit Urzeiten im Plugin drin.

    Ursprünglich diente er zum Ansteuern von LEDs, die parallel zum LCD an geschlossen werden konnten.


    Es kann sein, dass es im Menu auch LED oder so ähnlich heisst.

    Ich hab das Plugin schon länger nicht mehr drauf. Ich kann aber nachher mal nachschauen.

    Ich kannte solche Bauteile nur als "Verbinder" von SAT und terrestrischen Signalen.

    Der ist aber technisch was anderes.

    Es handelt sich dabei eher um eine Frequenzweiche. Sie Frequenzbereiche von SAT und terrestrischen Signalen überschneiden sich nicht und können daher "übereinander gestapelt" werden.

    Das funktioniert auch rückwärts.


    Beispiel: GOOBAY 67054 SAT-TV-Einschleuseweiche

    Quote

    Der Combiner kann auch "rückwärts" genutzt werden. Dann werden die Signale wieder aufgesplittet.

    Meistens ist das aber in der Antennendose eingebaut.



    ... Ist aber immer noch ein anderes Bauteil als ein Splitter ...

    Es gibt für SAT zwei Splittertypen:

    1. Der "übliche" zum Anschluss mehrerer Tuner an ein LNB.
      Bsp: Kathrein EBC 10 Verteiler 2fach 2,4 GHz
      Mit eingebauten DC-Entkopplungsdioden
      Stromflussrichtung nur von je von jedem der beiden Ausgäng zum Eingang.
    1. Den mit DC-Durchgang
      Bsp: Kathrein EBC 110 Verteiler 2fach 2,4 GHz
      Ohne Entkopplungsdioden gedacht für den Einsatz in Einkabel-Systemen.
      Die eingespeiste Spannung liegt bei dem Typ an allen Ein- und Ausgängen an.

    Der zweite Typ sollte theoretisch auch als Combiner gehen.



    Tatsächlich werden die LNBs hier in den SCR Kanälen/User Bändern gleich programmiert, eben der eine als Position "DiSEqC A", der andere als Position "DiSEqC B". Wird jetzt z.B. ein SCR Kanal für "DiSEqC A" angesprochen, wird gleichzeitig auf dem "DiSEqC B" LNB, der entsprechende SCR Kanal abgeschaltet und damit geschützt.

    Problematisch wird es aber, wenn ein LNB Amok läuft und sich nicht dran hält. Das kann das ganze System stören.




    Von Inverto gibt es auch einen Unicable kompatiblen Power Inserter zur Speisung der LNBs.

    Allerdings kann der auch nur 750mA liefern. Man bräuchte also einen pro LNB.

    Ohne zusätzliche Kabel wird es mit dem also auch nichts bei 4 LNBs.

    Ähm, naja, die Lösung, je 1 LNB pro SAT Position im Multifeed an einer Schüssel, funktioniert nur mit einem vorgeschalteten DiSEqC Schalter.

    Da ist aber immer ein DiSEqC Schalter pro Tuner verbaut. Die Schalter schalten auch das komplette Kabel um, prinzipiell wie ein normaler Wechselschalter. So kenne ich das zumindest.


    Hier bräuchte man aber einen Frequenzselektiven Schalter. Das bekommt man nicht für 10€ VK gebaut.


    Man kann sich nun streiten ob das passive Geräte sind oder nicht

    Die DiSEqC Schalter sind definitiv aktiv.

    Ein Signal vom Receiver wird ausgewertet und entsprechend umgeschaltet.

    Da ist also mindestens eine Auwerte-Elektronik für das DiSEqC und eine Art HF-Relais drin.


    Ein einfacher Splitter ist passiv. Da ist ein Richtkoppler oder was ähnliches drin.

    Im Endeffekt ist das nur ein kleiner Ringkern mit etwas Draht drum und ein paar Kondensatoren. Und halt noch die Dioden für DC.


    Richtkoppler kann man auch zum zusammenführen von Signalen verwenden (siehe unten im Link).


    Die SCR LNBs wissen von Ihrem Glück und voneinander nix ...

    Wissen sie doch!;)

    Die LNBs müssen entsprechend programmiert werden, wenn man mehr als einen verwenden will.

    Soweit ich das verstanden habe, muss mindestens jedem eine unterschiedliche Sat-Positions-Nummer zugewiesen werden.


    Hast Du denn schon eine genau auf deine Antenne abgestimmte Feedschiene, auch mit Höhenjustage der einzelnen LNBs?

    Von Gilbertini gibt es diese Schienen, da hattee ich schon mal geschaut.

    Ich selber habe die 100er von denen.


    Können die LNBs für Dein Vorhaben dort passen?

    Ich bezweifele das, die Dinger sind echt breit.

    Anfangs hatte ich einen Inverto-Quard verbaut (der Typ mit dem eingebauten Wasserschaden ;)), der hat ein ähnliches Format (Breite) wie die aktuellen Unicable-LNBs.

    Als minimal möglichen Abstand hatte ich da mal irgendwas kurz unter 15° ausgeknobelt. An der 85er wird das noch mehr.

    einzeln kosten die Teile weniger, was ist das den für ein Bundle.:wand

    Quote

    Inverto Unicable II Produkte können mit Hilfe eines speziellen Programmers für unterschiedliche Einsatzzwecke, wie beispielsweise der Empfang von mehreren Satelliten, programmiert werden. In der Regel ist diese Konfiguration einmalig notwendig.

    Die in unseren Unicable II Sets erhältlichen Komponenten wurden aufeinander abgestimmt und bereits vorprogrammiert, so das diese sofort zum Einsatz kommen könnnen. Ein Programmer ist in diesem Fall nicht notwendig.

    ... jetzt such mal nach dem Programmer, dann relativiert sich das ;).


    Der Programmer ist IMHO sowieso der Haken an der Anlage.

    Zum einrichten der Anlage braucht man entweder so einen Progger oder jemand er einem das macht. Besonders, wenn man mehrere Satelliten verwendet werden, sollte derjenige das nötige Know-how, sonst gibt es Chaos.

    Das gilt auch beim Austausch eines LNB, der genau so programmiert werden muss wie der defekte (an dessen Konfiguration man dann oft nicht mehr ran kommt).



    - Wie stabil wäre diese Lösung, insbesondere da jetzt (nehme ich an) der Receiver 4 LNBs speisen muss?

    Der LNB zieht laut Datenblatt 400mA.

    Die LNB-Versorgung der meisten Receiver kann irgendwas zwischen 700 und 1000mA.

    4LNB -> :burn1

    Externe Versorgung ist zwingend nötig (Netzteil + Einspeiseweiche). Selbst das Coax-Kabel kann da schon problematisch werden, die sind für die Ströme eigentlich nicht ausgelegt.

    Selbst zwei LNB am Receiver sind IMHO auch schon grenzwertig. Das kann gehen, das kann auch länger gehen oder nur kurz, oder auch gar nicht.

    Die Einspeiseweiche muss das 22kHz Signal durchleiten. Da weiss nicht, ob es sowas gibt.


    Die Weiche müsste dann zwischen Combiner und Splitter. Das könnte man aber in dem Zimmer mit den zwei SAT-Kabeln machen und mit zwei Splittern arbeiten.




    - Reicht die 85 cm Gibertini für diese Positionen aus?

    5W bis 23.5E ist schon einiges. Ich wäre da etwas skeptisch.

    Da solltest du aber noch mal in den entsprechenden Foren suchen, das ist ja unabhängig von der Unicable-Frage.


    Die nächste Frage ist, ob du diese 4 LNBs in den Positionen überhaupt angebaut bekommst. Gerade dieser Typ fällt recht breit aus.


    Ja, sind zwei verscheidene Bauteile, der Combiner ist m.E. ein (2-Kanal) DiSEqC Schalter, ein Splitter ein besseres Y-Stück welches über eine Dioden-Schaltung für die Speisung in nur eine Richtung sorgt und damit Kurzschlüsse verhindert.

    So wie ich die Beschreibung auf der Inverto-Seite verstehe sind die Dinger rein passiv.

    Da steht nicht, dass das Teil irgendwas umschaltet. Das würde auch nicht so einfach gehen, da da jeder der Receiver den Satelliten frei wählen können soll.

    Wahrscheinlich ist das lediglich sowas wie ein inverser Splitter. Evtl. geht auch einfach ein Splitter ohne DC-Blocker (= Dioden), die gibt es auch.


    Das Umschalten der Satelliten machen die LNBs. In Abhängigkeit der gewünschten Satelliten Position und der Programmierung senden die was oder nicht.


    - Gehen die Combiner nur mit Unicable I oder auch mit Unicable II?

    Der Combiner mischt nur die Ausgangssignale von den LNBs zusammen.
    Wichtig ist nur, dass nicht mehrere LNBs auf dem gleichen Kanal was senden.

    Den Combiner interessiert das Ansteuerprotokoll für die LNBs nicht.


    Unicable (EN 50494) unterstützt 2 Satellitenpositionen, Unicable II (= Jess = EN50607) 64.

    Wenn alle Komponenten, besonders die LNBs, Unicable II unterstützen sollte 4 Satellitenpositionen eigentlich gehen.


    Was dann bei nur Unicable I fähigen Receivern passiert, währe aber interessant.

    Man könnte ein Unicable I UserBand verwenden, aber welche Satelliten empfangbar sind ist die Frage. Eventuell gibt es auch Chaos, da sich immer mehrere LNBs abgesprochen fühlen und auf dem UserBand gleichzeitig senden.


    Statische Konfiguration müsste aber immer möglich sein. D.h. man kann 32Transponder von den Satelliten wählen und die parallel einspeisen.


    Übrigens, wesentlich mehr als 32 Receiver oder 32 Transponder nie über ein Coax-Kabel nie übertragen können, der Frequenzbereich 0,9 -2,2GHz ist komplett belegt (siehe Beschreibung der LNBs). (Allenfalls mit Wideband liesse sich noch mehr machen.)


    Wie sind die Erfahrungen mit Unicable LNBs und Combiner? Laufen solche Satinstallationen stabil?

    Erfahrung mit so einer Installation habe ich nicht, aber ich weiss wie F-Stecker und LNBs nach ein paar Jahren aussehen können, wenn Wasser eingedrungen ist.


    Ein Unicable-LNB würde ich schon verbauen.

    Aber LNB vier, Splitter, Combiner und einen Haufen F-Stecker in den Regen hängen und hoffen, dass es dauerhaft geht? Das würde ich mir nicht antun. Zu viele Fehlerquellen.

    Ausserdem habe ich die Befürchtung, dass die Fehlersuche aufwändig wird, da jeder LNB alles stören kann. Und ohne Programmiergerät, kann man nicht mal eben einen LNB gegen einen anderen tauschen.

    Falls jemand an einer Übersucht über diverse VDR Foren interessiert ist:

    Schön, dass es die wieder online sind.

    Ich hatte schon befürchtet, dass die dauerhaft verschwunden sind.


    Vielen Dank dafür!


    Die aktuelle Übersicht hier hat den Namen echt nicht verdient.:(

    Was die wiederholte Übertragung bei Fehlern auf dem PCIe betrifft, das gilt evtl. dann nicht für Message-Signaled-Interrupts (MSI), zumal diese auch nicht bestätigt werden.

    Nach meinem Verständnis werden die Wiederholungen auf der Hardware-Schicht ausgelöst.

    Das heisst, wenn die Message-Signaled-Interrupts in Datenpaketen verschickt werden, sollten die auch erneut übertragen werden.


    Mein Wissen stammt aber aus Sekunderquellen, bei derartigen Detailfragen müsste man sich selber mal durch die Spezifikation arbeiten.


    Nachtrag zum J4105M Board: Der Eintrag "options ddbridge msi=0" in /etc/modprobe.d/ddbridge.conf scheint wohl nicht nötig zu sein.

    Die Einstellung ist AFAIK auch nur bei fehlerhaften ACPI-, MSI-, Wasauchimmer-Tabellen im BIOS sinnvoll.

    da es aber im praktischen Betrieb keine Probleme gibt ist die Frage, ab wann es problematisch wird. Ein detektierter Fehler der das Flag setzt, wird nicht das Problem sein. Hier sind diese Fehler auch bekannt --> https://www.kernel.org/doc/Doc…ion/PCI/pcieaer-howto.txt und wohl üblich.

    Schwer zu sagen, ab wann es problematisch wird.


    Wenn man dieser Seite trauen kann, werden die Fehler durch eine erneute Übertragung behoben.

    Diese kosten natürlich unnötig Bandbreite und das wird man irgendwann merken.


    Wahrscheinlich wird es aber schon früher zu Problemen kommen und zwar, wenn eine Übertragung mehrfach hintereinander scheitert.

    Die Puffer sind in den Geräten sind nicht besonders gross, da könnte es schon nach ein paar Fehlversuchen eng werden.

    Leider geben die Flags nicht an, wie oft der Fehler aufgetreten ist, sondern nur, dass er (mindestens einmal) aufgetreten ist.


    Aber selbst ein Pufferüberlauf ist eigentlich kein Grund, dass die Karte komplett aussteigt.


    Meine Vermutung geht stark Richtung Timing-Problem.

    Die Karte muss synchron zum Referenztakt von 100MHz den Datentakt von 2,5GHz erzeugen. Das scheint auf einem FPGA nicht ohne Tücken zu sein.

    Wenn man nach diesen PCIe-Parametern sucht, stösst man immer wieder auf FPGA-Howtos bezgl. korrektem PCIe-Timing.

    Wenn der Oszillator stolpert, sind ruck-zuck ein paar Datenpakete hinüber und wenn die Störung zu gross wird hängt sich die Karte auf.


    100MHz gehen noch, wer will und in entsprechendes Oszilloskop hat, kann ja mal versuchen, ob man auf dem RecCkl-Signal beim J3355M was sieht.



    ... aber zurück zu den Fehlern.

    Wenn es alles richtig läuft, sollten die überhaupt nicht auftreten. Auf keinem meiner Computer konnte ich welche beobachten.

    Ein gutes Zeichen sind sie zudem nicht, besonders wenn sie regelmässig auftreten. Das es bedeutet, das irgendwas grenzwertig arbeitet.

    Quote

    Errors in the low-level packets are not only a performance issue (retransmissions are a waste of bandwidth). With properly designed hardware, there is no reason for their appearance at all, so their very existence indicates that something might be close to stop working.


    Wo die Grenze zwischen geht und geht nicht mehr in der Praxis liegt, hat kls schön gezeigt. Wir sitzen ziemlich genau drauf.

    Beim J4105M geht es, beim J3355M geht es nicht und der Unterschied in der Fehlerrate ist nicht so gross.



    neben den unterschiedlichen devices auch max payload, linkspeed, Powerlimit, devcap, linkctl, usw.

    Die ...Cap-Zeilen kann man ignorieren, die geben nur die Fähigkeiten des Devices an.

    Der aktuelle Status ist in ...Sta zu finden. Da sind dann die Abweichungen nicht mehr so gross.

    Ich habe dieses Board jetzt in meinen Wohnzimmer-VDR eingebaut und werde jetzt noch die Langzeitstabilität beobachten.

    Solange CorrErr+ im Rahmen bleiben, wird es wohl gehen.

    Nach dem Aufwand wäre es dir zu wünschen, dass es endlich klappt. Ich drücke jedenfalls mal die Daumen!



    Argus :

    Deine Vermutung war prinzipiell richtig, mein Beitrag war lediglich als Ergänzung der technischen Details gedacht.


    Ich denke, es ist schwierig, auf einen "Schuldigen" zu zeigen.

    Die CoerErr Fehler sind immer in dem Link, an dem die Cine beteiligt ist und auch nur da.

    Völlig unabhängig, welches Gegenüber: Asrock J3355M, PCIe Extension Board, ASRock J4105M immer bilden Fehler und Karte eine Einheit.

    Sogar im lspci -vv Auszug von Argus sind CorrErr+ UncorrErr+ gesetzt!

    Für mich ist das eindeutig genug.


    zudem könnte auch noch das BS mit ins Spiel kommen, wenn es unter Windows hier nirgendwo Probleme gibt. Das mit dem Windows müsste jemand verifizieren, der auch diese Probleme hat und mit winzigweich kann

    Hatte ich auch schon vorgeschlagen.

    Ich habe halt weder so eine Karte, noch wirklich Ahnung von Windows.


    Ich wüsste nicht mal, wie man an die CoerErr-Geschichte da auslesen kann und ob das überhaupt geht.

    Der normale User wird von dem Fehler jedenfalls nichts mit bekommen, solange die Karte nicht komplett aussteigt. Da dazu anscheinend schon einige Faktoren zusammenkommen müssen, ist nicht gesagt, dass es überhaupt auffällt.



    Alternativ könnte man auch mal unter Linux Daten sammel gehen.

    Errorcounter löschen ein Stündchen Fernsehen und dann mitlspci -vv auslesen.
    CorrErr+ UncorrErr+ sollten dann nicht gesetzt sein, bei keiner PCIe-Karte.


    Da CorrErr+ UncorrErr+ auch bei Argus lspci -vv Auszug gesetzt waren, vermute ich, dass das auf mehr Mainboards auftritt als bisher vermutet.

    Mit mehr Daten könnte man zwar Linux als Ursachen nicht ausschliessen, aber abschätzen, wie weit das Problem verbreitet ist.

    Das die Cine überhaupt mit dem Mainboard zusammen läuft, ist schon mal ein Ergebnis.

    Für mich bedeutet das, dass das Mainboard generell keine Macke hat.


    Auch damit CorrErr+ alle halbe Minute an 03:01.0, aber nie an 04:00.0.

    Das ist die Verbindung PCI bridge -> Cine!


    Auf der Verbindung PCI bridge (02:00.0) Mainboard gibt es keine Fehler. Das Mainboard ist also endgültig raus!

    Wobei das freilich keine in der Praxis brauchbare Lösung ist.

    Auch sind IMHO die CorrErr immernoch viel zu häufig.


    Erstaunlich finde ich, dass die auch nur noch in einer Richtung auftreten.

    Da hab ich aber auch keine rechte Idee, was das soll. Evtl. hängt es auch mit der Richtung der Datenmenge zusammen und ändert sich, wenn man ein CI betreibt.


    Eine Vermutung wäre , das das ext Board dolmetscht und sich so Teiln. A und B deutlich verstehen können.

    PCIe ist kein BUS im klassischen Sinne mehr. Es gibt immer nur noch Punkt zu Punkt Verbindungen zwischen zwei Geräten.

    Das ext Board baut eine PCIe-Verbindung mit dem Mainboard auf und eine andere mit der Cine.

    Mainboard und Cine kommunizieren also nicht mehr mit einander, was die Hardware-Ebene angeht.


    Bei HDMI ist es prinzipiell genau so. Wenn man einen HDMI-Extender zwischen zwei Geräte schaltet, baut jedes der Geräte eine Verbindung mit dem Extender auf (auch wieder nur die Hardware-Ebene betrachtet).

    Mein neuer Fernseher lässt sich nicht mit meinem einen Notebook per HDMI verbinden. Da gibt es zwar kurz mal ein paar Bild-Brocken, dann wird es Schwarz.

    Mit einem dazwischen geschalteten HDMI-Extender geht es aber einwandfrei.


    Ich schätze das wird hier so ähnlich liegen.


    Gibt es eigentlich einen Grund für die Fixierung auf Asrock als Hersteller?

    Wäre es nicht sinnvoller gewesen mit einem Board eines anderen Herstellers zu testen?

    Wenn man was vergleichbares sucht, wird die Auswahl eng. Die Marktnische hat Asrock fast allein besetzt.

    Und die Probleme wurden auch auf Boards von anderen Herstellern berichtet (mindestens ASUS).


    Ausserdem war in all den Jahren, wo ich mich mit so PC-Problemen rum schlage nie der Mainboard-Hersteller die Ursache.

    Es war immer auf einen speziellen Mainboard-Typ, den verwendeten Chipsatz (teilweise auch alle Chipsätze eines Herstellers), einzugrenzen, aber nie auf den Mainboard-Hersteller.

    Ich frage mich gerade, wie sich die Karte in so einem einem PCIe-Riser verhalten würde.

    Die Frage hatte ich mir auch schon gestellt, ob es mit einem aktiven Riser gehen würde.
    DD bietet selber auch solche Backplanes an.


    Beim suchen nach diversen PCIe-Parametern bin ich mehrfach auf das folgende Datenblatt gestossen. Das brachte mich dann drauf:

    DS50PCI402 2.5 Gbps / 5.0 Gbps 4 Lcwmp accountane PCI Express Repeater with Equalization and De-Emphasis


    Das Schema auf Seite 2 zeigt, wie so eine Verlängerung aufgebaut ist.

    Mit je einem von den winzigen ICs (nur 5,5 x 10 mm) am Ein- und Ausgang vom Kabel, kann man (mindestens) einen PCIe x1 übertragen.
    Es sollen beträchtliche Kabellängen realisierbar sein, die Tabellen gehen bis >15m!

    Ti hat noch einige andere PCIe-Retimer im Programm.

    Anscheinend gibt es das I2C Problem unter Windows nicht. Auch in den Bedienungsanleitungen zur Max findet sich der Hinweis bei I2C-Timeout zur msi Behandlung unter Linux.

    Das I2C-Problem, das mit msi zusammenhängt, wird es unter Windows nicht geben, schätze ich.

    Ich ordne es in die Reihe "übliche ACIP-Probleme" ein.

    Soweit ich sehen konnte, tritt es auch auf unterschiedlichen Mainboards auf und kommt bzw. geht teilweise mit den Kerneln.


    Das Problem hier scheint aber anders gelagert zu sein und betrifft anscheinend nur Mainboards mit Apollo-Lake-SOC.

    Diese Boards sind hier überproportional oft vertreten, weil sie praktisch ideal für diese Anwendung sind. Wie der Anteil bei Windows-Usern der DD-Karten aussieht, kann ich nicht abschätzen. Wenn der Anteil klein ist und die Ausfälle nur sporadisch auftreten, kann das Problem bislang durchaus unerkannt geblieben sein.

    Hier wäre jetzt interessant auszuprobieren, ob genau diese Boards unter Windows auch Probleme machen.

    Das würde für ein Hardware-Problem sprechen (höheres Rauschen auf Grund der Integration von PCIe-Controller und CPU in einem Chip oder ...) .

    Wenn es unter Windows geht, könnte man gezielter suchen. Registerdumps vergleichen usw...




    Wurde eigentlich schon mal

    Code
    1. pcie_aspm=off

    versucht? Ich hab da irgendwie den Überblick verloren.



    Möglicherweise würde es helfen, einen kernel mit AER(advanced error reporting) zu bauen.

    Das soll bei Debian drin sein, soviel ich weiss.

    Allerdings bekomme ich bei lspci nur AER Capabilities bei der Realtek-Netzwerkkarte angezeigt.

    Code
    1. Capabilities: [100 v1] Advanced Error Reporting
    2. [...]

    Auch in /sys/kernel/debug/dynamic_debug/control gibt es nichts zu den PCIe-Bridges usw. Nur wieder zur NIC und den USB-Controllern.

    Entweder unterstützten meine Boards das nicht, oder man muss da noch irgendwas aktivieren.

    Von diesem "I2C timeout" scheint es (mindestens) zwei Versionen zu geben.

    Der feine Unterschied war mir bislang nicht bekannt. Den Thread: "Treiber der Cine-CTv6/DDBridge/CI in den Kernel integrieren" hatte ich nicht verfolgt.


    Einmal die "normalen" Timeouts, die manchmal mit "MSI=0" zu beheben ist.


    Und dann die mit "IRS ffffffff".

    Diese treten anscheinend nur oder hauptsächlich auf Apollo-Lake-SOCs auf.

    Auch wenn da irgendwo von Asrock geschrieben wird, halte ich den Boardhersteller nicht für ausschaggebend.

    das ist ein Problem zwischen Board und Karte bzw. dessen FPGA und nach aktuellem Kenntnisstand nicht per Treiberupdate fixbar


    Wenn ddbridge anfängt, I2C Timeouts ins Kernellog zu loggen, und hinter "IRS" steht "ffffffff", bedeutet das zu 99% nicht, dass zu irgendeiner Zeit Interrupts (egal, ob MSI oder Legacy/PIN based - msi=0) verloren gegangen sind, sondern dass die Kommunikation zwischen PCIe-Bus und Karte weggeschmiert ist (ffffffff = Fehler beim Lesen von IOMem).



    Es ist also offensichtlich nur eine winzige Kleinigkeit, die dazu führt, dass die ddbridge in den Zustand CorrErr+ geht.

    Viel ist es wirklich nicht, die Übertragung scheint irgendwie Grenzwertig zu sein.

    Und jede Art Last auf dem System scheint negativen Einfluss zu haben, mal mehr mal weniger.


    Neu ist die Entdeckung, dass man den Fehler mit rsync zuverlässig reproduzieren kann.

    Eigentlich müsste man jetzt mal mit einem PCIe-Tester ran und schauen, was da wirklich passiert. Das ist nur leider kein Ding, was man so mal schnell irgendwo ausleihen kann.

    Ich weiss nicht, wie das Interesse seitens DD an dem Thema aussieht. Aber DD und Linux4Media waren AFAIK im Münchner Raum ansässig und das Equipment haben sie sicher auch. Vielleicht wollen die sich den Aufbau mal an schauen. Schliesslich laufen ja alle anderen, getesteten PCIe-Karten und Devices auf dem Board fehlerfrei.


    Man könnte es noch mal mit Windows versuche, ob da die Karten da besser laufen.

    Wenn ja, könnte man das evtl. Treibermässig auf der Seite vom Mainboard was machen.

    Ich glaube, damit dürfte die Theorie, dass es an der Stromversorgung oder dem EPG-Scan liegt, widerlegt sein.

    Es war aber wichtig das auszuschliessen.


    Da ja USB letztendlich auch am PCIe hängt (über die Bridges) und USB + NIC keine Fehler bereitet, bleibt als Verursacher nur die DD übrig. Da außer dem VDR Forum auch in anderen Foren und Groups von I2C Timeouts berichtet wird, scheint das auch nicht auf ein spezielles MB Problem hinzudeuten. Das klingt alles irgendwie nach einem Designfehler der DD V7.

    Das sehe ich genau so.

    Ich hatte das schon länger befürchtet, wollte aber nicht voreilig der Karte die Schuld zu schieben, bevor nicht alles andere ausgeschlossen ist.


    Ein anderes Mainboard ist IMHO daher auch keine wirkliche Lösung. Das kann gehen oder auch nicht, reines Glücksspiel.

    Wirklich helfen kann da wohl nur DD, wenn man die Karten weiter verwenden will.


    Ich betreibe eine ältere DD Cine seit mehreren Jahren im Streamserver im Dauerlauf. I2C ist mir dort noch nie aufgefallen.

    Bei DD gibt es etwa 10 unterschiedliche Firmwares in deren Paket, die werden je nach PCI-ID der Karte verwendet.

    Durchaus möglich, dass da nur einige Karten betroffen sind.


    Es könnte Sinn machen es mal mit Statistik zu versuchen und funktionierende bzw. problematische Mainboard-Karten-Kombinationen sammeln. Der Test ist einfach und die Karten sind hier recht beliebt. Wenn man genug zusammen bekommt, sieht man vielleicht irgendwelche Zusammenhänge.

    Bei dem Test um den Fehler zu provozieren läuft immer nur Live-TV (im Transfer-Mode, da ja keine FF-Karte im System ist), und das Problem tritt immer mit dem Device auf, von dem das Live-Signal geholt wird.

    Also nur ein Live-Kanal und kein EPG-Scan im Hintergrund?

    Wenn es da schon Fehler gibt ist es schlecht, das ist ja praktisch der minimal Lastzustand.


    Es ging mir darum, ob die Fehler durch das Wechseln der Transponder vermehrt auftreten. Das könnte auf die Stromversorgung hin deuten.

    Oder ob es mit der Anzahl an Aufnahmen, die über die Karte gehen schlimmer wird.



    Ich betreibe das System mit einer Pico-PSU und habe damit eigentlich sehr gute Erfahrungen gemacht.

    Kann es aber zur Sicherheit noch mit einer "großen" PSU testen.

    Auch ich verwende eine Pico-PSU und halte die generell für zuverlässig.


    Problematisch sind da aber bei mehreren Zusatzgeräten die Kabelpeitschen. Das geht dann alles an einen kleinen Stecker an der Pico-PSU. von den Übergangswiderständen ist das nicht ideal.


    Dann sind die Steckernetzteile meistens nicht geerdet. Das kann Probleme bereiten, weil die SAT-Antenne geerdet sein sollte. Das kann zu Ausgleichsströmen über die Sat-Leitungen und damit zu Störungen führen.

    Die PCIe x1 Slots haben auch recht wenige Massepins, durchaus denkbar, dass es sich auch auf die Verbindung auswirkt.


    Ein Test mit einem anderen "herkömmlichen" Netzteil ist IMHO nicht verkehrt, zumal es recht schnell durchführbar ist.


    Dabei auch darauf achten, dass alle Masse-Verbindungen verbunden sind. (Netzteil-Gehäuse, Computer-Gehäuse, Slotbleche, Mainboard an Gehäuse, ...)


    Bei dem Test mit Spannung am Power-Stecker der DD-Karte zeigte lspci immer noch AuxPwr- für diese an. Sollte das nicht auf AuxPwr+ gehen?

    Keine Ahnung ob sich das laut Spezifikation ändern soll.

    Letztendlich sind das AFAIK aber alles nur Register auf der DD-Karte und die zeigen das an, was der Hersteller rein programmiert.


    Meine DVB-Sky zeigt übrigens auch AuxPwr- an, obwohl sie ohne Stecker nicht gescheit läuft.

    Code
    1. 02:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 04) Subsystem: Device 4254:0952[...] DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-

    Die beiden CorrErr+ stammen von der ddbridge und der Gegensation. Es treten also anscheinend alle paar Sekunden CorrErr auf (mache ich nur 'sleep 2' ist noch kein Fehler da).

    CorrErr sollten gar nicht kommen.

    "alle paar Sekunden" ist IMHO also definitiv zu oft.


    Ohne den rsync bleibt es lange Zeit konstant bei CorrErr-. Aber ab und zu tritt ein CorrErr+ auf, manchmal nur bei der Gegensation, manchmal bei beiden.

    Macht es einen Unterschied, ob nur Aufnahmen laufen oder ein EPG-Scan?


    Irgend etwas stimmt also wohl auch ohne besondere Last nicht an der Kommunikation mit der ddbridge...

    Deshalb auch meine Frage nach der Stromversorgung.

    So merkwürdige Fehler, die unter Last schlimmer werden hängen erstaunlich oft damit zusammen.


    Ausserdem gehen langsam die Optionen aus, wenn es am Link direkt liegt.

    Da gibt es zwar Werte, die man theoretisch ändern könnte, ich habe aber noch nichts dazu gefunden, wie man da ran kommt.