Posts by Dr. Seltsam

carel: Do you have osdteletext plugin running? Does it make a difference? Probably not, because your EXTT channels are without Teletext-Pid in channels.conf, I guess.

Zabrimus Could you please post a link to the patch "prevent retune and obsolete"? I use the iptv-plugin for Telekom Entertain and there is only one filter (PAT 0x00) active right now. That was recommended in the past: RE: IPTV - aktuelle channels.conf für Telekom Entertain

I tested the 3 recommended filters instead but it seems that there is sometimes this problem: new picture appears, gets black and comes back again. There is no retune message in the log. It may have to do with osdteletext which has also receiver running.

Melde Interesse an!

Mein Test mit softhdodroid war erfolgreich - das Stillpicture-Bild kommt sofort und ist stabil ohne Flackern.

Beim weiteren Testen mit dem radio-Plugin habe ich dann bemerkt, dass PlayPes nur bei Replay funktioniert, und auch nur bei Aufnahmen von DVB-Radio. Bei radio-Aufnahmen vom iptv-Plugin (vlc) funktioniert weder StillPicture noch PlayPes. Da scheint die Erkennung als audio-only-Stream nicht zu funktionieren, aber das ist wohl eine andere Baustelle.

Soweit ich bisher glaubte, PlayPes würde auch im Live-Betrieb funktionieren, könnte das daraus resultieren, dass ich bisher ein Schwarzbild sowohl für live als auch replay konfiguriert hatte . Ich wollte meinen TV schonen und habe das radio-Plugin nur benutzt, weil das Spulen in Radioaufnahmen besser funktioniert, wenn das Ausgabeplugin auch ein Bild bekommt.

Wie ich jetzt erst sehe, sind die Patches des leider verstorbenen HelmutB aus seinem git inzwischen von M-Reimer auch auf vdr-projects übernommen worden, so dass Zabrimus das Plugin radio-ng dann m.E. aus seinem 'Sortiment' entfernen könnte.

Ich kann den Patch leider nicht in Verbindung mit softhddevice-drm-gles testen, weil ich da nur ein Fertig-Image von VDR*Elec habe. Für softhdodroid habe ich aber eine Entwicklungsumgebung in chroot und werde das heute oder morgen testen. Beide Methoden (StillImage und PlayPes) funktionierten ansonsten mit softhddevice (kann ich mangels Hardware leider auch nicht mehr testen) und softhdodroid bislang ohne Probleme. Ob und welche Verrenkungen in beiden Plugins dafür notwendig waren,weiß ich allerdings nicht.

If I remember right, the PES handling was improved in radio-ng. Did you use this code in iptv?

The still image always looked a bit flickering on my screen. I prefer PkayPes. This may even be necessary for perfect fast forward and rewind in radio recordings. Different output plugins have a different behaviour when playing audio-only.

Der Code für DeviceSwitch wurde am 29.12. als 'broken' auskommentiert. Möglicherweise steht das in Zusammenhang mit RE: SATIP-Plugin 2.5.0

Ich halte das aber für keine gute Lösung. Das Umschalten in femon geht sowohl auf DVB devices als auch mit devices des iptv-Plugins einwandfrei. Das Problem hat nur das satip-Plugin.

I tried this with VDR*Elec from 1 or 2 weeks ago (softhddevice-drm-gles (1.4.2-4f52dbcfd9-dirty)) on Raspi 4.

Using a Internet radio channel with iptv-plugin I get

Jan 05 12:03:31 LibreELEC vdr[11290]: [11310] [softhddevice] device: HandleStillPicture: invalid PES packet
Jan 05 12:03:32 LibreELEC start_vdr.sh[11238]: Segmentation fault (core dumped)

Where does LibreElec store the corefile?

Zabrimus: How do i choose the folder with the image and the mpeg file? I can't find any information in README or iptv.conf

Using the radio-plugin (not radio-ng) I needed to change the path in radio.conf to /storage/.config/vdropt/plugins/radio/mpegstill
With PlayPes I get no picture and log errors, but no crash

Jan 05 16:11:41 LibreELEC vdr[15264]: [15264] radio: [ChannelSwitch # Apid= 3811, Ca= 0] channelname '1LIVE', use image '/storage/.config/vdropt/plugins/radio/mpegstill/radio.mpg'
Jan 05 16:11:41 LibreELEC vdr[15264]: [15336] device 2 TS buffer thread started (pid=15264, tid=15336, prio=high)
Jan 05 16:11:41 LibreELEC vdr[15264]: [15286] [softhddevice] videostream: main: RenderFrame: error_flag or FRAME_FLAG_CORRUPT
Jan 05 16:11:41 LibreELEC vdr[15264]: [15352] shd main filter thread started (pid=15264, tid=15352, prio=high)
Jan 05 16:11:41 LibreELEC vdr[15264]: [15286] [softhddevice] videostream: main: RenderFrame: error_flag or FRAME_FLAG_CORRUPT
Jan 05 16:11:42 LibreELEC vdr[15264]: [15335] RadiotextCheckTS: new audio track - Pid 3811
Jan 05 16:11:46 LibreELEC vdr[15264]: [15365] DisplayChannel thread started (pid=15264, tid=15365, prio=high)
Jan 05 16:11:46 LibreELEC vdr[15264]: [15365] skinnopacity: First Lock(): 0ms
Jan 05 16:11:46 LibreELEC vdr[15264]: [15365] DisplayChannel thread ended (pid=15264, tid=15365)
Jan 05 16:11:49 LibreELEC vdr[15264]: [15352] shd main filter thread ended (pid=15264, tid=15352)
Jan 05 16:11:49 LibreELEC vdr[15264]: [15335] ERROR: 1 TS packet(s) not accepted in Transfer Mode
Jan 05 16:11:49 LibreELEC vdr[15264]: [15335] CC-ERROR: want 7, got 8
Jan 05 16:11:57 LibreELEC vdr[15264]: [15335] CC-ERROR: want 5, got 6

With radio plugin configured to StillImage I the same crash as with iptv.

So my experience is the opposite to fiveten_59 - it is not PlayPes what is crashing, but StillImage

Kann es sein, dass das nur die X11-spezifischen XKeySym-Einträge in der remote.conf betrifft? Im Gegensatz zu softhddevice verwendet softhddevice-drm-gles ja keinen X-Server.

Worauf vdr reagiert, wird doch über die remote.conf gesteuert. Du entscheidest selbst, worauf vdr reagiert (LIRC, remote-plugin, XKeySym, KBD)

Sonst müsste jrie mal erläutern, was er mit

Quote

If you use the vdr-plugin-softhddevice, you need to disable softhddevice's remote control function with -P'softhddevice ... -N'.

genau meint.

Das von Paulaner beobachtete Phänomen, dass ein Timer für eine längst abgeschlossene Aufnahme angeblich noch aktiv war, habe ich auch schon ein paar mal gehabt (DVB-C mit epg). Wenn ich mich richtig erinnere lag es jedes mal an markad, das sich mit hoher CPU-Last „festgefahren“ hatte und nicht beendet wurde.

Quote from rell

Wenn softhddevice-drm-gles bei dir läuft, gerne her mit Sachen, die dir auffallen...

Moin rell,

ich habe das nur kurz angetestet und auch eigentlich nur aus Neugier, denn mit meinen beiden amlogic-devices bin ich ausreichend versorgt.

Ich hatte sehr schnell ein Bild und es zeigt sich wieder einmal, dass heutzutage niemand mehr große PC-Hardware als Basis für einen VDR benötigt. Die Bildqualität ist top und auf gleichem Niveau mit meinen amlogic-Boxen/softhdodroid. Mir gefällt an Deinem Plugin, wie aufgeräumt und übersichtlich das setup-Menü ist .

Ich habe softhddevice-drm-gles in Verbindung mit einem an den Raspi 4 angeschlossenen DVB-C-Empfänger (WinTV duakHD) mit unverschlüsselten HD-Sendern getestet. Ein paar Anmerkungen und Beobachtungen:

• Die Umschaltgeschwindigkeit ist in etwa vergleichbar mit softhdodroid, wenn dort der "Fast Switch" deaktiviert ist. (Und das ist auch die Methode, mit der ich softhdodroid inzwischen nutze, denn auf Dauer ist es zu nervig, wenn das Bild zwar schnell kommt, dann aber nochmal stehen bleibt, weil die A/V-Synchronisation nicht fertig ist). Bei also vergleichbaren Ausgangsbedingungen würde ich sagen, die Umschaltgeschwindigkeit entspricht dem, was machbar ist. Wir haben bei h264 ja mitunter längere Abstände zwischen den i-frames, so dass sauberes Umschalten unter 1s einfach nicht in jeder Situation machbar ist.
• Der Ton kommt vergleichsweise spät nach dem Umschalten. Beim Durchzappen ist es einige male auch passiert, dass gar kein Ton kam und ich nochmal zurück und vor umschalten musste.
• Sporadisch ist nach dem Umschalten die unteren Bildhälfte (teils auch nur das untere Drittel) kurz mit Artefakten grün verpixelt. Ich gehe mal davon aus, dass Du auf den Beginn eines i-frames wartest, so dass das eigentlich keine Störungen sein können, die vom DVB-C-Stick durch den Umschaltvorgang (Tunen) kommen. Es tritt auch auf, wenn alter und neuer Kanal auf der gleichen Frequenz liegen. Ich habe versucht nachzuvollziehen, wie der Wechsel zwischen Schwarzbild und "Anknipsen" des neuen Bildes erfolgt. Der "Gegenspieler" von DisplayBlackFrame ist wahrscheinlich DisplayFrame? Meine (wahrscheinlich laienhafte) Vermutung wäre, dass das Timing hier nicht optimal ist.
• Es gibt in den Audio-Einstellungen die Möglichkeit, für die Lautstärkesteuerung zwischen Hardware und Software zu wählen. Per default ist nach meiner Erinnerung Hardware aktiv. Einen Unterschied zwischen Hard- und Software habe ich nicht bemerkt, soweit es Umschaltverhalten und -dauer angeht. Was unterscheidet die beiden Methoden? Ich frage deshalb, weil bei softhdodroid jojo61 als default-Voreinstellung Software vorgesehen hat. Dort hatte ich wohl irgendwann mal auf Hardware umgestellt und erst kürzlich bemerkt, dass es die Umschaltgeschwindigkeit m.E. spürbar verbessert, wenn es auf Software steht.

Ich würde wahrscheinlich Jahre brauchen, um den Code ansatzweise zu verstehen und mich da einzuarbeiten. Die Codebasis der verschiedenen softhd*-Plugins hat sich inzwischen sehr weit auseinander entwickelt. Aber das liegt halt in der Natur der Sache.

Ich wollte jetzt auch mal das Plugin von rell auf meinem Raspi 4 ausprobieren und habe von Zabrimus das image LE-RPi4.aarch64-13.0-VDR-1226 installiert. Jetzt stehe ich vor dem Problem, dass das darin enthaltene Libreelec addon-repository 12.80.4 nicht mehr verfügbar ist. Hier wurde wohl am 22.12. schon auf 12.80.5 umgeschwenkt.

Ich habe es jetzt gelöst, indem ich eine Datei kopiert

cp -a /usr/share/kodi/addons/repository.libreelec.tv/ /storage/.kodi/addons/

und diese dann editiert habe. Nach dem Neustart war dann das Repository 12.80.5 da. Ich hoffe nur, das gibt jetzt keinen Versions-Mischmasch.

Die Frage ist, warum kann der satip-Server den Kanal nicht entschlüsseln? Mit dem dvbapi-Plugin geht das auf beiden satip-devices. Wenn ohne dvbapi-Plugin nur auf einem einzigen satip-device entschlüsselt werden kann (aber warum?), dann dürften die anderen satip-devices doch gar nicht anwählbar sein. femon scheint in der Funktion ja auch zunächst zu prüfen, ob das device den Kanal entschlüsseln kann ("// Collect the current priorities of all CAM slots that can decrypt the channel")

Quote from FireFly

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.

Solange ich den Kanal nicht wechsle, bleibt es hell. Ob da ein re-tuning stattfindet kann ich ad hoc nicht sagen, aber wenn, dann führt das an der Stelle zumindest nicht zum Bildverlust.

Quote

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

Wenn jeder Client mit dem dvbapi-Plugin läuft und die CAM-Nutzung im satip-Plugin deaktiviert ist, hat es gut funktioniert und auch das Umschalten in femon links/rechts machte keine Probleme. Ich schreibe in der Vergangenheitsform, weil ich mit dem aktuellen git-Stand von minisatip nur sporadisch ein Bild auf verschlüsselten Kanälen bekomme. Mit einer von mir gepatchten minisatip-Version aus 2023 geht das hingegen auch heute noch problemlos. Aber auch dort: 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.

Quote from neumann2k

Ich verwende im Ganzen Haus an jedem TV ein RPI4 mit SATIP

Was für einen Satip-Server verwendest Du?

Aber vdr läuft solange nicht und kann nichts aufnehmen

Quote from don-baba

Kann denn dann Openelec den eingebauten Arm chip für ein besseres Streaming von z.b. netflix nutzen?

Die Qualität des Streaming z.b. Prime auf Linux nur 480p hängt von möglichen Zertifikaten Chips ab.

OpenElec gibt es nicht mehr, ist jetzt CoreElec. Man möge mich korrigieren, aber ich glaube es müssen sowohl die Box (Wivedine-Zertifizierung) als auch das Programm zertifiziert sein. Deshalb ist mit Kodi m.E. auch auf den zertifizierten Boxen nicht mehr als SD drin. Ich glaube es gibt User, die dafür ins parallel vorhandene Android booten und dann dort die offiziellen Apps der Streaming-Anbieter verwenden.

Ich habe erst jetzt wieder das satip-Plugin ausprobiert und bin nicht früher über die Auswirkungen der Änderungen gestolpert. Wie ich inzwischen mit dem alten Plugin (Stand Juni) nachvollziehen konnte, war es dort völlig egal, welche CA-IDs im OSD-setup ausgewählt wurden, Hauptsache irgendwelche.

Mein satip-Server ist minisatip, das zur Entschlüsselung direkt mit einem Server kommuniziert (nennen wir ihn mal oscar, in der Hoffung dass das nicht zensiert wird). Offenbar hat sich da auch bei minisatip einiges geändert. Mit dem neuen git-Stand kriege ich mit Deiner Plugin-Version auch ohne Parameter --caids ein Bild auf den verschlüsselten Kanälen (Vodafone Kabel mit G09-Smartcard) - aber nur einmal beim ersten Anwählen und nach dem Umschalten dann nie wieder. Das Problem habe ich mit wirbels Version hingegen nicht. Ich überblicke leider nicht, welche Deiner Änderungen die Ursache sind. Auch mit --caids=0x09C7;0x09C7 ist das Verhalten gleich.

Die erste Frage wäre nun, welches Ziel Du mit Deinem Plugin verfolgst bzw. welchen Anspruch es erhebt: Soll es ein Plugin sein, dass auf den Betrieb mit einem Octopus-Server zugeschnitten ist und in Kauf nimmt, dass die Kompatibilität zu anderen satip-Servern dadurch ggf. eingeschränkt ist? Das wäre schade. Ich sehe, dass Du viel an dem Plugin gearbeitet hast, und von vielen Änderungen würden sicherlich auch andere satip-Server profitieren.

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. Dumm ist, dass das satip-Protokoll dafür keine Vorab-Prüfung der Capabilities vorsieht. So kommt es nicht zu einem "Kanal nicht verfügbar", sondern das Bild bleibt einfach dunkel, wenn der Server kein passendes CAM hat. Ich würde es verstehen, wenn der --caids Parameter nun dazu dienen soll festzulegen, welche CA-ID das CAM entschlüsseln kann. So wie ich die README verstehe, soll der --caids Parameter ja auch eine Pflichtangabe sein. Dann müsste das Fehlen nach meinem Verständnis genauso behandelt werden, als wenn mit dem Parameter eine andere CA-ID vorgegeben wird, als sie in der channels.conf für den angewählten Kanal steht.

Tatsächlich schaltet vdr auch ohne --caids Parameter oder mit --caids=0x0000;0x0000 auf einen Kanal um, der in der channels.conf eine abweichende CA-ID 0x09C7 hat (und zunächst kommt sogar ein Bild, siehe oben). Eigentlich hätte ich erwartet, dass das Plugin über ProvidesChannel in beiden Fällen false zurückmeldet, so dass vdr das Umschalten mit "Kanal nicht verfügbar" ablehnt.

Bei allen getesteten satip-Versionen (rofafor, Wirbel, Firefly) habe ich 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. Kannst Du mal bitte testen, ob das im Zusammenspiel mit einer Octopus auch auftritt?

Da gibt es mit Sicherheit auch Bugs in minisatip. Die STR/SNR-Anzeige funktioniert trotz mehrerer Bug-Reports mit konkreten Lösungsvorschlägen bis heute nicht - die hier verkündete Lösung ändert nichts an dem Problem, dass harmlose und irrelevante Treiber-Rückmeldungen, die bei jedem Kanalwechsel auftreten, zu einem Abbruch der Funktion get_signal_new führen. Wahrscheinlich ist da noch mehr kaputt. Aber zu einem Einfrieren von vdr dürfte es deshalb dennoch nicht kommen.

na, ich hoffe doch amlogic löhnt für ihn

Quote from rell

Auch Amlogic schwenkt gottseidank endlich um. CoreELEC hingegen setzt noch auf die software, die der Hersteller zur Verfügung stellt - was ich persönlich für den falschen Weg halte.

Gibt es für ersteres Belege oder ernsthaft erkennbare Ansätze? Ich war doch einigermaßen erstaunt, wieviel Zeit und Mühe die CoreElec-Entwickler investieren, um wiederum mit einem amlogic-spezifischen Kernel 5.15, der offenbar zahlreiche -proprietäre- Änderungen enthält, von vorne anzufangen. Das hätten die wahrscheinlich nicht gemacht, wenn mainline-Unterstützung in Kürze fertig ist. Meine Vermutung ist, dass es zumindest für neue Hardware auf absehbare Zeit nur proprietäre Linux-Unterstützung geben wird. Und ich glaube, selbst für diesen 5.15 gibt es noch keine veröffentlichten Sourcen, weil die eine NDA unterschreiben mussten.