Beiträge von Xcoder

    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

    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

    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

    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

    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

    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

    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

    ...


    Um das zu lösen, muss man tiefer im VDR-Code drin sein, als ich es bin.
    Möglicherweise muss die ganze mutexReceiver Sache noch mal von Grund auf neu überdacht werden.


    Wenn doch jetzt die Situation von @jfie genau analisiert ist, könnte sich denn da nicht mal der ursprüngliche Author der Sache annehmen? Von wem stammt dieser Code? Bei mir sorgt das fast täglich für einen Hänger da ich praktisch nur die verschlüsselten CH Sender schaue.


    Gruss, Xcoder

    Gerade habe ich ihn wieder erwischt. Wenn ich das richtig sehe verhängen sich die Threads 1 + 19 (LWP 5424 + 5444):


    Grrr, doch wieder ein Deadlock:



    Gruss, Xcoder

    Ich habe epgsearch inzwischen allerdings (AFAIR nach einem Tipp von Louis) so gepatcht:



    Hallo,
    Bedeutet das, dass skindesigner momentan mit mcRecordingInfo oder mcTimer (aus epgsearch/menu_timersdone.c) nicht umgehen kann und mcUnknown einfach ein momentaner Workaround ist? Da es mit anderen Skins funktioniert, nehme ich an, dass epgsearch schon alles richtig macht.
    Gruss, Xcoder

    In cView::DoScaleTv() wird einfach cDevice::PrimaryDevice()->ScaleVideo(cRect::Null) aufgerufen. Skindesigner hat wohl gar keine Möglichkeit zu bestimmen wie das Fenster vorher ausgesehen hat. Die Grösse könnte man mit cDevice::GetVideoSize() abfragen, aber die Position nicht.


    Vermutlich sollte sich eher SoftHDDevice darum kümmern, dass bei ScaleVideo(cRect::Null) und noch aktiviertem PiP alles wieder wie zuvor angeordnet wird.


    Gruss, Xcoder