[Gelöst] Artefakte mit satip-plugin bei gleichem Bouquet

  • Hallo und guten Tag!


    Vorliegendes Szenario:


    Selfsat IP36 (FW version 2.2.19, HW version 0.2)

    -> Switch (DGS-1210-24)

    -> VDR (auf Debian Buster) mit vdr-plugin-satip 2.4.0-1


    Der Rest dahinter (VNSI, Libreelec und/oder Kodi) ist uninteressant, weil das Problem schon bereits bei Aufnahmen auftritt.


    Per se funktioniert das alles ausgezeichnet, mehr oder weniger ootb, gute Qualität und stabil. :-)


    Wenn ich jedoch zwei Kanäle aufzeichne oder ansehe, die im selben Bouquet liegen (zB KiKa und 3Sat), dann bekomme ich zuhauf Artefakte.


    Das passiert ab just dem Moment, in dem ich den zweiten Kanal zuschalte.


    Es gibt keinerlei Fehler, wenn die Kanäle in verschiedenen Bouquets liegen, auch bei 5 HD-Streams gleichzeitig.


    Ich habe schon allerhand getestet. In den Logs findet sich nichts Relevantes (VDR Log-Level 3), und auch Wireshark zeigt keinerlei Auffälligkeiten.


    Ich habe auch im Netz nachgeforscht, zu speziell diesem Problem findet sich jedoch nichts. Weder ein Firmware-Upgrade der Selfsat (kann ich eh nicht, da kein Windows-Rechner vorhanden) hilft (hat bei niemanden [mit anderen Problemen] etwas gebracht [war immer Netzwerk, speziell Fritzbox und Billig-Switches]), noch das Verändern der satip-plugin Konfiguration über die vorhandenen Optionen (in /etc/vdr/conf.d/50-satip.conf und /var/lib/vdr/setup.conf).


    Bin ratlos. Hilfreich zur Fehleranalyse wäre ein Schalter im VDR à la "Verwende immer ein neues Device, auch wenn der Kanal im selben Bouquet liegt". Aber so etwas gibt es ja nicht, oder ich finde es nicht.


    Falls jemand Vorschläge hat, was ich noch untersuchen könnte, so wäre ich dankbar.


    Noch ein wenig Info:


    Außer vdr-plugin-vnsiserver 5:1.6.0-dmo1 kein weiteres Plugin im VDR.


    Das bekannte EPG-Scan-Problem der Selfsat habe ich mit Ausschalten des Scans umgangen (ein nächtlicher Scan via cron tut's auch).


    Beende ich die Aufnahmen, so bekomme ich im Log buffer stats: 1% used o.ä. Am Buffer liegt es also schon mal nicht.


    Probiert in /etc/vdr/conf.d/50-satip.conf:

    Code
    1. # -d 4
    2. # -s 192.168.178.39|DVBS2-8|SAT2IP->AS_B3S100_V2
    3. # -s 192.168.178.39|DVBS2-8|SAT2IP->AS_B3S100_V2;192.168.178.39|DVBS2-8|SAT2IP->AS_B3S100_V2
    4. # -S
    5. # -n

    Bringt alles nichts.

  • Mehr Info :-)


    Die IP36 startet mit:


    Code
    1. Jan 1 00:00:06 kernel: DVB: registering new adapter (Abilis TB100 DVB framework)
    2. Jan 1 00:00:11 kernel: MxLWare 2.1.1.7-RC100, F/W 2.1.1.7-RC100, chip MXL584, Id 1, Ver 2
    3. Jan 1 00:00:11 kernel: tb100_adapter tb100-dvb-adapter0.8: DVB: registering adapter 7 frontend 0 (Hydra)...
    4. Jan 1 00:00:12 kernel: tb100_adapter tb100-dvb-adapter0.8: LPU0, tb100_sp_fw V1.0 (Sep 12 2014 08:51:48)
    5. Jan 1 00:00:12 kernel: DVB: registering new adapter (Abilis TB100 DVB framework)
    6. ...


    Sagt mir leider nix, und schnelles googeln bringt auch nix... Muss ich nochmal ausführlicher machen.


    Im satip-plugin findet sich in server.c der Quirks-Abschnitt, in dem verschiedenes gequirkt wird:


    Hier taucht der ID-String der IP36 SAT2IP->AS_B3S100_V2 gar nicht auf. Gut oder schlecht?! ;-)


    Ich könnte ja versuchsweise da mal reinfassen und auf gut Glück verschiedene Quirks zuordnen...


    Wäre das sinnig?


    -----


    Edit:


    Ah, geht auch über die Optionen:

  • Ich habe in der setup.conf


    satip.OperatingMode = 3


    Und den Satip-Server habe ich fix konfiguriert. Bei Dir ist in der satip.conf alles auskommentiert. Ich würde da folgendes setzen:


    -d 8

    -s 192.168.178.39|DVBS2-8|irgendeinname


    Gruss

    VDR: Zotac ZBOX EN860, 16GB RAM, 2 TB HDD, Debian Stretch, vdr-2.4.1, softhddevice, satip

  • satip.OperatingMode = 3 ändert nichts, schadet aber auch nichts.


    Quote

    Bei Dir ist in der satip.conf alles auskommentiert.

    Das ist mir schon klar, dass ich die # zum Testen weglassen muss. ;-)


    Ich habe jetzt mal alle Quirks mit -s 192.168.178.39|DVBS2-8|SAT2IP->AS_B3S100_V2:0x7f angeschaltet, als auch einzelne getestet, aber es ändert sich auch nichts. So langsam bin ich mit meinem Latein am Ende.


    Ich bin geneigt die Entwickler zu kontaktieren, wobei ich nur raten kann, ob der VDR oder das satip-Plugin verantwortlich ist... :/


    Hat noch jemand Vorschläge, bitte?


    Edit: an Flaschenhälsen kann es nicht liegen, Rechner, Switch und Kabel sind alle völlig ausreichend, - nur falls da Fragen wären... Zumal ja alles wunderbar funktioniert (außer die Kanäle liegen im gleichen Bouquet)...

  • Firmware vom Switch ist aktuell. Der Switch ist nicht das Problem, die NICs auch auch nicht (Wireshark, iptraf-ng melden gar nichts).


    Ich habe nun alles doppelt und dreifach überprüft. Der Fehler tritt in jedem Transponder auf, sobald ich mehrere Aufnahmen/Wiedergaben davon starte.


    Ich weiß, dass der VDR das per se kann, es ging früher mit den PCI DVB-S2 Karten ohne Probleme. Also vermute ich ein Problem mit dem Satip, welcher Art auch immer. Netzwerk kann's de facto nicht sein, weil ich einwandfrei 5 oder 6 HD-Streams von verschiedenen Transpondern zu den Clienten bringe. Die Clienten sind's auch nicht, weil das Problem bereits auftritt, wenn ich nur aufnehme.


    Bin etwas ratlos. Jeder Vorschlag ist willkommen...


    thx, p3t3er


    Edit: falls das jemand mal testen will und/oder kann: gleiche Transponder sind zB "3sat HD, KiKa HD, ZDFinfo HD" oder "Das Erste HD, Arte HD, SWR BW HD". Damit ihr nicht suchen müsst... ;-)

  • Hi,

    if the SelfSat IP36 has similar hardware like the Inverto IDL4K (Digibit R1, Grundig ...) it may has similar issues.

    https://github.com/perexg/sati…/2#issuecomment-116223458

    https://tvheadend.org/boards/4/topics/18253


    SelfSat Firmware update?


    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    The post was edited 1 time, last by 9000H ().

  • Selfsat hat neueste Firmware (3.1.18). Hat nichts geändert.


    Danke für die Links, die werde ich mir mal zu Gemüte führen. Habe schon via Port QoS höchste Prioritäten vergeben, da ändert sich aber leider auch nichts am Verhalten.

  • Ich hab alles getestet: QoS an, Qos aus, verschiedene Varianten, - alles durch. Es geht nicht.


    Nochmal: es geht wunderbar, wenn ich 5 oder 6 HD-Streams durchjage. Sobald aber 2 auf dem gleichen Transponder liegen, zicken diese beiden, der Rest läuft unbeeindruckt weiter.


    Ich denke nicht, dass das am Netzwerk liegt.

  • Keine "richtige" Lösung in Sicht, aber ich habe einen quick&dirty Workaround gefunden: wenn man bei doppelt/dreifach belegten Transpondern die channels.conf so verändert, dass bei Sender Eins "S19.2E" (also der originale Eintrag) steht, bei Sender Zwei aber "S19.3E", bei Sender Drei "S19.4E", so wird jeweils ein neues Device benutzt. Die falschen Sat-Positionen scheinen den VDR nicht zu stören. Jedoch muss in der /var/lib/vdr/setup.conf folgendes gesetzt werden: UpdateChannels = 2.


    In der sources.conf ergänzt:

    Code
    1. S19.2E Astra 1KR/1L/1M/2C
    2. S19.3E Astra 1KR/1L/1M/2C
    3. S19.4E Astra 1KR/1L/1M/2C
    4. S19.5E Astra 1KR/1L/1M/2C
    5. S19.6E Astra 1KR/1L/1M/2C




    hth, falls jemand das gleiche Problem hat.

  • Änderung im vdr-plugin-satip in device.c:


    Ich habe noch nicht alle Aufnahme/Wiedergabe-Szenarien durch getestet, aber es scheint so zu funktionieren wie erwartet: es wird jedesmal ein neues Device angefordert, auch wenn der Transponder bereits abgegriffen wird.


    Irgendwann werde ich mal die Zeit haben einen Quirk dazu zu basteln. Irgendwann... ;-)


    Edith: nochmal verändert, weil es sporadisch zu VDR-Restarts bei Aufnahmen kam.

    ...

    Edith 9: jetzt läuft es. Keine Fehler mehr, auch bei voller Auslastung auf bis zu 8 Devices, mit gleichzeitigen VNSI-Clients und Aufnahmen, in verschiedensten Kombinationen. Sogar ein parallel gestarteter EPG-Scan brachte nichts aus dem Tritt. - Das Problem bestand wohl darin, dass diese Funktion nicht nur aufgerufen wird, wenn ein neuer Stream initiiert wird, sondern auch, wenn sich bei einem laufenden Stream die PIDs ändern.


    Edith 10: falls ein Device bereits den Channel empfängt, so werden weitere Clienten, die exakt diesen Channel auch wollen, auf das Device aufgeschaltet. Dies wurde notwendig, weil es sonst in seltenen Fällen zu "emergency exits" kam, - warum auch immer.


    Achtung: der Parameter UpdateChannels muss auf 2 stehen, sonst werden Sender in der channels.conf als OBSOLETE markiert. Bei Multicast gab es Probleme mit dem Freigeben von Devices, deshalb verwende ich satip.TransportMode = 0.