Sectionsd nicht DVB-konform

[Nirvana]

Der Sommer nähert sich dem Ende - Zeit mal wieder eine Grundsatzdebatte anzuschieben.

Ich bin zu der Überzeugung gekommen, dass viele der Probleme, die der sectionsd im Moment noch hat, sich dadurch lösen ließen ihn DVB-konform zu machen.

Dazu erst einmal für die, die es nicht wissen die Erklärung, worin die Nicht-Konformität besteht:
Die DVB-SI Daten, also EPG, Senderliste, Bouquetliste, Transponderliste usw, werden auf definierten PIDs in Tables übertragen. Z.B. kommt der EPG auf PID 0x12 in den Tables 0x4e-0x60. Ist eine Table zu groß, wird sie in mehrere Sections unterteilt. Diese Sections erhalten Nummern wie 0/2, 1/2, 2/2. Das Dumme ist, der sectionsd kennt nur die sections (deshalb der Name) aber keine Tables.
Deshalb läuft er grob gesagt so:
Lese section - werte section aus - lese section - werte section aus - schlafe - wache auf - lese section....
Dem sectionsd ist also nie richtig klar, welche sections er schon behandelt hat und ob es neue Daten in den sections gibt.
Das führt zu einer riesigen Ressourcenverschwendung. Permanent werden Events gelöscht und wieder hinzugefügt.
Die Probleme mit der Instabilität im Speichergrenzbereich, Nico77s Problem der fehlenden Events und unnötige Rechenzeitvergeudung sind die Folgen. Außerdem werden bei ungünstigem table Zuschnitt die Descriptoren nicht richtig zugeordnet, weil sie zu der vorherigen Section gehören.

DVB-konform würde die Sache so aussehen:

while ((table incomplete) and (section = new)) do
cache section
end
Werte table aus
Überwache table Versionsnummer

D.h. die Events würden zunächst nur einmal in den Speicher geschrieben und erst erneuert, wenn eine Sondersendung eingefügt würde oder ein neuer Tag anbricht oder eben nach dem Umschalten. Das hätte außerdem den Vorteil, dass Lesezugriffe auf die Events nicht mehr ausgebremst werden, weil ständig neue Events hinzugefügt würden.

Deshalb schlage ich vor, eine Schicht einzuziehen, die die sections cached und Vollzug meldet, wenn die Table sich geändert hat oder nach dem Umschalten neu und vollständig ist.

Und warum nun meine Ausführungen? Ich hoffe auf eine Diskussion, ob so was sinnvoll ist und wie man es ggf. am besten implementieren könnte.

Aloha.

[mb405]

Bitte jetzt nicht peitschen
ich hab grad im remotecontrol.cpp was gefunden. vielleicht nutzt es ja was ?

Code: Alles auswählen

if ( msg == NeutrinoMessages::EVT_CURRENTEPG )
	{
		CSectionsdClient::CurrentNextInfo* info_CN = (CSectionsdClient::CurrentNextInfo*) data;

//		printf("Current/Next channelID: old(%llx) -> new(%llx)\n", current_channel_id, info_CN->current_uniqueKey >> 16);
		if ( ((info_CN->current_uniqueKey >> 16) == current_channel_id ) || ((info_CN->current_uniqueKey >> 16) == current_sub_channel_id ) )
		{
			//CURRENT-EPG fr den aktuellen Kanal bekommen!;
//			printf("Current/Next EPGID: old(%llx) -> new(%llx)\n", current_EPGid, info_CN->current_uniqueKey);
			if ( info_CN->current_uniqueKey != current_EPGid )
			{
			    if ( current_EPGid != 0 )
			    {
			    	// ist nur ein neues Programm, kein neuer Kanal
				
			    	// PIDs neu holen
			    	g_Zapit->getPIDS( current_PIDs );

			    	// APID Bearbeitung neu anstossen
			    	has_unresolved_ctags = true;
			    }

damit, oder so ahnlich kann man doch dem sectionsd sagen, das er nch neuen sachen suchen soll.
für normalen betrieb reichen doch 5 events in der zukunft aus. wenn auf den kanal gezappt wird, dann holt er sich den rest.

aber wie ich euch sectionsd-gurus so kenne, werdet ihr uns da alle wieder überraschen.

[Nico 77]

Mein Vorschlag wäre ein extra Branch weil die Leute die es interessiert da mitzuarbeiten checken den aus und Rest der Welt lebt in der Zeit gelassener als wie bei den ersten sectionsd Änderungen am Anfang.

[mws]

hi nirvana,

vom grundsatz her hast du recht.

du solltest dir aber mal die etsi 300468 dazu passend durchlesen, denn
hier ist es nicht nur so, das du x von y sections empfängst, sondern die sections noch wieder in segmente unterteilt sind.

von daher sollte man dort auch darauf achten, dass man die richtigen segmente erwischt.

gruss
mws

[rasc]

der sectionsd suckt dann trotzdem immer noch...




(ich weiss nicht hilfreich der Post - trotzdem, das muss gesagt werden)

[BOFH]

Dann möchte ich anregen, dass die Datenablage bei einer Neuauflage des sectionsd konfigurierbar gestalltet wird.
Ich denke, es wurde schon öfters vorgeschlagen, dass die Langbeschreibung der Events auf andere Pfade ausgelagert wird. Momentan stehen da ja viele Möglichkeiten zur Verfügung (NAS, IDE, SD).
Falls dies große Leistungseinbussen mit sich bringt, könnte man ja auch einen fixen 3-stufigen Ringbuffer mit einbauen , der jeweils den nächsten Eintrag vorläd und den letzten noch vorhällt.

@rasc: komm, da geht doch mehr


Gruß
BOFH

[usul1]

Dann möchte ich anregen, dass die Datenablage bei einer Neuauflage des sectionsd konfigurierbar gestalltet wird.
Ich denke, es wurde schon öfters vorgeschlagen, dass die Langbeschreibung der Events auf andere Pfade ausgelagert wird. Momentan stehen da ja viele Möglichkeiten zur Verfügung (NAS, IDE, SD).

Vorher wäre es aber noch weitaus sinnvoller nach dem Vorbild von SFI festlegen zu können welche Sender überhaupt gecached werden sollen.
(Wobei man dann trotzdem den EPG bekommen sollte wenn man direkt auf diesen nicht EPG Sender schaltet)

Ich habe z.B. kein Premiere Abo, aber wenn ich auf Sat.1 schalte habe ich den kompletten Premiere EPG im Speicher. Da fängt doch schonmal die Hauptverschwendung an.
Also sollte jemand mal einen komplett neuen Daemon fürs EPG schreiben dann sollte man IMHO sowas mal mit einplanen.

cu
usul

[Nirvana]

Langsam, immer schön der Reihe nach.

@Nico
Einen Schritt nach dem anderen. Wir machen ja nur eine Machbarkeitsstudie. Aber ich nehme erfreut zur Kenntnis, dass du den aktuellen sectionsd - Stand gut findest. Dann brauchen wir ja doch nichts mehr zu machen.

@mws
Richtig. Danke für den Hinweis. Wenn wir schon pingelig sind, dann müssen wir auch feststellen, dass NIT, SDT und BAT keine Segmente kennen und nur EIT diese Besonderheit aufweist.

@rasc
100% Zustimmung. Aber ich versuche auch nur auszuloten, ob der oben vorgeschlagene Schritt nicht das suckende Gefühl bei vertretbarem Aufwand lindern könnte. Ich meine, wenn einer eine komplettes Neudesign in der Hinterhand hat - jetzt wäre die Zeit damit rauszurücken.

@all
Das Auslagern ist orthogonal zur vorschlagenen Änderung.

[Muttersöhnchen]

Falls dies große Leistungseinbussen mit sich bringt, könnte man ja auch einen fixen 3-stufigen Ringbuffer mit einbauen , der jeweils den nächsten Eintrag vorläd und den letzten noch vorhällt.

Was für 3-stufigen Ringbuffer ?

[usul1]

Das Auslagern ist orthogonal zur vorschlagenen Änderung.

Naja, aber man kann doch schon mal erwähnen was sonst noch sinnvoll wäre (im Rahmen einer reinen Ideensammlung), wenn eh umfangreiche Änderung geplant/besprochen werden.

Nicht das jetzt einer anfängt den kompletten sectionsd umzuschreiben und wenn man DANN (wenns fertig ist) mit solchen (IMHO sinnvollen) Vorschlägen kommt heist es wieder "Tolle Idee, aber mit dem aktuellen Code läst sich das nicht ohne komplettes Redisign implementieren". ;-)

cu
usul

[rasc]

@mws
Richtig. Danke für den Hinweis. Wenn wir schon pingelig sind, dann müssen wir auch feststellen, dass NIT, SDT und BAT keine Segmente kennen und nur EIT diese Besonderheit aufweist.

wieso kennen NIT, BAT, etc. keine Segmente?

[mws]

rasc kennen sie, nur ist es bei eit nen büschen anders deklariert/gehandelt.

gruss
mws

[Nirvana]

Na dann lasst mich nicht doof sterben. Wo sind die Segmente außerhalb von der EIT? Ich sehe immer nur die sections und habe noch keine Daten wissentlich verpasst.

[mws]

die spec sagen, das die entsprechenden tables (NIT/SDT/....) über die sections segmentiert sein sollen. dadurch wird z.b. eine komplette NIT über 3 sections segmentiert == 3 segmente.

bei der eit ist die besonderheit, das man mehrere komplette tables über sections segmentiert. aus diesem grunde kann man über das segment_last_section feld erkennen, wann eine table information endet, sprich mit welcher section.

alle anderen sections besitzen dieses feld nicht, da immer nur eine komplette table übertragen wird.

gruss
mws

[Nirvana]

Na also, mein reden. Hätte mich auch gewundert, wo ich EN300468 schon so lange kenne.

[zor]

gibt es hier weitere schritte oder ist das nur bei einer diskussion geblieben?

gruss zor

[mws]

weitere reaktion

nirvana lies dir mal die tr 101211 v 1.5.1 durch.
kapitel 4.1.4 dürfte dir die eit besonderheiten am einfachsten verdeutlichen.

gruss
mws

[Nirvana]

Na, wie gut, dass ich ETSI member bin. Aktuell ist doch 1.7.1.

Aber mws, ich bin voll bei dir. Die EIT Besonderheiten müssen berücksichtigt werden.

Mein Anliegen ist nur festzustellen, dass der sectionsd bestimmte strukturelle Probleme hat, die sich durch eine DVB-konforme Implementierung lösen ließen. Falls also mal ein Code-Archäologe diesen Thread ausgräbt:
Wie waren nicht doof, wir wussten wenigstens woran es lag. Oder vielleicht findet sich ja bis dahin jemand, der sich opfert.

[mws]

*updated* danks
man kriegt ja gar nicht alle revs mehr mit

gruss
mws

[rasc]

???

... ist der Besuch 1x im Monat bei etsi nicht obligatorisch?