Beiträge von wwilde

    Ich stelle folgende Frage in den Raum:

    .. warum MUSS der vdr ( Core ) immer laufen ?

    Schau jemand ununterbrochen fern ?

    Ja, in meiner Verwendung laufen bis zu 8 Tuner pro Server permanent (24h*356) und liefern insgesamt so knapp 130 Radio-Streams an ein internes System aus. Die Kisten auf denen der VDR läuft haben aber relativ viel Speicher, so daß selbst bei monatelangem Dauerlauf kein echter Ausfall durch den Speicherverbrauch verursacht wurde. Restart des VDR erfolgt höchstens mal nach größeren Änderungen an der Kanaltabelle, falls manueller Eingriff nötig ist.


    Lustig ist, dass es auf der o.g. Seite unten rechts einen Link gibt, mit man eine channels.conf für den vdr erzeugen

    lassen kann... leider fehlen die ARD-Radiokanäle ...


    Grüße

    Bernie

    Das funktioniert mittlerweile offenbar. Also zumindest als Notlösung kann man darauf zurückgreifen - ich habe die dortige Liste für den Standort Hamburg zwar noch nicht auf Vollständigkeit getestet, aber zumindest ein Teil der Sender scheint einen Transport-Stream zu liefern.


    Vielen Dank an die guten Geister im vodafonekabelforum

    Leider habe ich trotz längerem Suchen bisher nicht gefunden, woran es liegt.

    Die Kanaltabelle vom VDR ist doch im Prinzip ein "moving target". Da kommen ja - je nach aktuellem Programm aller Sender - schon mal zusätzliche 5.1 Audiokanäle, Originalton.... etc. dazu oder verschwinden wieder. Das wird doch vermutlich im VDR im Memory gehalten, könnte sich da im Laufe der Zeit so viel ändern und der alte Eintrag in der "Tabelle" wird nicht gelöscht? 180MB/Tag wäre allerdings schon sehr viel. Selbst im Multi-Satelliten-Betrieb.

    Das log sieht normal aus.


    Die SRF Radiosender sind nie verschlüsselt. SRF Info ist gelegentlich auch nicht verschlüsselt, meistens wen Eigenproduktionen gesendet werden.


    Empfangsprobleme hast Du ausgeschlossen? Alle anderen Sender auf diesem Satellit gehen?

    Ja, alle anderen Sender funktionieren auf dem Rechner problemlos. Der TV-Sender FRANCE 2 z. B. lässt sich problemlos abspielen. (Der ist ebenfalls horizontal polarisiert und auf Eutelsat Hotbird 13. Der Empfangsweg *vor* dem VDR (Schüssel, LNB, Switch) ist also OK und der VDR schaltet auch auf den korrekten Satellit. Ich habe auch mal ausprobiert was passiert wenn ich dem VDR statt des "h" ein "H" im Parameterschlüssel unterjuble. Das hat er beim nächsten Neustart und Zugriff auf den Transponder auch sofort wieder in den korrekten Zustand zurück gesetzt. Ich denke also, daß die Auto-Update-Funktion für die channels.conf vollkommen richtig funktioniert.


    Könnte es sein daß der Streamdev-server vielleicht mit dem aus- und einpacken neuen Stream-Formats Probleme hat? Ich kann zwar nichts von fehlenden Abhängigkeiten entdecken, aber wird dafür noch irgend eine Library gebraucht? Ich vermute, die Radiostreams könnten vielleicht den HEVC (h264/h265) Codec verwenden? Nachdem das ganze bis zum 25.05.2021 auf dem alten Transponder einwandfrei funktioniert hat muß sich seit dem ja mit dem Transponderwechsel etwas grundsätzlich geändert haben.


    Die Streamdev(-server) Version 0.6.1 (stammt aus einem Debian Paket) scheint ja noch einigermaßen aktuell zu sein.


    Code
    vdr-Versionen:
    --------------
    vdr (2.4.0/2.4.0) - The Video Disk Recorder
    streamdev-server (0.6.1-git) - VDR Streaming Server

    An der channels.conf liegt es wohl kaum auch wenn Du hC23M5O35S1 hast und ich HC23M5O35P0S1. P0 ist ja eh nur der default für die Stream ID.


    Was sag denn das log vom vdr zu wenn der mplayer verbindet? Und eine IP 1.2.3.4 ist auch eher nicht so wie man es macht.

    lol - das mit der IP liegt wohl eher daran, daß ich logischerweise keine internen/ externen IP's oder auch Servernamen/ Domains auf Mailinglisten verbreite. ;)


    Das Log vom VDR sieht eigentlich ziemlich unspektakulär und normal aus: (IP's natürlich wieder anonymisiert, Zeitstempel und Hostnamen weg geschnitten)

    Code
    vdr: [10786] Streamdev: Accepted new client (HTTP) 3.2.3.4:43744
    vdr: [14716] device 4 receiver thread started (pid=10768, tid=14716, prio=high)
    vdr: [14715] streamdev-livestreaming thread started (pid=10768, tid=14715, prio=high)
    vdr: [14714] streamdev-writer thread started (pid=10768, tid=14714, prio=high)
    vdr: [14717] device 4 TS buffer thread started (pid=10768, tid=14717, prio=high)

    Ein Versuch mittels "MPlayer" den Stream wiederzugeben schlägt fehl, testhalber den Stream mittels wget zu downloaden bringt 0 Bytes Download.

    Schaut mir so aus als würde der Streamdev-Server die Verbindung problemlos zum VDR aufmachen und auf diesem den Sender selektieren. Könnte es sein daß der Datenstrom seit der Umstellung vom 25.05 auf den neuen Transponder eventuell auch verschlüsselt ist? Die Angaben darüber im Internet sind da leider sehr mehrdeutig. Das TV-Programm an sich ist jedenfalls nur mit CAM zu empfangen, ob das jetzt auch für das Radioprogramm gilt weiß ich leider nicht. Könnte sich das evtl. so äußern?

    Ist leider headless, also direkt updaten funktioniert nicht. Und wie gesagt - TV selbst ginge ohnehin nur mit CAM. Die Transponderdaten selbst habe ich ja aber eigentlich. Wenn dann könnte es sich höchstens um unterschiedliche decodierungsparameter handeln. w_scan hat mir ja bereits die aktuellen Transponderdaten selbst geliefert.

    Wenn du auf das TV gehst und im VDR "Kanäle und Transponder updaten" (oder so ähnlich) aktiviert hast, sollten auch die Radios in deiner channels.conf landen.

    Das wäre dann aber das TV-Programm, und für das bräuchte ich ein CAM, oder? Ich habe leider kein CA-Modul/Slot. Mir geht's eigentlich um die Radioprogramme. Hast du damit Erfahrungen?

    Versuch's mal mit

    Code
     SRF 1 HD;Schweizer Radio und Fernsehen:10971:HC23M5O35P0S1:S13.0E:29700:502=27:503=deu@3,504=eng@3;505=deu@106:507:500,4AFC:17201:318:12300:0

    Hallo zusammen,

    seit März 2021 stellt die schweizerische SRF/SRG ihre Satellitenprogramme (via Eutelsat Hotbird 13E) auf den Transponder 123 um. Ich wollte den Headless-Empfang auf den neuen Transponder umstellen, bekomme aber leider keinen Stream zustande. Andere TV-/ Radiostationen spielen über das physikalische Setup wunderbar, die Stationen der SRF/SRG leider nicht mehr. Auf den alten Transpondern/ Streams konnte ich das ganze problemlos empfangen.

    Hat jemand die Möglichkeit, das evtl. mal zu testen?


    so sehen bei mir die entsprechenden channels.conf Zeilen für einige der fraglichen Sender aus:

    Code
    SRF 1;Schweizer Radio und Fernsehen:10971:hC23M5O35S1:S13.0E:29700:0:211=ger@3:0:0:17221:318:12300:0
    SRF 1 AG SO;Schweizer Radio und Fernsehen:10971:hC23M5O35S1:S13.0E:29700:0:230=ger@3:0:0:17240:318:12300:0
    SRF 1 BS;Schweizer Radio und Fernsehen:10971:hC23M5O35S1:S13.0E:29700:0:231=ger@3:0:0:17241:318:12300:0
    SRF 1 BE FR VS;Schweizer Radio und Fernsehen:10971:hC23M5O35S1:S13.0E:29700:0:232=ger@3:0:0:17242:318:12300:0
    SRF 1 LU;Schweizer Radio und Fernsehen:10971:hC23M5O35S1:S13.0E:29700:0:233=ger@3:0:0:17243:318:12300:0
    SRF 1 SG;Schweizer Radio und Fernsehen:10971:hC23M5O35S1:S13.0E:29700:0:234=ger@3:0:0:17244:318:12300:0
    SRF 1 ZH SH;Schweizer Radio und Fernsehen:10971:hC23M5O35S1:S13.0E:29700:0:235=ger@3:0:0:17245:318:12300:0
    SRF 1 GR;Schweizer Radio und Fernsehen:10971:hC23M5O35S1:S13.0E:29700:0:236=ger@3:0:0:17246:318:12300:0


    Lyngsat liefert für die Frequenz. Polarisation und Symbolrate von Service ID 17221 z. B. folgende Informationen:

    10971 H
    tp 123
    Wide
    52-53
    DVB-S2
    8PSK
    29700
    2/3

    bzw. die Streamdaten:


    Die Transponderdaten habe ich im übrigen hier nochmal verifiziert:

    https://www.broadcast.ch/filea…ite_recept._d_f_i_V19.pdf



    Versuche ich, das ganze mit MPlayer wiederzugeben kommt lediglich folgende Ausgabe:

    VLC/ CVLC liefern leider überhaupt keine brauchbaren Meldungen, das Programm (ohne weitere Parameter abgesehen von der URL aufgerufen) scheint in einer Endlos-Loop auf den Datenstrom zu warten.

    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?