Neutrino lahmt beim Bouquet umschalten!

[Nico 77]

Ist es noch keinem aufgefallen das Neutrino mit neusten CVS lahmt beim umschalten sobald der EPG ziemlich auf jedem Sender geladen wurde?
Ich habe vorher den Stand vom 09.02.06 genutzt da tritt das Prob noch nicht auf.

Jedesmal wenn man die Bouquets mit OK Taste aufruft hat Neutrino eine verweilzeit und die setzt sich mit jedem Bouquetumschalten fort.

[morgoth]

Kann ich nur zustimmen. Ich hatte ein CVS-Stand vom 17.03 und da ging das Umschalten von Bouquets noch schnell (auch nach geladenen EPG-Daten). Dann habe ich ein Image vom 04.04 getestet und da war die Bouquet-Umschaltung nach geladenem EPG schon langsam. Interessant fand ich, dass wenn ich den 17.03 Stand nehme und dann das enthaltene neutrino binary in /bin durch das vom 04.04 ersetze dann lahmt Neutrino nicht. Also müssen andere Änderungen dafür zuständig sein.

[Nico 77]

Also hier liegt das Problem am sectionsd, genau genommen am letzten Arzka Patch.
Hast du mal einen alten sectionsd reinkopiert und geschaut?

http://cvs.tuxbox-cvs.sourceforge.net/l ... 00145.html
http://cvs.tuxbox-cvs.sourceforge.net/l ... 00146.html

@Arzka
Kannst du da nochmal reinschauen, wenn du nämlich ein paar Sat's nutzt schläft Neutrino gänzlich ein und ein wechsel vom einem Bouquet zum anderen geht quasi nur noch im 20 Sekunden takt.

Mal ganz davon abgesehen wofür ist der Patch eigentlich?
Um z.b. bei Taquilla den EPG in Deutsch anzuzeigen oder wie muss man das verstehen?

Kann man den Patch mit einer Zeile abschalten ohne das man ihn komplett ausdokumentieren muss?

[JtG-Riker]

Kann ich auch bestätigen, das lahmt sogar auf ner Kabelbox total, wenn man OK drückt geht die Liste mit verzögerung auf.

Wär super wenn man das wieder wegbekommt *g*


Riker

[zexma]

Kann die Änderungen am sectionsd nicht mal ein Berufener im cvs reverten?
Warum werden solche Änderungen überhaupt in letzter Zeit einfach so kommentarlos eingecheckt?
Mir scheint das Diff bezieht sich hierauf...
http://forum.tuxbox-cvs.sourceforge.net ... highlight=

[Nirvana]

Reverten finde ich zu hart. Immerhin macht mal jemand was und ich finde den Beitrag durchaus wertvoll. Vielleicht fragt ihr arzka einfach höflich per PM, ob er das Problem kennt und behebn kann. Mir hat er innerhalb von 6h geholfen, meinen EPG speichern Patch anzupassen.

[mb405]

reverten finde ich auch den falschen weg.
ich glaube, im epg-language von artzka(die erste version des patches) konnte man die bevorzugte sprache irgendwie einstellen. also so ne art vorzugssprache.

[zexma]

Vielleicht fragt ihr arzka einfach höflich per PM, ob er das Problem kennt und behebn kann.

Done.

[Bimmel]

ich glaube, im epg-language von artzka(die erste version des patches) konnte man die bevorzugte sprache irgendwie einstellen. also so ne art vorzugssprache.

#define LANGUAGEFILE "/var/tuxbox/config/epglanguages.conf"

pthread_mutex_lock(&languages_lock);
std::ifstream file(LANGUAGEFILE);
std::string word;
CSectionsdClient::SIlanguageMode_t tmpMode = CSectionsdClient::ALL;
std::vector<std::string> tmpLang;

if (!(file >> word)) goto error;
if (word == "FIRST_FIRST") {
tmpMode = CSectionsdClient::FIRST_FIRST;
} else if (word == "FIRST_ALL") {
tmpMode = CSectionsdClient::FIRST_ALL;
} else if (word == "ALL_FIRST") {
tmpMode = CSectionsdClient::ALL_FIRST;
} else if (word == "ALL_ALL") {
tmpMode = CSectionsdClient::ALL_ALL;
}

echo FIRST_FIRST > /var/tuxbox/config/epglanguages.conf
Nur was FIRST_FIRST , FIRST_ALL ,ALL_FIRST oder ALL_ALL ist ?

ps: Ich bin für reverten bis zu 12 Nov 2001 .

[mb405]

danke dir Bimmel
eben das, was first zeugs bedeutet gehört als readme mit ins cvs. und die conf gehört dort eigentlich auch rein. oder ?
also bei mir geht manchmal das zappen über die bouquets wunderbar wie früher, und dann wieder mal lahm.

ps. lasst das drin im cvs. nur artzka sollte sich dazu mal äussern.

[arzka]

Done.

Sorry for writing in english here in german forum, but my german is too bad. Now I read this discussion using babelfish and its translations are not so perfect
If I understood correctly my patch causes delay after you press OK and before list of channels appears to the screen?

In my box I haven't noticed that problem and my patch have been in use in dozens of boxes here in Finland since my first version (something about half year now) and they haven't reported this.

So what is different between Finland and Germany? Maybe you have longer texts in EPG? I don't know. Only problem I can imagine is that originally sectionsd stored data in the string every languages simply concatenated and my patch stores the data in the map<> and it may use little more memory.

I don't believe that the memory usage difference is significant but I cannot imagine any other reason. Anyone have any other theory what may cause the problem.

[zexma]

Done.

If I understood correctly my patch causes delay after you press OK and before list of channels appears to the screen?

No, not exaktly. It is not the list of channels itself that delays but after a channel-list (e.g. providerA) is still listed and you wanna switch in between via <-|-> to an other channel-list (e.g. providerB) and so on.

I don't believe that the memory usage difference is significant but I cannot imagine any other reason. Anyone have any other theory what may cause the problem.

As posted above from Nico77 the issue gets worse if much EPG-data is collected. So at my point of view it certainly seems to be an increased memory loading. But in fact i've got no evidences about it.

[arzka]

Anyone have any other theory what may cause the problem.

Now I got one idea. Maybe system runs out of memory even before my patch. But we don't have swap partitions so user allocated memory cannot swapped out. Only possibility is to swap out pages what contains program.

Now I am using setter and getter functions (I don't know if those can swapped out or not) My getter function uses SIlanguage::filter() what is static function and it can be swapped out.

So the reason may be the fact that before data was accessible without memory swapping, but now that filter() function must get swapped in before data is accessible.

Of course those getters can be removed but it is ugly solution. It will make code harder to maintain. More elegant solution should be that someone should analyze how much memory is used and where it is used. Then we can optimize memory usage.

At least one place where we can save the memory is Menu system in Neutrino, currently there are many manu objects created in the ram even if those menu events haven't never used.

(And I need to rewrite that menu system any way since the current frame buffer stuff do not support my plans to implement a subtitling)

PS. Can someone do the command "cat /proc/<sectionsd PID>/status" before and after (delayed) bouquet change.

[morgoth]

Wie es aussieht wurde der EPG-Language-Support am 26.03.2006 (kurz vor Ende der Tagesschau ) eingescheckt. Das würde sich mit meinen Beobachungen decken.
Ich bin dafür, dass dieses "Feature" über die Konfig abschalbar gemacht wird. Reverten finde ich zu hart, da dort viel Arbeit inverstiert wurde.
---
The way I see it the epg-language support was checked in on March 26, 2006 just before 20.15. This would explain my experiences with images of March 17th and April 4th.
In my opinion, the usage of this new feature should be configurable. I don't think reverting changes is the right way to go since a lot of work has been invested in this feature.

[arzka]

In my opinion, the usage of this new feature should be configurable.

It is configurable. I added few new messages to sectionsdclient and my new feature can be configured using those. I just haven't any menu-entry in the neutrinos user interface.

--
Arzka

[morgoth]

what exactly do you mean with sectionsdclient? Is this a new binary? If so, my image does not include this.
Could you explain the configuration a bit or a link where it is explained?
Is it possible to turn off the language support through this configuration?
Providing a neutrino menu to configure things is not so important to me as long as I know where to change things.

[arzka]

what exactly do you mean with sectionsdclient? Is this a new binary?

It is a library what neutrino uses for communicating with sectionsd.

--
Arzka

[morgoth]

I added few new messages to sectionsdclient and my new feature can be configured using those.

I guess I'm a bit slow understanding the configurability of this feature through messages to the sectionsdclient library. How does one send messages to a library?

[Nirvana]

http://cvs.tuxbox-cvs.sourceforge.net/c ... nsdclient/

[morgoth]

Danke Nirvana, es wird ja immer Benutzerfreundlicher hier. So weit war ich auch schon. Aber die besagte Konfiguration der Bibliothek ist mir aus den CVS-Sources nicht ersichtlich.
---
So I take it there is no decent documentation of this feature? I really I'm trying to understand this feature but looking at the feedback I'm getting support is just not a high priority. I hope you and your 12 other boxes in Finnland enjoy this new feature.

[arzka]

So I take it there is no decent documentation of this feature?

I said that I added new messages, not those client functions. Writing those functions is trivial 15 minute task, but I haven't it since I don't know what is good API. Should those functions use a vector as parameter or is some other structure better. That can be known better when configuration menus are .

You can get documentation about those new messages at the end of the sectionsdMsg.h in the sectionsdclient directory. Those messages are documented using exactly same format what was used in another messages as well.

I will make those few functions today if you will be more happy then. But IMO it should be more usefull first to try to understand why bouquet changes are so slow that configuration thing do not make it faster.

PS. While there is no menu entry for configuring this you can configure it manually by editing the file /var/tuxbox/config/epglanguages.conf. That file is very simple and you can found its description from page http://www.hyper.fi/dbox2/sectionsd/.

If that file is missing sectionsd should work almost same way what it was before my modifications (only differense: previously languages were returned more or less random order, now they are returned alphabetically ordered by language code) - every available languages are sent.

[morgoth]

Thanks for the information.
I think we misunderstood each other. When I was talking about configurability of the feature I was referring to an on/off switch since I am having these delays posted earlier.
If I understood it correctly I can configure what languages should be shown.
I can play around with the settings in epglanguages.conf and see how performance is affected.
My main concern is performance and thought through configuration (less functionality but better perfomance) to improve things. Since performance issues first appeared with this feature.

If that file is missing sectionsd should work almost same way what it was before my modifications (only differense: previously languages were returned more or less random order, now they are returned alphabetically ordered by language code) - every available languages are sent.

This is unfortunately not the case. The key word is almost.

[arzka]

When I was talking about configurability of the feature I was referring to an on/off switch since I am having these delays posted earlier.

Technically differences between two versions are:
* Storing the information
Old

Code: Alles auswählen

std::string Text;
Text += "Good evening"
Text += "Guten Abend";
Text += "Hyvää iltaa";

new

Code: Alles auswählen

std::map<std::string, std::string> Text;
Text["eng"] = "Good Evening";
Text["deu"] = "Guten Abend";
Text["fin"] = "Hyvää iltaa";

* And how data is accessed elsewhere
Old

Code: Alles auswählen

event.Text = "foobar";
PrintTextToSomewhere(event.Text);

New

Code: Alles auswählen

event.setText("foobar");
PrintTextToSomewhere(event.getText());

As you can see the actual modifications are quite small and that data storage model cannot get disabled at runtime.

I still think that the problem is that the SIevent::getText() (or SIlanguage::filter() used by getText()) is swapped out.

[morgoth]

So strings are now stored in maps according to language instead of concatenation. To be honest, I've never encountered EPG-Infos with more than one language in Germany (astra, eutelsat or cable). Maybe these maps are allocating too much memory as opposed to the earlier strings and it is just not getting filled around here.

[arzka]

To be honest, I've never encountered EPG-Infos with more than one language in Germany (astra, eutelsat or cable).

Here in Finland there are five languages in TV1000 (example screenshot taken from tv1000 nordic can be found on my web page mentioned above), four languages in Canal+ and two languages in national Yle channels.