Beiträge von HelmutB

  • Fragen zu multi channel decryption (MCD) und CA_PMT query

    Meine Versuche mit einem Neotion Modul MCD/MTD zu nutzen sind bisher leider erfolglos.


    Das Modul sollte Dualentschlüsselung beherschen, allerdings antwortet es nicht auf die CA_PMT query Anfragen.

    Der Grund dafür liegt vielleicht auch daran, das VDR bei mir gleich nach dem Start die query-requests an die CAM sendet, allerdings noch bevor ein Signal anliegt. Das bedeuted es sind leere Anfragen ohne Programmnummer und Pids. Danach wird in ci.c repliesToQuery auf false gesetzt.


    Nun meine Frage: ist das mit den leeren CA_PMT queries normal und wenn ja welche CAM antwortet dann (und vor allem wie) darauf - ich glaube MCD/MTD funktioniert ja mit den Alphacrypt Modulen, aber hat jemand auch mit einem "normalen" Modul erfolg?


    Hier ein kurzes Log in dem zu sehen ist, wie die 6 CA_PMT query Anfragen vor dem eigentlichen Tunen erfolgen. (mit vdr-2.3.8, ddci2 und meinem Wintv USB-CI Adapter):

    Vielleicht hat jemand eine Idee.


    Helmut

  • [gelöst] bash-Skript unerwartetes (für mich) Verhalten

    Versuche es damit:

    - regex für grep auch mit Anker ^ für Zeilenbeginn

    - alle sed Ersetzungen mit 'g' für alle Vorkommen in der Zeile

    Code
    dat_neu_var=$(grep '^S ' "$info_var" | sed 's/^S //; s/ /_/g; s/\//#2F/g; s/"("/\(/g; s/")"/\)/g; s/\:/#3A/g')
verz_neu_var=$(grep '^T ' "$info_var" | sed 's/^T //; s/ /_/g; s/\//#2F/g; s/"("/\(/g; s/")"/\)/g; s/\:/#3A/g')

    sieht bei mir dann so aus:


    Helmut

  • Bitte mit DVB-T2 testen!

    Auch hier in Wien die Parameter nur vom T2 ExtensionDescriptor (direkt über USB DVB-T2 Adapter).

    MUX B2 liefert übrigens immer noch eine falsche Stream-ID - sie sollte bei allen Sendern "1" sein.


    Helmut

  • WinTV-CI / Cinergy-USB-CI und ddci2

    Nachdem ich mich eine Zeilang mehr mit anderen Dingen beschäftigt habe hier nun ein Update des Kernel Treibers für das USB-CI.

    Um die Probleme durch blockierte Control USB-Endpunkte wegzubekommen, war das genaue Timing beim übertragender der TS-Daten herauszufinden, das hat auch etwas gedauert.

    Jetzt nach einem Kurztest sieht aber alles ganz gut aus, Kanalwechsel etc. ist nun ohne Fehler möglich.


    Im Anhang auch ein Logfile das die Infos ab dem anschließen des CI, den start des vdr und einigen Kanalwechsel (bei CA_PMT) auf verschlüsselte Kanäle zeigt.


    Helmut


    Edit:

    Das Kernel Modul heißt nun wintv-usb2ci

    Edit2:

    Ein paar Fotos wie es im Betrieb aussieht


  • fadvise wirklich nötig?

    Also hier am älteren Notebook mit xineliboutput und OHNE Hardwarebeschleunigung macht es beim schnellen Vorlauf keinen Unterschied (der schnelle Rücklauf funktioniert vermutlich wegen meiner Hardware oder dem Plugin nicht richtig).

    Zitat von kls

    Ich habe inzwischen etwas nachgelesen. Die Verwendung von posix_fadvise() wurde damals (vor mittlerweile fast dreizehn(!) Jahren) ja eingebaut

    Und hatte wie es ausssieht die ganze Zeit einen Fehler der erst seit Kernel 4.7 behoben ist:

    https://git.kernel.org/pub/scm…8e9f6d8d446427d8b7691c194


    Helmut

  • CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Bravo, und clever mit den TS-Fragmenten.
    Testen kann ich es mangels entsprechender Hardware leider nicht.


    interessant finde ich, dass die SYNC Verschiebung genau vor einem NULL-Paket stattfindet, und - da du ja keine Fehlermeldungen oder Bildfehler hast - tsin_find_offset() offenbar immer erfolgreich ist, Anderenfalls würden ja TS-Pakete ohne dem SYNC-Byte im tsout-Ringbuffer landen.


    Zitat von jasminj

    Das liegt am Ngene Chip der eigentlich für Audio gedacht ist und immer etwas erwartet, weil bei Audio ist das einfach so. Man hat das dann mit den leeren TS Paketen im Treiber gebastelt.

    Alles klar, habe ich nicht gewusst. Und ohne die Idle-Pakete geht es wie von nst gestestet ja wirklich nicht.



  • CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Ah, jetzt weiß ich wofür dieser Idle-Buffer gut ist - er beschäftigt das CAM obwohl es eigentlich gar nichts zu tun gibt.

    Hilft jetzt aber auch nicht weiter.


    Von der CAM-Control habe ich eigentlich nicht entdeckt - das läuft ja über den cxd2099, und ob das den selben Speicher/Buffer nutzt wie die TS-Daten würde mich wundern - möglich ist natürlich alles.

    Den Offset in tsin_exchange() einfach zu überspringen wird auch nicht gut funktionieren da dann zwangsläufig das unvollständige (<188 byte) TS-Paket am Ende nicht mehr in den Tsin Ringbuffer geschrieben wird. Man verliert also bei jedem exchange 1 TS-Paket.

    Im Moment fällt mir auch nicht mehr ein, außer noch einmal über den Code zu schauen.


    Vielleicht kannst Du noch vergleichen ob es sich mit einem anderen CA-Modul genau gleich verhält.


    Helmut


    Edit:

    Doch noch was eingefallen: Kann man aus den 4 oder mehr Bytes vor SYNC irgendetwas erkennen - z.B Reste des NULL-Pakets (0x6F) oder Fragmente einer Control - Kommunikation?

  • CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Sehr eigenartig.

    Ist der Offset gleich zu Beginn und bleibt dann gleich (also immer +188 bytes) , oder "bewegt" sich das SYNC byte ?

    Auf jedenfall ist irgendwann der tsin-Ringbuffer nicht auf SYNC ausgerichtet , dann sollte es doch zumindest einmal eine Fehlermeldung von ddci2 mit "skipped xx bytes to sync on start of TS packet" geben. Hier wird immer nur die MTD Meldung erwähnt - oder habe ich sie überlesen.


    Helmut

  • CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Hallo,

    wenn man sich die Daten der TS-Null Pakete ansehen könnte, hätte man vielleich einen Hinweis auf dei Quelle.

    Hier eine Erweitern der MTD Fehlermeldung in der originalen mtd.c :

    Die ersten 8 Bytes werden dabei nach der Pid als zwei 32-Bit Werte ausgegeben.

    Vielleicht willst du das einmal probieren.


    Helmut

  • Update der DVB-T2 Transponderdaten für GetSignalStrength() und GetSignalQuality()

    So, hier nun mein Patch für die Erweiterung von GetSignalQuality() und GetSignalStrength().

    (Ich hab den Titel etwas angepasst).


    Die Abfrage des Frontend für die tatsächlich verwendeten Werte von Modulation und Coderate erfolgt nun direkt in in diesen Funktionen, die channels.conf wird nicht mehr modifiziert.


    Zwei Anmerkung:

    Der für den SignalStrengthIndicator (SSI) erforderliche dBm-Wert wird leider von den wenigsten Treibern geliefert, diese Funktion wird daher fast nie verwendet.


    Beim SignalQualityIndex (SQI) wird bei DVB-T und C auch die Bitfehlerrate berücksichtigt.

    Bei einigen - oder eigentlich den meisten - Treiber die ich angesehen habe werden die Bitfehler aber bei jeder Abfrage aufsummiert - d.h. der Wert geht nie auf 0 zurück und die BER ist damit nicht wirklich brauchbar,

    Ich habe ein #define IGNORE_BER eingefügt, bei setzen auf 1 wird der BER-Wert vom Treiber ignoriert.


    Ich kann kein DVB-C testen, bei Terr. und Sat sind die angezeigten Werte plausibel, eher zu gut - also meistens über 90%.

    Vielleicht will den Patch wer testen und die Ergebnise hier kundtun.


    Helmut

  • Update der DVB-T2 Transponderdaten für GetSignalStrength() und GetSignalQuality()

    Zitat von rofafor

    Well, you were referring to Nordig standard earlier.

    Yes, but only to explain from where i have my "wisdom". In the meantime i understand your generally reminder about Nordig. Thank you.

    Zitat von wirbel

    such calculations require for terrestrial transmissions a few design choices which are specific to local requirements.

    Sounds more complicated than i thought (and looks so easy at Nordig).


    Anyway, as the current vdr supports DVB API 5 (i upgraded from vdr-2.2.0 only 2 or 3 month ago) i thought it was the right time to implement more general and hardware independent SSI/SQI indicators. But the missing, but required transponder parameters for DVB-T2 leaded to the start of this thread.


    Is it usus to remove improper attachments from the thread or can they still remain?


    Helmut


    BTW: if Rolf does'n mind, we could switch back to german.

  • Update der DVB-T2 Transponderdaten für GetSignalStrength() und GetSignalQuality()

    Hallo wirbel,

    Zitat von wirbel

    Rolf is absolutely correct here,

    yes, my fault - i should have (re-)read the vdr documentation before asking questions.

    But is the SSI/SQI representation really country-specific? And if, is there any DVB complient way to do this?

    Zitat von wirbel

    Implementing such a behaviour in VDR that may use *wrong* tuning settings may break tuning or cause undefined behaviour.

    You are right. I only checked the T2 drivers in the current kernel sources. That is a too simple sight.

    It is the best i leave channel config untouched and implement the FE_GET_PROPERTY ioctl's at the places where they are needed.


    Thank's for your explanations.

    Helmut

  • Update der DVB-T2 Transponderdaten für GetSignalStrength() und GetSignalQuality()

    Zitat von rofafor

    ...and a reminder that any Nordig specific implementation should be hidden behind a proper standard compliance: Setup.StandardCompliance==STANDARD_NORDIG

    May be a dumb question (i do not have much knowledge of compliance regulations) - what should be the meaning of this setup entry and why should it be implemented ? Is the intension to conditionaly execute some parts of code or is it only informational ?

    As far as i know this is an open Standard and free to use.


    Beside this, only the usage of some code-fragments or algos does not automaticaly make it complient to anything. So this setup entry could be missleading.


    Helmut

  • Update der DVB-T2 Transponderdaten für GetSignalStrength() und GetSignalQuality()

    Zitat von kls

    Wenn die tatsächlichen Werte nur für die Berechnung der Signalstärke und -qualität benötigt werden, dann wäre es doch sinnvoller, diese in den Funktionen cDvbTuner::GetSignalStrength() bzw. cDvbTuner::GetSignalQuality() zu holen, oder?


    Ja natürlich, es würde dafür vollkommen genügen.
    Der Vorteil die tatsächlich eingestellten Parameter "permanent" in die Kanalliste zu übernehmen ist für mich der, dass man z.B. über femon-plugin diese Info auch angezeigt bekommt.


    Die aktuellen DVB-T2 Teiber verwenden übrigens nur die Parameter "Bandbreite" und "Stream-ID", alle übrigen Einstellungen werden offenbar vom Demodulator direkt aus dem TS-Signal ermittelt und ev. vorhandene Einträge in der channels.conf haben auf das Tuning keinen Einfluss.


    Helmut

  • CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Das ist der Treiber für die schon ältere Cine Dual -S2 PCI Sat-Karte mit unterstützung für ein Digital-Devices CI-Interface (über caX und secX).

    Soweit ich den Treiber verstehe:

    Das schreiben zum CI-Interface erfolgt immer mit genau 4096 TS-Paketen. Wenn im TSout-Buffer nicht genügend Pakete vorhanden sind wird mit TS-Null Paketen aufgefüllt, diese Null-Pakete haben eine beondere Kennung am Datenblock - 0x6F.

    Beim Lesen vom CI werden diese selbst generierten Null-Pakete dann wieder verworfen.

    Warum es genau 4096 Pakete sein müssen ist mir nicht ganz klar, ich sehe nur das die TSin/TSout Ringbuffer auch 4096*188 bytes groß sind.


    LG

    Helmut

  • CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Da hast du natürlich recht - es war dann doch schon zu spät um noch klar zu denken.


    Es hätte das Problem aber eh nicht gelöst, da die selbst erzeugten Null-Pakete ja von tsin_exchange() wieder entfert werden und es keines bis zum VDR schaffen sollte.


    Man müsste sich in mdt.c beim einer PID von 0x1FFF das 5. Byte des Pakets ansehen - bei enem Wert von 0x6F würde kommt es definitiv vom ngene Treiber - aber wie ?


    LG

    Helmut

  • CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Ich habe zwar keine entspechende Hardware, aber wenn ich den ngene-Treiber richtig lese werden die

    TS-Null Pakete in ngene-core.c von der Funktion "FillTSBuffers()" erzeugt.


    Diese Funktion wird einerseits von "clear_buffers(struct ngene_channel *chan)" zum initialisieren der Ringbuffer aufgerufen, zum anderen wird sie in ngene-dvb.c von "tsout_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags)" zum Auffüllen eines TS Buffers bis zur gewünschten Größe verwendet bevor dieser dann zum CI gesendet wird.


    Die Funktion "tsin_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags)" versucht dann die TS-Null Pakete die vom CI

    kommen wieder zu entfernen.


    Hier die Funktion FillTSBuffer, die den Buffer zuerst mit dem Wert 0x6F (TS_FILLER) füllt und dann in gewissen Abständen des 4-byte TS-Null Header 0x47, 0x1F, 0xFF, 0x10 einfügt.


    Hier kommt mir allerdings seltsam vor, dass der Pointer für den TS-Null Header um 188/4 - also 47 bytes verschoben wird, der Längenzähler aber um die Länge eines ganze TS-Pakets mit 188 bytes verringert wird..

    Das würde bedeuten, das nur das 1. Viertel der erzeugten TS-Null Paktete eine gültigen Header hat, der Rest besteht nur aus den Werten 0x6F die tsin_exchange() dann nicht als Null-Paket erkennt und durchlässt.


    Falls jemand den Treiber verwendet, ev. könnte ein "ptr += 188;" etwas verbessern.

    LG

    Helmut

  • Update der DVB-T2 Transponderdaten für GetSignalStrength() und GetSignalQuality()

    Hallo Klaus,

    Zitat von kls

    Welchen Vorteil bringt denn dieser Patch in der Praxis?

    Ich verwende Modulation und Coderate/FEC für die Ermittlung der Referenzwerte zur Berechnung von SIgnalstärke und Signalqualität nach dem Standard von Nordig an den sich offensichtlich auch viele Hersteller von DVB-Receiver halten.

    Ein Wert von "auto" hilft hier nicht.


    Hier die Dokumentation: https://nordig.org/specifications/

    Die Berechnung für DVB-T/T2 ist ziemlich einfach und ich habe es bei mir mit einem Patch im VDR-2.3.8 eingebaut.

    (Ich verwende aber nur die SSI genau nach Nordig, den SQI habe ich etwas "gespreizt", da er sonst eigentlcih immerl 100% anzeigt).

    Zitat von kls

    Wenn die betreffenden Daten nicht in der NIT drin sind, und man diejenigen, die momentan tatsächlich verwendet werden, in die channels.conf einträgt, läuft man dann nicht Gefahr, den Kanal nicht mehr tunen zu können, wenn der Sender einen Parameter verändert, ihn in der NIT aber weiterhin nicht angibt?


    Hier hast du vielleicht nicht unrecht - und ich hab ehrlich gesagt an diese Möglichkeit gar nicht gedacht.

    Das würde aber umgekehrt bedeuten, das alle Parameter die nich in der NIT sind bei DVB-T2 immer auf "auto" gesetzt sein müssten.

    ---

    Ich zuvor versucht meinem Astrometa DVB-T2/DAB USB-Stick zu verwirren und die Parameter von Modulation, Coderate, Inversion auf verschiedeste unmögliche Werte gesetzt.

    Zu meiner Überraschung hat das aber keine Auswirkung, es gab immer wieder einen Lock auf den Sender. Ich nehme an, das der Demodulator von sich aus versucht die richtigen Parameter zu finden. und daher wären Änderungen durch den Provider auch ohne Folgen. Vielleicht kann das jemand mit anderer Hardware auch bestätigen.
    ---

    Ich habe den Patch übrigens etwas adaptiert - er werden nur Sender mit der gleichen Stream-Id aktualisiert.

    Vielleicht sollte die Aktualisierung auch nur ausgeführt werden, wenn Setup.UpdateChannels > 5 ist.


    Helmut