Posts by wwilde

    Ich hatte weiter oben geschrieben, dass schon ein Tuner gestartet wird (Annahme, da eine LED leuchtet) bevor VDR gestartet wird. Unter Windows ist das nicht so.


    Edit: Auf was ich hinaus will ist, wer weiß wie der Demodulator programmiert wird bevor VDR darauf zugreift. Vielleicht bringt das irgendetwas durcheinander. Es ist auf jeden Fall der offensichtlichste Unterschied zwischen Linux und Windows. Und was bzw warum wird ein Empfänger aktiviert bevor die eigentliche Anwendung (VDR) darauf zugreift?

    Das "was" kann ich dir vermutlich sagen - der udev-Daemon ist für die Bereitstellung der Geräte im System zuständig und lädt für potentiell bekannte Geräte jeweils die Kerneltreiber (z. B. Grafikkarten, Tastaturtreiber, Netzwerktreiber ....... etc. Dabei wird die Firmware in die Karte hochgeladen und das dürfte diese vermutlich deine LED bedeuten: Firmware hochgeladen und Karte betriebsbereit. Ändert sich die LED (Farbe? Blinken oder anderer Anzeigemodi?) wenn du den Betriebsmodus der Karte von DVB-T(1/2) auf DVB-C(1/2) änderst? Wenn nicht würde das für diese These sprechen, dass die LED lediglich die Funktionsbereitschaft des Tuners anzeigt.

    Suche doch einfach mal nach einem Prozess wie diesem: /usr/lib/systemd/systemd-udevd

    Einstellungen zum UDEV-Daemon in der Regel über /etc/udev/rules.d/, dort [...uuuups, hier fehlt noch was ==> edit!]


    ...dort liegt bei mir z. B. rtl-sdr.rules, wo entsprechende Parameter für die jeweiligen USB-IDs hinterlegt werden.


    Den ganzen anderen Krempel der hier zu finden ist hast du ja sicherlich schon ausprobiert (auch wenn's dieser Thread bereits von 2017 ist, grundlegendes hat sich hier ja bis auf die angebliche Unterstützung durch den Kernel an sich nicht geändert)?

    https://forum.ubuntuusers.de/t…ntv-dual-hd/#post-8846149

    Und Hauppauge weiß das alles nicht und produziert fleißig DVB Sticks die prinzipiell gar nicht funktionieren können? Das glaube ich nicht. Dann würden bestimmt die Hälfte aller verkauften DVB Sticks Retoure gehen. Und die andere Hälfte interessiert die Aussetzer nicht.

    Nein, es ist klar daß es natürlich im Normalfall funktionieren wird. Es kommt eben sehr oft darauf an, was alles schon an diesem einen konkreten USB-Adapter dran hängt. Wenn du z. B. das ganze an einem Notebook testest, dann könnte da z. B. ein Fingerprint-Reader, ein SD-Karten-Slot, eine HD-Kamera, ein Touchpad, ...... dran hängen. Sprich: Die ganz spezifische Konfiguration "drum herum". Das ist es was ich meinte. Nicht, daß Hauppauge unfähig wäre, funktionstüchtige Hardware zu produzieren. Dafür ist die Firma schon alleine viel zu lange am Markt und hat einen viel zu guten Ruf. ;)

    Das Problem an sich ist meiner Erfahrung nach bei USB in der Regel auch nicht der kontinuierliche *Durchsatz* sondern eher die Latenz vom Anliegen der Informationen am USB-Port bis diese dann vom USB-Treiber auch abgeholt werden. Hängt ein USB 2.0 Gerät an einem USB 3.0 Port so wird die Datenrate logischerweise auch in den USB-2.0 Modus und die niedrigere Durchsatzrate geschaltet und bremst so dann leider auch den USB3.0 Port aus.


    Im Gegensatz zu früheren Schnittstellen signalisieren USB-Ports auch *nicht*, ob aktuell gültige Daten auf Abholung warten. Wo ein Parallelport oder ein RS232-Port eben einen Interrupt erzeugt hat, um der CPU/ dem Programm mitzuteilen dass jetzt Daten anliegen, ist das moderne System eher auf "wird schon rechtzeitig abgeholt worden sein" angewiesen. Beim USB-Port wird halt zyklisch immer wieder gepollt "...hast du jetzt Daten anliegen?" ....... "....sind jetzt Daten für mich da?" und wenn du möglicherweise schon mehrere andere USB-Devices am selben USB-Port hängen hast dann ist die Wahrscheinlichkeit recht groß daß sich auch da schon andere Daten zur Abholung befinden und möglicherweise vor dem Stick abgearbeitet werden. Da der USB-DVB-T Stick die Daten aber meines Wissens nach auch nicht selbst in nennenswertem Umfang puffert, ist das Ding eben darauf angewiesen daß sie bereits vor eintreffen eines neuen decodierten Datenpaketes abgeholt wurden! Sonst sind diese Daten dann eben verloren weil sie bereits vom aktuellen Datensatz überschrieben wurden.


    Falls jemand gegenteiliges weiß - bitte gerne korrigieren! Nobody is perfect und ich lerne gerne dazu. ;)

    Ich hab die Sticks an nem normalen ATX Board, keinem Raspberry mit schwachem Netzteil o.ä. . Dennoch würde das erklären, warum es mit einem Tuner besser läuft als mit zweien -> Doppelte Leistungsaufnahme -> evtl. zu wenig mA für beide Tuner. [...]

    Eventuell hilft es auch schon, die Sticks an einen anderen USB-Port zu stecken. Oft teilen sich die USB-Ports auf unterschiedliche Controller und somit auch quasi mehrere Stromversorgungskreise auf - falls nicht ohnehin eine externe Stromversorgung via Hub vorhanden ist... ;)

    ==> Muß nicht unbedingt etwas bringen, ist aber in jedem Fall den Versuch wert.

    OK, bleibt für mich als eventuelle Fehlerquelle noch ein bei USB-Geräten ebenfalls beliebtes Thema - die Stromversorgung. Hast du schon mal versucht, die Sticks über jeweils ein kurzes Verbindungskabel an einem aktiven USB-Hub zu betreiben? Ideal wäre natürlich ein USB3-Hub mit eigenem Netzteil, aber prinzipiell sollte eigentlich auch ein guter aktiver USB-2.0 Hub mit wirklich guten USB-Kabeln seinen Dient tun.


    Vielleicht ist ja die Stromversorgung aus dem Computerport etwas "schwächlich"? Gerade viele Notebooks oder auch SOCs glänzen da nicht gerade mit allzu hohen Reserven. Nachdem sehr viele der USB-Sticks im Dauerbetrieb auch ordentlich warm werden ist leicht nachvollziehbar, dass die Dinger auch relativ viel Strom ziehen.

    Könnte es sich bei den Bildproblemen, gerade speziell bei den USB-Tunern die hier ja scheinbar gerade zur Diskussion stehen, nicht auch um ein generelles Problem des USB-Buses handeln? (Bandbreite bzw. Latenz?)


    Die Klötzchenbildung bei Szenenwechsel deutet für mich eigentlich schon in Richtung Bandbreitenproblem im Transportstream. Gerade im Augenblick des Szenenwechsels treten ja die höchsten Bitraten (naja, eigentlich Symbolraten :o) ) auf. Wenn dann der USB-Port von Haus aus nicht gerade der schnellste ist, es sich um HD- Format handelt dann könnte der Engpass in der Bandbreite da doch evtl. auch auf dem USB-Bus auftreten, oder nicht?


    Und der USB-Port wird ja prinzipiell immer nur im polling-Mode betrieben, d. h. der sendet garantiert keine Interrupts wenn gerade Daten auf Abholung warten...


    Und: Ja, es kann auch Probleme geben, wenn zu viele Teilnehmer bzw. Receiver gleichzeitig neue Transponder tunen möchten, das äußert sich bei mir aber vollkommen anders, nämlich in hartem aufhängen des Multi-Switches. Dafür genügen aber nicht nur einstellige Tunerzahlen... ;) Auch das kann aber in anderen Konfigurationen natürlich ganz anders aussehen. Je nach Marke und Qualität der einzelnen verwendeten Komponenten.

    Mal ne ganz blöde Antwort... jetzt wo du es fragst... ne ist noch keiner drauf gekommen die Spannungsversorgung auszuschließen. :S

    Naja, wenn ich lese dass das Board-BIOS die I2C Kommunikation stört (!?!)... Die Kommunikation mit der Karte erfolgt über die PCIe-Lanes, da gibt es keinen direkten I2C Port im PCIe-Slot. Deshalb wüsste ich nicht was das Mainboard - abgesehen von den physikalischen Parametern wie korrekter Abschluß der Lanes, gleiche Leitungslänge der beiden Leitungen für die differentielle Leitung wegen gleicher Laufzeiten für "Plus-" und "Minus-" Leitung des differentiellen Pärchens, die Gesamtleitungslänge der Lanes sowie dadurch bedingten Schaltkapazitäten der Lanes - an Einflüssen auf die Kommunikation bringen könnte. Bei modernen CPUs gibt es ja eh auch keine Northbridge mehr, also was bleibt dann noch großartig an Störeinflüssen in Bezug auf das Mainboard übrig. ;-)

    Mal eine ganz "blöde" Frage - habt Ihr schon mal an's Netzteil bzw. die Stromversorgung der Karte (via PCIe-Bus) gedacht? Kann man da Probleme ausschließen - bevor hier der gesamte PCIe Stack analysiert und zerpflückt wird und das ganze nur an einer etwas schwachbrüstigen oder verbrummten/ verrauschten Stromversorgung (altes Netzteil?) oder ungünstiger PCIe Slot mit den längsten Signalwegen liegt? Evtl. mal Brummspannungen messen, einmal am Netzteil und andererseits auf der Karte


    Falls mit Oszilloskop gearbeitet wird braucht ihr aber auf alle Fälle einen Trennstransformator, da das Oszilloskop auf der GND-Seite mit dem Erder der Stromversorgung verbunden ist und der Rechner bzw. auch die SAT-/ Antennenanlage jeweils ebenfalls einseitig geerdet ist und sich ansonsten eine Erdschleife/ Brummschleife bildet.

    So ganz verstehe ich das nicht, Helau. Der Hinweis auf evtl. Gefahr des Überhitzens innerhalb des Beamers und dadurch hochschalten der Lüfterstufe ist vollkommen berechtigt. Die Geräte sind nun mal so ausgelegt, daß heiße Luft nach oben steigen und von dort dann abtransportiert werden kann. Dumm allerdings, wenn dann die Elektronik als Deckel oben drauf liegt...


    Also gut gemeinte Hinweise willst du nicht haben - OK. Einen Vorschlag mit dem Raspberry wischst du auch gleich weg weil du nicht basteln willst. Erwartest du den Vorschlag: "Kauf dir doch 'nen Beamer, der von Haus aus für hängende Deckenmontage besser geeignet ist und einen leiseren Lüfter hat"?


    Sry, wer Vorschläge haben will sollte diese auch zumindest anhören wollen!

    OK, die SAT-Hardware scheidet also definitiv aus, wie sieht's mit der Tunerkarte aus? Entlädst du den Treiber für die DVB-Karte und lädst ihn neu bzw. rebootest den ganzen DVB-Rechner, oder bleibt der weiterhin aktiv und du startest nur die VDR-Software?

    Alles, was bis zum Zeitpunkt des "aussteigens" bereits getuned hat liefert bei mir im Fehlerfall jeweils auch weiterhin valide Daten, nur neue Tuning-Aufträge nimmt der SAT-Multiswitch in dem Fall dann gar nicht mehr an und die Tuningversuche laufen dann ins leere.

    Ja, genau, nur den Server neu durchstarten hilft, damit es wieder läuft...

    Reicht es, den VDR neu zu starten oder liegt's möglicherweise auch an DVB-Karte/Treiber? (Power-cycling bzw. rmmod/insmod nötig?) Ich betreibe selbst ein "etwas umfangreicheres" Setup mit mehreren DVB-S Streaming-Servern und wenn mehrere Server gleichzeitig mit jeweils 8 Tunerports nach Neustart anfangen alle Transponder zu tunen dann steigt dabei schon mal der Multiswitch aus. Das führt dann dazu, daß gar kein Tuner mehr einen neuen Stream bekommt und nur Power-cycling des (Kathrein-) Multiswitches diese Blockade wieder auflöst. Könnte natürlich sein, daß bei weniger Tunern ein Reset der DVB-Karte dieses Lock-up evtl. auch schon auflöst. Ein Problem beim Switch/ LNB könnt ihr vermutlich aber ausschließen, oder? Schon mal ausprobiert? Nicht, daß es deshalb nichts verdächtiges logt weil im Bereich VDR/ Streamdev Server gar nichts schief läuft sondern schon vorher!? ;)

    Seid ihr sicher, daß das Problem aus dem Streamdev Plugin und nicht vom System selbst kommt?

    Ich habe da etwas von "btrfs" im Avatarfenster gesehen - BTRFS macht aber z. T. auch Snaphots und/ oder ein rebalancing des BTREE Baumes. Während des Rebalancings hatte ich selbst auf meinem "Arbeitsknecht" (Notebook mit SSDs) früher schon mal mehrere Minuten lang ein komplett unresponsives System. Das hat dann eben auch wie geschildert noch nicht einmal mehr Logeinträge produziert. Mittlerweile hat sich das allerdings auch bei den aktuellsten Distributionen gebessert. Ich hatte allerdings mit BTRFS hin und wieder ein defektes und irreparables Filesystem, weshalb ich mittlerweile wieder auf andere Filesysteme zurück gegangen bin.

    Noch eine kurze Frage: Ist das Login von live eigentlich einigermaßen sicher?
    Also wäre es kritisch einfach per Port-Forwarding Port 8008 auf den VDR weiterzuleiten?

    Gruß,
    Grillbert

    IIRC erfolgt die Authentikation im VDR doch unverschlüsselt, oder? Da wäre direktes Port-Forwarding vermutlich vom SIcherheitsaspekt her nicht so prickelnd

    dbus2vdr hat seine eigene Liste an Aufnahmen. Die "Id" einer Aufnahme ist leider nicht das, was man bei einer Id erwartet. Richtig schön wäre es, wenn es in der Recording-Info eine uuid gäbe, die sich in der Lebenszeit der Aufnahme nie ändert und auch Neustarts des vdr überlebt.

    Man kann zwar SVDRP zum Verschieben von Aufnahmen benutzen, muss man aber nicht. Du kannst ja auch ganz normale Dateioperationen benutzen.


    Schade ist auch, dass MOVR nur die Id benutzt (die sich zwischen LSTR und MOVR ändern kann, falls der vdr zufällig neustartet). Die einzig zuverlässige Id einer Aufnahme ist ihr aktueller Pfad.

    Bin in der Vergangenheit auch schon über nicht eindeutige ID's gestolpert (Channels, Recordings, Timer...) - ich fände es klasse, wenn hier generell "Unique ID's" verwendet werden würden. Oder aber zumindest ein Mechanismus bei dem manuell eine Neuanordnung veranlasst werden muß. Diese Unique ID müsste ja eigentlich nicht durch den ganzen Code des VDR gezogen werden sondern "nur" generell als Zwischenschicht für alle User-Interaktionen verwendet werden. Oder liege ich da falsch? Wobei natürlich ein durchgängiges Konzept mit zusätzlicher Unique-ID vielleicht durchaus Vorteile haben könnte...