Hallo zusammen,
in der letzten Zeit haben sich immer wieder Beiträge gezeigt die aufzeigen, dass mdvbapi wohl noch einige Schwächen und ggf. Bugs hat.
Da auch Schwa sich darauf nicht mehr gemeldet hast und die Entwicklung offiziell eingestellt hat, habe ich selbst begonnen ein Plugin zu entwickeln.
Die Quellcodes sind auf Github zu finden:
Ich habe selbst lokal noch ein ausführliches Git-Repository, bei Github lade ich nur unregelmäßig hoch.
Dadurch kann es vorkommen, dass die DLL hier, und Github abweichend voneinander sind.
In diesem ersten Post hänge ich nun immer die aktuelle Version + Changelog an.
in der Locales.zip sind die Sprachdateien enthalten die ich verwende. Es handelt sich hier um Quellcode-Dateien - die werden vom Plugin nicht geladen!
Wenn jemand etwas übersetzen möchte, kann er es gern machen, und die Dateien hier zum drüberlesen im Forum anhängen, wenn das soweit alles OK ist, füge ich die im Projekt für das nächste Release ein.
Angehängt am Ende ist immer nur die aktuelle Version.
PS:
Aufgrund der häufigen Nachfragen, bzgl. Spenden:
Auf meiner Website (verlinkt im Profil) befindet sich unten ein Spenden-Button.
in der letzten Zeit haben sich immer wieder Beiträge gezeigt die aufzeigen, dass mdvbapi wohl noch einige Schwächen und ggf. Bugs hat.
Da auch Schwa sich darauf nicht mehr gemeldet hast und die Entwicklung offiziell eingestellt hat, habe ich selbst begonnen ein Plugin zu entwickeln.
Die Quellcodes sind auf Github zu finden:
Sie müssen registriert sein, um Links zu sehen.
Ich habe selbst lokal noch ein ausführliches Git-Repository, bei Github lade ich nur unregelmäßig hoch.
Dadurch kann es vorkommen, dass die DLL hier, und Github abweichend voneinander sind.
In diesem ersten Post hänge ich nun immer die aktuelle Version + Changelog an.
in der Locales.zip sind die Sprachdateien enthalten die ich verwende. Es handelt sich hier um Quellcode-Dateien - die werden vom Plugin nicht geladen!
Wenn jemand etwas übersetzen möchte, kann er es gern machen, und die Dateien hier zum drüberlesen im Forum anhängen, wenn das soweit alles OK ist, füge ich die im Projekt für das nächste Release ein.
Voraussetzungen:
Für das Plugin selbst und reiner Verwendung des DVB-CISSA (verwendet von z.B. BISS2 Cardsystem) Algorithmus wird nur das .NET Framework in der Version von mind. 4.0 benötigt.
Die meisten Anbieter nutzen noch DVB-CSA, da wird für die ffdecsa.dll zusätzlich die aktuelle VC++ Redistributable 2019 (v142) in x86 benötigt, einfach googeln.
DVB-CISSA, AES und DES funktionieren ausschließlich im DVBViewer, DVBViewer Media Server und Recording-Service!
via MDAPI(+) funktioniert nur plain DVB-CSA.
Bezüglich der Verwendung mit MDAPI oder MDAPI+ bitte die entsprechenden Anleitungen für die Verwendete Software beachten.
Konfiguration dieses Plugins ist identisch wie bei DVBViewer.
Es gibt 2 Möglichkeiten zur Installation des Plugins im DVBViewer, oder für MDAPI(+) kompatible Programme.
Oscam funktioniert ab R11520 (Ab da wird erst der nötige DemuxID Descriptor ausgewertet)
Zwischenzeitlich wurde viel an dem DVBAPI-Protokoll herumgeschraubt.
Daher habe ich eine Option erstellt mit der das alte Protokoll v2 erzwungen werden kann, mehr dazu in den Kommentaren der Konfigrationsdatei.
Mit der Version vom 30.07.2020 habe ich den Support für die neue Protokollversion (v3) vollständig entfernt da sich immer wieder user melden die Verbindungsprobleme hatten.
Das Oscam-Team arbeitet zudem auch nicht am Protokoll weiter, weshalb ich es erst wieder einbauen werde sobald eine stabile Verbindung möglich ist.
Eine Alternative Installation ist über ein Setup möglich, hier nochmals vielen Dank an @clemenss!
Der Thread hierzu kann dort gefunden werden: [SUCHE] OScam Installation mit DVBviewer
Für das Plugin selbst und reiner Verwendung des DVB-CISSA (verwendet von z.B. BISS2 Cardsystem) Algorithmus wird nur das .NET Framework in der Version von mind. 4.0 benötigt.
Die meisten Anbieter nutzen noch DVB-CSA, da wird für die ffdecsa.dll zusätzlich die aktuelle VC++ Redistributable 2019 (v142) in x86 benötigt, einfach googeln.
DVB-CISSA, AES und DES funktionieren ausschließlich im DVBViewer, DVBViewer Media Server und Recording-Service!
via MDAPI(+) funktioniert nur plain DVB-CSA.
Bezüglich der Verwendung mit MDAPI oder MDAPI+ bitte die entsprechenden Anleitungen für die Verwendete Software beachten.
Konfiguration dieses Plugins ist identisch wie bei DVBViewer.
Es gibt 2 Möglichkeiten zur Installation des Plugins im DVBViewer, oder für MDAPI(+) kompatible Programme.
Die ffdecsa.dll kommt in das Programmverzeichnis vom DVBViewer selbst, also der Ordner in dem sich auch die dvbviewer.exe befindet.
Hier sollte die korrekte Version ausgewählt werden, CPUs mit AVX-Register sollten mit der AVX-Version betrieben werden, da diese die beste Performance bieten. Ältere CPUs sollten SSE aber immer noch unterstützen. Wenn es eine noch ältere CPU ohne SSE2 ist, dann bleibt nur noch die standardversion ohne Optimierung übrig. Ihr findet diese im Ordner "INT". Wenn die CPU z.B. AVX oder SSE nicht unterstützt, dann Crasht der DVBViewer oder der Recording Service weg.
Leider kann ich den Fehler nicht abfangen, da das nativer Code ist, und der stürzt dann gnadenlos ab. Wenn ihr IPTV verwendet oder das Signal via SAT>IP (oder DVB>IP, wie auch immer) dann solltet ihr die ffdecsa aus dem mit "net" gekennzeichnetem Ordner nehmen. Die ist darauf optimiert maximal 7 Packets am Stück zu verarbeiten, das ist etwas effizienter.
Die dvbapiNET.ini Konfigurationsdatei kommt in einen neuen Ordner unterhalb Programdata-Verzeichnis. Ihr könnt es im Windows Explorer durch Eingabe %programdata%
dort erstellt ihr den Ordner dvbapiNET, und packt dann dort die dvbapiNET.ini rein. Falls das Logging aktiviert ist, wird dort auch die Logdatei geschrieben.
Hier sollte die korrekte Version ausgewählt werden, CPUs mit AVX-Register sollten mit der AVX-Version betrieben werden, da diese die beste Performance bieten. Ältere CPUs sollten SSE aber immer noch unterstützen. Wenn es eine noch ältere CPU ohne SSE2 ist, dann bleibt nur noch die standardversion ohne Optimierung übrig. Ihr findet diese im Ordner "INT". Wenn die CPU z.B. AVX oder SSE nicht unterstützt, dann Crasht der DVBViewer oder der Recording Service weg.
Leider kann ich den Fehler nicht abfangen, da das nativer Code ist, und der stürzt dann gnadenlos ab. Wenn ihr IPTV verwendet oder das Signal via SAT>IP (oder DVB>IP, wie auch immer) dann solltet ihr die ffdecsa aus dem mit "net" gekennzeichnetem Ordner nehmen. Die ist darauf optimiert maximal 7 Packets am Stück zu verarbeiten, das ist etwas effizienter.
Die dvbapiNET.ini Konfigurationsdatei kommt in einen neuen Ordner unterhalb Programdata-Verzeichnis. Ihr könnt es im Windows Explorer durch Eingabe %programdata%
dort erstellt ihr den Ordner dvbapiNET, und packt dann dort die dvbapiNET.ini rein. Falls das Logging aktiviert ist, wird dort auch die Logdatei geschrieben.
Dies ist die einfachste Möglichkeit zur Installation, erlaubt einen einzigen Sender gleichzeitig zu schauen.
Hier kommt die dvbapiNET.dll einfach in das Unterverzeichnis Plugins.
Hier kommt die dvbapiNET.dll einfach in das Unterverzeichnis Plugins.
Mit dem DVBViewer Media Server können mehrere Kanäle gleichzeitig entschlüsselt werden.
Hier wird pro Sender ein Plugin benötigt.
Die Plugins für den RecordingService/DVBViewer Media Server kommen in Plugins\PluginsX
Wobeidas X für 1 bis max. 32 steht. begonnen bei Plugins1
Dort nur jeweils einmal die dvbapiNET.dll einkopieren.
Mit einem kleinen Trick ist es möglich mehr als einen Sender pro Tuner zu entschlüsseln.
Kenner werden es bereits wissen, in der Hardware.xml vom Service gibt es die Möglichkeit die Option <MultiPID>1</MultiPID> hinzuzufügen.
Das Verhindert, dass der Service ein weiteres Device öffnet wenn der Sender auf dem Selben Transponder liegt.
Meine Empfehlung bei Verwendung des Service: ALLES über den Service laufen, Timer, Streaming, Etc. Idealerweise sind DVBViewer und Service auf verschiedenen Rechnern.
Ich habe zwar Vorkehrungen getroffen, weiß aber nicht wie gut diese funktionieren, wenn im DVBViewer Sender aufgenommen werden verwendet dieser seinerseits auch die PluginsX-Ordner.
Auf jeden Fall kommt es dann zu doppelten Anfragen in Oscam, weil der Service als auch der DVBViewer den Sender Tunen.
Hier wird pro Sender ein Plugin benötigt.
Die Plugins für den RecordingService/DVBViewer Media Server kommen in Plugins\PluginsX
Wobeidas X für 1 bis max. 32 steht. begonnen bei Plugins1
Dort nur jeweils einmal die dvbapiNET.dll einkopieren.
Mit einem kleinen Trick ist es möglich mehr als einen Sender pro Tuner zu entschlüsseln.
Kenner werden es bereits wissen, in der Hardware.xml vom Service gibt es die Möglichkeit die Option <MultiPID>1</MultiPID> hinzuzufügen.
Das Verhindert, dass der Service ein weiteres Device öffnet wenn der Sender auf dem Selben Transponder liegt.
Meine Empfehlung bei Verwendung des Service: ALLES über den Service laufen, Timer, Streaming, Etc. Idealerweise sind DVBViewer und Service auf verschiedenen Rechnern.
Ich habe zwar Vorkehrungen getroffen, weiß aber nicht wie gut diese funktionieren, wenn im DVBViewer Sender aufgenommen werden verwendet dieser seinerseits auch die PluginsX-Ordner.
Auf jeden Fall kommt es dann zu doppelten Anfragen in Oscam, weil der Service als auch der DVBViewer den Sender Tunen.
Aufgrund der Vielzahl von verschiednenen Programmen gehe ich nicht weiter auf die Plugin-Installation ein.
Es wird bei MDAPI(+) nur die dvbapiNET.dll benötigt, NICHT die ffdecsa.
Die Entschlüsselung wird von der Host-Anwendung vorgenommen, mein Plugin dient nur als "dumme" Schnittstelle zwischen OScam DVBAPI und der Host-Anwendung.
Das Schränkt auch die Verwendung von anderen Verschlüsselungsalgorithmen ein. Es wird nur DVBCSA unterstützt! Bei Verwendung mehrerer Instanzen für PIP oder Aufnahmen muss darauf geachtet werden, dass alle Instanzen im Speicher verbleiben und nicht entladen werden (einige TV-Programme bieten diese Option in den Plugin-Einstellungen)
Es wird bei MDAPI(+) nur die dvbapiNET.dll benötigt, NICHT die ffdecsa.
Die Entschlüsselung wird von der Host-Anwendung vorgenommen, mein Plugin dient nur als "dumme" Schnittstelle zwischen OScam DVBAPI und der Host-Anwendung.
Das Schränkt auch die Verwendung von anderen Verschlüsselungsalgorithmen ein. Es wird nur DVBCSA unterstützt! Bei Verwendung mehrerer Instanzen für PIP oder Aufnahmen muss darauf geachtet werden, dass alle Instanzen im Speicher verbleiben und nicht entladen werden (einige TV-Programme bieten diese Option in den Plugin-Einstellungen)
Oscam funktioniert ab R11520 (Ab da wird erst der nötige DemuxID Descriptor ausgewertet)
Zwischenzeitlich wurde viel an dem DVBAPI-Protokoll herumgeschraubt.
Mit der Version vom 30.07.2020 habe ich den Support für die neue Protokollversion (v3) vollständig entfernt da sich immer wieder user melden die Verbindungsprobleme hatten.
Das Oscam-Team arbeitet zudem auch nicht am Protokoll weiter, weshalb ich es erst wieder einbauen werde sobald eine stabile Verbindung möglich ist.
Eine Alternative Installation ist über ein Setup möglich, hier nochmals vielen Dank an @clemenss!
Der Thread hierzu kann dort gefunden werden: [SUCHE] OScam Installation mit DVBviewer
INI:
[dvbapi]
# Hostname oder IP-Adresse unter der OSCAM DVBAPI erreichbar ist:
server=127.0.0.1
# Port am OSCAM-Server:
port=633
# Adapter-Offset, Tweak um mehrere Verbidnungen mit oscam zu ermöglichen.
# Wichtig ist, dass der Offset immer größer ist als die schon in anderen Apps konfigurierten gleichzeitigen Instanzen!
# Grundlegend empfehlenswert ist aber die Verwendung von meheren Oscam-Instanzen.
offset=0
[log]
# 65535 sollte alles loggen, läuft über Flags.
# Bedeutungen:
# Fehler = 1,
# Warnungen = 2,
# Info = 4,
# EcmInfo = 8,
# DvbApi = 16,
# Dvbviewer Plugin Event = 32
# InterCom Verbindung Allgemein = 128,
# InterCom Client (Verbindung Seite "Demuxer") = 256
# InterCom Server (Verbindung Seite "DVBApi-Client") = 512
# Kontrollwörter Loggen = 1024
# Hex-Dump aktivieren (nur zusammen mit anderen, nicht alleinig funktional) = 32768
debug=0
# ausführliche hex-dump mit ascii aktivieren, ansonsten einzeiliger dump (ideal für copy paste)
prettyhex=1
[debug]
# zu debug zwecke um genau zu bestimmen was das plugin
# an Daten bekommt, kann mit nachfolgendem Wert (1) ein Streamdump erstellt werden.
# Der Dump wird in diesem Ordner erstellt. Es sollte für ausreichend Platz
# gesorgt werden. Im 184 Byte MDAPI Modus kann hiermit der rekonstruierte Stream überprüft werden.
streamdump=0
Du musst Regestriert sein, um das angehängte Bild zusehen.
Angehängt am Ende ist immer nur die aktuelle Version.
Hier die einzelnen Changelogs:
Try-Fix/Misc:
- Deadlocks bei AltDVB behoben, statt Sendmessage async Postmessage verwendet..
- Diverse Interne strukturuelle Anpassungen zwecks einfacherer Verwendung in anderen Projekten.
- Add: Adaption Field Parser für eigene Projekte.
Misc/Fix:
- Der Einfachheit halber Unterstützung für dvbapi Protkoll v3 entfernt.
Misc:
- Logging im Fehlerfall weiter optimiert
- Schnittstelle für z.B. Konsolenausgabe einer Debug-Anwendung eingefügt.
- Texte angepasst, Plugin-Version als auch Debuglevel werden nun zur Initialisierung einmal geloggt
- MDAPI+: Hier wurde der 188 Byte-Modus zu früh aktiviert, was dazu führte, dass die falschen PIDs bei MDAPI+ angefordert wurden.
Reines Pflege-Update, keine neuen Features oder Verbesserungen am Plugin selbst.
Misc:
Misc:
- Exporte angepasst, Internas des Plugins sind nun internal, nicht mehr public.
- ffdecsa DLLs ausgetauscht, auch hier unnötige exports entfernt.
- zusätzliche Funktionen für Nutzung in anderen .NET Anwendungen eingepflegt, ggf. für spätere eigene Tools wertvoll.
- Fehlerhafte INT-Dll von ffdecsa ausgetauscht, funktioniert jetzt auch auf CPUs ohne SSE und AVX
Fix:
- MDAPI+: Hostversion wurde nicht richtig gelesen, damit wurde der 188 Byte Modus nicht eingeschaltet wenn echtes MDAPI+ genutzt wird.
- Performance-Optimierung bei aktiviertem Logging. Bei Langsamen HDDs konnte es zu Thread-Blockierungen kommen. Das ist behoben.
Es dürfte von der Performance jetzt keinen Unterschied mehr machen, ob Logging aktiviert oder nicht. - Kleinere Anpassungen an den Log-Texten
Add:
- Multi-Language-Support: Bei PCs mit deutscher Sprache sind die Log-Ausgaben in Deutsch, ansonsten Englisch
- DES Schlüssel konnte aufgrund eines Denkfehlers nicht gesetzt werden. DES war nicht funktionsfähig.
Falls jemand testen kann, bitte um Rückmeldung.
Fix:
- Bei Fehlender Port-Option wurde keine Primär-Instanz gestartet, dadurch keine Verbindung zu Oscam und der Instanzen untnereinander
- Tweak um mehrere Clients an Oscam anzubinden. Hierzu habe ich eine neue Konfigurationsvariable in die Config eingebaut.
in der Section [dvbapi] die Variable offset. In der Konfiguration habe ich entsprechende Hinweise gegeben, was zu beachten ist.
Standardwert für Offset (falls fehlend in der Konfiguration) ist 0
- Optimierungen am Log-System es werden nun die Log-Zeilen erst bei aktiviertem Log zusammengebaut ála sprintf(...);
- Genauere Differenzierung ob überhaupt Fehler bei Logging bezüglich der Pipe-Server-Instanz, hier war vorher keine Ausgabe.
- Stabilität bei Fehlern während der Initialisierung oder nach fehlerhafter Initialisierung erhöht.
Fix:
- DVB-CISSA/AES/DES: Schlüssel wurde nicht korrekt gewählt, Denkfehler bei Implementierung.
Tests mit Verimatrix und anderen DVB-CISSA Beispielen liefen jetzt fehlerfrei.
DES weiterhin ungetestet!
- No-Delay-Option bei internen Sockets hinzugefügt um ggf. verzögerter Verarbeitung der Socketdaten vorzubeugen.
- Weitere Performance-Optimierungen, es läuft nun nur noch die beigefügte ffdecsa Version. Es kann auch eine Eigene verwendet werden, es werden wenn diese die getrennten Controlword-Setter ausführt (set_even_control_word(...) und set_odd_control_word(...) in Cdecl Aufrufkonvention)
Das gilt nur für DVBV/DMS/RS, MDAPI bringt eigenes ffDeCSA mit!
Fix:
- MDAPI(+): Löschen des FIlters funktioniert nun, hier waren mehrere Codebeispiele die ich nutzte schon falsch. RunningID wird nun zurückgelesen und für Stoppen genutzt.
- MDAPI(+): CaPMT-Update funktioniert nun auch bei MDAPI, es wird eine Network-ID über die SDT ermittelt, sofern Transport-Stream-ID korrekt gesetzt.
- MDAPI(+): 184 Byte-Mode war fehlerhaft, wenn mehr als 1 packet in den Filter kam.
- Fehler in SDT-Parsing behoben.
- SDT und CAT wurden unnötigerweise vom Plugin angefordert - entfernt
Fix:
- CaPMT-Update funktioniert nun, sofern die TransportStream ID in den Sendereinstellungen korrekt ist. Oscam holt sich diese selbst über die PAT, Bei einem CaPMT-Update prüft Oscam allerdings den Eigma-Namespace, der nicht vorhanden war, und eigentlich hier nicht existiert. Hier ist jetzt eine Minimalimplementierung mit Network ID und Transportstream ID vorhanden. Benötigt wird das u.A. bei einigen Services mit dynamischer Anzahl Audio-Streams.
- Experimenteller Support für DES-Verschlüsselung - UNGETESTET, Warnung wird bei entsprechender Debug-Log auch ausgegeben.
Misc:
- Kompatibilität mit verschiedenen ffdecsa-Versionen erhöht.
Wer eigene Version baut, dort müssen die originalen Exports vorhanden sein mit CDECL Aufrufkonvention. - Performantere ffDeCSA-Versionen von @schwa226 eingefügt, BIG THX! NUR FÜR DVBVIEWER/DVBV MEDIA SERVER/RECORDING SERVICE!
Alte Version liegt im Ordner OLD, neue Version liegt je nachdem was verwendet wird (SAT>IP oder normale Hardware) in ffdecsa SATIP oder ffdecsa Ordner. AVX für moderne CPUs, SSE2 für ältere.
Wenn es nicht läuft kommt es leider zum Teilweise bis kompletten Crash vom DVBViewer/Mediaserver Da der Native-Code knallt, lässt sich das nicht abfangen.
Fix:
- MDAPI 184 Byte Modus: EMM filter gefixed, alle EMM mit Table-ID 0x8... werden nun erfasst. Erhöht u.U. aber auch die Fehleranfälligkeit, hier sollte dann mit EMM Len Whitelist in oscam gearbeitet werden.
- Einige Log-Ausgaben im MDAPI-Teil waren noch falsch zugeordnet (Info statt Error oder Warning)
Fix:
- Videoguard EMM Fix auf alle TS-Packets angewendet; dadurch oft fehlerhafte (unvollständige) Sections und kein Bild bei einigen Sendern.
- MDAPI 184 Byte Modus: EMM für bestimmte viaccess Karten gehen möglicherweise nicht an Oscam.
Grund ist dass ich nur bestimmte Table IDs zulasse, 0x80, 0x81 für even und odd ecm, 0x82 und 0x83 für emm. viaaccess scheint hier noch weitere zu nutzen, von 0x84 bis 0x8e
Dann steigt allerdings die Fehlerquote für EMM/ECM.
Fix:
- MDAPI: Videoguard-EMM wurden im 184 Byte Mode zu oft an Oscam übertragen, je nachdem wie viele EMM pro TS-Packet waren, teilweise 6-7 mal. Ursache: statt nur die betreffende Section in den Buffer zu kopieren wurde das gesamte TS-Packet kopiert.
- Änderungen bzgl. AES Cissa im ECB-Modus (stammt aus Test für einen User im SB) rückgängig gemacht. Falls jemand AES ECB kodiertes Material hat, bitte testen.
Add & Fix:
- MDAPI 184 Byte Modus - von nun an funktioniert auch der 184 Byte Modus, also alte MDAPI+ oder MDAPI-Versionen sollten nun auch funktionieren.
Test war mir leider bisher nur mit ProgDVB Möglich. Realisierung läuft über Rekonstruktion der TS-Packets aus den 184 Bytes Packets ermittelten DVB-Sections. - Mittels Stream-Dump über die Konfiguration kann der rekonstrukierte TS-Datenstrom in eine Datei geschrieben werden.
- Code Cleanup
- ProgDVB löscht die Filter für die einzelnen Streams unter Umständen nicht oder nicht sofort. Das hat bei aktiviertem Warning-Logging zur Folge, dass die Logdatei extrem aufgebläht wird. In dem Fall wird pro empfangenen Packet was nicht mehr zugeordnet werden kann eine Zeile in die Logdatei geschrieben.
Fix:
- Ausnahmen beim beenden bezüglich geschlossener Streams und Sockets beseitigt.
- MDAPI+ Schnittstelle hinzugefügt. BIG THX to schwa226! Der 184 Byte-Modus ohne TS-Header funktioniert noch nicht, wenn die angeforderte Section mehr als 181 Byte einnimmt.
Hier muss noch gearbeitet werden. In ProgDVB funktioniert das Plugin. Ausführlich testen konnte ich nicht, da meine ProgDVB-Installation äußerst instabil läuft und immer wieder die Senderliste beim Einschalten eines Senders zerstört. Fehler sind daher auch hier nicht gänzlich auszuschließen.
Aufgrund der Struktur von MDAPI funktionieren nur Sender mit DVB-CSA Verschlüsselung.
Fix:
- Wenn im Puffer der TV-Karte noch alte Daten vom vorherigen Transponder enthalten sind, kam es dazu, dass diese Daten immer wieder herangezogen wurden.
- Für Debugzwecke Funktion zum Stream-Dump eingebaut, TS-Dateien werden im selben Verzeichnis wie auch die Logfile angelegt. Nähere Infos in den Kommentaren der Konfigurationsdatei.
Misc:
- Verhalten bei falschem Stream angepasst, Log-Ausgaben sollten nun besser funktionieren.
- Bei CAPMT-Update schlägt dieses fehl. Ursache ist, dass oscam Daten vergleicht, die auf PC-Systemen nicht zur Verfügung stehen, z.B. Enigma Namespace oder Ca-Mask-Descriptor (veraltet, wurde durch andere Descriptor ersetzt).
Diese Daten gibt es nur auf einem E2 Receiver, und nicht am PC. Möglichkeit wäre hier die Informationen vorzugaukeln, jedoch muss das mit Bedacht geschehen.
Fix:
- Bei Senderwechsel wurde der Descrambler nicht aufgeräumt, das führt zwar zu kürzeren Umschaltzeiten (im <5ms Bereich) aber führt dazu, dass neue PIDs mit dem falschen CW descrambled werden. Empfindliche Video und Audiodecoder haben damit Probleme und können u.U. abstürzen.
- Wenn lediglich DVBCISSA/AES128 verwendet wurde kann die ffdecsa. entfallen. Bei Fehlen dieser DLL gibt es nun keine Probleme mehr.
CSA steht in dem Fall nicht zur Verfügung, führt aber dennoch zu Fehler-Ausgaben im Logfile.
- CW-Logging aktiviert. Bezug auf ECM ist nicht mögilch, da ich nicht weiß was das ECM ist was an Oscam gesendet wird.
Hier hilft es weiteres Logging + Hex-Dump zu aktivieren.
- Vereinfachung der internen Descrambler Schnittstelle und Fehleranfälligkeit reduziert.
Tryfix:
- Unter bestimmten Umständen kam es vor, dass der Dvbapi-Client die Verbindung zu Oscam nicht neu aufgebaut hat.
Ich habe den Teil hier etwas umstrukturiert, dass ein separater Thread sich ausschließlich um den Verbindungsaufbau
und die Überwachung dessen kümmert. Vorher lief das über den Funktion zum Senden der Nachrichten.
Fix:
- ECM-Info kam bereits bei Loglevel 2 (Warning)
- Log-Ausgabe angepasst bei Stop-Filter, u.U. kommt es beim Umschalten zu einer Warnung,
dass der übermittelte Filter/Demuxer nicht gefunden werden kann. Das hat den Hintergrund dass oscam etwas spät, bzw. das Plugin etwas früh alles abräumt.
- Kleinere Umstrukturierungen.
Fix/Workaround:
- Nochmal zum Fehler aus der Vorherigen Version mit dem Falschen Stream-Inhalten:
Alle Packets werden nun über den RawTransponder Callback abgewickelt, hier scheinen bisher die Packets korrekt reinzukommen.
Es kam sogar oft zu keinem Bild, da ausschließlichüber den PidCallback nur noch Packets eines anderen Transponders rein kamen.
- Abwicklung nun nur noch über den Main TS-Callback damit einfachere Implementierung neuer Plugin-Schnittstellen.
- eigenen Packetfilter eingebaut
- Logging ergänzt
- Code etwas aufgeräumt.
TryFix:
- Unter bestimmten Umständen kommt es vor, dass der DvbviewerMediaServer die Streams vermischt. z.B. erhält plugin1 dann die PMT-Daten vom anderen Tuner, falls ein 2. Sender eingeschaltet ist. Ich habe hier nun einen Filtermechanismus eingebaut, der wenigstens die PMT-Daten filtert. Bei den ECM-Streams ist das nicht möglich. Daher kann es u.U. zu Fehlern kommen, z.B. Sender werden nicht hell wenn auf beiden Transpondern die ECMs in den selben PIDs liegen.
In dem Fall wird das PMT-Tracking abgeschaltet, heißt falls Audiochannels weg und zugeschaltet werden bekommt Oscam das nicht mit.
Den "Fehler" habe ich bereits beim Dvbviewer-Team gemeldet.
Add
- ECM-Info, wenn im Log eingeschaltet werden ECM-Zeiten usw. geloggt.
- DVB-CISSA/AES128 ECB/CBC Unterstützung z.B. bei BISS2
- Default-Config, Es besteht die Möglichkeit das Plugin ohne Konfiguration laufen zu lassen, altes Protokoll wird erzwungen und Logfile ist deaktiviert, Voraussetzungen sind:
Server: 127.0.0.1 (localhost)
Port: 633
- Plugin-Vorbereitung für Mediaportal
Ich war bisher nicht in der Lage Mediaportal mit dem Recording-Service als SatIP-Server laufen zu lassen.
- Bei Videoguard/NDS EMM kommt es im Filter zu einer unendlichen Rekursion sobald mehr als 2 EMM pro TS-Packet übertragen werden.
Wenn ihr meint, dass es Fehler oder Fehlfunktionen gibt, dann benötige ich möglichst ausführliche Informationen:
- Sender der Entschlüsselt werden soll
- Satellitenposition und Frequenz
- Logdatei vom dvbapiNET (Debug in Konfiguration auf 32767 stellen, Binary Dumps brauche ich erstmal nicht
Fordere ich bei bedarf aber an. - Oscam-Log, vollständig vom Start bis zum Fehlerzeitpunkt, Hier Debug auf 128 stellen
- Genaue Beschreibung des Fehlers, wann tritt der auf, bzw was ist zu tun bis der Fehler
- Versionsstände der Software die Verwendet wurde.
Manchmal scheint es mit dem DVBViewer Probleme mit dem Decoding zu geben, ich selbst habe das z.B. auf meinem Standrechner bemerkt, wo ich von einer alten Version auf eine neuere aktualisiert habe. In älteren Versionen scheint die Einstellungen für Max Queued Audio für Probleme zu sorgen. Hier ist manchmal ein Wert größer als Null eingetragen.
Idealerweise steht da 0 drin, denn dann puffert der DVBViewer so viel wie er benötigt. Dazu bei (1) klicken, dann bei (2) und (3) den wert auf 0 setzen und mit Übernehmen + OK speichern.
Idealerweise steht da 0 drin, denn dann puffert der DVBViewer so viel wie er benötigt. Dazu bei (1) klicken, dann bei (2) und (3) den wert auf 0 setzen und mit Übernehmen + OK speichern.
Du musst Regestriert sein, um das angehängte Bild zusehen.
Misc:
- Überlegung im Bereich alternativer Verzeichnisse in dem die Konfiguration abgelegt sein kann.
- weitere Plugin-Schnittstellen? Vorschläge?
- Angabe mehrer dvbapi-Fallbacks, vorschlag aus dem Streamboard.
- DVB-IP (Sat>IP) Proxy zum zwischenschalten an z.B. Fernsehgeräte oder Software ohne Plugin-Support
- Webinterface für das Plugin um Status, offene sender, CWs usw. abzurufen.
- Für MDAPI-Clients, die einzelne Instanzen wieder entladen: Hostanwendung für die Verbindung zu Oscam
bzw. um die Master-Instanz aktiv zu halten.
PS:
Aufgrund der häufigen Nachfragen, bzgl. Spenden:
Auf meiner Website (verlinkt im Profil) befindet sich unten ein Spenden-Button.
Hallo Leute,
Angefangen habe ich im alten mdvbapi-Thread, und dort bereits angekündigt, dass ich ein neues Projekt erstellen werde.
der Erste Versuch ist leider gescheitert, aufgrund der schlechten Dokumentation von Visual C++ Klassen usw.
Und wenn etwas zu finden war, bin ich irgendwie von einem Fettnapf in den nächsten getapst.
Ich habe nun eine Möglichkeit (zuverlässig) gefunden mit der ich C# .NET Module mit herkömmlichen stdcall/cdecl Exports aufbauen kann:
Da ich bereits einiges an C# Entwicklung durch habe, ist das ganze für mich wesentlich leichter. Ich schaffe pro Zeit doppelt so viel.
Seit gestern Abend deutlich mehr geschafft:
(Screenshot entfernt)
Nun benötige ich aber so langsam eure Hilfe, denn das was ich an Infos benötige bekomme ich nicht mehr vom DVBViewer Forum, da dieses in den Forenregeln dort verboten ist: Softwareseitiges Descrambling.
Ich fange mal etwas weiter vorn an:
Pro TS-Packet wird die PidCallback(IntPtr tsPacket){...} einmal aufgerufen.
Wie kann ich nun mehr als 1 Paket gleichzeitig durch ffdesca jagen?
Einzelne Pakete zu descramblen ist äußerst ineffizient und selbst mit aktuellen CPUs steigt die Last erheblich an.
Da ich nun auch mit dem Debugger in das Modul während des Betriebs reinschauen kann habe ich festgestellt dass mehrere Threads gleichzeitig laufen, entsprechend wird die PidCallback auch mehrfach parallel aufgerufen. Singlethreaded - da hat mir der debugger einen streich gespielt.
Das ändert aber nichts daran, dass ich keine 200 Pakete gleichzeitig durch den desccrambler jagen kann.
Selbst wenn ich es Asynchron mache, können die Pakete bereits weiterverarbeitet oder die Pointer auf die Pakete bereits ungültig sein.
Ich hoffe mein Problem verständlich genug rüber gebracht zu haben - und jemand liest es der eine Lösung kennt
AddRawTsCall bringt mir da auch nicht viel, da dort ebenfalls nur 188byte Packets reinkommen.
Zumindest mit meiner Hardware (tt-connect s2-3600 und dd cine s2)
Nachtrag 8.10.
CaPMT kann ich nun mittlerweile passend zusammenbauen.
Bin gerade bei der implementierung der Oscam DVBAPI. Muss noch herausfinden wie das ding im Detail funktioniert und wie ich die ECM/EMM aus den Pids herausfiltern muss.
Nachtrag 13.10.
Ich werde wohl die gesamte Pipe-Kommunikation über den Haufen schmeißen.
Pipes sind nicht Threadsafe. Weiterhin gibt es das Problem, dass wenn Prozess A in die Pipe schreibt, Prozess B das ausliest, aber prozess A
dann direkt nochmal was schreibt, Prozess B weiter liest, dann die Daten vom 2. Write von Prozess A bekommt.
Da scheint sich dann die Pipe zu "verschlucken"
ich lass mir da eine Lösung einfallen.
Nachtrag 23.10.
Ich habe das über einen Netzwerksocket eingerichtet, der auf eine zufällige localhost-ip (im bereich 127.0.0.0/8) auf einem zufälligen Port horcht.
per Pipe übertrage ich dann die genauen daten und ein kleines authentifizierungs-token.
Bin nun soweit, dass ich oscam mit den gefilterten Daten entsprechend versorgen kann.
ECMs werden bereits übermittelt, CWs kommen zurück.
ein paar dvbapi-befehle muss ich noch implementieren und eine Sache mit der Capmt direkt mit den oscam devs klären.
danach kommt der csa kram dran.
Nachtrag 30.10.
Mein Rechner hat gestern die Grätsche gemacht, friert dauernd ein, als notlösung hab ich das OS neu installiert.
Ich muss den jetzt erstmal neu einrichten - das wird eine Weile dauern.
Nachtrag 1.11.:
Rechner läuft wieder, malschauen wie lange. Nicht dass ich noch reklamieren muss.
Habe das Plugin nun soweit, dass ich oscam mit emm versorgen kann. mehrfache sender gleichzeitig gehen auch schonmal. Anders als im originalen mdvbapi werden die demuxer in oscam nicht bei jedem senderwechsel eines einzelnen Senders neu gestaret. das ganze verhält sich schlicht so wie auf einem e2 receiver. Dadurch gibt es keine discontinuities bei den anderen Sendern, Aufzeichnungen z.B. sollten so fehlerfrei bleiben.
im dvbviewer scheint das plugin gut zu funktionieren, Tests im Recording-Service waren eine komplette Nullnummer, keine Ahnung was da schief geht.
Als nächstes kommt nun die Einbindung vom ffdecsa.
Grüße
Angefangen habe ich im alten mdvbapi-Thread, und dort bereits angekündigt, dass ich ein neues Projekt erstellen werde.
der Erste Versuch ist leider gescheitert, aufgrund der schlechten Dokumentation von Visual C++ Klassen usw.
Und wenn etwas zu finden war, bin ich irgendwie von einem Fettnapf in den nächsten getapst.
Ich habe nun eine Möglichkeit (zuverlässig) gefunden mit der ich C# .NET Module mit herkömmlichen stdcall/cdecl Exports aufbauen kann:
Sie müssen registriert sein, um Links zu sehen.
Dieses NuGet Paket nutze ich in dem Projekt - und es funktioniert.Da ich bereits einiges an C# Entwicklung durch habe, ist das ganze für mich wesentlich leichter. Ich schaffe pro Zeit doppelt so viel.
Seit gestern Abend deutlich mehr geschafft:
(Screenshot entfernt)
Nun benötige ich aber so langsam eure Hilfe, denn das was ich an Infos benötige bekomme ich nicht mehr vom DVBViewer Forum, da dieses in den Forenregeln dort verboten ist: Softwareseitiges Descrambling.
Ich fange mal etwas weiter vorn an:
Pro TS-Packet wird die PidCallback(IntPtr tsPacket){...} einmal aufgerufen.
Wie kann ich nun mehr als 1 Paket gleichzeitig durch ffdesca jagen?
Einzelne Pakete zu descramblen ist äußerst ineffizient und selbst mit aktuellen CPUs steigt die Last erheblich an.
Das ändert aber nichts daran, dass ich keine 200 Pakete gleichzeitig durch den desccrambler jagen kann.
Selbst wenn ich es Asynchron mache, können die Pakete bereits weiterverarbeitet oder die Pointer auf die Pakete bereits ungültig sein.
Ich hoffe mein Problem verständlich genug rüber gebracht zu haben - und jemand liest es der eine Lösung kennt
AddRawTsCall bringt mir da auch nicht viel, da dort ebenfalls nur 188byte Packets reinkommen.
Zumindest mit meiner Hardware (tt-connect s2-3600 und dd cine s2)
Nachtrag 8.10.
CaPMT kann ich nun mittlerweile passend zusammenbauen.
Bin gerade bei der implementierung der Oscam DVBAPI. Muss noch herausfinden wie das ding im Detail funktioniert und wie ich die ECM/EMM aus den Pids herausfiltern muss.
Nachtrag 13.10.
Ich werde wohl die gesamte Pipe-Kommunikation über den Haufen schmeißen.
Pipes sind nicht Threadsafe. Weiterhin gibt es das Problem, dass wenn Prozess A in die Pipe schreibt, Prozess B das ausliest, aber prozess A
dann direkt nochmal was schreibt, Prozess B weiter liest, dann die Daten vom 2. Write von Prozess A bekommt.
Da scheint sich dann die Pipe zu "verschlucken"
ich lass mir da eine Lösung einfallen.
Nachtrag 23.10.
Ich habe das über einen Netzwerksocket eingerichtet, der auf eine zufällige localhost-ip (im bereich 127.0.0.0/8) auf einem zufälligen Port horcht.
per Pipe übertrage ich dann die genauen daten und ein kleines authentifizierungs-token.
Bin nun soweit, dass ich oscam mit den gefilterten Daten entsprechend versorgen kann.
ECMs werden bereits übermittelt, CWs kommen zurück.
ein paar dvbapi-befehle muss ich noch implementieren und eine Sache mit der Capmt direkt mit den oscam devs klären.
danach kommt der csa kram dran.
Nachtrag 30.10.
Mein Rechner hat gestern die Grätsche gemacht, friert dauernd ein, als notlösung hab ich das OS neu installiert.
Ich muss den jetzt erstmal neu einrichten - das wird eine Weile dauern.
Nachtrag 1.11.:
Rechner läuft wieder, malschauen wie lange. Nicht dass ich noch reklamieren muss.
Habe das Plugin nun soweit, dass ich oscam mit emm versorgen kann. mehrfache sender gleichzeitig gehen auch schonmal. Anders als im originalen mdvbapi werden die demuxer in oscam nicht bei jedem senderwechsel eines einzelnen Senders neu gestaret. das ganze verhält sich schlicht so wie auf einem e2 receiver. Dadurch gibt es keine discontinuities bei den anderen Sendern, Aufzeichnungen z.B. sollten so fehlerfrei bleiben.
im dvbviewer scheint das plugin gut zu funktionieren, Tests im Recording-Service waren eine komplette Nullnummer, keine Ahnung was da schief geht.
Als nächstes kommt nun die Einbindung vom ffdecsa.
Grüße
Zuletzt bearbeitet:
