Beiträge von HelmutB

Auf 12534H ist ein Transponder mit 4 Streams (33,34,35,36) aber ohne PLS : Link.

Bekommst du da einen Lock ? Ohne PLS sollte es VDR auch ohne den multistream Patch können.

Hier 2 Kanaleinträge für die Stream-Id 33:

ISID33:12543:HC89M5O0P33S1:S5.0W:34200:0:0:0:0:0:0:0:0

Giallo:12543:HC89M5O0P33S1:S5.0W:34200:0:0:0:0:16:11:33:0

Und hier noch 2 Varianten für MIS+PLS auf 12648V

bbb:12648:VC89M5O0P1Q1212121S1:S5.0W:29500:0:0:0:0:0:0:0:0

TF1:12648:VC89M5O0P1Q1212121S1:S5.0W:29500:0:0:0:0:2561:8442:10:0

Helmut

Ok, habe den Fehler gefunden. DVB-APi Version 5.11 ist gefragt - in Hex 0x50B, und nicht 0x511 wie im Patch.

Dadurch wurde der scrambling_sequence_index '121212' nicht an das Frondend gesendet - kann daher auch nicht gehen.

Im Anhang ein kleines diff und der ganze Patch als Version 1.

LG Helmut

Da die Informationen des S2 DeliverySystemDescriptors derzeit noch nicht verwertet werden, hier ein Patch der - so wie ich es mir vorstelle - DVB-S2 Multistream in den VDR bringt.

Ich wollte ihn dieses Wochenende auch in der Praxis mit Eutelsat 5.0W testen, nur ist meine alte Selfsat Antenne die dazu verwendet habe offensichtlich nicht geeignet, da sich zw. 8.0W und 3.0W noch 4 weitere Satelliten befinden und die Selfsat, vermutlich durch einen zu großen Öffnungswinkel, alle einfängt und man daher kein stabiles Signal bekommt. Als Satempfänger war eine TBS-5520SE angeschlossen.

Da es bis zu einem weiterem Versuch mit besserer Antenne etwas dauern wird, stelle ich den Patch einmal ungetestet hier ins Forum. Vielleicht hat ja jemand ein "Auge" auf 5.0W oder eine andere Position die Programme in Multistream/PLS aussendet.

Helmut

Zitat von hepi

weil die NIT ja schon source-spezifisch ist

... oder zumindest sein sollte. Es wird aber in nit.c. (noch) nicht geprüft ob die NIT zum getunten Deliverysystem passt (falls nicht, wäre sie eigentlich ungültig).

Ich habe einen halbfertigen Pach für nit.c. der u.a. auch das überprüft und werde ihn bei Gelegenheit posten.

LG Helmut

Wenn auf einem Transponder durch Programmverschiebung oder -abschaltung ein neuer Transportstream aufgeschalten wird, verbleiben die urspünglichen Kanaleinträge aber weiterhin in der channels.conf. Wenn es nur eine 1:1 Verschiebung auf einen anderen Transponder war, erkennt "MarkObsoleteChannels()" zwar irgendwann die ungültigen Programme, wenn aber Nid oder Tid nicht mehr aktiv sind klappt das so nicht mehr.

Der Patch im Anhang überprüft nun, ob die in der NIT angegebene Netzwerk- und Transportstream-ID mit den Werten des Programms der auf diesen Transponder getuned hat noch übereinstimmen. Falls nicht, werden alle Programme mit ungültiger Nid oder Tid für diesen Transponder als "OBSOLETE" markiert.

Damit der Eitscanner nichts übersieht, wird nun für jede Transponder/Nid/Tid Kombination ein eigener Channels Eintrag in die ScanList aufgenommen.

Bei mir hat es doch einige "Karteileichen" zum Vorschein gebracht.

Wer es testen will: zuvor die die channels.conf sichern, alle bereits von VDR als "OBSOLETE" markierten Programm entfernen und einen EPG Scan starten

Helmut

Wenn ich es richtig sehe, wird MTD von deinem Plugin nicht unterstützt, der TsPostProcess Patch hilft hier auch nicht.

Helmut

Ohne jetzt genau zu wissen, was du sehen willst und wie du es anstellst - villeicht ist der Patch von hier die Lösung: mtd-fix-ccamslot-tspostprocess.

Und bei einer neuen VDR-Version oder nach einem Patch der Änderungen in den VDR-Header Dateien vornimmt solltest du immer alle Plugins neu bauen.

LG Helmut

Hier das Update auf camtweaks-2.3 mit ein paar Vereinfachungen und Verbesserungen.

- nach dem Übertagen einer CA_PMT an das Modul und vor dem Senden der nächsten TPDU werden nun mind. 300ms abgewartet.

Das löst das Problem, bei dem ein Programmwechsel nach mehrern Umschaltungen irgendwann nicht mehr möglich war.

- Mit MTD können bei einem Programmwechsel alte TS-Pakete die noch im CI-Treiber waren nicht mehr auf die Original-Pid zurückgemappt

werden und bekommen mit 0x1FFF die Pid eines TS-NULL Pakets. Das führte manchmal zu einer 3 Sekunden Verzögerung so wie hier:

Jul 20 13:59:21 home-05.home.de vdr[1753]: [1753] CAM 1: unassigned from device 1
Jul 20 13:59:21 home-05.home.de vdr[1753]: [1753] CAM 1/1: reusing MTD CAM slot
Jul 20 13:59:21 home-05.home.de vdr[1753]: [1753] CAM 1/1: MTD mapper cleared
Jul 20 13:59:21 home-05.home.de vdr[1753]: [5813] cCamSlot::TsPostProcess: Pid #0: 8191 (1FFF) S P : 9BFF1F47 ...
Jul 20 13:59:24 home-05.home.de vdr[1753]: [1753] CAM 1: assigned to device 1

Zumindest in der Kombination ddci2+ddbridge können das auch einige hundert Pakete sein, daher werden diese nicht mehr an das Device weitergegeben.

- Die Programm Limits werden nun schon vor einer möglichen Zuordnung eines Device an den CamSlot überprüft.
- Die Debugmeldungen werden nun nicht mehr ausgegeben sondern können mit 0x1000 (CAMTWEAKS) und 0x2000 (DEBUG_MTD) dazugeschalten werden

Zusätzlich sollten (weiterhin) auch noch der vdr-2-4-1-mtd-lockedtctspostprocess-patch sowie der vdr-2-4-1-mtd-stopdecrypting-patch angewendet werden.

Helmut

An einem i2c Bus können mehrere Slaves hängen. Die Addressen aller an einem Bus vorhandenen Slaves kann man mit "i2cdetect -y <I2cbus>" erfahren.

Bei mir z.B ist die Slaveaddresse des Notebookpanels 0x50. Und mit dieser Addresse kann ich dann die EDID Daten auslesen:

gentoo64 ~ # i2cdetect -l
i2c-3    i2c           i915 gmbus panel                    I2C adapter
i2c-1    i2c           i915 gmbus ssc                      I2C adapter
i2c-8    i2c           DPDDC-B                             I2C adapter
i2c-6    i2c           i915 gmbus dpd                      I2C adapter
i2c-4    i2c           i915 gmbus dpc                      I2C adapter
i2c-2    i2c           i915 gmbus vga                      I2C adapter
i2c-0    smbus         SMBus I801 adapter at 7000          SMBus adapter
i2c-9    i2c           DPDDC-C                             I2C adapter
i2c-7    i2c           DPDDC-D                             I2C adapter
i2c-5    i2c           i915 gmbus dpb                      I2C adapter
gentoo64 ~ # i2cdetect -y 7
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                         
gentoo64 ~ # i2cdump -y 7 0x50
No size specified (using byte-data access)
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 ff ff ff ff ff ff 00 4d d9 fa 06 01 01 01 01    ........M???????
10: 20 14 01 04 95 1d 10 78 02 0f 15 9a 56 4b 8b 26     ??????x????VK?&
20: 20 50 54 00 00 00 a9 c0 01 01 01 01 01 01 01 01     PT...??????????
30: 01 01 01 01 01 01 2f 2a 40 71 61 84 0f 30 40 40    ??????/*@qa??0@@
40: 33 00 23 a4 10 00 00 18 b9 1d 40 df 61 84 0f 30    3.#??..???@?a??0
50: 40 40 33 00 23 a4 10 00 00 18 00 00 00 fc 00 53    @@3.#??..?...?.S
60: 6f 6e 79 20 4c 43 44 0a 20 20 20 20 00 00 00 fd    ony LCD?    ...?
70: 00 27 3d 24 37 0b 00 0a 20 20 20 20 20 20 00 de    .'=$7?.?      .?
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
gentoo64 ~ #

LG Helmut

I found a similar question in this thread: vdr patchen und neu bauen

And a link to the Debain tutorial https://wiki.debian.org/BuildingTutorial

May be, this is helpfull for you.

BG

Halmut

To apply the patch to the VDR sources, you could copy it into the vdr-2.2.0 source directory and run patch -p1 < vdr-2.2.0-Add-bul-LanguageCode.patch.

But as i m using gentoo, i dont know the right steps to patch and build your own binary of VDR for YaVDR.

May be some other forum members can help you (i think seahawk1986 is the master of the yavdr universe).

BG

Helmut

Hallo Alexandro,

i think that adding this line in i18n.c should fix it:

--- a/i18n.c.orig    2012-09-01 12:53:43.000000000 +0200
+++ b/i18n.c    2019-09-01 20:05:38.346970858 +0200
@@ -60,6 +60,7 @@ const char *LanguageCodeList[] = {
   "tur",
   "ukr",
   "ara",
+  "bul",
   NULL
   };

BR

Helmut

Ich habe jetzt nachgelesen:

Ab dem Kernel 5.1.12 und damit auch im Kernel 5.2 wird statt dprintk nun dev_dbg verwendet (der Patch im Link in Pos #2) tund damit sollte diese Meldung ab dieser Kernelversion nicht mehr auftauchen.

Helmut

Es hat sich herausgestellt,, daß der Lock in CamSlot::TsPostProcess() ohne MTD zu einem Deadlock des (Master) CamSlots führen kann.

Das Locken muß richtigerweise in cCiTransportConnection::TsPostProcess() erfolgen.

Helmut

Nachdem der camtweaks-2.1 Patch bei den neuen Funktione immer noch fehlerhaft war, hier nun mit etwas Verzögerung der camtweaks-2.2.patch.

Wie es aussieht lassen sich damit nun auch mit der Sky-CAM 2 Programme gleichzeitig aufnehmen.

Für MTD und CI+ ist (unter anderem) auch noch der vdr-2.4.1-Mtd-LockedTsPostProcess.patch von hier erforderlich.

Und damit das CAM bei SIngle-und MCD sowie MTD immer gleich behandelt wird, kann auch noch vdr-2.4.1-Mtd-StopDecrypting.patch von hier eingespielt werden.

Die Einstellung 0x3 sollte unverändert wie in camtweaks-1 funktionieren.

Mit der Option 0x23 werden alle aktiven Progrmme (auch bei MTD) in einer einzigen CA_PMT an das CAM gesendet ( mit 0x13 eine CA_PMT je Transponder ). Das funktioniert bei einigen CAMs problemlos, bei einer meiner CAMs habe ich allerdings Bildstörungen beim Entfernen von Pids festgestellt. Der Erfolg kann also etwas vom Modul abhängen.

Helmut

Das CamSlot::TsPostProcess() des MasterSlot benötigt einen Lock, damit auch bei Zugriff von mehrern MtdCamSlots die modifizierten Daten immer im richtigen TS-Paket landen.

Helmut

Hi Corvy !

First, the camtweaks-2.1.patch is faulty, Sorry, but I spent the the last weeks to make the Sky CI+ CAM working, so i did not post a better Version.

But today i got a possitive feedback and so i will post a new camtweaks2.2.patch in the next hour or so.

And yes, you can delete EnableCaModuleTweaksin setup.conf (if you stay on version2), i did a reneming and forgot to think on the old name in camtweaks1. And that why you had to enable camtweaks again in setup.

BR

Helmut

BTW: the description in your camtweaks.conf should look a little different in version 2 , as there are 2 more possible options to set.

And if you have troubles, the camtweaks1.patch should stil work with vdr-2.4.1

Laut https://www.linuxtv.org/wiki/i…hp/Hauppauge_WinTV-dualHD wird seit Kernelversion 4.7 ein Tuner und erst ab 4.17 beide Tuner unterstützt.

Ubuntu 18.04 dürfte aber Orignal nur den Kernel 4.15 dabei haben: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes. Es kann also auch daran liegen.

LG

Helmut

Edit: Falls du überhaupt Ubuntu 18.04 benutzt - habe mich da beim Spoiler verschaut

Edit2: Alles Unsinn -du verwendest ja schon schon Kernel 4.19

Helmut

Ich habe es jetzt erst registriert - du verwendest den grafischen "Systemprotokollbetrachter" und siehst syslog / kernlog.

Wenn es stimmt, dann verwendet Ubuntu schon seit längerem nicht mehr "/var/log/messages" sondern eben syslog. Da werden aber alle möglichen Infos angezeigt, auch Kernelmeldungen. Vermutlich siehst du auch Meldungen, bei der die printk Konfiguartion nicht berücksichtigt wird - so wie in dmesg.

Hier eine Erklärung und mit weiterem Link wie man /var/log/messages bei Ubuntu wieder aktiviert,

https://unix.stackexchange.com…where-is-var-log-messages

(ich habe tail -F /var/log/messages immer in einem Terminalfenster laufen)

Helmut

Zitat von thba1

eine Änderung von kernel.printk hier oder wie oben...

Hätte ich auch so gesehen, sitze aber garade an einem Windoes Rechner und kann es nicht überprüfen.

Ich werde es mir am Abend oder Morgen ansehen.

Helmut