Ist das allgemein ein Problem des decodings? Bin nämlich neu in dem Bereich, hatte bisher (seit rund 10 Jahren) nur free TV aufgenommen und seitdem nie einen Absturz dvbviewer bedingt gehabt (tägliche Aufnahmen). Der Absturz nach dem Wechsel von mdvbapi zu dvbapi.NET war aber auch bis heute nur der einzige...
edit: sorry, hattest du mir oben bereits beantwortet, müsste also auch bei free TV passieren.
Recording Service undder Nachfolger DVBViewer Media Server.
Und bitte keine Komplettzitate, und sicher nicht wenn du antwortest auf ein Post der direkt drüber steht.
Bluescreens kannst du ganz simpel provozieren, auch ohne Plugin im RS/DMS/DVBV
Sender einschalten, taskmanager her holen, und im richtigen Moment den Prozess abschießen et voila Bluescreen - hat nix mit mdvbapi oder meinem Plugin zu tun.
Passiert bei Digital Devices Cine S2 karten sehr schnell.
Für einen Bluescreen muss es ja im Kernel Code krachen. Soweit ich weiss, haben RS/DMS/DVBV keine eigenen Treiber, deshalb muss es eigentlich im Treiber der DVB-S Karte knallen.
Oder irgendwo im Windows Kernel, aber das ist glaube ich eher unwahrscheinlich.
Also eigentlich ein Bug von Digital Devices. Ich selber habe steinalte FireDTVs und Sat->IP, da hat es noch nie geknallt, wenn ich den DMS Service Prozess abschiesse.
DMS läuft in einer VM und kann auf die Digital Devices Treiber auf dem Host zugreifen? Oder laufen die Treiber auch in der VM? Und machen dann da bei Bedarf den Bluescreen?
Doch, man benötigt allerdings. CPUs und Chipsätze die das unterstützen. IO Virtualisierung nennt sich das. Linux drauf installiert auf dem Rechner, KVM mit libvirtd als Umgebung und darauf die VMs aufgesetzt. Ich nutze oVirt als Repository damit lässt sich das bequem installieren. Hardware kann dann durchgereicht werden, geht auch mit Grafikkarten oder anderen PCIe Geräte. OT Ende.
Kann jemand Mal PowerVu mit DES Verschlüsselung testen ob das auch funktioniert?
Nunja, es sind überlegungen, ob ich das mache, ist noch eine andere Sache. Ich habe da nicht Mal einen Rohbau oder Ahnung von dem Umfang des Protokolls
nutze nun seit einigen Tagen / Wochen den aktuellen DVBViewer MS und die dvbapiNET in Kombination. Auf einem OrangePI läuft die aktuelle Oscam mit einer HD01 Karte in einer smartmouse. DVBV MS läuft auf einem Win 2008r2 mit einer DD Cine S2 V5 mit zusatz- Doppeltuner - sprich 4 Tunern in Kombination.
Nun habe ich, seit ich HD+ aufnehme (hab erst im Dez. 2019 nen Abo aktiviert), vereinzelt discontinuties / Errors. Vereinzelt wirklich relativ selten. Bei den freien ÖR und SD Privaten hatte ich so gut wie NIE in den letzten Jahren solche disconts / Errors - habe ich auch aktuell nicht.
Nun meine Frage, Wie kann ich diesen genauer auf den Grund gehen? Vielleicht dvbapiNET logs???
Hier ein Auszug aus der Oscam.log, der besagt, dass da alles rund lief:
Code:
2020/02/05 20:00:03 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:AB0AB93AAFFD9D07055B195CB05F5AED): found (323 ms) by HD01
2020/02/05 20:00:13 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:223EE63D8A8B16D915107DA6E238B790): found (323 ms) by HD01
2020/02/05 20:00:23 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:2062AF49E4A4FCF68284C0D06E2421C6): found (324 ms) by HD01
2020/02/05 20:00:33 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:4C08E761B081931C105FC564BF0E4FEB): found (325 ms) by HD01
2020/02/05 20:00:43 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:22853DF312F2E29573137C11752D6403): found (324 ms) by HD01
2020/02/05 20:00:53 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:BCACA053AA3B1B5A003EBA83FE3B3437): found (324 ms) by HD01
2020/02/05 20:01:03 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:A31A2E0655826A6884FDFB6594A9BCB0): found (323 ms) by HD01
2020/02/05 20:01:13 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:F0B93B690C952A89EB892CE70EF75FFE): found (324 ms) by HD01
2020/02/05 20:01:23 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:E893DC3F40947D604290672E3372345C): found (323 ms) by HD01
2020/02/05 20:01:33 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:28624CBC10F9C89654FBE3131C0EA08C): found (324 ms) by HD01
2020/02/05 20:01:43 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:B5FB6564E4FECB809C754451A8891E89): found (322 ms) by HD01
2020/02/05 20:01:53 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:BF17F08A95D6E3ABA512CA72B4C3871D): found (323 ms) by HD01
2020/02/05 20:02:03 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:0A29028538BF3189CF4472E1471D549E): found (323 ms) by HD01
2020/02/05 20:02:13 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:5167CA3BDE7399B467437743C4338DA1): found (325 ms) by HD01
2020/02/05 20:02:23 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:0A9E845337D810FDD87435FA8CAC6B8B): found (324 ms) by HD01
2020/02/05 20:02:33 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:63AE1C781A5AE590390A556243F07705): found (325 ms) by HD01
2020/02/05 20:02:43 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:5907E1C21CB5EDAF465762B944AE06C8): found (324 ms) by HD01
2020/02/05 20:02:53 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:2678036B113C37CA5380C76A2DA8F80D): found (325 ms) by HD01
2020/02/05 20:03:03 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:B406039C66CD2D0008B37144C607589A): found (324 ms) by HD01
2020/02/05 20:03:13 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:33978E0E9C17DA74D5DE3BB62A8B79F0): found (324 ms) by HD01
2020/02/05 20:03:23 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:80A42AB0AAC1C07019BFCE343EF30C35): found (324 ms) by HD01
2020/02/05 20:03:33 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:12A12D7A0A3A491A52D073F31C55C9FD): found (324 ms) by HD01
2020/02/05 20:03:43 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:3E9C156776262670E0580A3F8497387D): found (324 ms) by HD01
2020/02/05 20:03:53 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:3518F99672504451DADAB55F1A9DCC9C): found (324 ms) by HD01
2020/02/05 20:04:03 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:984A1EC9D54DE7CF2AC2528BE526D097): found (324 ms) by HD01
2020/02/05 20:04:13 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:30880CA42EDC031F423FC6990C162657): found (332 ms) by HD01
2020/02/05 20:04:23 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:1C823B3770D8869832568ADCD28F0A67): found (347 ms) by HD01
2020/02/05 20:04:33 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:05832E483F00841AC8FA35988D935EAF): found (324 ms) by HD01
2020/02/05 20:04:43 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:6F2192BE6E8F5399E63115C807667575): found (324 ms) by HD01
2020/02/05 20:04:53 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:121E35EF28CA4FC2432E80B99C4EAC52): found (324 ms) by HD01
2020/02/05 20:05:03 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:15833D719CEBF0C51A0D6D56FA5FA8C6): found (324 ms) by HD01
2020/02/05 20:05:13 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:190B26DA80AAAB25EFEF71B4A1639814): found (324 ms) by HD01
2020/02/05 20:05:23 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:416D824D519ED1582E87D36FD79851D2): found (324 ms) by HD01
2020/02/05 20:05:33 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:9BE6A49203CEE44E344BC13059FC5059): found (323 ms) by HD01
2020/02/05 20:05:43 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:E46B1032FDE1D80C88E3603CC50F1AFD): found (323 ms) by HD01
2020/02/05 20:05:53 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:D3D588221599D76B660B82CE27E7DF87): found (324 ms) by HD01
2020/02/05 20:06:03 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:FB6545492AE7B5E5875E1A5011203C30): found (323 ms) by HD01
2020/02/05 20:06:13 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:566C2988AAD62043816D5BE3A9C5AECE): found (325 ms) by HD01
2020/02/05 20:06:23 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:61C96A7FC2A3C053F152FC1F788FEAB3): found (323 ms) by HD01
2020/02/05 20:06:33 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:9A331C9F8C9BA03D902FA91DE442AC4A): found (325 ms) by HD01
2020/02/05 20:06:43 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:B6B06988D161C46BB180E533C85285B9): found (323 ms) by HD01
2020/02/05 20:06:53 02996D0C c (ecm) anonymous (1830@000000/0000/EF77/92:6387172685322180EDE0D6AF44A92575): found (324 ms) by HD01
Fehler in der Hardware schließe ich an sich aus, da hat sich nichts geändert, der hier verwendete Tuner 1 hängt an einer sauber arbeitenden Hausanlage.
Habt ihr solche errors - vereinzelt - auch, oder ist das gar normal?
keine Fehler bei mir
welche Hardware (Cpu, RAM) verwendest du, und achte Mal drauf dass deine dvbapinet Version aktuell ist. logging erstmal deaktivieren.
während die Fehler auftreten, wird innerhalb der Satanlage die Ebene gewechselt? auf einem anderen LNB Ausgang oder Multischalter Ausgang? oder gar ein anderer Tuner von der Karte verwendet?
mache Mal einen Transponder dump im Recording Service bzw Media Server und gucke Mal mit Transedit rein, ob da disconts auftauchen, am besten da in Transedit High Speed File Analysis aktivieren erst wenn das fehlerfrei ist dann gucke ich mir das Plugin an, ansonsten ist das bei den Fehlern zu viel im trüben Fischen
ich bereite gerade bisschen mdapi+ schnittstelle vor dass auch z.b. mediaportal funktioniert. benötige da aber noch bisschen zeit.
Leider bekomme ich mediaportal auch nicht ans laufen immer nur "no signal"
aber erstml frohe weihnachten, sehen uns nach den Feiertagen wieder :smile:
MDAPI(+) sollte nun funktionieren.
Leider habe ich lediglich ProgDVB, alles andere was mit mdapi läuft habe ihc nicht ins laufen bekommen.
ProgDVB zudem auch nur sehr rudimentär. Vollumfängliche Tests waren leider nicht wirklich möglich.
MDAPI(+) funktioniert schon seit geraumer zeit. wäre vielleicht schön wenn du mir mal aufzeigst wie du mdapi(+) überhaupt in Mediaportal hinbekommen hast
Anderenfalls habe ich dir hier nochmal alle Changelogs bzgl. MDAPI zusammengefasst (steht alles im ersten Beitrag), oberste sind die neuen, bis unten hin die alten.
dvbapinet funktioniert in der Einrichtung prinzipiell genauso wie mdvbapi, weitere Infos im ersten Beitrag.
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.
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)
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.
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.
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.
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.
...während die Fehler auftreten, wird innerhalb der Satanlage die Ebene gewechselt? auf einem anderen LNB Ausgang oder Multischalter Ausgang? oder gar ein anderer Tuner von der Karte verwendet?
...
Manchmal ist man einfach nur blind. Gerade mal ins Windows Ereignisprotokoll zur besagten Zeit geschaut:
05.02.2020 20:04:12
Code:
Device 001:20000 Signal lost tuner filter 1
05.02.2020 20:04:13
Code:
Device 001:20000 Relock or late lock tuner filter 1
Es ist eine Multi- Teilnehmer Anlage vom 8-Parteienhaus. Ich gehe davon aus, dass die Störung nun von außen kam.
Komisch nur, dass ich vorher nie oder so gut wie nie solche Aussetzer hatte, in SD und ich nehme auch viel im ÖR auf...
Trotzdem herzlichen Dank für die Hilfe... Vielleicht helfen mir die Tipps ein andermal oder auch jemanden, der auch solche Probs hat :smile:
PS: Da fällt mir gerade ein, dass ich vor 1-2 Jahren diese Probs schonmal hatte. Da hatte der Flughafen hier aus der Nähe eine Bahn gesperrt und die Vögel flogen nun eine andere Route, direkt durch den Sat-Empfang. Da hatte ich häufiger mal so 1-Sekunden Aussetzer. Vielleicht ist es auch sowas wieder...