Beiträge von Grumpy

  • CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Ich weiß, klingt komisch. Aber nachdem ich feststellen musste, dass es mit Buffer > 1500 es eher (auch im Bild sichtbar) schlimmer wurde, habe ich einfach mal ausprobiert, den Buffer unter den Defaultwert zu setzen. Und bei mir hatte das den beschriebenen positiven Effekt.


    Das -A Flag habe ich übrigens nicht gesetzt. Wenn ich das Flag setze und die Buffersize auf Default lasse bzw. höher setze, bekomme ich wieder Fehlermeldungen und zwar wieder die alten bekannten:


    Code
    vdr: [1466] DDCI-Err: Can't write packet VDR CamSlot for CI adapter (/dev/dvb/adapter2/ca0)


    Die MTD Fehlermeldungen tauchen aktuell gar nicht mehr auf. So richtig eine reproduzierbare Systematik kann ich da leider auch nicht erkennen. Hab aber auch viel getestet, evtl. hat sich da das ein oder andere überlagert.


    So wie es im Moment mit dem verkleinerten Buffer läuft, bin ich zufrieden... :)


    Edit: Zu früh gefreut: MTD-Fehler sind wieder da. :( Läuft trotzdem insgesamt stabil und gut.


    Hab mal nach PID 8191 gesucht, die in den Fehlermeldungen ständig auftaucht und habe folgendes in Wikipedia gefunden:

    Zitat

    Nullpakete

    Bestimmte Übertragungsprotokolle wie ATSC und DVB schreiben eine konstante Bitrate vor (CBR). Um dieses sicherzustellen, kann es vorkommen, dass ein Multiplexer zusätzliche Pakete einfügen muss. Hierfür ist die PID 8191 reserviert, die dann keine Daten enthält und vom Empfänger ignoriert wird. (8191 ist die größte und somit letzte Zahl, die mit 13 Bits dargestellt werden kann.)

  • CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Also nach Installation der neuen Treiber und ein wenig Rumspielen mit den EInstellungen des ddci2-Plugins, habe ich für mich folgendes, zufriedenstellendes Ergebnis:

    1. Mit den neuem Treibern hat vdr bisher nicht mehr den Kontakt zum CAM verloren.

    2. Mit der Einstellung "--bufsz 500" scheinen auch die Fehlermeldungen aus dem syslog verschwunden zu sein. Generell scheint es damit besser zu laufen, da ich vorher gelegentliche Bildstörungen hatte (Klötzchen), die ich jetzt nicht mehr beobachten konnte.


    Ich hoffe, das ist jetzt nicht nur eine Eintagsfliege. Wenn es so bleibt bin ich echt happy.


    Lieben Dank für den geduldigen Support :) :) :)

  • CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Hab die neuen Treiber gem. Anleitung von hier kompiliert und installiert. Nach reboot sieht es so aus:


    Leider sind die Fehlermeldungen im Log immer noch zu sehen.


    Code
    Aug  8 20:05:44 localhost vdr: [2015] ERROR: invalid MTD number (31) in PID 8191 (1FFF)


    Der DDCI-Error hat sich allerdings verändert:

    Code
    Aug  8 20:05:46 localhost vdr: [2015] DDCI-Err (ddcitsrecv.cpp,151): skipped 134 bytes to sync on start of TS packet


    Nach einem Neustart des vdr sieht es im syslog so aus:

  • CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Hallo Jasmin und danke für die schnelle Rückmeldung.


    Korrekt, die ddci2-Plugin Version ist 1.0.5.


    Die Treiber ngene und cxd2099 sind, die die im aktuellen Kernel von Ubuntu 16.04.03 enthalten sind:


    Damit lief es ohne CI bisher immer problemlos.


    Sollte ich ggfs. andere Treiber verwenden?


    Die Fehlermeldungen

    Code
    vdr: [5444] ERROR: invalid MTD number (31) in PID 8191 (1FFF)


    und

    Code
    DDCI-Err: Can't write packet VDR CamSlot for CI adapter (/dev/dvb/adapter2/ca0)


    kommen auch, wenn das CAM noch ansprechbar ist. Ich hab in meinem ersten Post mal einen Auszuag aus dem syslog ergänzt (nach Neustart des vdr). Zu dem Zeitpunkt konnte ich trotz der Fehlermeldungen problemlos einen verschlüsselten Kanal schauen.
    Dass der Kernel den Kontakt zum CAM verliert kommt nur sporadisch vor, während die Fehlermeldungen zurzeit permanent auftreten auch wenn scheinbar alles läuft.


    Danke


    Grumpy

  • CI-Unterstützung für CineS2, Mystique SaTiX-S2 Dual usw.

    Hallo zusammen,


    seit ein paar Tagen nutze ich nun auch das ddci2-Plugin mit vdr 2.3.8 unter Ubuntu 16.04 64-bit. Meine Hardware ist eine schon etwas ältere Cine-S2 v5.5 (ngene) mit einem Single-CI-Modul. Meistens läuft die Kombo recht gut und zuverlässig. Dafür schon meinen großen Dank an Jasmin und alle, die hier geholfen haben.


    Leider füllt sich mein syslog aktuell mit folgenden Fehlermeldungen - unabhängig davon, ob ich einen (verschlüsselten) Kanal schaue oder nicht:

    Zitat

    vdr: [1466] ERROR: invalid MTD number (31) in PID 8191 (1FFF)

    und

    Zitat

    vdr: [1466] DDCI-Err: Can't write packet VDR CamSlot for CI adapter (/dev/dvb/adapter2/ca0)

    Außerdem scheint der VDR gelegentlich - aus für mich bisher nicht bachvollziehbaren/reproduzierbaren Gründen - den Kontakt zum CI/CAM zu verlieren. Unter den VDR-Einstellungen->CAM steht dann nur "1 - " satt wie sonst "1 - Alphacrypt". Im syslog finde ich dann nur

    Zitat

    kernel: [ 4555.455414] i2c i2c-9: NO CAM
    vdr: [1463] CAM 1: no module present

    Ich hab gelesen, dass unter früheren Versionen des Plugins bzw. vdr auch schon mal ein User Probleme damit hatte, zumindest interpretiere ich die Posts #339 - #341 dieses Threads entsprechend.


    Liegt es evtl. an meiner älteren HW- & Treiberkombo, dass diese Fehler bei mir auftreten oder läuft die Cine-S2 v5.5 mit CI bei anderen problemlos?
    Was kann ich tun bzw. welche Infos zur Verfügung stellen um bei der Fehlersuche/beim Fix zu unterstützen?


    Edit: Anbei noch ein Auszug aus dem syslog nach Neustart des vdr:


  • VDR-Client: Status per Skript abfragen

    seahawk1986: Das hatte ich schon fast befürchtet. Aufgrund der lsof ausgabe hatte ich gehofft, dass der vdr auch über vnsi den Replay als solchen erkennt und entsprechende Ausgaben (über dbus2vdr bzw. restfulapi) macht. Mittles des JSON-RPC hab ich die Abfrage jetzt über kodi gelöst, allerdings muss ich das ggfs. für jeden Client separat durchführen. Eine zentrale Abfrage des vdr hätte es einfacher gemacht...


    hopsi: Die Lösung gefällt mir sehr gut, aber ich befürchte, dass dies in meinem Fall ebenfalls im Sande verläuft, da die Ausgabe nicht über den vdr selbst sondern via vnsi über kodi erfolgt.

  • VDR-Client: Status per Skript abfragen

    Prima, danke für den Hinweis. Hab mir gerade die aktuellen Files von github geholt und kompiliert. Werde ausprobieren und berichten..


    Update: Funktioniert leider auch nicht wie gedacht. Vielleicht sollte ich noch erwähnen, dass ich kodi als Frontend nutze. "lsof" zeigt mir an, dass vdr eine Aufnahme wiedergibt:

    Code
    $ sudo lsof -u vdr
...
vdr 1214 vdr 18r REG 8,34 1212162336 18648972 /home/kodi/Aufnahmen/Der_König_der_Löwen/2016-12-28.18.47.126-0.rec/00001.ts
...


    Bei Abfrage mit "vdr-bus-send" erhalte ich jedoch nur:

    Code
    $ vdr-dbus-send /Status status.IsReplaying
method return time=1482975499.642189 sender=:1.29 -> destination=:1.79 serial=905 reply_serial=2
   string ""
   string ""
   boolean false


    Andere Abfragen, z.B. zu den eingestellten Timern oder installierten Plugins funktionieren einwandfrei.


    Was mache ich falsch bzw. wo ist mein Denkfehler?

  • VDR-Client: Status per Skript abfragen

    Sorry, dass ich diesen 1 Jahr alten Thread noch mal ausgrabe. Ich nutze mittlerweile vdr 2.3.1 und habe mir das aktuelle RestfulAPI Plugin in der Version 2.6.5 installiert, in der Hoffnung, dass ich damit ermittlen kann, ob VDR gerade eine Aufnahme abspielt.


    Obwohl das RestfulAPI Plugin an sich läuft, bekomme ich keine Ausgabe von <video name= ... mittels der info.xml Abfrage, obwohl eine Aufnahme aktuell wiedergegeben wird. Ich vermute, dass das Plugin noch nicht 100% kompatibel zu VDR 2.3.1 ist, konnte aber keine aktuellen Infos dazu im Web finden.


    Die Alternative lsof zur Abfrage der geöffneten Dateien zu benutzen, funktioniert leider ebenfalls nicht, da vdr bei mir nicht unter root läuft.
    Die Idee ist, die Konvertierung einer beendeten Aufnahme so lange zu verschieben wie noch ein Nutzer die Aufnahme ansieht.


    Vielleicht gibt es noch andere Alternativen als RestfulAPI oder lsof. Wäre da für jeden Tipp dankbar...

  • [ANNOUNCE] VDR developer version 2.3.1

    Ob "wahr" oder "falsch" mag ja immer noch am individuellen Setup liegen. Ich hab bis April/Mai auch die 4.1 Releases von TVH getestet und wenn sich da in den letzten Monaten nicht ganz viel geändert hat, war damit mein Eindruck wie oben beschrieben. Auch bei den Umschaltzeiten konnte ich keine gravierenden Unterschiede feststellen. Mein Setup läuft auf einem Intel Board mit i3 CPU und Cine S2 unter Ubuntu 16.04 LTS.

  • [ANNOUNCE] VDR developer version 2.3.1

    Ich meld mich mal als Neuer hier im Forum. Bisher habe ich immer nur mitgelesen.


    Ich komme ursprünglich aus der MCE Ecke und war damit auch solange zufrieden bis MS den Support mit W10 an den Nagel gehängt hat. Seit ca. einem Jahr läuft jetzt die Kombination Kodi/VDR bei mir mit wachsender Begeisterung und steigendem WAF. Es brauchte ein gutes Stück Arbeit bis alles lief, aber mittlerweile übersteigen die Möglichkeiten bei weitem das, was ich mit MCE hatte und das zu einem Preis von 0.


    TVHeadend habe ich mir angeschaut - und gleich wieder die Finger von gelassen. Ein Alptraum einzurichten und instabil im Betrieb - vor allem mit Timeshift. Meiner Meinung kommt man an VDR nicht vorbei, wenn man ein stabiles PVR System unter Kodi betreiben will. Die Integration in Kodi ist über VNSI noch nicht zu 100% perfekt, wird aber mit jedem neuen Release besser. Ab Kodii 17/Jarvis wird ein VDR 2.3.1 unterstützt und zeichnet sich in der Kombination sogar mit mehr Extras wie Z.B. EPG basierte Timer aus,


    Schade nur, dass manche Doku im Netz wie auch manche Plugins seit 1-2 Jahren wohl nicht mehr so intensiv gepflegt werden. Das macht den Einstieg leider nicht ganz einfach. Über die Gründe dafür kann ich auch nur spekulieren , ob es am zunehmenden Streaming-Angebot liegt oder die Bastler einfach nur "weitergezogen" sind.


    Ich hoffe, es ist nicht verpönt hier so etwas zu sagen, aber für mich macht die Kombi Kodi/VDR richitg SInn und ich hoffe, dass das Projekt noch lange am Leben bleibt oder vielleicht dadurch noch mal so richitg in Schwung kommt.


    Grumpy

  • VDR aus Repo durch selbst-kompilierte Version ersetzen?

    So denn, nachdem ich mich am Wochenende etwas mehr mit dem Buildsystem auseinander gesetzt habe, läuft nun VDR 2.3.1 auf meinem System, zusammen mit Kodi 17 beta 1 als Front-End. Leider werden in der Kodi Beta noch nicht alle Funktionen sauber unterstützt, aber es sieht zumindest schon mal "verheißungsvoll" aus.


    Beim Kompilieren benötigte ich noch libsystemd-dev, um mit Schalter SDNOTIFY=1 kompilieren zu können. Ohne SDNOTIFY wurde VDR immer wieder beendet, was aber an der "type=notify" EInstellung in meinem vdr.service Datei lag. Überhaupt bin ich so vorgegangen, dass ich mir zunächst VDR 2.2.0 aus dem Default Ubuntu PPA installiert und eingerichtet habe. Dort waren auch die benötigten zusätzlichen Files, wie z.B. für die recording-hooks, enthalten, die ich für mein Setup nutze.


    Nach dem Kompilieren habe ich /usr/bin/vdr und svdrp als symbolischen Link auf meine selbstkompilierten Binaries zeigen lassen und ähnlich hab ich es für das Plugin-Verzeichnis unter /usr/lib/vdr gemacht. Damit konte ich über das Umsetzen von drei symlinks und Neustart ggfs. schnell wieder auf die Vorgänger-Version zurückwechseln. War aber nicht nötig, da es damit nach Anpassung der vdr.service bzw. nach Kompilieren mit SDNOTIFY=1 rund lief.


    In Kodi gewinnt man mit VDR 2.3.1. nun die Möglichkeit EPG basierte TImer einzurichten. Damit wird epgsearch wohl dann auch nicht mehr benötigt.


    Statt des live Plugins habe ich mir vdradmin-am installiert, was mit SVDRP arbeitet. Ist zwar schon etwas betagt, aber scheint auch mit VDR 2.3.1 anstandslos zu arbeiten, sofern man kein streamdev benötigt. Per http remote auf die EPG Daten zuzugreifen und einen Timer zu erstellen, hat auf jeden Fall einwandfrei funktioniert.


    Danke für Eure Tipps und Unterstützung.

  • VDR aus Repo durch selbst-kompilierte Version ersetzen?

    Vielen Dank, mini73 und SvenS, schon mal für Eure schnellen und hilfreichen Tipps. Die idee mit dem eigenen PPA klingt spannend, bisher hatte ich schon ein Pinning auf yavdr, damit ich immer von dort aus meine Updates ziehen konnte.


    Das Kompilieren scheint bereits zu funktionieren, zumindest konnte ich vdr 2.3.1. und einige Plugins erfolgreich erzeugen. epgsearch aus dem entsprechenden tree für vdr-2.3.1 war auch darunter Ich hoffe, dass es dann auch tut. Dass live noch nicht mit vdr 2.3.1 läuft ist echt ärgerlich.


    Leider erwartet das vdr/vniserver addon für Kodi Krypton nun offenbar vdr 2.3.1 um alle Funktionen anbieten zu können. Daher erscheint, der Vorschlag von SvenS auch interessant, um mehrere Versionen parallel halten zu können.


    Auf jeden Fall ist mir die Vorgehensweise nun klarer. Ich werde dann wohl am Wochenende mal die nächsten Schritte angehen und mich hier zurück melden.

  • VDR aus Repo durch selbst-kompilierte Version ersetzen?

    Hallo zusammen,


    mein erster Beitrag :)


    Ich hab bisher den vdr (2.2.0) aus dem ppa:yavdr/stable-vdr auf Ubuntu installiert. Nun möchte ich mich - im ZUge eines Updates auf vdr 2.3.1 - daran wagen, den vdr und Plugins selbst zu kompilieren.


    Was mir dabei nich nicht ganz klar ist:
    Muss ich die alte Version vorher mit apt-get remove oder sogar apt-get purge (vollständig) entfernen, oder kann ich mit make install da drüber installieren (hab die Pfade in Make.config so eingestellt, dass das vdr binary im selben Pfad installiert wird: /usr/bin)?
    Wie kann ich ggfs. verhindern, dass durch ein apt-get update/upgrade meine selbst-kompilierte Version wieder überschrieben wird?


    Und sind die Konfig Files aus vdr 2.2.0 auch mit vdr 2.3.1 weiter nutzbar?


    Danke vorab


    Grumpy