satip-plugin liefert periodisch keine PMTs

  • Hallo,


    Ich hatte festgestellt, dass VLC mit einigen Sendern Probleme hat und keine Wiedergabe hinkriegt. Nach einigem hin und her ist nun klar, dass streamdev-server keine PMTs auf diesen Sendern liefert wenn man per HTTP verbindet (z.B http://vdr:3000/TS/24). Damit kommt VLC nicht klar, andere Player, z.B. MPlayer X gehen trotzdem. Es kommen nur PATs und die Video und Audio PIDs.


    Nun ist es so, dass wenn man im LiveTV auf den gleichen Sender umschaltet, kommen plötzlich PMTs, und die Wiedergabe in VLC beginnt. Erstaunlich ist aber, dass ab diesem Moment keine PATs mehr geliefert werden, nur noch PMTs für diesen Sender...


    Speziell an meiner Installation ist, dass ich alle Sender via vdr-plugin-satip von 2 Quellen empfange. DVB-S kommt von minisatip, DVB-C kommt von einem OctopusNET. Obiges Problem besteh nur mit verschlüsselten DVB-C Sendern. Bei verschlüsselten DVB-S Sendern geht alles Wunderbar, habe aber nur SRF im Empfang.


    Ich habe mir mal den ganzen TS Stream auf einer DVB-C Frequenz angeschaut und da ist eigentlich alles OK. Auch der Empfang für Live TV geht problemlos. Löscht man betroffene Sender werden diese sauber wieder durch die Kanalaktualisierung erstellt sobald man auf einen anderen Sender auf der gleiche Frequenz zappt. Daher gehe ich davon aus, dass die Sender eigentlich korrekt geliefert werden.


    Hat jemand eine Idee wo man da am ersten suchen sollte?



    Danke und Gruss, Xcoder

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

    Einmal editiert, zuletzt von Xcoder ()

  • Hallo,


    Ich habe mal das DEBUG im streamdev Plugin aktiviert. Wenn ich mit VLC auf den entsprechenden Sender gehe (Live TV währenddessen auf einem anderen Sender), erhalte ich folgende Meldungen:



    Die PID 164 ist der PMT für den entsprechenden Sender. Auch die Audio und Video PIDs sind korrekt. Also auf den erste Blick alle i.O., ausser das sich streamdev einen Wolf loggt, aber das mach es auch bei Sendern die auf Anhieb gehen.


    Schalte ich irgenwann Live TV auf den gleichen Sender, passiert im Log nichts weiter. Es kommt weiterhin 13-14 mal pro Sekunde die cStreamdevPatFilter Meldung. Und der VLC hat Bild...


    Jemand mit einer Idee?


    Gruss, Xcoder

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

    Einmal editiert, zuletzt von Xcoder ()

  • Ich vermute mal ein bisschen:


    <vermut>
    Die verschlüsselten Sender über dvb-c entschlüsselst du mit dem bösen plugin direkt in vdr, die verschlüsselten dvb-s sender entschlüsselst du direkt im minisatip-daemon.
    </vermut>


    Ich sehe bei der o.g. Methode ähnliche Probleme. Allerdings läuft das mit VLC über streamdev nur beim ersten mal nicht richtig.
    Also: VDR-Startup,
    1. Versuch einen bestimmten Sender über VLC zu streamen: geht nicht.
    Direkt hinterher nochmal: geht.


    Das auch nur, wenn das böse Plugin im spiel ist.
    Wenn die Sender von minisatip-daemon angeliefert werden, sind die für VDR ja schon entschlüsselt und er macht direkt alles richtig.

  • Hi fkyle,


    Nein, in beiden Fällen, DVB-S und -C wird erst im VDR per pösem Plugin entschlüsselt. Ich nutze nicht das Feature in minisatip.


    Gruss, Xcoder

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

  • Hi, ob das hier das richtige Forum ist dafür? Sowas geht schon sehr arg in die Grauzone...
    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Jaja, welche Grauzone wohl? Der VDR hat eine API die von bestimmten Plugins genutzt werden. Und das ist hier nicht einmal das Thema.


    Siehe Forenregeln, diese sind ganz einfach und klar:


    Zitat

    Beiträge über das Manipulieren von Smartkarten und/oder das technische Verändern von Hardware und/oder das Installieren von Software mit dem Ziel "Umgehen eines Kopierschutzes" etc. sind hier verboten.


    Es hier in diesem Thema keiner der Punkte betroffen:

    • Manipulieren von Smartkarten -> Nein, es geht nicht um Smartkarten
    • technische Verändern von Hardware -> Nein, es geht nicht um Hardware
    • Installieren von Software... -> Nein, es geht nicht um die Installation an sich


    Falls es sich herausstellt, dass ein Fehler in einer der cCIxxx Klassen die Ursache ist für das Problem ist, auch dann gibt es kein Problem, da diese integraler Bestandteil des VDR sind und ansonsten konsequenterweise jede Diskussion über den VDR ausgeschlossen währe.


    Fertig. Also bitte wieder zurück zum Thema.


    Danke und Gruss, Xcoder

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

  • Hi, CI geht, nur CI+, das gewollterweise nicht mit PCs geht, tut nicht.


    Ich denke schon das Böse Plugin ist die Ursache.


    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • So, nach längerem Durchforsten von streamdev-server ist nun klar dass es nicht an diesem Plugin liegt. Die Methode cStreamdevLiveReceiver::Receive() erhält jeweils einzelne PMTs, dann erfolgt aber ein mehr oder weniger langer Unterbruch. Folglich erhällt also streamdev-server gar nicht alle PMTs obwohl die entsprechende PID korrekt angefordert wurde. OK, immerhin kenne ich nun den halben streamdev-Code...


    Vermutlich macht das satip-plugin etwas komisches. Ich sehe in den RTSPs Requests zum Sat>IP Server dass genau im gleichen Takt wie PMTs in streamdev-server ankommen die Anweisungen addpids=/delpids= mit der PID der entsprechenden PMT. Irgendetwas im satip-plugin scheinnt die PMT PID kurz einzuschalten und dann wieder zu deaktivieren... Das passiert bei allen Sendern, sowohl Kabel und Sat, verschlüsselt und unverschlüsselt, aber nicht mit der gleich langen Unterbrechung.


    Bei einigen Sendern ist nun wohl die Unterbrechung zu gross, so dass VLC aufgibt und nie mit der Wiedergabe beginnt, auch wenn dann doch mal ein PMT kommt.


    Komisch ist, dass es mit LiveTV gar keine Probleme gibt. Vermutlich sind für das softhddevice die PMTs nicht relevant.


    So, dann nehme ich mir mal satip zur Brust. Da hatte ich doch irgendwann ein Update gemacht...



    Gruss, Xcoder

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

  • Dank der Hilfe von rofafor habe ich nun die Ursache identifiziert. cPatFilter::Process() iteriert durch alle PMTs die ein Transponder liefert. In der Folge werden Aufrufe an cSatipDevice::OpenFilter() und cSatipDevice::CloseFilter() mit den PMT PIDs gemacht und die PID des PMT vom aktuellen Sender wird aktiviert und wieder deaktiviert auch wenn zuvor die PID eigentlich mit cSatipTuner::SetPid() aktiviert wurde.


    Was soll mit einer PID passiert die mit SetPid() aktiviert wurde wenn danach OpenFilter()/CloseFilter() aufgerufen wird? Sollte ein cDevice die mit SetPids() aktivierten PIDs nicht fix liefern? Wenn ich die Dokumentation von cDevice lese sollte CloseFilter doch eigentlich einen PID nicht deaktivieren, sondern nur den file handle schliessen.


    Gruss, Xcoder

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

  • In cPatFilter sollte die PAT nach PMT-Pids abgesucht werden und dann für jede dieser dort gefundenen PMT Pids eine cFilter abgeleitete Klasse benutzt werden, um die Services zu finden.


    Also erst eine cFilter abgeleitete Klasse mit PID=0x00 und TID=0x00 (PAT), und dann der Reihe nach mehrere cFilter mit PID=xxx und TID=0x03.
    Der cSectionhandler hat die file handles und sorgt dann dafür, dass die PIDs erst deaktiviert werden, wenn kein andres cFilter diese PIDs nutzt. CloseFilter() wird dort nicht direkt aufgerufen, erst wenn der used counter kleiner 1.




    Andererseits ist ein TS vom satip Plugin imho nur komplett, wenn es eine PAT gibt, und für jede der in der PAT aufgeführten ptm pids eine PMT sowie die Streams dazu aus der PMT.

  • Was macht denn cDvbDevice im vdr?


    Lars


    Bei cDvbDevice wird mit open() ein neuer File-Handle geöffnet und darauf die PIDs aktiviert/deaktiviert "ioctl(f, DMX_SET_FILTER, &sctFilterParams)". Der Empfang für Live TV/streamdev läuft über einen ander File-Handle mit eigner PIDs Auswahl und ist so völlig unabhängig von dem was der cSectionHanderl respektive cPatFilter tut. Dort wird es also auf Linux DVB Ebene geregelt.



    Gruss, Xcoder

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

  • Falls das streamdev Plugin wirklich section data (PAT/PMT/SIT/TDT/NIT/..) abruft ohne eine von cFilter abgeleitete Klasse, wäre das eigentlich ein bug im Plugin.


    Zitat Plugins.html:

    "If you want to receive section data you have to implement a derived cFilter class "

  • Dann kann VDR dem Plugin SI Tables nicht abschalten.

  • Kurzes Update: Die OctopusNet Firmware 1.0.72 hat noch einen Bug welcher bei bestimmten addpids RTSP Requests die angeforderten PIDs dann doch nicht liefern. Bei mir passiert dass bei einigen Sendern wenn per streamdev-server empfangen wird. Zufällig handelte es sich um die PMT PIDs... Für die nächsten Tage hat Digital Devices ein Update versprochen.


    Gelegentlich fallen aber die PMTs dennoch aus. Es könnte auch noch ein zusätzlicher Bug im satip-plugin geben, der bei cSatipDevice::CloseFilter() die PID abmeldet, obwohl diese vorher vom Receiver mit cSatipDevice::SetPid() angefordert wurde. Die Implementation im cSatipDevice ist nicht genau identisch wie im cDvbDevice. In meinem Fork vom satip-plugin gibt es einen teilweise getesteten und wohl noch unvollständigen Fix dafür (https://github.com/REELcoder/vdr-plugin-satip.git).


    Gruss, Xcoder

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

    Einmal editiert, zuletzt von Xcoder ()

Jetzt mitmachen!

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