Posts by Grumpy

    Im Moment läuft bei mir eine Aufnahme auf einem privaten Kanal im Hintergrund während ich durch andere private Kanäle am TV zappe. Jetzt ist plötzlich kaum noch ein Verzug zwischen Umschalten und hell werden festzustellen und ich sehe auch keine "auto responses" mehr auf PIN Anfragen... merkwürdig.


    Ich hatte vorher mal testweise mit der VNSI Server Einstellung

    Code
    1. vnsiserver.DisableScrambleTimeout = 0

    rumgespielt, aber ohne VDR neu zu starten, da ja noch die Aufnahme läuft. Werde ich später nochmal etwas systematischer testen, ob sich dadurch noch etwas optimieren lässt oder ob es gerade nur "zufällig" besser läuft.


    Update: Auch nach einem VDR-Neustart, geht das Zappen nun flüssiger und im Log erscheint aktuell keine PIN Abfrage mehr nach dem Umschalten. Zufall oder die Änderung der vnsiserver Einstellung hat hier tatsächlich eine Verbesserung bewirkt (Aktueller Wert ist 0; bin mir nicht sicher, was hier die Default-Einstellung ist)

    kamel5 , ich hab leider die Herausforderung, dass ich zwar ein uATX Board (Asus B250M-C) mit mehreren PCI Slots habe, dies aber in einem sehr flachen Streacom FC5 Alpha Gehäuse mit nur einem (horizontalen) Slot für PCI-Karten betreibe. D.h. die aktuell verwendete Riser-Card läßt da keine Auswahl, in welchen Steckplatz am Board sie gesteckt wird. Man könnte evtl. eine flexible Riser-Card nehmen. Das müsste ich mal ausprobieren.


    Aktuell läuft die Erkennung aber aus meiner Sicht relativ stabil. Ich hab gestern auch ca. 2h eine Aufnahme auf einem privaten Kanal gemacht, die problemlos durchlief. Ich kann auch nicht ausschließen, dass ich das NDS Modul bei meinen ersten Versuchen nicht sauber im CI Schacht eingesteckt hatte. Dies könnte ein weiterer Effekt des Ziehens und erneut Einstecken gewesen sein, so dass das Modul dann endlich sauber saß.


    Das Wechseln auf einen privaten Sender läuft bei mir so, dass es zunächst ein paar Sekunden schwarz bleibt, dann kommt vom VDR VNSI Client die Meldung "Channel: no data" und unmittelbar danach wird es hell. Das kann man auch im Log ganz gut nachvollziehen; nach dem VNSI Error (VNSI-Error: cParser::AddPESPacket - max buffer size reached) kommt nach 9-10 Sekunden die PIN Abfrage und danach geht es weiter:

    Ich bin zwar mit den 9-10 Sekunden Verzug bis das Bild hell wird nicht mega-happy, freu mich aber, dass es nun endlich funktioniert.


    Vielleicht sieht der ein oder andere ja noch eine Möglichkeit zur Optimierung oder weiß, woher der VNSI-Error stammt und wie man ihn ggfs. vermeidet. Kürzere Umschaltzeiten wären natürlich der "Hit".


    FernetMenta, der Maintainer des VNSI-Server-Plugins und entprechenden Kodi PVR VNSI Addons scheint ja leider nicht mehr an diesem Projekt zu arbeiten (was ich sehr bedaure), so dass man ihn nicht mehr direkt ansprechen kann.


    P.S.: Hatte bei der Arbeit an meinem Post die Antwort von nanohcv übersehen. Der Zusammenhang mit VNSI ist damit wohl erklärt.

    Es tut sich (et)was. Beim Einschieben des Moduls nach Start von vdr erhalte ich nun die Authentifizierungsmeldungen:

    Es kommen zwar kurz wieder die DDCI2 Fehlermeldungen, aber dann ist erstmal Ruhe. Beim Tunen auf einen privaten Kanal erscheint nun folgendes im Log:

    Code
    1. Feb 1 21:07:36 kodi-mc vdr: [1083] CAM 1: Enquiry ------------------
    2. Feb 1 21:07:36 kodi-mc vdr: [1083] CAM 1: 'Bitte geben Sie Ihre Jugendschutz-PIN ein.'

    So war es auch beim TV. Danach wurde es hell. Nur wie bekomme ich die PIN da jetzt rein?

    Ich dachte mit der DD Hard- und Software würde diese Abfrage umgangen.


    Update: Ich konnte jetzt über kodi->PVR & TV in das VDR OSD und dort im CAM Menü die Jugendschutz-Pin eingeben. ET voila :) :) :) Der Sender wurde hell!


    Leider muss ich das jetzt nach jedem Umschaltvorgang wiederholen. Hab schon versucht, die camresponses.conf zu bearbeiten, aber das hat nicht funktioniert.


    Noch ein Update: Heureka, es läuft. :) :) :) :) :) Ich hab die camresponses.conf nochmal bearbeitet und die PIN wird jetzt automatisch im Hintergrund eingegeben. Bild wird dann nach kurzer Verzögerung hell. Der Delay mach schon ein paar Sekunden aus, aber damit kann man (auch frau) leben.


    Ich vermute, der Tipp von HelmutB war hier entscheidend, so dass mit dem Einschieben der Karte nach vdr-Start der Authentifizierungsprozess re-initialisiert wurde. Auf jeden Fall liegt jetzt im Verzeichnis /var/cache/vdr/plugins/ciplus eine auth-Datei. Auch mit dem Patch und aktivierten camtweaks läuft es nun endlich.


    Danke für Eure schnelle Unterstützung und Tipps, die letztlich zur Lösung geführt haben.

    Hab extra zum Test eine ungepatchte Version von vdr-2.4.1 verwendet und auch alle Plugins neu gebaut. HW und SW, bis auf Ubuntu Updates ist dieselbe, mit der das alphacrypt problemlos lief.


    in /etc/modprobe.d ist nur für cxd2099 eine Option gesetzt, nichts für ddbridge:

    Code
    1. cat cxd2099.conf
    2. options cxd2099 buffermode=1

    Der I/O Fehler kommt nur mit ciplus und libciplusprivate.so.


    Hatte schon die Vermutung, ob es an der OpenSSL Version liegt. Bei mir läuft OpenSSL 1.1.1


    Werde mal den Tipp von HelmutB ausprobieren, das Modul erst nach dem Start des vdr reinzuschieben.


    Zwischenzeitlich stand auch mal sowas im log:


    Code
    1. Cannot open /var/cache/vdr/plugins/ciplus/slot01.auth

    Diese Datei existiert bei mir auch nicht (das Verzeichnis ist leer). Ich hab auch bei der ersten Nutzung nicht von den 5 Authentifizierungsphasen im Log gesehen.

    Ich nutze die Standard-Treiber aus dem Kernel 5.3.0 Kernel von Ubuntu 18.04.4. Das CI ist noch ein älteres Flex-CI (Single CI), was ich seit einigen Jahren einsetze. So wie ich das sehe, lädt ddbridge den Treiber cxd2099 für das CI Modul nach:


    und

    und

    Leider funktioniert es auch mit dem ungepatchten vdr nicht. Anbei mein Log vom vdr-Start (ich hab zusätzlich das ddci2 debug angeschaltet).


    Man sieht, dass nach den ddci2 Fehlermeldungen, das CAM ständig resettet wird. Ohne libciplusprivate.so wird natürlich auch nix hell, aber die Resets bleiben aus, so dass man z.B. auch das CAM Menü aufrufen kann (was sonst wegen der ständigen Resets nicht möglich ist).


    P.S.: Die Benutzerrechte unter /dev/dvb/ scheinen zu stimmen:

    Files

    • vdrstart.txt

      (11.5 kB, downloaded 18 times, last: )

    Da hier doch relativ viele Anfragen zu dem Thema kommen und ich gerade auf dem Schlauch stehe:


    Kann jemand, bei dem es funktioniert - auch gerne per PN, falls das hier nicht diskutiert werden darf - die Voraussetzungen nennen, unter denen man die Kombi Sky CAM Modul, ddci2 und das ciplus Plugin ans Laufen kriegt?


    Ich habe mich bisher an die Anleitung aus dem Post von kamel5 gehalten, was aber leider nicht geklappt hat. Mein System ist ein Ubuntu 18.04.4 LTS (GNU/Linux 5.3.0-28-generic x86_64), mit vdr 2.4.1 und ddci2, vnsiserver und dem ciplus plugins (inkl. libciplusprivate.so), sowie Kodi 18.5. Die Quellen habe ich frisch aus den "offiziellen" Repositories geholt und fehlerfrei kompiliert. Hardware besteht aus Intel i3 Mainboard, mit DD Cine-S2 (ddbridge) und DD single-CI mit dem Sky NDS CiPlus Modul.


    Bis auf das Descramblen der privaten Kanäle läuft alles. Das System hat auch mit einem alphacrpyt CI Modul letztes Jahr noch einwandfrei funktioniert. Nur eben das Setup mit ciplus will partout nicht. Das Sky Modul läuft in einem anderen Gerät problemlos.

    Ich habe die Patches für VDR 2.4.1 installiert und aktiviert.

    Als Plugins laufen momentan nur ddci2, ciplus und vnsiserver. Trotzdem wird außer den FTA Channels nichts hell :( In meinem TV mit CI+ Schacht läuft alles, nur leider nicht mit VDR.

    Die libciplusprivate.so ist im Verzeichnis /usr/local/lib/vdr/plugins vorhanden.

    Was mir im Log auffällt ist diese immer wiederkehrende Fehlermeldung:

    Code
    1. DDCI-Err: can't write to CI adapter (/dev/dvb/adapter2/ca0): Input/output error

    Das CAM scheint dadurch auch ständig resettet zu werden, so dass ich nicht einmal mehr ins CAM Menü komme.

    Hat jemand einen Tipp woran es liegt?

    I am using this addon for koidi https://github.com/Paulemann/service.shutdown.watchdog which should address most or at least some of your requirements.

    In kodi you must configure a keymaps.xml (or any other .xml) file in userdata/keymaps with the code of k400r power button to trigger the script.


    I am not yet sure why you're taking all the effort to have vdr shutdown separately. I just shutdown from kodi and that's all it needs.

    You can configure wakeup timer via a small exceutable script setwakeup.sh you put e.g. in /usr/local/bin and which is specified under kodi pvr & tv settings -> energy savings -> wakeup command: sudo setwakeup.sh

    Shell-Script
    1. #!/bin/sh
    2. #$1 is the first argument to the script. It is the time in seconds since 1970
    3. echo 0 > /sys/class/rtc/rtc0/wakealarm #this clears your alarm.
    4. echo $1 > /sys/class/rtc/rtc0/wakealarm #this writes your alarm
    5. exit 0

    The author says that - in his opinion - VDR is kind of dead. However, I would assume the same applies to any other FTA/DVB based Live TV solution in the long-term since user preference seem to steadily shift towards VOD and streaming platforms.


    To me the question is not whether TVH or VDR is the better solution, but how long will a Live-TV & recording solution survive in general.


    Personally, I still watch Live-TV quite frequently. I don't need many of the extra bells & whistles of TVH and the pure combo of VDR and VNSI meets 99% of my demands and has been giving me a rock solid performance, even more with the improvements that came with the recent 2.4.0 release.


    I hope a skilled programmer will pick up this great project and maintain VNSI in the future. Maybe there is also a slight chance the current maintainer will reconsider his decision.

    Seit Sky zum Jahresanfang wider einmal die Frequenzen einiger Sender geändert hat, hab ich Schwierigkeiten, nach Updates der Channels.conf einige Sender ans Laufen zu kriegen. Speziell 1 Sport und 2 BuLi Sender werden mir immer wieder als OBSOLETE markiert, obwohl ich mir (fast) sicher bin, dass ich alle Parameter richtig eingetragen habe. Leider tauchen diese Sender auch bei Channelpedia aktuell nicht auf, daher hoffe ich auf Euren Rat.


    Dei beroffene Sender scheinen sich Transponder und VID mit einem anderen Sender zu teilen. Und ich vermute, dass auch daher die Probleme herrühren. Evtl. muss für diese Sender noch etwas mehr in der Channels.conf angepasst werden. Hies sind meine Channels.conf Einträge mit den funktionieren und den OBSOLETE markierten Sendern auf derselben Frequnz und mit gleicher VID:


    Code
    1. Sky Sport Bundesliga 3,Sky Buli 3;SKY:11758:HC910M2O35P0S1:S19.2E:27500:3839=27:3840=qab@3,3841=qac@3:32:9C4,98C,9AF,98D:272:133:2:0
    2. Sky Sport Bundesliga 4,Sky Buli 4;SKY:11758:HC910M2O35P0S1:S19.2E:27500:4607=27:4608=qab@3,4609=qac@3:32:9C4,98C,9AF,98D:282:133:2:0
    3. ...
    4. Sky Sport Bundesliga 7 OBSOLETE,Sky Buli 7;OBSOLETE SKY:11758:HC910M2O35P0S1:S19.2E:27500:3839=27:3840=qab@3,3841=qac@3:32:9C4,98C,9AF:312:133:2:0
    5. Sky Sport Bundesliga 8 OBSOLETE,Sky Buli 8;OBSOLETE SKY:11758:HC910M2O35P0S1:S19.2E:27500:4607=27:4608=qab@3,4609=qac@3:32:9C4,98C,9AF:322:133:2:0
    6. ...
    7. Sky Sport 5,Sport5;SKY:11758:HC910M2O35P0S1:S19.2E:27500:4863=27:4864=qae@3,4865=qaf@3:32:9C4,98C,9AF,98D:283:133:2:0
    8. ...
    9. Sky Sport 9 OBSOLETE,Sport9;OBSOLETE SKY:11758:HC910M2O35P0S1:S19.2E:27500:4863=27:4864=qae@3,4865=qaf@3:32:98C,9C4,9AF,98D:323:133:2:0

    Ich habe die Parameter wiederholt mit den Werten auf satindex abgeglichen. Entweder sehe ich den Wald vor lauter Bäumen nicht oder ich steh woanders auf dem Schlauch.

    Und: in der Liste der Devices scheint beim letzen Device das Trennzeichen '-' zu fehlen. Das ist übrigens auch bei der TImer Liste so. Ist aber eher ein "kosmetisches" Problem.

    Okay, vermute, das mit dem EInbau der alte Karte in das neue System sollte sich mit der Vorgehensweise bewerkstelligen lassen. Probeweise hab ich schon mal die Kernelmodule mittels

    Code
    1. git clone --branch buildall https://github.com/herrnst/media_build.gitst/dddvb-linux-kernel.git
    2. git clone --branch mediatree/master-ngene-tsfix https://github.com/herrnst/dddvb-linux-kernel.git
    3. cd media_build
    4. ./build_all.sh ../dddvb-linux-kernel/

    bauen lassen, was auch fehlerfrei durchgelaufen ist.


    Mal ne Frage wegen des Backups: Reicht es aus, das /lib/modules/4.13.0-36-generic Verzeichnis vor dem make install zu kopieren und hinterher wieder zurückzukopieren oder ist es besser nochmal die Kernel-Module für ddbridge zu erstellen und per make install die Dateien einfach zu überschreiben?


    P.S.: Hab jetzt mit "--branch buildall" erfolgreich bauen können. Vorher musste ich i.d.R. "--branch buildall-ioctl" nutzen, da es sonst nicht durchlief. Was ist der Unterschied und wie ist der aktuelle (empfohlene) Weg? Nutze Ubuntu 16.04.03 LTS (GNU/Linux 4.13.0-36-generic x86_64).

    Ich weiß es wirklich zu schätzen, dass hier nochmal explizit auf das Problem mit den ngene Tribern eingegangen wird. Allerdings hab ich mittlerweile komplett auf neue Hardware, d.h. neues ASUS Mainboard und Cine-S2 v6.5 umgestellt (ddbridge-Treiber), womit es problemlos läuft. Ich kann versuchen, am Wochenende nochmal das alte System zu reaktivieren, muss dazu aber ubuntu, vdr und kodi komplett neu aufsetzen, Wenn ich das hinkriege teste ich und werde berichten ....

    jasminj : Noch aprospros "Treiber"; Gem. Empfehlung von Dir, verwende ich die aktuellen Treiber aus dem media_build git von herrnst. Jetzt habe ich entdeckt, dass es unter linuxtv.org ebenfalls ein media_build git-Repository für linux gibt, an dem Du auch selbst mitwirkst.


    Welcher Unterschied besteht zwischen den Treibern, die aus den unterschiedlichen Repositories gebaut werden und welches ist für welchen Fall zu empfehlen?

    Wie hast du denn bisher geschaut?

    Auch über VDR bzw. KODI/VDR und den (Standard) Kernel-Treibern von Ubuntu 16.04. Nur hab ich da ein anderes Plugin genutzt (das aber hier nicht erwähnt werden darf). Ich bin dann auf CI und DDCI2 Plugin umgestigen, da die vorige Lösung (wie bei vielen) nicht mehr lief. Wie gesagt, in der Konstellation - auch schon mit VDR 2.3.8 - lief es recht gut

    Und das MB tauschen?

    Ja, das scheint mir dann letzlich wohl der einzige Weg. Ist leider nicht nur das MB, was ersetzt werden muss: CPU, Speicher, Netzteil. Das alte Board hatte noch einen LGA1155 Sockel, S0-DIMMs und eine 19V Stromanschluss, die heute kein Board mehr unterstützt. Ich würde dann gleich auf was moderneres wie LGA 1151 setzen und das alte Board ggfs. noch irgendwo als Server oder so nutzen.


    Meine aktuelle Wunschkonfig wäre: ASUS B250M-C, I3-6100T, 8GB DDR4-RAM. Das sollte auch noch für längere Zeit passen (das alte Board hatte ich ca. 4 Jahre im Einsatz) und dann hoffentlich auch mit der v6.5 gut zusammenspielen