Beiträge von onur

mir ist das nur bei ORF/SRF aufgefallen.

hallo klaus,
ist immer noch aktuell - und sollte in den 2.4.1 code übernommen werden.
danke, für dein arbeit, lg, onur

hallo,

vdr-2.4.0 macht dass schon richtig - soweit ich den code verstanden habe.

du könntest folgendes testen:
zeile 2504 ci.c
if (GetCaPids(source, transponder, p->programNumber, CaSystemIds, MAXRECEIVEPIDS + 1, CaPids) > 0) {

if (Active)

caPidReceiver->AddPids(CaPids);

else {

++++ FixSharedCaPids(p->programNumber, CaSystemIds, CaPids);

caPidReceiver->DelPids(CaPids);

}

}

falls dies Besserung bringt - bitte unbedingt an klaus melden - der kümmert sich dann.
gruß, onur

hallo,

ab vdr 2.3.3 funktioniert der patch nicht - bzw. ist nicht notwendig.

ab version 2.3.3 funktionieren shared CaPids.
ist niemand aufgefallen, und klaus ging nicht davon aus dass es so etwas gibt.

da wird quasi srf2 mit dem key von srf1 entschlüsselt.

wenn einer der sender beendet wird, dann wurden die pids gelöscht, und der verbliebene sender nicht mehr entschlüsselt.
der neue vdr macht das besser.
mein patch löscht pids nur wenn CaPid nicht mehr gebraucht wird.
gruss, onur

@jrie

shared CaPids sollte seit vdr 2.3.3 funktionieren.

mir ist dass mit ORF2 HD Vlbg und orf sport+ aufgefallen.

in vdr 2.3.3 wurde folgende neue funktion eingeführt.

cCamSlot::BuildCaPmts
seitdem sollte es keine probleme mit shared ECM pids geben.

falls du bei vdr-2.2.0 bleiben willst versuch folgendes - hat damals bei mir funktioniert.

void cCamSlot::SendCaPmt(uint8_t CmdId)
....
if (GetCaPids(source, transponder, p->programNumber, CaSystemIds, MAXRECEIVEPIDS + 1, CaPids) > 0)
{ 
   if (Loop == 1)
   {
      FixSharedCaPids(p->programNumber, CaSystemIds, CaPids);
      caPidReceiver->DelPids(CaPids);
   }
.....

in ci.h
void FixSharedCaPids(int programNumber, const int *CaSystemIds, int *CaPids);

in ci.c folgendes hinzufügen.
void cCamSlot::FixSharedCaPids(int programNumber, const int *CaSystemIds, int *CaPids) //02.06.2016 {
  //dont delete shared CaPids
  //example: ORF 2 V and ORF Sport plus shares the same CaPids

  int numPids = 0;
  int *pCaPids = CaPids;
  while (*pCaPids)
  {
    numPids++;
    pCaPids++;
  }
  if (numPids <= 0)
    return;

  int CaPids2[MAXRECEIVEPIDS + 1];
  for (cCiCaProgramData *p = caProgramList.First(); p; p = caProgramList.Next(p))
  {
    if (p->programNumber != programNumber)
    { 
      if (GetCaPids(source, transponder, p->programNumber, CaSystemIds, MAXRECEIVEPIDS + 1, CaPids2) > 0)
      {
        int* pCaPids2 = CaPids2;
        while (*pCaPids2)
        {
          pCaPids = CaPids;
          while (*pCaPids)
          {
            if (*pCaPids == *pCaPids2)
            {
              *pCaPids = CaPids[numPids - 1];
              numPids--;
              CaPids[numPids] = 0;
              if (numPids <= 0)
                return;
            }
            else
              *pCaPids++;
          }
          *pCaPids2++;
        }
      }
    }
  }
}

Ja, besser ins VNSI Plugin, falls die Aufnahmen nicht davon betroffen sind.
Info: VNSI macht keinen CAM Reset, sondern nur StopDecrypting und RETUNE.
Frage: mein Cam benötigt ab und zu einen Reset(alle 2 Wochen??), ist das bei euch auch so?

Eventuell den Patch auf AlphaCrypt CAM beschränken - dann muss aber in folgenden Codeabschnitten Device übergeben werden.

m_Demuxer.Read(m_Device,&pkt_data, &pkt_side_data);

int cVNSIDemuxer::Read(cDevice *Device,sStreamPacket *packet, sStreamPacket *packet_side_data)

int error = stream->ProcessTSPacket(Device,buf, packet, packet_side_data, m_WaitIFrame);

int cTSStream::ProcessTSPacket(cDevice *Device,uint8_t *data, sStreamPacket *pkt, sStreamPacket *pkt_side_data, bool iframe)

m_pesParser->ParsePacketHeader(Device,data);

int cParser::ParsePacketHeader(cDevice *Device,uint8_t *data)

bool IsAlphaCrypt(cDevice *Device)
{
  if (!Device) return false;
  cCamSlot* sl=Device->CamSlot();
  if (sl) {
    sl=sl->MasterSlot();
    if (sl->GetCamName() && strcmp(sl->GetCamName(), "AlphaCrypt") == 0 )
      return true;
  }
  return false;
}


int cParser::ParsePacketHeader(cDevice *Device,uint8_t *data)
{
  if (TsIsScrambled(data))
  {
    if (TsHasAdaptationField(data) && IsAlphaCrypt(Device)) 
    {
       data[3] &= ~TS_SCRAMBLING_CONTROL;
    }
    else
    {
      m_Error = ERROR_PES_SCRAMBLE;
      return -1;
    }
  }
....

Onur

Problem: VNSI Plugin und TsIsScrambled()

mir ist folgendes aufgefallen:

bei RTL2 HD(und eventuell andere) werden manche pakete nicht entschlüsselt,

diese paket haben alle ein AdaptationField - im grunde also keine mpeg daten, nur PCR usw...

eventuell ist es ein HW (alphacrypt) problem - kann ich wegen fehlender hardware aber nicht testen.

wer hat zeit und lust das zu debuggen.

man müsste folgendes testen: gibt es das problem nur mit one4all, nur mit hdplus?

ist es eventuell ein treiber problem.

möglicher patch:

--- vdr/mtd.c    2018-03-05 18:44:15.051387147 +0100
+++ vdr/mtd.c    2018-03-05 18:44:16.451347364 +0100
@@ -318,6 +318,7 @@
         return NULL;
         }
      if (c >= TS_SIZE) {
         TsSetPid(d, mtdMapper->UniqToRealPid(TsPid(d)));
+        if (TsIsScrambled(d) && TsHasAdaptationField(d))
+           d[3] &= ~TS_SCRAMBLING_CONTROL;
         delivered = true;
         }

nach langem testen hab ich das problem gefunden.

/var/lib/ntp/ntp.drift und-oder /etc/adjtime

nachdem ich die 2 dateien gelöscht habe, funkionierte adjtime.
bei mir stand in ntp.drift -500 (500 ist der max. korrektur wert).
adjtime bzw. die Geschwindigkeits-Korrektur scheint wohl nicht zu funktionieren wenn ntp diese dateien vermüllt hat.

die 2 dateien werden bei bedarf von ntp neu angelegt (dauert aber).
ntp berechnet über einen längeren zeitraum den drift der hardwareuhr.
falls mal kein inet vorhanden, bzw. ntp nicht läuft, wird anhand dieser daten die zeit angepasst, somit wird quasi die hardwareuhr gepatcht.

gruß, onur

danke klaus, welchen kernel nutzt du?

bei mir macht adjtime leider nix.

waren gleich mehrere fehler im post oben, sind nun korrigiert (kernel 4.12 also neu und /var/log/syslog).

eleganter ist natürlich klaus seine grep variante.

noch eleganter wäre sekunden diff in der logausgabe.

@min73

ntp will ich nicht. Es muß, und soll die DVB-S Zeit sein.

mit der DVB Zeit ist VPS und der ganze kram einfach viel genauer.

info am rande:

der böse cardserver verhindert ein backwards stellen der systemzeit (bis inklusive version 11233 gibt es keine probleme).

hab das vor einem jahr schon mal gemeldet, die wollen aber aus unerklärlichen Gründen keine Monotonic Clock verwenden.

gruß, onur

die funktion adjtime funktioniert bei mir nicht (kernel 4.12).

die funktion wird ohne Fehler ausgeführt, aber die System Zeit wird nicht verändert.

ich weiß dass die funktion die interne uhr beschleunigt bzw. verlangsamt und die zeit quasi smooth angepasst wird.

aber auch nach 12 Stunden bleibt die Differnz unverändert.

der vdr ruft im 5 Minuten Takt die Funkton auf falls differnez kleiner 10 Sekunden.

test Szenario:

vdr starten.

date --set 09:40:00

zeit sollte ca. 5 sekunden vor aktueller DVB-S zeit sein, damit die vdr funktion greift.

30 minuten warten...

prüfen:

cat /var/log/syslog | grep "system time"

gruß, onur

hi, problem gefunden, neurdings geht dvbsky frontend erst ab kernel 4.7
DVB_M88DS3103: Requires at least kernel 4.7.0
schöne sch... - gibt es eine möglichkeit einen alten stand zu verwenden (im nov ging es noch?).
ich habs mit git checkout 50dcb6cdb70281d76b28d1564f8e076bb08f2c60 versucht - aber nicht hinbekommen.
danke für deine mühe, gruss, onur

ich hab ja DD im mischbetrieb mit dvbsky .
das ging immer mit deinem rep.
jetzt hab ich die blöde fehlermdelung?
der kernel ist ein aktueller debian jessie.

was mir noch aufgefallen ist: mit github.com/herrnst/media_build.git war mein treiberpaket nur halb so groß?

danke, gruss, onur

@nst - funktioniert leider nicht - meine dvbsky karte geht mit git clone https://github.com/herrnst/media_build.git
leider nicht?
mache ich etwas falsch??
ich mache folgendes:

mkdir -p /usr/src/dvbdev
cd /usr/src/dvbdev
git clone https://github.com/herrnst/media_build.git
git clone https://github.com/herrnst/dddvb-linux-kernel.git

cd /usr/src/dvbdev/dddvb-linux-kernel
git checkout mediatree/master-ddbridge

cd ../media_build/linux/
make tar DIR=../../dddvb-linux-kernel
make untar
cd ..
make stagingconfig

make install

danke, gruss, onur

@nst - danke
ich musste wirklich statt: git clone git://linuxtv.org/media_build.git
git clone https://github.com/herrnst/media_build.git

verwenden,

patch ist vor 12 tagen - backport msi alloc for ddbridge
https://github.com/herrnst/med…3edaf33dd6f48130820f209a1

gruss, onur

nach einem CONFIG_FRAME_VECTOR = y hat er kompiliert.
gruss, onur

hi,
kann mir jemand helfen?
bekomme diesen fehler beim kompilieren (debian jessie kernel 3.16.0-4-amd64)

ddbridge.c:104:3: error: implicit declaration of function 'pci_alloc_irq_vectors' [-Werror=implicit-function-declaration]
stat = pci_alloc_irq_vectors(dev->pdev, 1, nr, PCI_IRQ_MSI);
error: 'PCI_IRQ_MSI' undeclared
...

die rep von //linuxtv.org/media_build.git kompiliert ohne probleme?

danke, gruss, onur

hallo,

Ich würde gerne dem decoder mitteilen Pakete (eigentlich ganze Frames) bei der wiedergabe zu verwerfen (nicht darstellen).
Die Pakete sollten aber trotzdem beim decoder ankommen.
Falls so etwas möglich wäre könnte man einen frame-genauen schnitt (zumindest bei der wiedergabe) bewerkstelligen.

wurde so etwas schon mal diskutiert?

gruss, onur

@UFO
du hast recht (entladen von stv090x hab ich vergessen)
mit dem media_build_experimental_work treiber scheint dieses verhalten weg zu sein.

ich teste jetzt noch mit all den anderen karten varianten auf die ich zugriff habe.

frage: die option, dvb_demux_tscheck "enable transport stream continuity and TEI check");
hast du eine schnelle anleitung wie ich dass testen kann (ohne vdr).
wo sehe ich die TS fehler wenn ich dass an mache.

danke, gruss, onur

hi,
neustart ist bei mir nicht so einfach, auf dem rechner laufen KVM Virtualisierungen...

ich mache aber immer folgendes:

vdr stoppen
rmmod ngene
rmmod dvb-core

dpkg -i --force-overwrite xxx.deb

modprobe ngene
das der wert gesetzt wurde sehe ich in:
/sys/module/dvb_core/parameters/dvb_powerdown_on_sleep

sollte also passen,
nach dem entladen gibt es kein /dev/dvb/ mehr - denke also es ist alles entladen...

ich versuche mal morgen einen neustart.

gruss, onur

hab getestet,
options dvb-core dvb_powerdown_on_sleep=0

Mystique Satix S2 dual V1

Mystique Satix S2 dual V2

Cine S2 V5.5

Cine S2 V6.5 - kann ich derzeit nicht testen

immer noch das selbe verhalten, egal ob media_build_experimental oder media_build_experimental_work

gruss, onur