Posts by FireFly

Quote from lnj

I tested now with latest ffmpeg.

I just tried with the latest softhddevice (Dec 20) and ffmpeg 6.1.3 and can still reproduce this issue with the SD channels of ProSieben, Sat.1 and KabelEins.

Jumping to a cutting mark plays audio but no video and the playing time in OSD is not updated. It seems that also the VDR setting replay->"Pause replay when jumping to a mark" has an effect because if set to "no" sometimes the replay works but if set to "yes" it is reproducible. Also the jumping direction seems to have an effect: on jumping backwards it is always reproducible, jumping forward most of the times.

Maybe related is that sometimes replaying a recording from beginning also does not update the playing time.

Quote from obelix

Allerdings sehe ich nur einen Eintrag vom aktuellen Sender

Das Plugin versucht die maximale angezeigte Anzahl Zeilen im OSD zu ermitteln. Das ist vorher gecrashed, jetzt wird stattdessen die max. Anzahl auf 1 gesetzt. Evtl. wäre es sinnvoll die auf eine höhere Zahl, z.B. 5 zu setzen? Meines Wissens gibt es keine Möglichkeit die Anzahl zu ermitteln - der VDR geht davon aus, dass alle anzuzeigenden Zeilen vom Plugin geliefert werden und er scrollt je nach empfangenem Tastendruck.

Da müsste man mal analysieren, wie femon da arbeitet um das nächste Device zu bestimmen, da bin ich raus.

Quote from Dr. Seltsam

Sobald ich es ohne dvbapi-Plugin und mit aktivierter CI-Erweiterung im satip-Plugin laufen lasse, führt der Versuch eines devices-Wechsels mittels femon zur Unbedienbarkeit und 100% CPU-Last von vdr.

Mit diesen Einstellungen kann ich es Nachvollziehen wenn die OcotpusNet den Sender nicht entschlüsseln kann. Dann loopt der VDR Hauptthread innerhalb femon und ruft immer wieder DeviceSwitch() auf, weshalb das dort gefixed werden müsste:

(gdb) bt
#0  0x00007fc8d4ffa954 in cSatipDevice::HasInternalCam (this=0xae92910) at device.c:522
#1  0x00007fc8d558ffe5 in cFemonOsd::DeviceSwitch (this=this@entry=0xaa89f90, directionP=directionP@entry=1) at osd.c:865
#2  0x00007fc8d55902ff in cFemonOsd::ProcessKey (this=0xaa89f90, keyP=<optimized out>) at osd.c:1074
#3  0x0000000000481717 in main (argc=<optimized out>, argv=<optimized out>) at vdr.c:1420

Quote from Dr. Seltsam

Die erste Frage wäre nun, welches Ziel Du mit Deinem Plugin verfolgst bzw. welchen Anspruch es erhebt

Das Plugin soll natürlich mit möglichst vielen SATIP-Servern laufen. Andererseits kann ich nicht alle Hardware-Konfigurationen testen und bin auf Rückmldungen aus der Community angewiesen.

Quote from Dr. Seltsam

So ganz verstehen tue ich ehrlich gesagt nicht, welchen Zweck dieser --caids Parameter hat. Die CA-ID steht in der channels.conf und wird mit an den satip-Server übergeben. Es ist dann doch seine Sache, für die Entschlüsselung auf das passende CAM zuzugreifen

Für die Entschlüsselung muss der RTSP Session die PMT mitgegeben werden, nicht die CA-ID. Dafür hat der VDR extra die Funktion GetPmtPid(). Um vorab zu wissen ob der Kanal entschlüsselt werden kann (ProvidesChannel()) wird die CA-ID benötigt. Dass Du kurz ein Bild hast rührt vermutlich daher, dass der VDR nach seinem Start immer erst auf den Kanal tuned um eventuelle CA-IDs zu erhalten und dann MIT CA-IDs re-tuned.

Ansonsten kannst Du in diesem Thread von der Entwicklung damals mehr zu den Details lesen: RE: SATIP und vTuner mit SAT Receiver Digital Devices SX8 mit integriertem CI

Quote from Dr. Seltsam

Mein satip-Server ist minisatip, das zur Entschlüsselung direkt mit einem Server kommuniziert

Dann frag doch mal Deinen oscar ob er nicht direkt mit dem VDR reden will, es gibt auch ein API dafür.

Quote from Dr. Seltsam

das Problem, dass beim Versuch, mittels des femon-Plugins (links/rechts-Tasten) auf einem verschlüsselten Kanal das satip-device zu wechseln, vdr mit über 100% CPU-Auslastung unbedienbar wird

Das klappt bei mir ohne nennenswerte CPU-Auslastung.

Quote from Dr. Seltsam

Mir erscheint das ganze doch etwas zu sehr Octopus-spezifisch zu sein

Die ganze CAM-Nutzung ist nicht Teil der SATIP-Spezifikation und von Digital Devices für die OctopusNet entwickelt worden und damit Octopus-spezifisch. Soviel ich weiß hat die alte Version mit der neuen Firmware nicht mehr funktioniert und ich habe mich bei der Entwicklung an deren Spezifikation zur Implementierung gehalten. Und weil sich die Konfiguration geändert hat ist das im README beschrieben. Da ein CAM nur einem Ocotpus-Tuner zugeordnet werden kann macht es keinen Sinn dem VDR zu sagen er könne mit allen Devices das CAM benutzen um dann später festzustellen, dass es doch nicht geht. Mit einer DVB-Karte ist ja auch das CAM fest zugeordnet.

Quote from Dr. Seltsam

Und offenbar werden da ja von unterschiedlichen Sendern auch unterschiedliche CA-IDs aus der Range verwandt

Es gibt Sender, die können mit mehreren (unterschiedlichen) Smartcards entschlüsselt werden. Sofern eine davon passt wird diese benutzt, deshalb langt es, die (eine) CA-ID der Smartcard anzugeben.

Quote from Dr. Seltsam

Muss man jetzt jede einzelne CA-ID kommagetrennt vorgeben, oder ist es möglich, auch eine Range von-bis anzugeben? Sonst wird das ja eine ellenlange Zeile mit über 100 Einträgen.

Meines Wissen hat jede Smartcard nur eine CA-ID, es gibt Dual CAM Module, die zwei Smartcards aufnehmen können und dann zwei CA-IDs zur Verfügung stellen. Wieso willst Du einen Bereich vorgeben? Hast Du so viele Smartcards?? Und die Konfiguration macht man nur am Anfang oder bei Kartenwechsel.

Und wieso hast Du Dich nicht schon im Spätsommer in die Diskussion eingeklinkt? Ansonsten bin ich für Patches offen.

Quote from SurfaceCleanerZ

du nutzt eine GPT und dann ist fdisk das falsche Tool, das kann damit nicht umgehen

Genau, und das "fdisk" für GPT heißt gdisk

Quote from MarkusE

Ich könnte die Episodeninformation auch in's aux Feld des Events schreiben, z.B. im XML oder json Format. Das hätte den Vorteil, dass sie nicht von jedem anderen, der das EPG verändert, überschrieben wird. Das würde aber nur helfen, wenn epgsearch diese Information aus dem aux Feld auch auswertet.

Das geht ja seit einigen Tagen nachdem der Aux-Patch drin ist z.B. bei mir mit @ <xmltv4vdr><season>13</season><episode>25</episode><episodeOverall>298</episodeOverall></xmltv4vdr> :

# cat /usr/local/bin/vdr_get_series.sh
#!/bin/bash
# $1 = title
# $2 = subtitle
# $3 = aux

SEASON=$(echo "$3"|xmlstarlet sel -t -v "/xmltv4vdr/season")
EPISODE=$(echo "$3"|xmlstarlet sel -t -v "/xmltv4vdr/episode")
printf "%s~S%02dE%02d - %s" "$1" ${SEASON:-0} ${EPISODE:-0} "$2"

und in epgsearchuservars.conf:

%Season%=system(/usr/local/bin/vdr_get_series.sh,%title% %subtitle% %aux% )
%DateVar%=%time_w% %date% %time%
%SerieSD%=%Subtitle% ? %Subtitle% : %DateVar%
%SerieVar1%=%Title%~%SerieSD%
%Serie%=%Season% ? %Season% : %SerieVar1%

Aber bei JSON bitte auch in ein XML-Tag einpacken, da XML sich ja im Laufe der Jahre quasi als Standard für das AUX-Feld etabliert hat.

Die Werte der F-Zeile stammen aus dem cFrameParser, der am Anfang der Aufnahme aufgerufen wird um die Daten für die Info-Datei zu liefern. Wenn der Wert nicht konstant ist, kann man das sowieso nicht in der F-Zeile abbilden sondern bräuchte eine andere Methode.

X 1 01 heißt lt. ETSI EN 300 468 das es ein MPEG2 Video mit 4:3 Aspect Ratio und 25 Hz ist. (X 1 03 wäre MPEG2 in 16:9 ) Also insofern ist das konsistent.
Das "4:3" dahinter ist ein beliebiger Freitext (genaus wie "Deutsch" darunter).

Im Zweifelsfall würde ich dann eher den F-Zeilen vertrauen weil das auch die Ausgabeplugins nutzen.

lnj Did you have a chance to check this issue?

Mit -d kann man die Anzahl der DVB-Devices angeben, die der VDR sieht (insofern stimmt das indirekt mit der Anzahl der gleichzeitigen Transponder überein). So viele Devices sollten auch im SATIP-Plugin für die Zuordnung der CAMs sichtbar sein.
Wieviele Streams das SATIP-Plugin von der Octopusnet gleichzeitig aufmachen kann (was auch wieder der Anzahl gleichzeitiger Transponder enspricht) wird mit -s angegeben (oder wird dynamisch via Suche im lokalen Netz ermittelt wenn keine -s angegeben ist), z.B. DVBS2-6 heißt 6 Devices von Typ DVBS2. Details zur Syntax siehe Readme.
Du kannst ja mal vdr --showargs aufrufen, dann werden alle Parameter ausgegeben mit denen VDR startet (richtiges Config-Verzeichnis vorausgesetzt, MLD kenne ich nicht).

Edit: Aber am besten machst Du dafür einen neuen Thread auf, damit auch von MLD eher drauf geschaut wird

Quote from Dumpfbacke

Jetzt hab ich nur noch das Problem, dass ich nur zwei Devices auf dem mld bekomme, obwohl ich vier eingestellt habe.

Den Satz verstehe ich nicht .... Was hast Du denn in der satip.conf bei -d und bei -s eingestellt?

anderer VDR? Das CAM kann nur jeweils einen VDR bedienen, da das die Octopus so beschränkt

Hast Du den richtigen Slot eingestellt? Ob Slot 1 der obere oder untere ist weiß ich auch nicht mehr, aber im Webinterface der Octopus müsstest Du sehen, in welchem Slot das CAM steckt.

Quote from Dumpfbacke

Kann man das per Parameter übergeben?

Ja, ich zitiere mal das README:

If you want to use the CI slot(s) of the OctopusNet you need to define
the CA IDs supported by each slot with the "--caids" parameter. Multiple
CA IDs per slot can be given separated by comma, multiple slots are
separated by semicolon:
--caids=<CAM1_ID1>[,<CAM1_ID2,...][;<CAM2_ID1>[,<CAM2_ID2>,...];....]

Example for CA ID 0x1000 in slot 1 and 0x2000 and 0x2020 in slot 2:
--caids=0x1000;0x2000,0x2020
Additionally in the plugin's settings you need enable the "Use CI extension" and
define the VDR device(s) the CI slot(s)s will be attached to.

Das wäre dann in Deinem Fall --caids=0x4a20 (bzw. wenn die Karte im zweiten Slot steckt: --caids=0x0;0x4a20) und gehst nach einen VDR-Neustart in die Einstellungen des Plugins, setzt "Aktiviere CI Erweiterung" auf Ja und wählst welchem VDR Device das CI zugewiesen werden soll - vorzugsweise eine höhere Device-Nummer damit VDR mit Aufnmahmen von unverschlüsselten Sender nicht das Device mit dem CI belegt.

Dann fehlt da etwas, normalerweise wird da die Zeile mit ausgegeben

Quote

reicht das hier

Nicht wirklich, das zeigt zwar die Funktion, aber nicht bei welcher Zeile/Statement es passiert weil wohl die Debug Symbols fehlen.

Quote from clausmuus

Es geht um die Git Revision: 270fc642e291602753b0e3c6b3139ff66f0b9eb6

Das ist also Release 1.2.8 - was spricht gegen skinElchiHD 1.2.9 die seit August draußen ist? Ich denke aber nicht, dass das das Problem löst.

Quote from clausmuus

Ich gehe davon aus, dass im Moment des Absturtzes ein "svdrpsend PLUG softhddevice DETA" aufgerufen wurde.

Das würde zu dem oben von mir beschriebenen TrueColor Problem passen, also mal das Ausgabeplugin auf den aktuellen Stand bringen und/oder hier im Forum danach suchen, da wurde das auch schon mal beschrieben.

... und alles ohne Angabe von Versionsnummern Wie soll ich denn aus diesem HEX-Kauderwelsch rausfinden was passiert ist????
Es gab vor längerem mal den Fall, dass ein Ausgabeplugin beim Start sagt, dass es TrueColor unterstützt, dann aber beim Suspend kein TrueColor OSD mehr zur Verfügung stellt. Das wurde dann im Ausgabeplugin gefixed. Deshalb installiere mal die neusten Versionen von skinElchiHD und deines Ausgabeplugins (also evtl. neuer als das was MLD zur Verfügung stellt). Ansonsten brauche ich einen Backtrace und die MLD Maintainer müssen Dir sagen wie man den dort erstellen kann.