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,

    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

    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.

    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

    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:

    Code
    1. gentoo64 ~/bin # ./_testing.sh
    2. please select the size in KiB for size_1 ? 123
    3. please select the size in KiB for size_2 ? 456
    4. please select the size in KiB for size_3 ? 789
    5. please select the size in KiB for size_4 ? 100
    6. size_1 = 123
    7. size_2 = 456
    8. size_3 = 789
    9. size_4 = 100

    LG Helmut

    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

    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

    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