[gelöst] Keine EPG Anzeige für Das Erste HD, ZDF HD und NDR MV HD nach Wechsel von 1.7.29 auf 1.7.42


  • Hm, es gibt doch DTV_API_VERSION. Damit kann man die "running API-Version" abfragen...


    Danke für den Hinweis, irgendwie hab ich die Funktion ewig gesucht und immer daran vorbei geschaut...


    Anyway, es gibt ein Update für den s2apiwrapper, der das Problem mit Laufzeitchecks endgültig löst.


    Das Problem mit EPG bei DVB-S2 ergab sich übrigens präzise so:
    - Seit 1.7.40 sendet VDR ein DTV_STREAM_ID auch an DVB-S2 Karten.
    - Wurden die Quellen gegen Header DVBAPI 5.7 oder älter übersetzt, wird statt dessen DTV_DVBT2_PLP_ID gesendet.
    - Das geht schon mal gar nicht, weil dieses Kommando exklusiv nur für DVB-T2 ist.
    - Vor DVBAPI 5.3 ist selbst DTV_DVBT2_PLP_ID für DVB-T2 unbekannt.
    - Durch das eine fehlerhafte Kommando wird die ganze Kommandokette abgebrochen, was zum fatalen Versager führt.


    Und obwohl ich von dem Problem wusste, bin ich natürlich prompt blind selbst hinein gerannt, denn ich verwende DVB-Treiber direkt aus Powarman's Zweig, und der ist auf DVBAPI 5.2 stehen geblieben.


    Jedenfalls verwendet der aktuelle Wrapper jetzt Laufzeit-Codeweichen für API 5.3 und API 5.8.



    Gruß,


    Udo

  • Urig


    Cool, pack den Neuen grad in die Lucid/Natty Pakete, werde berichten ... :)


    Regards
    fnu

    HowTo: APT pinning

  • Urig


    Also der Patch funktioniert gut, ist jetzt nicht mehr ganz "so leicht", musste hier und da noch an anderen Patches zupfen. Vielen Dank für die Mühen.


    UFO & kls


    Sorry, das ich nicht realisiert hatte, dass das Issue solch große Auswirkung hat, allerdings die Freunde mit denen ich geredet hatte ja auch nicht gleich ... ^^


    @all


    Nachdem ich eine Nacht drüber geschlafen habe, komme ich zu dem Schluß das es wohl sicherer ist bei allen Paket-basierten Angeboten urig's "s2apiwrapper light 0.10" zum Einsatz zu bringen mit VDR 2.0.0. Also auch z.B. Ubuntu Precise+ oder Debian Wheezy, jew. Kernel 3.2, auch wenn mich Klaus dafür jetzt steinigt.


    Zumindest für Ubuntu als auch Debian werden die Pakete ja gegen den Stock-Kernel gebaut und es scheint keiner weiß so genau was die tatsächlich können. Das was nicht funktioniert, merkt man erst nach einiger Zeit z.B. fehlender EPG oder fehlende Channel Updates ...


    Regards
    fnu

    HowTo: APT pinning


  • Nachdem ich eine Nacht drüber geschlafen habe, komme ich zu dem Schluß das es wohl sicherer ist bei allen Paket-basierten Angeboten urig's "s2apiwrapper light 0.10" zum Einsatz zu bringen mit VDR 2.0.0. Also auch z.B. Ubuntu Precise+ oder Debian Wheezy, jew. Kernel 3.2, auch wenn mich Klaus dafür jetzt steinigt.


    Wer Binärpakete baut, hat afaics gar keine andere Wahl. Die Pakete müssen schließlich unter verschiedenen Kernelversionen und damit DVB-API-Versionen laufen...


    @Klaus
    Imho sollte man das StreamId-Gedöns erst ab derjenigen API-Version verwenden, die DTV_STREAM_ID enthält (5.8???). Läuft eine ältere Version, würde ich es komplett weglassen. Braucht doch kaum jemand, und wenn, dann soll er gefälligst einen aktuellen Treiber verwenden.


    Von meinen DVB-S2-Karten unterstützt es einzig die CineS2 V6.5. Da ich keinen Sender kenne, der dies verwendet, habe ich es nicht getestet.


    Bei dem API-Chaos wäre es außerdem nicht schlecht, wenn VDR beim Start ausgeben würde,
    - gegen welche API-Version er kompiliert wurde
    - welche API-Version der geladene Treiber verwendet.


    Würde bei der Diagnose von Problemen helfen. API-5 ist leider nicht mehr so stabil wie es API-3 war.


    CU
    Oliver

  • Mal für die Akten, da man das sonst nirgends aufgeschlüsselt findet:


    Linux-3.8: DVBAPI 5.9 (Ubuntu 13.04 'Raring Ringtail')
    Linux-3.7: DVBAPI 5.9
    Linux-3.6: DVBAPI 5.6
    Linux-3.5: DVBAPI 5.6 (Ubuntu 12.10 'Quantal Quetzal')
    Linux-3.4: DVBAPI 5.5
    Linux-3.3: DVBAPI 5.5
    Linux-3.2: DVBAPI 5.4 (Debian 7.0 'Wheezy') (Ubuntu LTS 12.04 'Precise Pangolin')
    Linux-3.1: DVBAPI 5.3
    Linux-3.0: DVBAPI 5.3 (Ubuntu 11.10 'Oneiric Ocelot')
    Linux-2.6.39: DVBAPI 5.2
    Linux-2.6.38: DVBAPI 5.2 (Ubuntu 11.04 'Natty Narwhal')
    Linux-2.6.37: DVBAPI 5.2
    Linux-2.6.36: DVBAPI 5.2
    Linux-2.6.35: DVBAPI 5.1 (Ubuntu 10.10 'Maverick Meerkat')
    Linux-2.6.34: DVBAPI 5.1
    Linux-2.6.33: DVBAPI 5.1
    Linux-2.6.32: DVBAPI 5.1 (Debian 6.0 'Squeeze') (Ubuntu LTS 10.04 'Lucid Lynx')
    Linux-2.6.31: DVBAPI 5.0 (Ubuntu 9.10 'Karmic Koala')
    Linux-2.6.30: DVBAPI 5.0
    Linux-2.6.29: DVBAPI 5.0
    Linux-2.6.28: DVBAPI 5.0 (Ubuntu 9.04 'Jaunty Jackalope')
    Linux-2.6.27: DVBAPI 3.2 (Ubuntu 8.10 'Intrepid Ibex')
    Linux-2.6.26: DVBAPI 3.2 (Debian 5.0 'Lenny')


    Auf der sicheren Seite mit DTV_STREAM_ID (ab API 5.8) ist man also erst mit Kernel 3.7, und vor Kernel 3.0 (API 5.3) funktioniert EPG definitiv nicht. Dazwischen bin ich mir auch nicht sicher, da sendet plain VDR 2.0.0 noch sein DTV_DVBT2_PLP_ID an DVB-S2, was zwar schon definiert, aber für DVB-S2 natürlich unsinnig ist.



    Eine Logmeldung baue ich mal in die nächste Version ein, bis dahin kann sich das jeder aber auch selbst einbauen, cDevice holt sich die Runtime-Version im Konstruktor und speichert sie in dvbApiVersion, da könnte man sie auch loggen.



    Gruß,


    Udo


  • Danke für die Liste.


    For the record:
    media_build_experimental hat z.Zt. API 5.10.


    Zitat


    Auf der sicheren Seite mit DTV_STREAM_ID (ab API 5.8) ist man also erst mit Kernel 3.7, und vor Kernel 3.0 (API 5.3) funktioniert EPG definitiv nicht. Dazwischen bin ich mir auch nicht sicher, da sendet plain VDR 2.0.0 noch sein DTV_DVBT2_PLP_ID an DVB-S2, was zwar schon definiert, aber für DVB-S2 natürlich unsinnig ist.


    Dazu kommt, daß DTV_DVBT2_PLP_ID den Wert 43 hat, DTV_STREAM_ID dagegen 42 (ersetzt DTV_ISDBS_TS_ID). Also nicht binärkompatibel. So etwas muß schief gehen!


    CU
    Oliver


  • Danke für die Liste.


    For the record:
    media_build_experimental hat z.Zt. API 5.10.


    DVB API >= 5.3 wird in dvbdevice.h schon seit längerem vorausgesetzt.


    Zitat


    Dazu kommt, daß DTV_DVBT2_PLP_ID den Wert 43 hat, DTV_STREAM_ID dagegen 42 (ersetzt DTV_ISDBS_TS_ID). Also nicht binärkompatibel. So etwas muß schief gehen!


    Ach, waren das noch Zeiten, als der DVB-Treiber nicht im Kernel war. Da konnte man einfach sagen "Nimm *diesen* Treiber und gut is". OK, das kann man heute auch noch, denn ich benutze auf meinem VDR Kernel 2.6.37 und den Treiber von http://linuxtv.org/hg/~endriss/media_build_experimental - und alles funktioniert wunderbar.


    Vorher hat VDR den Wert mit DTV_DVBT2_PLP_ID übergeben, und jetzt mit DTV_STREAM_ID.
    Soweit ich das verstanden habe ist das frühere dvbt2_plp_id in stream_id aufgegangen:


    Daher hätte ich eigentlich erwartet, daß es sich je nach verwendeter DVB-API richtig verhält.
    Daß man sich jetzt auch noch dynamisch je nach verwendeter Treiber-Version anders verhalten soll gibt dem Ganzen eine völlig neue Dimension.


    Klaus


  • Ach, waren das noch Zeiten, als der DVB-Treiber nicht im Kernel war. Da konnte man einfach sagen "Nimm *diesen* Treiber und gut is". OK, das kann man heute auch noch, denn ich benutze auf meinem VDR Kernel 2.6.37 und den Treiber von http://linuxtv.org/hg/~endriss/media_build_experimental - und alles funktioniert wunderbar.


    Tja - hat alles seine Vor- und Nachteile.



    Wie man sieht, sind die APIs weder source- noch binärkompatibel. Ganz großes Kino. :wand


    Übel ist dies vor allem für Distributionen: Kernel und Applikation sind nun nicht mehr voneinander unabhängig.


    Linus hat Mauro ja schon wegen API-Inkompatibilitäten "zur Sau" gemacht. Aber er kapiert das offenbar nicht. :§$%


    CU
    Oliver

  • Linux-3.2: DVBAPI 5.4 (Debian Wheezy) => Ubuntu LTS 12.04 (Precise)
    ...
    Linux-2.6.32: DVBAPI 5.1 (Debian Squeeze) => Ubuntu LTS 10.04 (Lucid)

    Hab's mal für Ubuntu ergänzt ...


    media_build_experimental hat z.Zt. API 5.10.

    Oh, eine imaginäre Kernel Version ... ^^


    DVB API >= 5.3 wird in dvbdevice.h schon seit längerem vorausgesetzt.

    Ist bekannt und die Existenz-Basis für Udo's manchmal unabdingbaren Patch .. :)


    Übel ist dies vor allem für Distributionen: Kernel und Applikation sind nun nicht mehr voneinander unabhängig.

    Ja, das ist nicht nur bei DVB Devices ein Problem. Man könnte vmtl. recht neue media-builds mit z.B. Lucid nutzen, müßte dann aber den ganzen (input)lirc Sachen in Eigenverantwortung mitpatchen und aktualisieren für "rc-core" ...


    Linus hat Mauro ja schon wegen API-Inkompatibilitäten "zur Sau" gemacht. Aber er kapiert das offenbar nicht.

    Och, die Schelte hätte ruhig etwas größer ausfallen dürfen und trifft nicht den Falschen, am Besten noch seinen anderen RedHat Kumpel mitschimpfen ... :huh:


    Regards
    fnu

    HowTo: APT pinning

    2 Mal editiert, zuletzt von fnu ()

  • Bevor ich hier in irgendeiner Weise aktiv werde würde ich gerne mal das eigentliche Problem nachvollziehen können.


    Ich habe jetzt mal folgende Versuche gemacht:


    - Treiber ist immer der aus http://linuxtv.org/hg/~endriss/media_build_experimental
    - VDR ist immer Version 2.0.0
    - vor jedem Versuch epg.data gelöscht
    - VDR übersetzt mit dem Treiber-Stand von 2013-03-01, also DVB-API 5.10, tatsächlich benutzter Treiber ist der Stand von 2012-10-06 (DVB-API 5.6, älteste Version die ich noch hier habe)
    --> Ergebnis: einwandfreier EPG auf allen Kanälen (DVB-S, DVB-S2 und DVB-T)
    - VDR übersetzt mit dem Treiber-Stand von 2012-10-06, also DVB-API 5.6, und diesen Treiber auch benutzt
    --> Ergebnis: einwandfreier EPG auf allen Kanälen (DVB-S, DVB-S2 und DVB-T)
    - VDR übersetzt mit dem Treiber-Stand von 2012-10-06, also DVB-API 5.6, tatsächlich benutzter Treiber ist der Stand von2013-03-01 (DVB-API 5.10, meine aktuell verwendete Version)
    --> Ergebnis: einwandfreier EPG auf allen Kanälen (DVB-S, DVB-S2 und DVB-T)


    Zumindest für diese beiden Treiberversionen scheint also sowohl Source- als auch Binärkompatibilität gegeben zu sein.
    Oder mache ich da was falsch?


    Klaus

  • Ist das hier jetzt eigentlich noch ein Problem, oder hat sich das inzwischen erledigt?
    Falls das Problem noch besteht, kann mir bitte jemand sagen, wie genau ich es nachvollziehen kann? Bei meinen Versuchen (siehe Posting #30) konnte ich zumindest kein Fehlverhalten erkennen.


    Klaus

  • kls


    Ich kann meine Erfahrungen problemlos nachvollziehen, urig vmtl. auch wieder, aber alles eher alter Stand. Dennoch sind seine Recherchen schlüssig und decken sich mit UFOs Feststellungen. Daher bin ich jetzt mal recht direkt, bloß weil Du das in Deiner einen Installation nicht nachvollziehen kannst, heißt das nicht es ist bei den hundert(en) anderen keines. Insofern wäre eine Flexibilisierung angelehnt an urig's s2apiwrapper mehr als wünschwenswert, es gibt weit mehr Kombinationsmöglichkeiten da draussen, als Du oder ich je testen könnten und die Herren von RedHat arbeiten eher an noch mehr, denn an mehr Überschaubarkeit ...


    Bin schon unglücklich über die Beschränkung auf DVBAPI>=5.3, aber habe hier dank Udo einen Weg raus. Dennoch ist der stable Kernel Zweig 2.6.32 mit DVBAPI 5.1 immer noch weit verbreitet, binäre Pakete müssten eben auch mit dem Stockkernel funktionieren.


    ... just my 2 cents.


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • kls


    Ich kann meine Erfahrungen problemlos nachvollziehen, urig vmtl. auch wieder, aber alles eher alter Stand. Dennoch sind seine Recherchen schlüssig und decken sich mit UFOs Feststellungen.


    Wobei "UFO" ja meinte, daß DVB-API 5.8 eine "magische Grenze" sein soll, was ich aber nicht nachvollziehen konnte.


    Zitat


    Daher bin ich jetzt mal recht direkt, bloß weil Du das in Deiner einen Installation nicht nachvollziehen kannst, heißt das nicht es ist bei den hundert(en) anderen keines. Insofern wäre eine Flexibilisierung angelehnt an urig's s2apiwrapper mehr als wünschwenswert, es gibt weit mehr Kombinationsmöglichkeiten da draussen, als Du oder ich je testen könnten und die Herren von RedHat arbeiten eher an noch mehr, denn an mehr Überschaubarkeit ...


    Bin schon unglücklich über die Beschränkung auf DVBAPI>=5.3, aber habe hier dank Udo einen Weg raus. Dennoch ist der stable Kernel Zweig 2.6.32 mit DVBAPI 5.1 immer noch weit verbreitet, binäre Pakete müssten eben auch mit dem Stockkernel funktionieren.


    Ich schau mir mal "Urig"s Wrapper an.
    Wobei da einiges drin ist, das VDR gar nicht braucht. Z.B. das ganze DTV_ISDB*-, DTV_ATSC*- und ATSCMH*-Zeugs. Hat das einen Grund?
    Der Patch hat zwar "light" im Namen, bringt aber anscheinend doch noch überflüssiges "Fett" mit...


    Klaus

  • Der Patch hat zwar "light" im Namen, bringt aber anscheinend doch noch überflüssiges "Fett" mit...


    Das stimmt, der wurde in der Version 0.10 etwas fetter, hatte ich auch weiter oben schonmal erwähnt. Der Alte 0.9, war wirklich leicht, da wurden quasi nur ein paar Strings ausgetauscht, aber die Situation jetzt erforderte wohl einen breiteren Rechen. Udo hatte aber IIRC auch irgendwo erwähnt, das man da wohl nomm'l ran könnte ...


    Ob man alles davon benötigt kann urig oder UFO sicher besser beurteilen, ich denke beide lesen zeitnah hier mit ... :)


    Regards
    fnu

    HowTo: APT pinning


  • Das stimmt, der wurde in der Version 0.10 etwas fetter, hatte ich auch weiter oben schonmal erwähnt. Der Alte 0.9, war wirklich leicht, da wurden quasi nur ein paar Strings ausgetauscht, aber die Situation jetzt erforderte wohl einen breiteren Rechen. Udo hatte aber IIRC auch irgendwo erwähnt, das man da wohl nomm'l ran könnte ...


    Ob man alles davon benötigt kann urig oder UFO sicher besser beurteilen, ich denke beide lesen zeitnah hier mit ... :)


    Dann wäre es gut, wenn jemand einen "bis auf die Knochen" abgemagerten Patch machen würde, der auch wirklich nur das Allernötigste enthält.
    Ansonsten schmeiß ich halt einfach alles raus, was VDR nicht braucht.


    Klaus

  • Man könnte ihn sicher noch abmagern. Light ist er im Vergleich zum alten Patch, der das S2API mit Mitteln des alten DVBAPI nachbaut. Das ist zum Glück beerdigt.


    Alles was in der s2apiwrapper.h noch drin steckt, ergänzt nur die Definitionen, die in der frontend.h seit API 5.0 dazu gekommen sind, schön Version für Version, damit nichts doppelt deklariert wird. Ich hab sicherheitshalber einfach mal alle Änderungen gesammelt, falls irgendwann mal was davon nötig wird. (Ich hab auch eine komplette Sammlung aller frontend.h's, wer Interesse hat.)


    VDR braucht nur eine Handvoll davon, ohne Anspruch auf Vollständigkeit glaube ich FE_CAN_TURBO_FEC, DTV_DVBT2_PLP_ID, DTV_STREAM_ID, FE_CAN_MULTISTREAM. Bleibt es bei der Einschränkung auf API >= 5.3, ist die gesamte s2apiwrapper.h überflüssig, da VDR ja auch alles mitbringt. Das würde den Patch wohl auf die ersten 130 Zeilen eindampfen.


    Der Rest ist die Runtime-API-Versionsabfrage, und die paar Codeweichen. Bei den Delivery Systems gönne ich mir noch das Fallback-Verhalten von plain VDR bei API >= 5.5, wahrscheinlich würde hier aber auch eine einfache Codeweiche (DTV_ENUM_DELSYS ab >= 5.5, Legacy Mode bei < 5.5) genügen.


    Etwas unaufgeräumt ist auch, dass jedes Device das DVB-API ermittelt und speichert, ein mal zentral würde auch genügen. War halt so einfacher zu patchen.


    Gruß,


    Udo

  • VDR braucht nur eine Handvoll davon, ohne Anspruch auf Vollständigkeit glaube ich FE_CAN_TURBO_FEC, DTV_DVBT2_PLP_ID, DTV_STREAM_ID, FE_CAN_MULTISTREAM. Bleibt es bei der Einschränkung auf API >= 5.3, ist die gesamte s2apiwrapper.h überflüssig, da VDR ja auch alles mitbringt. Das würde den Patch wohl auf die ersten 130 Zeilen eindampfen.


    Denkbar, das Du das als schmalen Patch an Klaus gibst und den s2apiwrapper für VDR 2.0.1 (oder was auch immer) für API<5.3 an diesen Änderungen orientierst?


    Regards
    fnu

    HowTo: APT pinning

  • Dennoch sollte man jetzt erst einmal nachstellen, was unter welchen Bedingungen passiert:
    - Gegen welche Treiberversion wurde Vanilla VDR 2.0 kompiliert?
    - Mit welcher "running" Treiberversion tritt dann das Problem auf?


    Sonst riskiert man, daß ein tieferliegendes Problem verschleiert wird, was dann irgendwann wieder hochpoppt.


    CU
    Oliver

  • Dennoch sollte man jetzt erst einmal nachstellen, was unter welchen Bedingungen passiert:
    - Gegen welche Treiberversion wurde Vanilla VDR 2.0 kompiliert?


    Die beiden Treiberversionen mit denen ich getestet habe stammen von http://linuxtv.org/hg/~endriss/media_build_experimental
    und sind von 2012-10-06 bzw. 2013-03-01.


    Zitat

    - Mit welcher "running" Treiberversion tritt dann das Problem auf?


    Ich habe mit beiden o.g. Versionen übersetzt und sie geladen, "passend" und "über Kreuz", aber das Problem trat bei mir nie auf. Ich hatte immer ordentlichen EPG.


    Klaus

Jetzt mitmachen!

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