rass und radiotext

[seife]

Kommt bei euch auch ständig
Code:
!!! 150 bytes skipped to get PS/PES sync!!!

oder liegt das an der Tripledragon (der TD-Demux ist subtil anders, wie schon beim sectionsd schmerzhaft bemerkt )

Ist mir bisher nicht augefallen. Passiert das immer, oder nur bei bestimmten Sendern etc...?

Das kommt immer, aber das kann sehr wohl am TD-Demux liegen, vermutlich muss da der Puffer immer erst komplett leer gelesen werden, vor er wieder gefüllt wird (kein ringbuffer im Kernel) und deswegen kommt irgendwann nur ein halbes Paket raus.
Aber da der Radiotext-reader mit einer Ringbuffer-Implementation im Usersapce sowieso viel eleganter zu lösen wäre, mache ich mich mal da dran

[GetAway]

Kommt bei euch auch ständig

Code: Alles auswählen

!!! 150 bytes skipped to get PS/PES sync!!!

oder liegt das an der Tripledragon (der TD-Demux ist subtil anders, wie schon beim sectionsd schmerzhaft bemerkt )

Kommt auch bei jedem Umschalten auf der Dbox.

[seife]

In diesem Fall lag es an den TD-Treibern. Mit ringbuffer ist es weg.

[seife]

So, für die, die probieren wollen: radiotext-ringbuffer-and-other-fixes.diff

Das implementiert den PES-Reader mit einem ringbuffer (wie z.B. im MP2), was effektiver sein sollte (schaut mal die CPU last ohne und mit dem Patch an, wenn radiotext aktiv ist)

Ausserdem:
- fix fd leak
- start Radiotext in radio mode, not in TV mode
- stop Radiotext when leaving radio mode
- open demux non-blocking => faster zapping and thread termination
- terminate thread with a simple flag variable, not complex mutexes

Ausserdem ist noch ein Haufen debug-code drin und ich habe den Radiotext wieder von oben nach unten anzeigen lassen, aber das ist Geschmackssache.

Valgrind ist erstaunlich ruhig mit dieser Version, ich dachte erst er ist kaputt

[rhabarber1848]

- start Radiotext in radio mode, not in TV mode
- stop Radiotext when leaving radio mode

Diesen unstrittigen Teil des Patches habe ich soeben committed:
http://article.gmane.org/gmane.comp.vid ... x.scm/1064

[rhabarber1848]

ich habe den Radiotext wieder von oben nach unten anzeigen lassen, aber das ist Geschmackssache.

Mit diesem Patch?

Code: Alles auswählen

-       S_RtOsdLoop     = 0;
+       S_RtOsdLoop     = 1;

Wie wäre es, wenn wir für Radiotext ein paar Neutrino-Optionen kreieren,
u.a. eine für den Scrollmodus? Dabei könnte die Option zum Aktivieren
des Radiotextes aus dem Infobarmenü in ein eigenes Menü, z.B. unter
dem neuen Zapit-Menü, verschoben werden. Dabei könnte die Option
Radiotext Ja/Nein in eine Option verwandelt werden, welche die Anzahl
der auf dem Bildschirm angezeigten Zeilen bestimmt. Wenn Null Zeilen
gewählt sind, ist Radiotext ausgeschaltet.

[seife]

Ja, mit dem S_RtOsdLoop. Ausserdem im infoviewer den Hintergrund vergrössert.

Persönlich bin ich der Meinung, dass es schon zu viele Konfigurationsmöglichkeiten gibt, und "Radiotext vorwärts oder Rückwärts anzeigen?" etwas esoterisch wäre

Ist aber Geschmackssache, ich weiss.

Hat denn jemand mal den performanceunterschied zwischen meiner Ringbufferimplementierung und dem Original getestet? Ich kann es nicht vergleichen, da das original auf der TD nicht richtig funktioniert und ausserdem die CPU-Last so im unteren einstelligen Bereich schwierig zu beurteilen ist

[dbt]

...Ausserdem im infoviewer den Hintergrund vergrössert.

Finde ich auch so besser

Persönlich bin ich der Meinung, dass es schon zu viele Konfigurationsmöglichkeiten gibt, und "Radiotext vorwärts oder Rückwärts anzeigen?" etwas esoterisch wäre

Ist aber Geschmackssache, ich weiss.

Wenns so bleibt ist das ok, Einstellungen dafür wären übertrieben.

Hat denn jemand mal den performanceunterschied zwischen meiner Ringbufferimplementierung und dem Original getestet? Ich kann es nicht vergleichen, da das original auf der TD nicht richtig funktioniert und ausserdem die CPU-Last so im unteren einstelligen Bereich schwierig zu beurteilen ist

Bis auf das sich überschlagende Log scheint alles recht flott zu laufen, vorallem das Umschalten läuft jetzt wie gewohnt ohne Wartezeiten. Insofern merkt man das schon.

Was noch fehlt wäre in der RT-Klasse ein public Member für eine vernünftige Abfrage die true/false zurückgibt wenn Rt-daten gefunden wurden.
sowas wie das hier

Code: Alles auswählen

haveRadiotext()

Das könnte man evtl. hier

Code: Alles auswählen

int CRadioText::PES_Receive

abrufen

Edit:Weil sich einges gezwickt hat, Patch hier aufs aktuelle CVS
neutrino-rt_diff-2009-09-06-12-57-44.patch

[GetAway]

Hat denn jemand mal den performanceunterschied zwischen meiner Ringbufferimplementierung und dem Original getestet? Ich kann es nicht vergleichen, da das original auf der TD nicht richtig funktioniert und ausserdem die CPU-Last so im unteren einstelligen Bereich schwierig zu beurteilen ist

Jap, da kommt aber ne Menge Debug raus.
So siehts bei mir aus:

Code: Alles auswählen

RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x45
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x63
!!! 644 bytes skipped to get PS/PES sync!!! read: 64986 processed: 64986
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x02
!!! 303 bytes skipped to get PS/PES sync!!! read: 26902 processed: 26902
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0xb3
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x55
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x00
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x8f
!!! 409 bytes skipped to get PS/PES sync!!! read: 6508 processed: 6508
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x55
RDS-Error: wrong CRC # calc = b631 <> transmit = 7292
(RDS-MEC '46') -> RadiotextDecode - 17
RDS-Error: wrong CRC # calc = b991 <> transmit = d702
(RDS-MEC '42' not used -> End)
!!! 21 bytes skipped to get PS/PES sync!!! read: 64986 processed: 64986
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x36
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x0a
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x3c
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x00
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x00
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x08
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x4a
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0xaa
!!! 21 bytes skipped to get PS/PES sync!!! read: 64986 processed: 64986
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0xa8
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x10
!!! 1 bytes skipped to get PS/PES sync!!! read: 46396 processed: 46396
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x50
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x00
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x00
!!! 326 bytes skipped to get PS/PES sync!!! read: 14948 processed: 14948

Irgendwann kommt dann mal das, aber das RT-Symbol wird nur kurz gelb(wohl richtig?):
Achja, umschalten geht viel schneller, trotz debug.

Code: Alles auswählen

(RDS-MEC '30' not used -> End)
(RDS-MEC '30' not used -> End)
(RDS-MEC '30' not used -> End)
(RDS-MEC '30' not used -> End)
(RDS-MEC '0a') -> RadiotextDecode - 76
MEC=0x0a DSN=0x00 PSN=0x00 MEL=65 STATUS=0x01 MFL=69
Radiotext[1]: B5 aktuell - Das Informationsradio des Bayerischen Rundfunks
(RDS-MEC '46') -> RadiotextDecode - 17
(RDS-MEC '46') -> RadiotextDecode - 17
(RDS-MEC '42' not used -> End)
(RDS-MEC '42' not used -> End)
(RDS-MEC '30' not used -> End)
(RDS-MEC '30' not used -> End)

[seife]

Hm. Ja. Also das debug ist sehr verbose, das würde ich natürlich wieder leiser machen.

Die "this never happens"-Meldung sollte tatsächlich nie kommen, mal schauen, was da schiefgelaufen sein kann. (Wenn, dann sollte sie nur einmal kommen)

[rhabarber1848]

Fehler 1 habe ich so gefixt:

In die infoviewer.h eine Variable "bool rticon;"

Das Icon wird nur noch dann gelb, wenn Radiotext empfangen wird, so wie bisher.

committed:
http://article.gmane.org/gmane.comp.vid ... x.scm/1069
http://article.gmane.org/gmane.comp.vid ... x.scm/1070

[rhabarber1848]

schaut mal die CPU last ohne und mit dem Patch an, wenn radiotext aktiv ist

CVS-Neutrino hat 6-8% CPU-Last auf einem Radiotext-Sender,
wenn ein neuer Radiotext-Block reinkommt, sonst 1-2%.

Mit Deinem Patch schwankt Neutrino zwischen 40-80%,
das Umschalten geht dennoch flüssiger vonstatten.
Nach "patch -R $Dein_Patch && make neutrino" und
Neutrino-Neustart ist die CPU-Last sofort signifikant
niedriger. Ich habe zudem einiges an Debug-Code in
Deinem Patch deaktiviert, um die CPU-Last besser
vergleichen zu können.

[dbt]

Fehler 1 habe ich so gefixt:

In die infoviewer.h eine Variable "bool rticon;"

Das Icon wird nur noch dann gelb, wenn Radiotext empfangen wird, so wie bisher.

committed:
http://article.gmane.org/gmane.comp.vid ... x.scm/1069
http://article.gmane.org/gmane.comp.vid ... x.scm/1070

edit:
Hab das Ganze etwas überarbeitet.

[seife]

Ok, ich habe eine Idee woran das mit der CPU-Last liegen könnte. Moment.

[seife]

Sooo. radiotext-ringbuffer.diff

Das sollte wesentlich besser sein. Hoffentlich

[GetAway]

So geht's ca 3 Minuten bis es dann so wie unten weitergeht.
Nach dem Umschalten das gleiche.

Code: Alles auswählen

RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x4b
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x00
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x0f
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x92
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x44
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x59
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0xaa
!!! 21 bytes skipped to get PS/PES sync!!! read: 64906 processed: 64906
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0xac
!!! 15 bytes skipped to get PS/PES sync!!! read: 11952 processed: 11952
RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x0e
!!! 1 bytes skipped to get PS/PES sync!!! read: 1934 processed: 1934
RT pes_SyncBufferRead: ringbuffer empty (0 < 6)
RT pes_SyncBufferRead: ringbuffer empty (0 < 6)
RT pes_SyncBufferRead: ringbuffer empty (0 < 6)
RT pes_SyncBufferRead: ringbuffer empty (0 < 6)
RT pes_SyncBufferRead: ringbuffer empty (0 < 6)
RT pes_SyncBufferRead: ringbuffer empty (0 < 6)
RT pes_SyncBufferRead: ringbuffer empty (0 < 6)

Edit:
Nach Wechsel auf TV geht es munter so weiter.

Code: Alles auswählen

RT pes_SyncBufferRead: ringbuffer empty (0 < 6)
RT pes_SyncBufferRead: ringbuffer empty (5 < 6)
RT pes_SyncBufferRead: ringbuffer empty (0 < 6)
RT pes_SyncBufferRead: ringbuffer empty (5 < 6)
RT pes_SyncBufferRead: ringbuffer empty (0 < 6)
RT pes_SyncBufferRead: ringbuffer empty (5 < 6)

[seife]

Das "ringbuffer_empty" ist ne reine debug-Meldung. Allerdings ist es schon sehr seltsam, dass das noch nach dem Umschalten auf TV kommt, denn da sollte der Radiotext beendet und das Objekt gelöscht sein...

Anscheinend liefert der demux der TD einen ziemlich "sauberen" PES, während die dbox da noch irgendwas anderes reinpackt. Oder sich beim Auslesen anders verhält. Oder irgendwie sowas.

Egal, es schaut so aus, als müsste ich tatsächlich mal wieder ne dbox aus dem Schrank holen und anschliessen

[rhabarber1848]

Sooo. radiotext-ringbuffer.diff

Radiotext funktioniert zu Anfang noch und die CPU-Auslastung von
/bin/neutrino überschreitet selbst beim Empfang von Radiotext nie 3%.
Das sieht gut aus. Das RT-Icon bleibt nun nach dem erstmaligen Empfang
von Radiotext-Daten gelb, der Patch von dbt funktioniert gut.

Aber ... irgendwann wird kein Radiotext mehr angezeigt, obwohl das
RT-Icon gelb ist, d.h. ich schalte auf einen RT-Sender, das RT-Icon
wird gelb, aber es wird kein Radiotext angezeigt.
Tritt das bei Euch auch auf?

[dbt]

Das Icon zeigt dem Benutzer nur, dass der Sender Radiotext hat, also quasi fähig dazu ist und irgendwann Daten gefunden wurden. Vorher weiß man das ja nicht. Bei einem Sender wo keine Daten anliegen wird das also nicht vorkommen.
Wenn dann keine Daten angezeigt werden, dann liegen mit ziemlicher Sicherheit keine aktuellen Daten an, die zur Anzeige bereitstehen könnten. Man könnte sich natürlich auch sowas überlegen, dass das Icon blinkt wenn auf einem fähigen Sender gesucht, eigentlich gewartet, wird. Das wäre eine Möglichkeit, um den Benutzer das auch noch mitzuteilen.

[GetAway]

Eine weitere Möglichkeit wäre gelb für den Wartemodus und grün wenn Daten empfangen wurden.

[dbt]

Das vergrößerte Fenster habe ich grad committed.
Bis auf diese Sachen hier läuft das recht flüssig und die CPU-Last ist soweit ok, soweit ich das beurteilen kann.
Der reddelt sich aber hier einen ab, das müsste man noch irgendwie abfangen.

Code: Alles auswählen

RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0xb7

RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x00

RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x58

RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x14

!!! 268 bytes skipped to get PS/PES sync!!! read: 814 processed: 814

RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x00

!!! 391 bytes skipped to get PS/PES sync!!! read: 17851 processed: 17851

RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x70

RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x00

RT pes_SyncBufferRead: unsynced, ret = -1! (this never happens) ppes[3] = 0x06

!!! 1 bytes skipped to get PS/PES sync!!! read: 2894 processed: 2894

Weil sichs etwas mit dem letzten Stand gebissen hatte hier aktualisiert auf aktuellen CVS-Stand:
radiotext.cpp-radiotext.h-diff-2009-09-08-09-24-43.patch

[seife]

Ich weiss wo mein Denkfehler lag und wann das "this does never happen" auftritt. Aber ich kanns erst am Wochenende testen

Warum es allerdings auf der TD niemals auftritt ist mir ein Rätsel...

[liab]

Nach einem verlängerten Wochenende habe ich mal vorhin ein neues Image für die D-Box 2 gemacht. Die Icon Steuerung des Radiotextes mit der infoviewer.cpp,v 1.270 funktioniert. Das immer gelbe "RT" nach erstmaligen Textempfang sollte so bleiben. Hatte neulich schon für mich gedacht, daß die kurzzeitige gelbe Anzeige eigentlich Blödsinn ist, wer schaut schon bei Radio ständig hin!

Das Protokoll der noch nicht funktionierenden Aufnahme sieht so aus:

• Record channel_id: 44da4016f3e epg: 44da4016f3e3ff8, apids 0x0 mode 2
  fsk:0, Genre:0, Dauer: 235
  [stream2file]: ringbuffersize 8388608
  [stream2file] allocated ringbuffer size: 8388607
  [stream2file]: timeout reading from demux
  [stream2file]: pthreads exit code: -4, dir: '/mnt/film/filme', filename: 'WDR_4_
  ARD-Nachtexpress_Vom_S_dwestrundfunk_2009-09-10_022033' myfilename: '/mnt/film/f
  ilme'
  Record channel_id: 44da4016f3e epg: 0, apids 0x0 mode 2
  no response from sectionsd
  no response from sectionsd
  [stream2file] INFO: /mnt/film/filme/WDR_4_ARD-Nachtexpress_Vom_S_dwestrundfunk_2
  009-09-10_022033.xml already exists, not overwriting
  [stream2file]: ringbuffersize 8388608
  [stream2file] allocated ringbuffer size: 8388607
  [stream2file]: timeout reading from demux
  [stream2file]: pthreads exit code: -4, dir: '/mnt/film/filme', filename: 'WDR_4_
  ARD-Nachtexpress_Vom_S_dwestrundfunk_2009-09-10_022033' myfilename: '/mnt/film/f
  ilme'
  Record channel_id: 44da4016f3e epg: 0, apids 0x0 mode 2
  no response from sectionsd
  no response from sectionsd
  [stream2file] INFO: /mnt/film/filme/WDR_4_ARD-Nachtexpress_Vom_S_dwestrundfunk_2
  009-09-10_022033.xml already exists, not overwriting
  [stream2file]: ringbuffersize 8388608
  [stream2file] allocated ringbuffer size: 8388607
  [timerd] timer_wakeup = false; a.time: 0 now: 1252542063
  [timerd] not scheduling shutdown event
  Stop
  record time: 3
  [mi] saveXml: /mnt/film/filme/WDR_4_ARD-Nachtexpress_Vom_S_dwestrundfunk_2009-09
  -10_022033.xml
  saveFile:1082 saving TS movieinfo: WDR_4_ARD-Nachtexpress_Vom_S_dwestrundfunk_20
  09-09-10_022033.xml
  [audio.cpp:setSource:148] ioctl(fd, AUDIO_SELECT_SOURCE, source): Invalid argume
  nt
  [stream2file]: timeout reading from demux
  [stream2file]: pthreads exit code: -4, dir: '/mnt/film/filme', filename: 'WDR_4_
  ARD-Nachtexpress_Vom_S_dwestrundfunk_2009-09-10_022033' myfilename: '/mnt/film/f
  ilme'
  Stopping RT Thread

Die Meldung "Stopping RT Thread" kommt nach Beendigung der Aufnahme und anschließendem Zappen. Dann hängt die Box! Über die Konsole kann neutrino neu gestartet werden, dann geht die FB wieder.

[rhabarber1848]

Mit automatischer Abschaltung des Radiotextes bei Aufnahme kann man aber auch leben.

Bitte testen: EDIT: Patch ist im CVS

Aufnahmen funktionieren hier, ob Radiotext und Aufnahme gleichzeitig möglich sind, weiß ich nicht.
Der rezap ist nötig, da der Radiotext-Thread sonst nicht neugestartet wird.
Oder hat jemand noch eine andere Idee?

To-Do
Während der Aufnahme ist kein RT-Icon in der Infobar, es sollte stattdessen dunkelgrau sein.

[rhabarber1848]

Aber ... irgendwann wird kein Radiotext mehr angezeigt, obwohl das
RT-Icon gelb ist, d.h. ich schalte auf einen RT-Sender, das RT-Icon
wird gelb, aber es wird kein Radiotext angezeigt.
Tritt das bei Euch auch auf?

Ich konnte das Problem dadurch beheben, indem ich
in seifes Patch die Zeile

Code: Alles auswählen

+       usleep(250000); /* save CPU if nothing read */

geändert habe in

Code: Alles auswählen

+       usleep(10000); /* save CPU if nothing read */

CPU-Last bleibt bei 3% zum Zeitpunkt der Radiotext-Anzeige.