rass und radiotext

[liab]

Deshalb schlage ich folgenden Patch zum Testen vor:

Habe das mal in ein eben erstelltes Image gebaut. Merke mit und ohne Patch keinen Unterschied.

Habe leider immer noch das Problem, daß bei einigen Sendern (WDR 4) RT manchmal erst nach 10 Minuten und später kommt - dann aber regelmäßig. Nach Zappen ist die Freude wieder vorbei. Bei YOU FM kommt RT fast immer sofort zusammen mit dem gelben Icon.

Verwende ich radiotext.cpp v 1.3 mit der dazugehörenden radiotext.h ist diesbezüglich alles ok. Ab v 1.4 beginnt der Ärger. Einer der wesentlichen Unterschiede zwischen v 1.3 und danach ist der Variablentyp (unsigned char *data) und bei v 1.4 und "char *data". Kann das damit zusammenhängen?

[seife]

Einer der wesentlichen Unterschiede zwischen v 1.3 und danach ist der Variablentyp (unsigned char *data) und bei v 1.4 und "char *data". Kann das damit zusammenhängen?

Das ist einer der unwesentlichen Unterschiede ;-)
Ausserdem ist auf dem Target char sowieso unsigned.

Also: nein.

[Gaucho316]

Deshalb schlage ich folgenden Patch zum Testen vor:

Habe das mal in ein eben erstelltes Image gebaut. Merke mit und ohne Patch keinen Unterschied.

Ich habe den Patch jetzt auch testen können. Bei mir scheint es zu funktionieren. Folgendes habe ich mit und ohne Patch gemacht: Box gestartet -> auf "B5 aktuell" geschaltet -> auf den Radiotext gewartet -> in Radiotextüberschriftzeile steht "Radiotext :" -> Technische Informationen aufgerufen und wieder geschlossen -> Infobar aufgerufen -> auf den Radiotext gewartet. Ohne den Patch steht dann in der Radiotextüberschriftzeile "Radiotext einige wirre Sonderzeichen:" und mit Patch "Radiotext :". Das alles kann natürlich auch purer Zufall sein.

[GetAway]

Ich hatte schon mal bemerkt das der Radiotextthread beim flashen beendet werden sollte,
gleiches sollte gelten, wenn man den Movieplayer aus dem Radio-Modus heraus startet.

[rhabarber1848]

Ich hatte schon mal bemerkt das der Radiotextthread beim flashen beendet werden sollte

Ich habe das nicht vergessen Bitte testet diesen Patch:
EDIT: Patch ist im CVS

[GetAway]

Könnte auch ein Racecondition sein.
Die Reihenfolge ist auf jedenfall merkwürdig, Dabei ist es egal ob
ich über den MP oder den Filebrowser starte.

Code: Alles auswählen

[mp] ... reader thread terminated
[mp] leaving player loop ...
[mp] ... checking for another playlist item
[mp] mp_playFileThread terminated
[mb] start MovieBrowser
[mb]->Paint
[mb] browser info
[mb] saveSettings
[frontend] uncommitted_switch_mode 0 auto_fec 0
[zapit] tuned frequency does not match request. difference: 20142
[movieplayer.cpp] executing /var/tuxbox/config/movieplayer.end.
Stopping RT Thread
RT RadioTextThread: exit
19:48:23.924 eit_set_update_filter, servicekey = 0x44500016ef4, current version 31
in RadioTextThread fd = 20
Thread Setting PID 0x8d

[rhabarber1848]

Könnte auch ein Racecondition sein.

Am Movieplayer schraube ich jetzt gerade erst rum.

[liab]

Deshalb schlage ich folgenden Patch zum Testen vor:

Habe das mal in ein eben erstelltes Image gebaut. Merke mit und ohne Patch keinen Unterschied.

Ich habe den Patch jetzt auch testen können. Bei mir scheint es zu funktionieren.

Gaucho316 hat Recht. Die oberste Zeile macht in der Tat ohne den Patch Fehler. Besonders nach der von Gaucho316 beschriebenen Prozedur.

[liab]

Ich hatte schon mal bemerkt das der Radiotextthread beim flashen beendet werden sollte,
gleiches sollte gelten, wenn man den Movieplayer aus dem Radio-Modus heraus startet.

Mal eine Frage, könnte es sein, daß RT, Movieplayer, Rekorder usw. den gleichen Ringbuffer verwenden? Wenn ja, wäre es nicht verwunderlich, daß Aufnahme und RT nicht gleichzeitig gehen.

Wenn man aus RT heraus den Movieplayer startet sind nach Beenden des MP bei RT zunächst in der obersten Zeile Fehlzeichen.

[rhabarber1848]

Wenn man aus RT heraus den Movieplayer startet sind nach Beenden des MP bei RT zunächst in der obersten Zeile Fehlzeichen.

Das liegt daran, dass der RT-Thread beim Start des MP nicht beendet wird.
Ich arbeite daran.

[rhabarber1848]

Deshalb schlage ich folgenden Patch zum Testen vor:

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

[rhabarber1848]

Ich hatte schon mal bemerkt das der Radiotextthread beim flashen beendet werden sollte

Ich habe das nicht vergessen

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

[rhabarber1848]

gleiches sollte gelten, wenn man den Movieplayer aus dem Radio-Modus heraus startet.

Bitte Patch testen: EDIT: Patch ist im CVS

[rhabarber1848]

gleiches sollte gelten, wenn man den Movieplayer aus dem Radio-Modus heraus startet.

Bitte Patch testen: EDIT: Patch ist im CVS

aktualisiert, bitte nochmal runterladen.

[liab]

gleiches sollte gelten, wenn man den Movieplayer aus dem Radio-Modus heraus startet.

Bitte Patch testen: radiotext_movieplayer.diff

aktualisiert, bitte nochmal runterladen.

Stopping RT Thread
RT RadioTextThread: exit

kommt jetzt wenn MP, AP, Bildbetrachter, Esound oder Internet Radio gestartet werden. Die Grafik scheint jetzt frei von Anzeigefehlern zu sein. Nur leider immer noch das alte Prob, daß bei einigen Sendern RT manchmal erst "zünden " muß.

[dwilx]

Ich hatte schon mal bemerkt das der Radiotextthread beim flashen beendet werden sollte

Ich habe das nicht vergessen

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

Wäre es nicht besser neutrino um mode_flashing zu erweitern

Code: Alles auswählen

enum
		{
			mode_unknown = -1,
			mode_tv = 1,
			mode_radio = 2,
			mode_scart = 3,
			mode_standby = 4,
			mode_audio = 5,
			mode_pic = 6,
			mode_ts = 7,
			mode_mask = 0xFF,
			norezap = 0x100
		};

So scheint mir das zu umständlich zu sein. Wenn das zu- u. abschalten der Threads in der Radiotext-Klasse selbst überwacht wird, kann man sich solche Patches in den einzelnen Apps, bei denen RT abgeschaltet werden soll in Zukunft sparen. Bei einigen Apps wie z.B. Streaminfos, die keinen eigenen Mode mitbringen, ist es wahrscheinlich sinnvoll einen Thread vor Ort lahm zu legen und beim Beenden wieder herzustellen, aber wenn es die Auswahl an übergebenen Modi hergibt, müsste das mit der Selbstüberwachung doch wesentlich handlicher sein oder liege ich hier falsch.

[rhabarber1848]

Wäre es nicht besser neutrino um mode_flashing zu erweitern

Da nach dem Flashen der RT-Thread nicht wieder eingeschaltet
werden muss, halte ich das nicht für notwendig.

Wenn das zu- u. abschalten der Threads in der Radiotext-Klasse selbst überwacht wird, kann man sich solche Patches in den einzelnen Apps, bei denen RT abgeschaltet werden soll in Zukunft sparen

Das habe ich auch vor, um den o.g. Patch für Movieplayer & Co.
kleiner zu machen. Bis dahin ist er ein proof-of-concept.
Zudem vermute ich, dass irgendwo noch ein

Code: Alles auswählen

g_Radiotext->setPid(g_RemoteControl->current_PIDs.APIDs[g_RemoteControl->current_PIDs.PIDs.selected_apid].pid);

fehlt, was die teilweise langen Wartezeiten auf Radiotext
erklären könnte, das muss ich aber noch debuggen.

[rhabarber1848]

Stopping RT Thread
RT RadioTextThread: exit

kommt jetzt wenn MP, AP, Bildbetrachter, Esound oder Internet Radio gestartet werden.

und RT wird nach dem Zurückschalten in den Radiomodus wieder gestartet?

[dwilx]

Da nach dem Flashen der RT-Thread nicht wieder eingeschaltet
werden muss, halte ich das nicht für notwendig.

Das ist klar, aber ich meine das ja auch mehr allgemein für alle ähnlichen Fälle, aber wenn du schon drüber bist, ist das ok.

[rhabarber1848]

kann man sich solche Patches in den einzelnen Apps, bei denen RT abgeschaltet werden soll in Zukunft sparen.

Es geht sogar noch einfacher: EDIT: Patch ist im CVS

In neutrino.cpp reicht ein "g_Radiotext->setPid", um dem
RT-Thread die richtigen Einstellungen mitzugeben.
Der Patch für pictureviewer.cpp ist analog zu den anderen
Playern. Der Patch in vcrcontrol.cpp ist eine Verbesserung
zu meinem früheren Patch, ein reZap ist nicht nötig,
g_Radiotext->setPid reicht.

[GetAway]

@rhabarber1848

In neutrino.cpp hab ich nochmal einen draufgesetzt, um 3x den gleichen Code zu vermeiden.
radiotext_movieplayer-2.diff

[liab]

Stopping RT Thread
RT RadioTextThread: exit

kommt jetzt wenn MP, AP, Bildbetrachter, Esound oder Internet Radio gestartet werden.

und RT wird nach dem Zurückschalten in den Radiomodus wieder gestartet?

Ja, RT wird nach dem Zurückschalten wieder gestartet.

[rhabarber1848]

@rhabarber1848

In neutrino.cpp hab ich nochmal einen draufgesetzt, um 3x den gleichen Code zu vermeiden.
radiotext_movieplayer-2.diff

danke, committed:
http://article.gmane.org/gmane.comp.vid ... x.scm/1183
http://article.gmane.org/gmane.comp.vid ... x.scm/1184
http://article.gmane.org/gmane.comp.vid ... x.scm/1185

[GetAway]

@rhabarber1848

Da ist mir vorhin beim copy&paste was durchgegangen:
LastMode == mode_radio ist an der Stelle überflüssig, sogar falsch. Den
gibts ja erst, wenn man den RadioModus mindestens 1x verlassen hat.

Code: Alles auswählen

Index: apps/tuxbox/neutrino/src/neutrino.cpp
===================================================================
RCS file: /cvs/tuxbox/apps/tuxbox/neutrino/src/neutrino.cpp,v
retrieving revision 1.982
diff -U3 -r1.982 neutrino.cpp
--- a/apps/tuxbox/neutrino/src/neutrino.cpp	29 Sep 2009 14:53:27 -0000	1.982
+++ b/apps/tuxbox/neutrino/src/neutrino.cpp	29 Sep 2009 17:39:19 -0000
@@ -3209,7 +3209,7 @@
 #ifdef ENABLE_RADIOTEXT
 			if((data & mode_mask) != mode_radio)
 			{
-				if (lastMode == mode_radio && g_settings.radiotext_enable && g_Radiotext != NULL)
+				if (g_settings.radiotext_enable && g_Radiotext != NULL)
 				{
 					delete g_Radiotext;
 					g_Radiotext = NULL;

[seife]

Und die Abfage nur als

Code: Alles auswählen

    if (g_Radiotext)
    {
        delete...
        ...
    }

Würde IMHO auch reichen, denn wenn g_settings.radiotext_enable nicht true ist, kann g_Radiotext nie != NULL sein.