Posts by Grumpy

  • VDR Timeshift in kodi Omega 21.2

    In letzter Zeit, gefühlt seit dem letzten Update auf kodi Omega 21.1, habe ich leider häufiger (nicht immer) das Problem, dass der Timeshift nicht mehr zuverlässig funktioniert.
    Nachdem ich den Livestream pausiert habe und dann wieder Play drücke, wird der Livestream 1-2 Sekunden fortgesetzt und friert dann ein.
    Im kodi Log finde ich dann folgende Zeilen:
    2025-03-21 14:45:07.272 T:1305    error <general>: AddOnLog: pvr.vdr.vnsi: TransmitMessage - Failed to write packet, bytes written: 0 of total: 16
    2025-03-21 14:45:07.272 T:1305    error <general>: AddOnLog: pvr.vdr.vnsi: SignalConnectionLost - connection lost !!!
    2025-03-21 14:45:07.272 T:1305    error <general>: AddOnLog: pvr.vdr.vnsi: TransmitMessage - Failed to write packet, bytes written: 0 of total: 16
    2025-03-21 14:45:07.272 T:1305    error <general>: AddOnLog: pvr.vdr.vnsi: Close - failed to close streaming
    VDR Version ist aktuell (2.7.4) und die Einstellungen für Timeshift sind: FILE, Puffer 2GB
    Am Setup oder den verwendeten Plugins/Addons habe ich gegenüber früher nichts geändert. Bisher lief das vorbildlich.

    Hat jemand hier ähnliche Erfahrungen gemacht und hat vielleicht einen Tipp, woran das liegen kann?

  • wirbelscancontrol 0.0.2 kompiliert nicht mit vdr 2.6.0/wirbelscan 2021.12.11

    Hallo in die Runde,

    ich versuche gerade vdr 2.6.0 unter Ubuntu 18.04 mit ein paar Plugins zu bauen. Bisher (vdr 2.4.x) hab ich auch immer das wirbelscan Plugin (Version 2020.12.22) und wirbelscancontrol mit gebaut. Nach Update auf vdr 2.6.0, vdr-wirbelscan-2021.12.11 mit aktueller librepfunc kann ich nun wirbelscancontrol 0.0.2 nicht mehr kompilieren.

    Ich erhalte folgende Meldungen, mit einem Fehler bei scanmenu.c:383:25 (siehe unten).

    Hat jemand eine Idee, ob und wie man das fixen kann oder ob es Alternativen gibt?

  • [Patch] CAM-Tweaks für Multi Channel Decryption

    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
    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)

  • [Patch] CAM-Tweaks für Multi Channel Decryption

    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.

  • [Patch] CAM-Tweaks für Multi Channel Decryption

    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
    Feb  1 21:07:36 kodi-mc vdr: [1083] CAM 1: Enquiry ------------------
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.

  • [Patch] CAM-Tweaks für Multi Channel Decryption

    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
    cat cxd2099.conf 
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
    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.

  • [Patch] CAM-Tweaks für Multi Channel Decryption

    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

  • [Patch] CAM-Tweaks für Multi Channel Decryption

    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:

  • [Patch] CAM-Tweaks für Multi Channel Decryption

    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.

  • [Patch] CAM-Tweaks für Multi Channel Decryption

    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
    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?

  • Vdr backend and Kodi frontend in same machine

    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

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

  • Kodi plugin VNSI - no more updates

    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.

  • Problem mit einigen Sky Sport und BuLi Sendern in channels.conf

    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
    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
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
...
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
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
...
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
...
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.