Premiere umschaltzeiten

  • hi,


    ich habe ein alphacrypt mit 3.09 firmware, eine premiere karte und einen aktuellen vdr (1.4.1-1). in dem vdr ist eine tt 1.5 ff mit ci und eine budget. seit dem kanalwechsel habe ich nun das problem, dass die umschaltzeit auf den premiere kanälen sich seltsam verhält. entweder es geht ruck zuck oder es dauert bis zu 10 sekunden. ist kanalunabhängig, aber tritt oefter beim wechsel von Premitere 3 auf Premiere 4 auf. auch zeigen filmclassics, filmfest und nostalgie lange umschaltzeiten. vor dem update und channelwechsel waren die zeiten zwar insgesammt langsamer, aber dafür konstant.


    hat jemand ähnliche probleme, damit man mal nach gemeinsamkeiten in der konfig suchen kann bzw. diverse konfigurationsoptionen ausschließen kann?


    gruß


    fen

  • Habe hier VDR 1.4.1(vanilla), eine 1.5er TT Karte mit CI + Alphacrypt 3.09 und habe genau die gleichen Symptome. Manchmal dauert es auch hier bis zu 5-10 Sekunden. Ich habe schon im Alphacrypt an den paar vorhandenen Einstellmöglichkeiten herumgespielt, aber konnte keine Veränderungen erreichen.


    Ich habe im Treiber für die FF Karte den Patch von Oliver drin, der das Verhalten mit den Aussetzern und dem Stottern unter ARD und ZDF verbessert. Hast du den auch? Könnte es vielleicht damit zusammenhängen?


    Wo wir grad bei dem Thema sind... Wofür stehen eigentlich die Single/Multi und Dynamic/Static Einstellungen im CAM? Was stelle ich damit ein? Kann mir das jemand erklären? Was macht die PMT-Zeit aus, die ich einstellen kann?


    Jarod

    Gehäuse: Intertech 4U 4416, Board: Supermicro X11SAE; Kathrein EXIP418; OS: Ubuntu 18.04; Plugins: xineliboutput, satip, burn, femon, live, streamdev-server, text2skin:anthra-1920

    2x RPI2/3; Plugins: rpihddevice; videodir via NFS


  • Mein CICAM läuft erst seit gestern. Ich wundere mich, warum ich auf Premiere aufnehmen und gleichzeitig noch alle Programme (ausser die anderen Premiere-Kanäle) durchschalten kann?! Ich hätte erwartet, dass zumindest ein Teil der Programme beim Aufnehmen von Premiere weg sind, so wie beim Aufnehmen der anderen Kanäle auch. Da ist zwar noch eine weitere Budget-Karte im Rechner aber VDR kann doch wohl kaum über die Budget aufnehmen und mit dem CAM der FF decodieren...

  • Das Alphacrypt CAM speichert seit Firmware-Version 3.09 die CA_PMT-Daten für die zu entschlüsselnden PIDs etwas länger, um störungsfreies Umschalten beim gleichzeitigen Entschlüsseln mehrere Kanäle zu ermöglichen. Dummerweise hat das bei VDR einen unschönen Nebeneffekt bei den zusätzlichen Audio-Spuren, die im Live-Modus vorsorglich mal im CAM gesetzt werden. Anscheinend läuft da dann mit der Zeit was voll und wird erst nach einigen Sekunden wieder freigegeben.


    Versuch doch mal in VDR/dvbdevice.c die Zeilen


    Code
    //XXX quick workaround for additional live audio PIDs:
         if (ciHandler) {
            ciHandler->SetPid(Channel->Apid(1), true);
            ciHandler->SetPid(Channel->Dpid(0), true);
            }


    auszukommentieren. Wenn du eh' keine Originalsprache bzw. Dolby brauchst, könnte das helfen.


    Eine saubere Lösung hierfür wird's wohl erst in der VDR-Version 1.5.x geben, wo ich als erstes das CAM-Handling überarbeiten werde, da es ja immer mehr vorkommt, daß jemand mehrere CAMs hat, die das gleiche Verschlüsselungssystem implementieren, aber nur je eines davon kann einen bestimmten Kanal decodieren.


    Klaus

  • ich benötige zwar dd und fremdsprachen, aber ich habs trotzdem mal probiert :) es ist tatsächlich so, dass am anfang das zappen sehr viel besser lief, aber nach einigem mal hin und herzappen waren die probleme wieder da.


    ich verwende die v4l treiber mit dem og. patch. vielleicht ist das daran schuld... kann ich nicht beurteilen :/


    edit: 22:09


    ich habe gearde nochmal das aktuelle hg von olivers refactoring gezogen und getestet: kein erfolg. anschließend habe ich den master gezogen und ebenfalls gleiches problem. reproduzierbar mit einmal premiere zeugs hochzappen und anschließend zurückzappen - dann bleibts irgendwann ne zeitlang hängen.


    config: vdr-1.4.1-1 mit bigpatch, f22623 firmware, aktuelle hg master treiber, alphacrypt mit 3.09 firmware. ich hab auch schon diverse einstellungen am cam probiert. u.a. auch die omt cache zeit auf 0 gesetzt und pmt force read auch schon auf off gehabt.


    gruß fen

  • hi,
    hallo klaus,


    Zitat

    Eine saubere Lösung hierfür wird's wohl erst in der VDR-Version 1.5.x geben, wo ich als erstes das CAM-Handling überarbeiten werde, da es ja immer mehr vorkommt, daß jemand mehrere CAMs hat, die das gleiche Verschlüsselungssystem implementieren, aber nur je eines davon kann einen bestimmten Kanal decodieren.


    dies genau ist der grund, warum ich jedem der es wissen will oder nicht meine antipathy betr. dieser teuren unbrauchbaren proprietären hardware mitteile.


    die zukunft wird vermutlich zeigen, dass wir pro cryptsystem (premiere, arena, grundverschlüsselung, bevorzugte ausländische pakete ....) pro satreceiver (standallone, vdr, ...) jeweils ein ci nebst cam, nebst smart-card benötigen werden.


    ICH kann mir nicht vorstellen, wie dies im vdr hardwaretechnisch realistisch zu lösen ist.


    daher präferiere ich solche methoden welche hardware-mässig eher - nennen wir es - geizig sind.


    sorry klaus, dass ich der ansicht bin, dass deine mühen betr. "Eine saubere Lösung hierfür wird's wohl erst in der VDR-Version 1.5.x geben" in eine "nicht notwendige richtung" laufen.


    bernd


    ps: btw : wiedermal die besten danks (dankes, ...) für deine (und aller anderen) bemühungen für dieses projekt.

    --------------------------------
    aktuelle Konfiguration:
    SERVER-VDR:suse10, kernel:2.6.5, DVB-treiber: kerneleigener, vdr-1.4.0 plain + noad + and. Serverdienste, 2*Nova-S-SE Rev:1.0, gesteuert via xxv-4.0, hda3-->/video0
    CLIENT-VDR: activy-300 mit gen2vdr1.2 (thx@helau+activy-300), hda3-->/video0
    nfs-mounts:
    server:/video0 --> client:/video0/SERVER_NEU
    server:/hdc1 --> client:/video0/FILME
    server:/hdd1 --> client:/video0/SERIEN
    SERVER läuft 24/7, CLIENT bei Bedarf

  • Zitat

    Originally posted by blehnert
    sorry klaus, dass ich der ansicht bin, dass deine mühen betr. "Eine saubere Lösung hierfür wird's wohl erst in der VDR-Version 1.5.x geben" in eine "nicht notwendige richtung" laufen.


    Das verstehe ich nicht ganz. Willst du damit sagen, daß VDR generell nicht mehr mit CAMs arbeiten soll?


    Klaus

  • So, jetzt habe ich doch eine Lösung gefunden, mit der zumindest bei meinem Alphacrypt 3.09 das Umschalten zwischen fünf verschiedenen verschlüsselten Kanälen auf dem gleichen Transponder beliebig oft schnell klappt. Auch das Umschalten der Audio-Spuren geht damit, ohne daß sich im CAM alte PIDs ansammeln.


    Versucht es bitte mal mit beiliegendem Patch.


    Klaus

  • Zitat

    Versucht es bitte mal mit beiliegendem Patch.


    Hab ich gemacht und auch gleich getestet.
    Ich hab die letzte Viertelstunde mal durch alle verschlüsselten Kanäle gezappt und es ist wirklich besser geworden. Als Maximum hatte ich ~4 Sekuden nach dem Kanalwechsel bis ein Bild zu sehen war.


    Danke vielmals.
    Jarod

    Gehäuse: Intertech 4U 4416, Board: Supermicro X11SAE; Kathrein EXIP418; OS: Ubuntu 18.04; Plugins: xineliboutput, satip, burn, femon, live, streamdev-server, text2skin:anthra-1920

    2x RPI2/3; Plugins: rpihddevice; videodir via NFS


  • hi klaus,


    Zitat

    Das verstehe ich nicht ganz. Willst du damit sagen, daß VDR generell nicht mehr mit CAMs arbeiten soll?


    jein, zumindest nicht mit "hard"-cams.


    nein, ich rede nicht von illegalen einsätzen des "s"-cam.


    um konkreter zu werden (just my two pence) sollte es genügen, wenn du - wie bisher - die pluginschnittstelle unterstützt oder noch besser die native unterstützung des c...3 implementierst.


    wie auch anders sollte es hardwaremässig möglich sein, seine fünf bis 15 smartcards (womöglich noch mit mehreren vdr, sonstige satreceiver) zu verwalten.


    bernd


    ps: meine umschaltzeiten liegen bei beiden getesteten crypttypen (premiere und nova) im selben bereich wie bei nichtverschlüsselten kanälen.

    --------------------------------
    aktuelle Konfiguration:
    SERVER-VDR:suse10, kernel:2.6.5, DVB-treiber: kerneleigener, vdr-1.4.0 plain + noad + and. Serverdienste, 2*Nova-S-SE Rev:1.0, gesteuert via xxv-4.0, hda3-->/video0
    CLIENT-VDR: activy-300 mit gen2vdr1.2 (thx@helau+activy-300), hda3-->/video0
    nfs-mounts:
    server:/video0 --> client:/video0/SERVER_NEU
    server:/hdc1 --> client:/video0/FILME
    server:/hdd1 --> client:/video0/SERIEN
    SERVER läuft 24/7, CLIENT bei Bedarf

    Einmal editiert, zuletzt von blehnert ()

  • Zitat

    Originally posted by blehnert
    hi klaus,



    jein, zumindest nicht mit "hard"-cams.


    Hardware-CAMs sind nunmal die einzige Möglichkeit, legal Pay-TV empfangen zu können (von "zertifizierten Receivern" und diversen AGBs mal abgesehen). Somit soll VDR das auch nativ beherrschen.


    Zitat


    nein, ich rede nicht von illegalen einsätzen des "s"-cam.


    um konkreter zu werden (just my two pence) sollte es genügen, wenn du - wie bisher - die pluginschnittstelle unterstützt oder noch besser die native unterstützung des c...3 implementierst.


    Was ist das "c...3"?


    Zitat


    wie auch anders sollte es hardwaremässig möglich sein, seine fünf bis 15 smartcards (womöglich noch mit mehreren vdr, sonstige satreceiver) zu verwalten.


    Tja, das wird wohl ein generelles Problem werden, wenn irgendwann mal alles verschlüsselt wird. Aber vielleicht gehen dann viele von uns zum ersten mal seit langer Zeit wieder hinaus in die Welt und merken, wieviel Zeit uns die Glotze in der Vergangenheit gestohlen hat. Vielleicht ist ja sogar die endgültige 100%-ige Verschlüsselung aller Kanäle das beste, was uns überhaupt passieren kann... ;)


    Klaus

  • Hallo


    Zitat

    Original von blehnert
    um konkreter zu werden (just my two pence) sollte es genügen, wenn du - wie bisher - die pluginschnittstelle unterstützt oder noch besser die native unterstützung des c...3 implementierst.


    Ich denke nicht, dass der VDR sich auf eine Lösung aus dünnem Eis verlassen sollte und damit die Nutzer zwingt diese Software verwenden zu müssen.


    Wohl sehe ich aber das Smartcards demnächst zur normalen "Hardware" des VDRs gehören werden. Ein "korrekter" Umgang damit und die parallele Entschlüsselung beliebig viele Kanäle wird dann erforderlich. Auch ist die Frage, wie man mehrere Smartcards parallen anschliessen kann. Bin mal gespannt wie das Consumergeräte lösen wollen.


    Gruss
    AleX


    EDIT: c...3 ist eine "Serversoftware" für die Verwaltung von Smartcards. Der VDR würde sich dann als Client an dieser Software anmelden und von dort die "Keys" für die Entschlüsselung beziehen. Ein übliches Verfahren für das "Cardsharing" aus dem Dbox-Bereich.

    Hardware: Intel Cel 1Ghz+, 256MB, 420GB HD, TT DVB-S (Premium) Rev 1.5, 2* Activy DVB-S (Budget), PVR-250, Lirc-USB (ati-rf-remote)
    #############################################
    Software: Debian Etch 2.6.16.1, DVB-Kernel, VDR 1.3.42 + enAIO + noEPG +weitere Patches
    Plugins: tvonscreen, femon, streamdev, mplayer, vdradmin, wapd,
    osdteletext, vcd, dvd, burn, vdrrip
    Other: nvram mit rebootscript
    IRC-Nick: df-h

    2 Mal editiert, zuletzt von alex-zero ()

  • ... doppelt

    Hardware: Intel Cel 1Ghz+, 256MB, 420GB HD, TT DVB-S (Premium) Rev 1.5, 2* Activy DVB-S (Budget), PVR-250, Lirc-USB (ati-rf-remote)
    #############################################
    Software: Debian Etch 2.6.16.1, DVB-Kernel, VDR 1.3.42 + enAIO + noEPG +weitere Patches
    Plugins: tvonscreen, femon, streamdev, mplayer, vdradmin, wapd,
    osdteletext, vcd, dvd, burn, vdrrip
    Other: nvram mit rebootscript
    IRC-Nick: df-h

    Einmal editiert, zuletzt von alex-zero ()

  • Ich fürchte damit wäre dann aber Premiere schauen nicht mehr "nur" ein Verstoß gegen die AGB von Premiere.
    Und der Schritt von wenig legal zu illegal ist dann möglicherweise so klein, dass dahin wäre mit der Duldung eines VDR.

  • hi,
    @ales-zero

    Zitat

    Ich denke nicht, dass der VDR sich auf eine Lösung aus dünnem Eis verlassen sollte und damit die Nutzer zwingt diese Software verwenden zu müssen


    nein, da ist es sicher sinnvoller, den user zu zwingen, sich fünf bis 15 ci´s nebst cams zu besorgen welche dann hardwaremässig noch nicht einmal zu verwalten sind.


    machen wir uns doch nix vor, die sportbegeisterten - zu denen ich nicht gehöre - sind schon heute gezwungen, zwei smartcards zu betreiben. kommt dann die grundverschlüsselung sinds bereits drei.


    deshalb bin ich der ansicht, dass es das vernünftigste ist die smartcardverwaltung zu outsourcen und lediglich die eine (die gibts) oder die andere (die gibts nicht s.o.) schnittstelle zur verfügung zu stellen.


    @klaus

    Zitat

    Hardware-CAMs sind nunmal die einzige Möglichkeit, legal Pay-TV empfangen zu können (von "zertifizierten Receivern" und diversen AGBs mal abgesehen). Somit soll VDR das auch nativ beherrschen.


    wie du schon sagst sehen wir von agb und sonstigem einmal ab:
    ich bin mir nicht sicher, ob die hardwarelösung legaler ist als die softwarelösung.
    die einzige ZUVERLÄSSIGE methode besteht eh nur in verbindung mit einer ORIGINALEN smartcard.
    niemand zwingt mich, das umstrittene plugin mit "illegalen" möglichkeiten zu kompilieren.
    wäre da nicht das vorhandensein lizenzgeschützter software (afaik) welche vermutlich auch in den hardcams vorhanden ist, sähe ich noch nicht mal ein problem darin, eine mit NUR cardclient-support kompilierte version des plugins zur verfügung zu stellen.

    Zitat

    Was ist das "c...3"?


    diese frage hat alex-zero (für dieses forum ausreichend) beantwortet


    aber wie gesagt, alles nur meine ansicht


    bernd

    --------------------------------
    aktuelle Konfiguration:
    SERVER-VDR:suse10, kernel:2.6.5, DVB-treiber: kerneleigener, vdr-1.4.0 plain + noad + and. Serverdienste, 2*Nova-S-SE Rev:1.0, gesteuert via xxv-4.0, hda3-->/video0
    CLIENT-VDR: activy-300 mit gen2vdr1.2 (thx@helau+activy-300), hda3-->/video0
    nfs-mounts:
    server:/video0 --> client:/video0/SERVER_NEU
    server:/hdc1 --> client:/video0/FILME
    server:/hdd1 --> client:/video0/SERIEN
    SERVER läuft 24/7, CLIENT bei Bedarf

  • Zitat

    Original von blehnert
    nein, da ist es sicher sinnvoller, den user zu zwingen, sich fünf bis 15 ci´s nebst cams zu besorgen welche dann hardwaremässig noch nicht einmal zu verwalten sind.


    Ich sagte ja, dass dies ein Problem ist, was in der Zukunft angesprochen werden muss. Wie gesagt, ich bin gespannt wie "Consumer" Geräte dieses lösen wollen.


    Zitat

    Original von blehnert
    deshalb bin ich der ansicht, dass es das vernünftigste ist die smartcardverwaltung zu outsourcen und lediglich die eine (die gibts) oder die andere (die gibts nicht s.o.) schnittstelle zur verfügung zu stellen.


    Den "Sportbegeisterten" ist sowas jetzt schon egal, also warum sollte man den VDR für diese Gruppe (die es ja garnicht benötigt) optimieren und diesen Weg offiziell einschlagen? Das mag für ein paar hundert Techies ein Unterschied sein, aber die "Medien/Presse" wird dieses anderesrum ausschlachte (Schlagzeile "VDR offiziel optimiert für ...").


    Zitat

    Original von blehnert
    ich bin mir nicht sicher, ob die hardwarelösung legaler ist als die softwarelösung.
    die einzige ZUVERLÄSSIGE methode besteht eh nur in verbindung mit einer ORIGINALEN smartcard.


    Genau, das Problem liegt bei dem Wort "einer". Es wird "nur" noch eine für beliebig viele Clients verwendet und genau da liegt das Problem. Die Bindung einer Smartcard an eine bestimmte Hardware (CI+CAM) ist sicherlich nicht unabsichtlich geschehen.
    Der offizielle Weg ist eine Smartcard pro Gerät, leider zählt in diesem Fall jede Satkarte als einzelnes Gerät.


    Gruss
    AleX

    Hardware: Intel Cel 1Ghz+, 256MB, 420GB HD, TT DVB-S (Premium) Rev 1.5, 2* Activy DVB-S (Budget), PVR-250, Lirc-USB (ati-rf-remote)
    #############################################
    Software: Debian Etch 2.6.16.1, DVB-Kernel, VDR 1.3.42 + enAIO + noEPG +weitere Patches
    Plugins: tvonscreen, femon, streamdev, mplayer, vdradmin, wapd,
    osdteletext, vcd, dvd, burn, vdrrip
    Other: nvram mit rebootscript
    IRC-Nick: df-h

    2 Mal editiert, zuletzt von alex-zero ()

  • so - mal ganz lösgelöst um die cam diskussion: der patch funktioniert wunderbar. umschaltzeiten sind sehr sehr sehr viel besser und sogar konstant.


    im cam habe ich pmt force auf auto und pmt delete time auf 5 sec.


    gruß fen

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!