Jugendschutz im SportPortal!?!?

[jmittelst]

Ja, hab es heute beim experimentieren mit yjogols Webinterface die Box sogar mehrfach zum Halt bekommen. Ist wohl der Speicher vollgelaufen.
Aber sieht richtig gut aus. Wenn man den Speicherverbrauch etwas mindern könnte, wäre es schon dicht an Optimum.
cu
Jens

[Houdini]

Heisst das jetzt es gibt memory leaks?
oder einfach nur mehr speicherverbrauch?
Wie gibts du die memory info aus?

Houdini

[Metallica]

cat /proc/meminfo

[Houdini]

stimmt ich war zu blind
thanx

[Houdini]

So, jetzt mal ein inbound diff:
vielleicht kann mir mal jemand erklären wo der Speicher im anderen Zweig (if) freigegeben wird.

Houdini

Code: Alles auswählen

diff -ur -x CVS sectionsd.orig/sectionsd.cpp sectionsd/sectionsd.cpp
--- sectionsd.orig/sectionsd.cpp	2005-08-17 22:31:01.000000000 +0200
+++ sectionsd/sectionsd.cpp	2005-08-17 22:36:02.000000000 +0200
@@ -3671,6 +3671,10 @@
 					//dprintf("[eitThread] added %d events (end)\n",  eit.events().size());
 				} // if
 			} // if
+			else
+			{
+				delete[] buf;
+			}
 		} // for
 	} // try
 	catch (std::exception& e)

[kroki]

Hi all,

erstmal einen Dank an Houdini für die hervorragende Arbeit !!

Läuft schon hervorragend .......

Ich hab da ein kleines Problem festgestellt, wo ich nicht weis ob es direkt mit dem Patch zu tun hat :

Direktaufnahme (Features->Aufnahme Start) aus dem Portal geht nur bei Optionenskanälen die auf dem gleichen Transponder(ID 0003) wie das Portal liegen. Wenn ich die Option 2 (Feed DD auf TP:0011) versuche aufzunehmen schaltet er auf den TP:0011, aber nimmt dann SCI-Fi auf. Wenn ich dagegen einen Timer über die EPG-Daten erstelle, dann funktionierts.
In der timerd.conf steht die richtige Channel_ID drinnen. Ich versuche mich grad durch die Sourcen zu wühlen, aber bin noch nicht fündig geworden, vielleicht hat ja mal einer einen Tip, wo ich so ungefähr suchen sollte......

Gruß Kroki

[Houdini]

ich hätte da so folgenden Verdacht:
g_RemoteControl->current_channel_id gibt die Portal channelID zurück und nicht die option channelID, warum nicht eventinfo.channel_id benutzt wird weiss ich auch nicht.

Code: Alles auswählen

bool CNeutrinoApp::doGuiRecord(char * preselectedDir, bool addTimer)
{
	CTimerd::RecordingInfo eventinfo;
	bool refreshGui = false;
	if(CVCRControl::getInstance()->isDeviceRegistered())
	{
		if(recordingstatus == 1)
		{
			puts("[neutrino.cpp] executing " NEUTRINO_RECORDING_START_SCRIPT ".");
			if (system(NEUTRINO_RECORDING_START_SCRIPT) != 0)
			perror(NEUTRINO_RECORDING_START_SCRIPT "failed");
			CZapitClient::CCurrentServiceInfo si = g_Zapit->getCurrentServiceInfo();
			eventinfo.channel_id = CREATE_CHANNEL_ID_FROM_SERVICE_ORIGINALNETWORK_TRANSPORTSTREAM_ID(si.sid, si.onid, si.tsid);
			CEPGData		epgData;
			if (g_Sectionsd->getActualEPGServiceKey(g_RemoteControl->current_channel_id, &epgData ))
			{
				eventinfo.epgID = epgData.eventID;
				eventinfo.epg_starttime = epgData.epg_times.startzeit;
			}
			else
			{
				eventinfo.epgID = 0;
				eventinfo.epg_starttime = 0;
			}

[jmittelst]

Schade, das Dir niemand helfen will. Für mich sind die Codes hier eher verschlüsselt (soll heißen: ich versteh nix). Vielleicht schaut aber ja mal ein Source-Code-Versteher mal rein und hilft Dir etwas.
cu
Jens

[Zwen]

ich hätte da so folgenden Verdacht:
g_RemoteControl->current_channel_id gibt die Portal channelID zurück und nicht die option channelID, warum nicht eventinfo.channel_id benutzt wird weiss ich auch nicht.

Mit g_RemoteControl->current_channel_id werden doch nur die EPGInfos geholt - ist glaub ich Absicht dass die EPG-Infos vom Portal kommen.
Entscheidend ist in diesem fall ja eventinfo.channel_id, die wird über dieses komische Konstrukt CREATE_CHANNEL_ID_FROM_SERVICE_ORIGINALNETWORK_TRANSPORTSTREAM_ID ....
erzeugt. Da müsste man mal forschen, ob das die richtige channelId ist.
Bei der AUfnahme wird später dann nämlich abgefragt:

Code: Alles auswählen

		if(g_Zapit->getCurrentServiceID() != channel_id)	// und momentan noch nicht getuned ist
		{
			g_Zapit->zapTo_serviceID(channel_id);		// dann umschalten
		}

Da er bei der Aufnahme zappt, muss getCurrentServiceID() und CREATE_ID_blabla ja unterschiedlich sein. Und da falsch gezapt wird, stimmt dieses CREATE_CHANNEL_blabla wohl nicht. Warum nicht auch beim setzten der eventinfo in neutrino.cpp die channel_id auf getCurrentServiceID() setzen ?
Oder auf 0, dann wird nämlich nie nicht gezappt...

@jmittelst: nicht so ungeduldig, nicht jeder hat die Zeit sich das forum stündlich reinzuziehen ;-)
Zwen

[Houdini]

meine eigentliche Frage um die es ging war folgende, da es wahrscheinlich noch ein memory leak in meiner letzten version gab, hab ich nachgeschaut und anhand dem Vergleich mit dem EIT thread folgenden diff gemacht. Ich habe aber nicht gefunden wo der Speicher im anderen Zweig freigegeben wird (genau wie im EIT Thread).

Zu diesem Diff hat sich noch niemand geäußert obs was gebracht hat, bei mir siehts aber besser aus.

Die Sache mit der channelid wollte sich Kroki anschauen, ich hab da erst mal einen Tip gegeben, aber ich schau dort auch mal nach
Houdini

Code: Alles auswählen

diff -ur -x CVS sectionsd.orig/sectionsd.cpp sectionsd/sectionsd.cpp
--- sectionsd.orig/sectionsd.cpp   2005-08-17 22:31:01.000000000 +0200
+++ sectionsd/sectionsd.cpp   2005-08-17 22:36:02.000000000 +0200
@@ -3671,6 +3671,10 @@
                //dprintf("[eitThread] added %d events (end)\n",  eit.events().size());
             } // if
          } // if
+         else
+         {
+            delete[] buf;
+         }
       } // for
    } // try
    catch (std::exception& e)

[JtG-Riker]

meine eigentliche Frage um die es ging war folgende, da es wahrscheinlich noch ein memory leak in meiner letzten version gab, hab ich nachgeschaut und anhand dem Vergleich mit dem EIT thread folgenden diff gemacht. Ich habe aber nicht gefunden wo der Speicher im anderen Zweig freigegeben wird (genau wie im EIT Thread).

Zu diesem Diff hat sich noch niemand geäußert obs was gebracht hat, bei mir siehts aber besser aus.

Die Sache mit der channelid wollte sich Kroki anschauen, ich hab da erst mal einen Tip gegeben, aber ich schau dort auch mal nach
Houdini

Code: Alles auswählen

diff -ur -x CVS sectionsd.orig/sectionsd.cpp sectionsd/sectionsd.cpp
--- sectionsd.orig/sectionsd.cpp   2005-08-17 22:31:01.000000000 +0200
+++ sectionsd/sectionsd.cpp   2005-08-17 22:36:02.000000000 +0200
@@ -3671,6 +3671,10 @@
                //dprintf("[eitThread] added %d events (end)\n",  eit.events().size());
             } // if
          } // if
+         else
+         {
+            delete[] buf;
+         }
       } // for
    } // try
    catch (std::exception& e)

Ich guck mir das gleich mal an, und jmittelst testet es auch gleich mal, hab das eben mal eingebaut.

Gruß Riker

[Zwen]

meine eigentliche Frage um die es ging war folgende, da es wahrscheinlich noch ein memory leak in meiner letzten version gab, hab ich nachgeschaut und anhand dem Vergleich mit dem EIT thread folgenden diff gemacht. Ich habe aber nicht gefunden wo der Speicher im anderen Zweig freigegeben wird (genau wie im EIT Thread).

Dann helf ich dir mal
Der Speicher wird erstmal nicht freigegeben. Weil in diesem Zweig das Event ja gespeichert wird. Erst wenn das Event "veraltet" wird es gelöscht und damit auch der Speicher...
Technisch:
Der Pointer auf den Speicher wird an den Konstruktor von SIsection übergeben. Das SIsection object übernimmt sozusagen die ownership für diesen Speicher. Wird das SIsection object zerstört, wird in dessen Destruktor der Speicher freigegeben...

Zwen

[Houdini]

Danke Zwen, jetzt ists klar, ist mir aber bei meiner Implementation nicht aufgefallen, ich werde mir das nochmal reinziehen.

Happy Testing

[Houdini]

Wie schon vermutet ist Krokis Problem hier zu fixen:
Beim Sportportal ist die aktuelle channelID die vom Portal und nicht vom Optionskanal, also die aktuelle gibts dann von zapit.
Hab jetzt kein diff gemacht

Houdini

Code: Alles auswählen

bool CNeutrinoApp::doGuiRecord(char * preselectedDir, bool addTimer)
{
	CTimerd::RecordingInfo eventinfo;
	bool refreshGui = false;
	if(CVCRControl::getInstance()->isDeviceRegistered())
	{
		if(recordingstatus == 1)
		{
			puts("[neutrino.cpp] executing " NEUTRINO_RECORDING_START_SCRIPT ".");
			if (system(NEUTRINO_RECORDING_START_SCRIPT) != 0)
			perror(NEUTRINO_RECORDING_START_SCRIPT "failed");
			CZapitClient::CCurrentServiceInfo si = g_Zapit->getCurrentServiceInfo();
			eventinfo.channel_id = CREATE_CHANNEL_ID_FROM_SERVICE_ORIGINALNETWORK_TRANSPORTSTREAM_ID(si.sid, si.onid, si.tsid);
			CEPGData		epgData;
//			if (g_Sectionsd->getActualEPGServiceKey(g_RemoteControl->current_channel_id, &epgData ))
			if (g_Sectionsd->getActualEPGServiceKey(eventinfo.channel_id , &epgData ))
			{

[kroki]

Hi,
das ist nicht das Problem, weil die Channel-ID richtig übergeben wird.
Beim Timer und VCR kommen jedenfalls die richtigen Werte an !

Es wird auch nicht gezappt, so wie es aussieht werden die falschen Video/Audio-Pid es an den Demuxer gegeben......... Da bin ich aber noch am suchen.

Gruß Kroki

[AudioSlyer]

Nach dem Drücken des ? bekommt man nicht mit Rechts/Links die nächsten EPG-Event anzeigt.

[JtG-Riker]

Den Fix den Metallica eingecheckt hat geht leider nicht, wenn man OK drückt wird kein EPG mehr angezeigt auf den Feeds.

Gruß Riker

[Nico 77]

Habe jetzt mal einen aktuellen JTG snapshot drauf gemacht, leider macht der neue sectionsd oder zapit ständig Probleme und schmiert beim EPG einlesen knadenlos ab.

Code: Alles auswählen

PES, queue 0 normal.
[camd] starting onid 0085 sid 0008
[controld] VIDEO_EVENT_SIZE_CHANGED 544x576 (4:3 -> 4:3)
descramble onid: 0085 sid: 0008 status: 8484
[basicsocket] receive timed out.
[CBasicClient] receive failed: /tmp/sectionsd.sock
[basicsocket] receive timed out.
[CBasicClient] receive failed: /tmp/zapit.sock
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
[basicsocket] send_data: Broken pipe
usw...

Die Box ist hierbei nicht mehr bedienbar und es hilft nur noch der reboot bis es dann irgendwann wieder auftritt.

[jmittelst]

Hmm - ich hatte bislang nur Probleme mit dem alternativen nhttpd - hast Du auch irgendwas auf der Box laufen, was nicht dem Standard von Neutrino entspricht? Bei mir läuft der Snap vom 16.8. seit dem 17.8. problemlos (von dem nhttpd-Problem mal abgesehen).
cu
Jens

[Nico 77]

Hmm - ich hatte bislang nur Probleme mit dem alternativen nhttpd - hast Du auch irgendwas auf der Box laufen, was nicht dem Standard von Neutrino entspricht? Bei mir läuft der Snap vom 16.8. seit dem 17.8. problemlos (von dem nhttpd-Problem mal abgesehen).
cu
Jens

Jo, eine andere camd2 sonst nichts.

Die Sachlage verhält sich ganz einfach so:
Ich habe Boxen mit meinen selbsterstellten Images und wenn da was mucken macht schliesse ich die Box mit JTG Image an und mach einen aktuellen shot drauf. Gepatcht ist das nichts.

So wie es aussieht sobald die epg Infos einen Tick zu spät kommen schmiert alles ab.
Passiert hauptsächlich auf Sender die vom Empfang her hier nicht ganz so stark sind.

[jmittelst]

Hmm - und ich dachte immer, das mein Empfang hier schlecht ist ...
cu
Jens

[Nico 77]

Gibts noch irgendwo den snap vom 15.08. ?

[jmittelst]

Schau mal da rein: http://www.jackthegrabber.de/viewtopic. ... 9762#69762
cu
Jens

[Nico 77]

So runtergeladen geflasht, der snap vom 15.08. macht 0 Probleme.
Snap vom 16.08. wieder geflasht sectionsd und zapit stürzen ab.
15.08. wieder geflasht, läuft bleibt da erstmal drauf.

Also hat sich am 16.08. ein Bug eingeschlichen.

Wenn jemand Ideen hat, immer her damit, kann gerne testen(source oder binary egal).

[JtG-Riker]

So runtergeladen geflasht, der snap vom 15.08. macht 0 Probleme.
Snap vom 16.08. wieder geflasht sectionsd und zapit stürzen ab.
15.08. wieder geflasht, läuft bleibt da erstmal drauf.

Also hat sich am 16.08. ein Bug eingeschlichen.

Wenn jemand Ideen hat, immer her damit, kann gerne testen(source oder binary egal).

Ich mach gleich mal einen aktuellen Snap, allerdings hauts bei mir auch noch ab und zu die Box weg mit dem aktuellen sectionsd.

Na wird schon noch werden, aber testen kann man es ja mal.

Riker