Posts by HelmutB

Hi,

I found a datasheet for the cx24116 with register description. There could be an easy way, to avoid unneeded firmware reloads, but this needs a driver patch. I will post it on the evening.

Helmut

Hi,

according to this information (updated on 2021-10-16), Al Jazeera is DVB-S, not DVB-S2 as in your channels.conf

https://www.lyngsat.com/muxes/…D3_Australia_12136-V.html

Besides the testing of other firmwares, try it with this transponder parameters: :VM2O35S0:

Helmut

Edit

wirbel : you were faster

Hi,

can you post the lines from your channels.conf for the programs you want to receive and the output of vdr in syslog (or of 'Journalctl -u vdr').

Try to access these card with a different software, e.g. use w_scan2 (and select the adapter with the '-a' option) to scan the transponders for a LOCK.

Helmut

Hi,

I assume that the HVR-4000 DVB-S2 frontend0 was able to display the program with the unpatched VDR in your 1st post - right?
Can you post the syslog from the start of the patched VDR up to the switch from DVB-T to DVB-T2 on this device (and, if available the syslog without the patch too).

BR Helmut

Hi Wirbel,

you are right, that's a wild assumption, but "...however VDR only detects frontend0" is perhaps not too much information.

You can see in the driver that both frontends have separate tuners and demodulators, so there must be other "shared" hardware (or wires) that prevents the two frontends from being used at the same time - but DvbOpen() still could work.

With "query" I mean more cDvbFrontend :: QueryDeliverySystems () after a successful DvbOpen() of frontend1. if VDR don't get any useful information here, the DvbDevice for frontend1 does exist, but it is "stupid" and would therefore always be ignored when selecting a channel.

But we will see if separating the access to this two frontends has any effect.

BR Helmut

Due to the existing demux0 and demux1, VDR treats each frontend as an independent dvbDevice and both frontends are opened during initialization.
In the linuxtv wiki i for your card i found this:

Due to a hardware limitation, the two frontends cannot be used simultaneously. However they can be used sequentially within the same application.

I suspect that after opening frontend0 no information for frontend1 can be queried. You could check the VDR-start log for some information on frontend1.

And you can try the (untested) patch in the attachment. With it, VDR should treat your card as a multi-frontend device and only one frontend is open at a time.

Helmut

Ich sehe gerade, dass es"AV_FRAME_DATA_DATA_STREAM_ELEMENT0" nur in der FFmpeg Version, von Carsten Gross als Erweiterung vonenum AVFrameSideDataTypegibt oder gab:

https://github.com/carsten-gro…4baba64a65a0b9dfd13fe90fa.

Im Original-ffmpeg haben wird nur der SideDataType AV_FRAME_DATA_AUDIO_SERVICE_TYPEverwendet.

LG Helmut

Du hast recht, Die Tpid für Radiotext zu verwenden wäre schon logisch und vermutlich auch ohne Nebeneffekte

Muß ffmpeg wirklich gepatched werden? Ich kenne mich mit den Audioformaten bzw. ffmpeg nicht wirklich aus, aber wenn ich mir den verlinkten Patch ansehe, kommt mir vor, als wird damit statt wie bisher die SideStreamElemente 0 bis 7 nur noch das eine Element für RDS eingebettet?

Im Kodi-Forum finde ich: BR,MDR,NDR,RB,RBB are embedding Radiotext in AAC frames as "Data Stream Elements" identified by "instance_tag=0"

Wären im ungepatchten ffmpeg die RDS-Daten nicht bereits jetzt inAV_FRAME_DATA_DATA_STREAM_ELEMENT0 zu finden?

Um bei Aufnahmen die separate RDS-Pid mitzunehmen, könnte man es im VDR so ähnlich wie beim ttxtsubs-Patch von hier lösen.

LG Helmut

Nachträglich, nur von einer Aufnahme, derzeit ja.

Für "Live" habe ich einen experimentellen Patch für den VDR, der die RDS-Pid ermittelt. Sie kann dann über cChannels::Upid() abgefragt werden.

Zum Testen habe ich das im vdr-radio Plugin mit einen weiteren kleinen Patch umgesetzt.

Damit bekomme ich RDS bei hr1, SWR, ... Leider kann das Plugin aber die neuen aac-Frames auch nicht auslesen.

LG Helmut

Noch eine kurze Anmerkung: da es bei xineliboutput mit Stillimage keinen Ton gibt, habe ich die Funktion deaktiviert. Um das Hintergrundbild zu verwenden ist im VDR-patch in Zeile 7 das "if 1" auf "if 0" zu ändern.

jsffm wrote:

Bei den alten Sendern kann ich die Aufzeichnungen mit Projectx demuxen und habe dann den RDS im Log

Bei den neuen Sendern sind die RDS-Daten von BR, MDR, NDR und RBB im aac-Stream enthalten.

Bei WDR, SWR, hr und SR werden sie aber in einem separaten Stream (ohne Audio) mit eigener PID gesendet und sind daher nicht in der Aufzeichnung enthalten.

Im Kodi-Forum mehr dazu, auch zu aac: https://forum.kodi.tv/showthre…82&pid=3052210#pid3052210

LG Helmut

Das kommt vermutlich aus gx1133.c vom TBS-Mediatree (das ist der Demodulator einiger TBS6902 Karten):

https://github.com/tbsdtv/linu…-frontends/gx1133.c#L1125

Diese Meldung ist eigentlich unnötig, wenn sie dich stört und du die TBS-Treiber selbst bauen kannst, entferne die "printk"-Zeile einfach aus dem Quellcode.
Helmut

Weil es gerade passt, da derzeit fast alle SimpliTV DVB-T2 Programme auch ohne Zusatz-Abo freigeschalten sind, hier die Erweiterung des camtweaks-2.4.2 Patch mit dem auch die beiden CI+ Programme "RTL HD Austria" und "VOX HD Austria" mit statischer CAPMT ohne zusätzlches Plugin zu empfangen sind (es wird offensichtlich nur die erste ECM-Pid in der CAPMT auf eine CI+ Erweiterung geprüft, ohne entsprechende Daten mit dieser Pid gibt es auch keine CC-Verschlüsselung)

Ich habe diese Möglichkeit schon letztes jahr hier festgestellt, nun ist diese Option ist mit dem Flag 0x80 einfach zuschaltbar.

Die entsprechende Config Zeile sieht bei mir dann so aus: 0xC3,0,<CAFE:BABE,Irdeto Access>,[0x69C:4:4]

(Wird beim Sky-Modul nicht funktionieren, vielleicht aber bei anderen Anbietern).

Helmut

Bert : wenn es kein Array sein soll, kann man mit "eval" Variable auch dynamisch erzeugen.

Hier dein vereinfachtes Script aus dem Post #3:

Das Ergebnis:

LG Helmut

kfb77 wrote:

Jun 25 02:44:24 roadrunner vdr: [9326] markad: cStatusMarkAd::Recording(): index 0, pid 9562, filename /srv/vdr/video/local/Horizon_Line/2021-06-25.02.35.100-0.rec: recording stopped
Jun 25 02:44:24 roadrunner vdr: [9326] markad: cStatusMarkAd::RunningRecording(): running recording on device 0
Jun 25 02:44:24 roadrunner vdr: [9326] markad: cStatusMarkAd::RunningRecording(): 1 running recordings
Jun 25 02:44:24 roadrunner vdr: [9326] markad: cStatusMarkAd::Recording(): resume not possible, still 1 running recordings

In dem Abschnitt (der sich sinngemäß mehrmals wiederholt) sieht man, dass die Aufnahme abgebrochen wird, das device 0 danach aber immer noch belegt meldet.

Die Aufnahme auf Adapter 0 (bei dir Device 0) ist aber schon das neue Device. Die abgebrochene Aufnahme lief zuvor auf Adapter 1:

Im kompletten syslog sollte man auch die SignalInfo nach dem Device-Switch sehen können.

LG Helmut

Ich sehe schon, da muss ich beim SignalMonitoring Patch nachbessern. Hier gibt es keinen "Lost Lock" sondern es kommt 1 Sekunde lang keine PAT - deshalb das (vermutlich) unnötige Retune.

Mir ist das bei meinen Tests nie untergekommen, ich werde es mir morgen genauer ansehen.

Zum Receiving(): Bei einer Aufnahme auf einem ungültigen Transponder mit Retune sieht es - zumindest im syslog - bei mir so aus, dass zuerst der receiver thread auf dem neuen Device(2) gestartet und dann der auf dem alten Device(3) beendet wird.

Du kannst der Sache ja grundsätzlich nachgehen, aber ich glaube, mit einem verbesserten SignalMonitoring Patch wird zumindest bei Fourty2 keine Änderung in markad notwendig sein.

LG Helmut

Fourty2 wrote:

Das macht ein Patch von HelmutB (vdr-2.4.7-SignalMonitoring2.patch). Ob es einen realen Signalverlust gab (Sat-Schüssel), die DVB-S Karte bisweilen spinnt, oder der Patch zu nervös ist, läßt sich nicht sagen.

Wenn es während der Aufnahme zu einem Signalverlust kommt, solltest du zuerst so eine Meldung im syslog sehen:

frontend 1/0 lost lock on channel....

Erst wenn danach 11 Sekunden lang kein Signal kommt, versucht der SignalMonitoring-Patch für Livebild oder Aufnahme auf ein anderes freies Device umzuschalten. Zu sehen mit No signal on tp xxx for channel... und retuning due to modification of channel....

Du kannst es testen, indem du das Antennenkabel abziehst.

LG Helmut

kls wrote:

dann könnten ja nie mehrere Applikationen den gleichen Filter benutzen.

Du hast recht, eher unwahrscheinlich - aber dann sollte sich die Änderung in pat.c überhaupt nicht auf w_scan_cpp auswirken.

Vielleicht bringe ich den SAT-Scan zum laufen und sehe dann mehr,

LG Helmut

Den Filehandle nicht, aber vielleicht wird mit einem Del() in dmxdev.c des Kernel der Filter entfernt und es kommen keine Daten mehr zum cPmtScanner von w_scan.

Ich habe es gestern nur kurz mit DVB-T getestet und w_scan_cpp hat auch mit vdr-2.5.5 alle Programme gefunden, ich kann den Fehler also noch nicht nachvollziehen,

DVB-S mit Unicable/SCR funktioniert bei mir nicht, da fehlt ein passendes ProvidesTransponder().

Mit StopSectionHandler/StartSectionhandler könnte man vielleicht feststellen ob sich hier etwas in die Quere kommt.

LG Helmut

wirbel : So wie ich das sehe, behandelt w_scan die Sections eigenständig und damit am device::Sectionhandler vorbei - so wie hier zu sehen:

Daher weiß der VDR klarerweise nichts von zusätzlichen Usern und kann sie beim Del() auch nicht berücksichtigen

Wie wäre es, vor dem Scan die VDR-Sectionhandler mit cDevice::StopSectionHandler() zu beenden, und danach mit cDevice::StartSectionHandler wieder zu starten (ich habe es selbst aber noch nicht ausprobiert) ?

LG Helmut

Ab EAPI 6 muss man das ebuild normalerweise überhaupt nicht ändern.

Ein oder mehrere Patches können einfach unter /etc/portage/patches/CATEGORY/PACKAGE abgelegt werden. Für epgd wäre das z.B. /etc/portage/patches/media-tv/epgd-9999.

Siehe auch https://wiki.gentoo.org/wiki//etc/portage/patches.

LG Helmut