LNB Sharing: Probleme beim Zapping (LiveTV)

    Hallo, wie im folgenden Post (Ausgangs-Thread) angekündigt hier die Probleme die ich (und mindestens noch ein anderer) mit dem LNB Sharing habe:
    http://vdrportal.de/board/thread.php?postid=939032


    Weiterer Querverweis ins yaVDR-Forum:
    http://vdrportal.de/board/thread.php?threadid=97341


    Verwendetes System: yaVDR 0.2, welche Version des Patches da drin ist weiss ich nicht genau, aber hotzenplotz5 hat ihn eingebaut, und in folgendem Thread findet man ihn aufgeführt: http://vdrportal.de/board/thread.php?threadid=99180


    Ich habe die Karte Mystique Satix S2 dual V2, die zwei DVB-S2 devices stellt, und die vom VDR immer vor meinem zusätzlichen DVB-T device erkannt werden. Ich habe für beide devices LNB 1 konfiguriert (VDR-Einstellungen / LNB). Seltsamerweise wird auch dem DVB-T-device der LNB 1 zugewiesen..


    Code
    Sep  7 20:08:43 flgmedia vdr: [869] frontend 0/0 provides DVB-S2 with QPSK ("STV090x Multistandard")
Sep  7 20:08:43 flgmedia vdr: [869] frontend 0/1 provides DVB-S2 with QPSK ("STV090x Multistandard")
Sep  7 20:08:43 flgmedia vdr: [869] frontend 1/0 provides DVB-T with QPSK,QAM16,QAM64 ("Siano Mobile Digital MDTV Receiver")


Sep  7 20:08:43 flgmedia vdr: [869] LNB-sharing: setting device 0 to use LNB 1
Sep  7 20:08:43 flgmedia vdr: [869] LNB-sharing: setting device 1 to use LNB 1
Sep  7 20:08:43 flgmedia vdr: [869] LNB-sharing: setting device 2 to use LNB 1

    Beide Anschlüsse der Karte sind an einem einfachen Kabel-Verteiler (2fach) angeschlossen, der mir beide Anschlüsse gleichberechtigt zu versorgen scheint, da das folgende Verhalten unabhängig vom jeweiligen Ausgangs-Device ist. Also Steuerspannungen werden von beiden Ausgängen zurück zum LNB geleitet.


    Etwas seltsam: im femon werden bei einem der zwei DVB-S2 devices keine Qualitäts/Stärke-Werte angezeigt und als Name nur DVB-S und Siano (entsprechend dem DVB-T-Stick). Beim DVB-T zeigt femon garnichts. Daher dürfte das alles nur ein femon-Problem sein. Beide DVB-S2 devices zeigen problemlos HDTV.


    Ausgabe läuft über xineliboutput mit vdpau.


    Jetzt zum eigentlichen Kern der Sache: das Verhalten bzgl. des LNB Sharing. Befindet man sich auf einem der Haupt-SD-Sender (ich nenne das mal die "Haupt-Ebene", für deutsche Sender: horizontal / hohe Frequenzen) und will dann umschalten auf einen HDTV-Sender (ARD/ZDF/arte HD aber auch arte SD oder EinsPlus, "HDTV-Ebene", horizontal / niedrige Frequenzen), dann klappt das erst mal nicht: schwarzer Schirm (auch kein "no signal").


    Und das ist ganz offensichtlich so, weil das zweite freie device nicht ebenfalls in die HDTV-Ebene umgeschaltet wird, was aber natürlich notwendig wäre. Die Haupt-Ebene scheint im Zweifel zu "gewinnen", wenn die devices unterschiedliche Ebenen anfordern, vermutlich weil dort die "Steuer-Spannung" dominant ist oder sowas. Jedenfalls gibt es keine Probleme in umgekehrter Richtung, wenn man von HDTV auf SD umschaltet. Gleiche Probleme wiederum, wenn man von den Haupt-Sendern auf Sport1/Tele5 umschaltet (nochmal eine andere Ebene, eine vertikale, ebenfalls "unterlegene").


    Was man tun muss, um ein Bild zu erhalten ist, auch das zweite device in die HDTV-Ebene zu bringen. Da VDR wohl round-robin mit den devices macht, muss man dazu nur noch einen anderen HDTV-Kanal auf einem anderen Transponder ansteuern, dieser funktioniert dann, und anschliessend auch der ursprünglich gewollte. Alternativ kann man mit femon das device für den angewählten Sender umschalten, was ebenfalls zum Erfolg führt (wohl weil dann eben beide in der HDTV-Ebene liegen).


    Wie ich eben noch festgestellt habe: wenn man gut 1min abwartet, dann kommt der Sender auch von selbst noch. Warum kann ich dem Log nicht entnehmen. Im folgenden Fall wird um 00:50:28 umgeschaltet, um 00:51:47 dann kommt das Bild


    Bei Aufnahmen dagegen findet man knapp 1min vor dem Timer im Log, dass schon mal das "andere" device vorbereitend umgeschaltet wird, daher funktionieren diese dann problemlos. Das Live-Bild bleibt allerdings einfach stehen, daran ändert sich auch dann beim eigentlichen Timer-Start nichts. Man muss halt dann umschalten auf einen Sender der passenden Ebene.


    Code
    Sep  8 01:11:10 flgmedia vdr: [869] switching device 2 to channel 41
Sep  8 01:11:19 flgmedia vdr-sxfe[1398]: [1423] [input_vdr] No data in 8 seconds, queuing no signal image
Sep  8 01:11:19 flgmedia vdr-sxfe[1398]: [1423] [input_vdr] using custom "no signal" image /usr/share/libxine1-xvdr/nosignal.mpg
Sep  8 01:11:21 flgmedia vdr: [1379] frontend 1/0 timed out while tuning to channel 0, tp 682
Sep  8 01:12:00 flgmedia vdr: [869] switching device 1 to channel 41
Sep  8 01:12:00 flgmedia vdr: [869] timer 3 (41 0112-0114 'Alles nur Tarnung') start


    Im zweiten oben verlinkten Thread meldet tüddelkopp die gleichen Probleme.


    Übrigens zählt VDR die devices ab 1, also 1, 2 (DVB-S2) und 3 (DVB-T), anders als die obige LNB-Sharing-Log-Ausgabe mit 0,1,2!


    Danke für jede Hilfe!

    Nachtrag: sobald ein device eine Aufnahme macht, wird wie erwartet beim anderen ggf. "Kanal nicht verfügbar" angezeigt, wenn man einen Sender aus einer nicht dazupassenden Ebene wählt.


    Falls noch weitere Log-Auszüge zu bestimmten Aspekten benötigt werden, versuche ich die so schnell wie möglich nachzuliefern!

    Einmal editiert, zuletzt von hivdr ()

    Weiterer Nachtrag: ziehe ich den DVB-T-Stick ab, so ist das Verhalten soweit unverändert wie beschrieben! Das dritte device hat also nichts mit den Problemen zu tun!


    Sozusagen off topic: femon zeigt nur mit den beiden DVB-S2-devices nur mit dem ersten überhaupt etwas an, beim zweiten sieht man keine Anzeige (muss aber trotzdem mit "exit" femon wieder verlassen, sonst ist zB OK wirkungslos - so wie vorher beim dritten DVB-T-device). Schaltet man (per Pfeil-rechts) im femon vom ersten auf das zweite device um, so zeigt er als Name korrekt an: DVB-S2 #1 (statt #0) STV090x.

    Und weiter: nach aktuellem Update yaVDR alles unverändert.


    Habe mal das source-Paket "vdr" installiert und finde unter
    vdr-1.7.15/debian/patches


    die Datei opt-57_lnb-sharing.dpatch mit Inhalt
    ## opt-57_lnb-sharing.dpatch by MarkusE at vdrportal
    ...
    diff -u -r -N vdr-1.7.14/config.c vdr-1.7.14-lnb/config.c


    Scheint also schon Deine aktuelle Version für 1.7.14 (aber gegen 1.7.15) verwendet worden zu sein!

    Hallo hivdr,


    Setze doch mal im VDR unter Einstellungen -> LNB -> LNB-Nutzung protokollieren auf 'ja'.
    Dann sollte Dein Log etwa so aussehen:


    Code
    Sep 15 19:31:22 vdr1 vdr: [1493] LNB 1: Request for channel 2 on device 1. MaxBadPriority is -1
Sep 15 19:31:22 vdr1 vdr: [1493] LNB 1: Request for channel 2 on device 1. MaxBadPriority is -1
Sep 15 19:31:22 vdr1 vdr: [1493] switching to channel 2
Sep 15 19:31:22 vdr1 vdr: [1493] LNB 1: Request for channel 2 on device 1. MaxBadPriority is -2
Sep 15 19:31:22 vdr1 vdr: [1493] LNB 1: Request for channel 2 on device 1. MaxBadPriority is -2
Sep 15 19:31:22 vdr1 vdr: [1493] LNB -8: Switching device 2 to channel 2
Sep 15 19:31:22 vdr1 vdr: [1493] LNB 1: Switching device 1 to channel 2


    Und poste dann den Log, wenn das Umschalten nicht funktioniert.


    Noch eine Frage: Steht DiSEqC benutzen auf 'ja' oder 'nein'?


    Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    MarkusE


    Danke dass Du Dich damit auseinandersetzt, bei mir ist allerdings der Urlaub inzwischen vorbei, und ich werde nun erst wieder in zwei Wochen bei dieser Kiste ("VDR3") vor Ort sein. Darum kann ich erst dann das tun / was dazu sagen.


    Dass mir diese Option "protokollieren" nicht aufgefallen ist, wundert mich, kann aber nat. schon sein.
    DiSEqC ist mit hoher Wahrscheinlichkeit aus, denn ich habe jedenfalls nie etwas in der Richtung gemacht, und das sollte ja per default wohl nicht aktiviert sein.


    Ich melde mich dann. Vielleicht mag sich ja tüddelkopp in der Zwischenzeit auch mal damit beschäftigen.

    So, lange hats gedauert, aber nun habe ich das Protokollieren mal eingeschaltet (DiSEqC ist wie vermutet abgeschaltet), und folgendes passiert. Kanal 41 ist ARD HD, wobei ich mich vorher auf SD-Programmen rumgetrieben hatte.



    Frage mich natürlich was LNB "-8" sein soll, und "device3" - könnte das DVB-T sein, wobei ja aber der LNB-Sharing-Patch von 0 ab zu zählen scheint, demnach dürfte es nur 0,1,2 geben. Und wie gesagt, auch ohne den DVB-T-Stick ist das Problem das gleiche.


    Noch ein Versuch.. Wieder ausgehend von SD Sender zu ZDF HD (42).


    Wartet man eine Minute, dann kommt das Bild doch noch (im Log wohl zu sehen ab der Zeile mit [xine..put]) - wenn auch oft ohne Ton (aber damit habe ich auch so gelegentlich kleine Probleme).


    Und nun nochmal ohne DVB-T-Stick, nur die zwei DVB-S2 devices der Satix-Dual-Karte.


    Kanal 45 (mittleres Log) und Kanal 4 (unteres Log) sind übrigens auch jeweils Kanäle der HDTV-Ebene (Servus-TV und arte SD). Man sieht also ganz gut: sobald auch das zweite device auf die richtige Ebene geschaltet wird, ist das Bild da - aber warum passiert das immer erst (ziemlich exakt) 1min später??
    Verwirrend auf jeden Fall immer: in den Zeilen mit LNB -x scheinen die devices mit 1,2 statt 0,1 gezählt zu werden.


    Also, ich hoffe der Kenner erkennt jetzt was vor sich geht. Bin gespannt.

    Einmal editiert, zuletzt von hivdr ()

    auch ich bin sehr an einer Lösung interessiert ;)
    ist so ganz schön lästig und ich kenne mich leider zu wenig aus um selbst eine Lösung zu finden, testen kann ich allerdings ;)


    spockele

    YaVDR 0.4
    TechnoTrend Budget S2-1600 HDTV, Skystar 2.6, KNC1 DVB-T; GeForce 9600 GT
    DENON AVR-1706 und Teufel Conzept E (Magnum) - Lautsprecher, Samsung UE40B7000

    Einmal editiert, zuletzt von spockele ()

    Schön dass sich noch wer meldet. Dann wissen wir jetzt von drei Personen - auch noch nicht das ganz starke Argument viel Zeit zu investieren, fürchte ich. Also jeder der sich denkt "betrifft mich auch" doch auch bitte hier sagen.. und möglichst noch dazusagen in welchem Kontext, also VDR-Installation (bei mir und tüddelkopp wars yaVDR 0.2).


    Zitat

    testen kann ich allerdings


    Ja dann nix wie los: Protokollieren einschalten und einen Log-Auszug von so einem erfolglosen Umschalt-Vorgang posten. Sollte natürlich in etwa aussehen wie bei mir, aber dann ist es zumindest mal von zwei Leuten bestätigt, und wenn nicht umso interessanter.. und vielleicht könntest Du auch etwas kurzfristiger als ich auf Lösungs-Vorschläge eingehen (bin ja im Moment nur recht selten bei der Kiste).

    Hallo,


    Ich hab Euch nicht vergessen. Es ist nur einiges dazwischen gekommen: Meine C Entwicklungsumgebung ist in 10.04 nicht installiert (ich hatte den Patch unter 9.10 entwickelt).
    Und dann gab's 10.10 . Und ich dachte, ich könnte erst auf 10.10 upgraden, und dann die Entwicklungsumgebung installieren. Und dann gab's Probleme beim Upgrade ...


    Also, es wird wieder werden, und dann poste ich auch einen Patch zum Testen.


    In der Zwischenzeit, für die Tester:
    Sucht mal im Log nach Einträgen wie:



    Sollte helfen, die Zuordnung zwischen Device Number und Gerät zu machen. Ist leider etwas verwirrend, da manchmal von 0 an gezählt wird, und manchmal von 1 an. Und das xine Device erst als Nummer 9 genannt wird, und dann als Nummer 3 (s. oben, im von mir geposteten Log). Daran ist lnb-sharing übrigens unschuldig ...


    Interessant wären auch Log Einträge eine Minute nach dem Umschalten, wenn der Kanal wieder angezeigt wird.


    Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    MarkusE


    Danke dass Du noch "dran" bist!


    Ich werde so ab Sa 30.10. wieder vor Ort sein, dann etwas länger als nur das WoE. Melde mich dann mit den gesuchten Log-Einträgen.


    Allerdings denke ich dass in meinen oben bereits geposteten Logs das mit den devices doch recht klar ist: 0+1 (bzw. 1+2) sind die beiden DVB-S2 devices, im untersten Log habe ich DVB-T ja abgeklemmt, ansonsten ist es halt device 2 bzw. 3.


    Meine Log-Auszüge (Post vom 3.10.) enthalten auch jeweils schon einige Einträge von 1min nach dem Umschalten - siehe was ich dazu geschrieben habe. Man sieht jeweils einige Einträge mit LNB, ab der Zeile mit xine ist dann das Bild wieder da und ich glaube es kommt nichts weiter relevantes danach.


    Wenn es dann wirklich einen Patch gibt: ich hoffe ich bekomme das mit dem Patchen und build hin - bin da nicht sonderlich geübt. Auf dem anderen selbst-gebauten System (wo ich kein LNB Sharing brauche) wäre das schon klar (make etc), aber mit yaVDR bzw. dem ganzen Ubuntu (Source-)Package-Management und wie man so ein Paket neu übersetzt habe ich keinerlei Erfahrung. Je konkretere Anleitung Du geben kannst desto besser.. Danke :)

    Hallo,


    Ich habe einen 'update' des Patch. Sollte fehlerfrei gegen vdr 1.7.14 laufen.
    Vermutlich geht's auch mit neueren VDR Versionen, habe ich aber nicht getestet.


    Wie Du das in ein Ubuntu Paket bringst? Keine Ahnung, ich würde empfehlen, einen plain VDR zu nehmen, patchen, übersetzen, und testen. Und wenn der Fehler behoben ist, bringen wir die Korrektur schon in die Ubuntu Pakete. Falls nicht, gibt's einen neuen Patch.


    Markus

    Hallo zusammen... ich habe ein yaVDR 0.3 und mit einer Hauppauge WinTV HVR 4000 (Hybrid DVB-S2 mit Analog und DVB-T) umschaltprobleme ...
    von ZDF nach Anixe HD kann ich auch ca 1Min warten dan habe ich Bild ...
    auch auf SKY zu schalten habe ich lange Wartezeiten ...
    auf Hotbird zu wechselen bringt keine Probleme

    Aktuelles System yaVDR64 0.5.0a, Hauppauge WinTV NOVA-HD-S2, Mainboard ASUS P5N7A-VM, Bios 512MB eingestellt, 2 GB Ram, CPU Intel 7200
    Neu: ASUS Nvidia GeForce GT610 Silent 2GD3 und Hauppauge 5500 mit yaVDR 0.6.0 funktioniert noch nicht (kein Bild)

    Hallo Markus,


    danke für die Arbeit.
    Leider bin ich aber zu doof das zu testen. Kann das jemand anderes hier machen? Oder mir zumindest sagen was ich tun muss, oder einen Link schicken, wo kompilieren unter yavdr erklärt wird...


    spockele

    YaVDR 0.4
    TechnoTrend Budget S2-1600 HDTV, Skystar 2.6, KNC1 DVB-T; GeForce 9600 GT
    DENON AVR-1706 und Teufel Conzept E (Magnum) - Lautsprecher, Samsung UE40B7000

    Schön dass sich was tut, aber leider muss ich auch sagen: so mal eben in einem plain VDR testen bekomme ich nicht hin. Meinen Haupt-VDR habe ich zwar wie erwähnt auf diese Art ganz manuell selbst aufgebaut - aber da war ich entsprechend lange beschäftigt. Es ist ja nicht damit getan, den VDR allein zu übersetzen, man braucht mindestens noch die ganze xine-output-Geschichte, und die ist alles andere als trivial. Sorry, wenn ich das nicht im bestehenden yaVDR reinpatchen kann, wirds bei mir nichts mit dem Test.


    Aber vielleicht baut es uns ja hotzenplotz gleich rein in den yavdr.


    Allerdings bekommt man mittlerweile, wenn man ein normales yavdr-Update macht, wohl die aktuelle Version 0.3 - und ob das so problemlos updated von 0.2 wäre auch sehr interessant. Wie sind denn da die Berichte, kann man das riskieren? Auch diese Kiste ist mittlerweile im "Produktivbetrieb", ein Ausfall nach Update-Versuch wäre fatal..

    Zitat

    Original von spockele
    wo kompilieren unter yavdr erklärt wird...


    Da das Kompilieren unter yaVDR auch nicht anders ist als anderswo, gibt es solch einen Link natürlich nicht.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Einmal editiert, zuletzt von gda ()

    Hallo hotzenplotz5,


    Zitat

    Original von hotzenplotz5
    MarkusE kleiner hinweis :
    .metadata/.plugins/org.eclipse.cdt.core/


    jede menge davon im patch :schiel


    vielen Dank für den Hinweis. Werde das im nächsten Patch entfernen.
    Jetzt warten wir mal auf die Ergebnisse der Tester, ob der Fehler behoben ist.


    Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden