Frage zur Funktion SelectAPID() in neutrino.cpp

[Ryker]

Neutrino hat ja das Problem, daß keine AudioPIDS mehr aus der GUI herausgelöscht werden, wenn der nachfolgende Film weniger AudioOptionen hat, als der vorhergehende.
Beispiel.
20:15 Film blah -> deutsch, DD5.1, englisch
21:45 Film fasel -> stereo, DD2.0
Neutrino meldet aber:
21:45 Film fasel -> stereo, DD2.0, german ....german ist dann noch die APID vom verhergehenden Film, die es jetzt eigentlich nicht mehr gibt.
Komischerweise werden aber AC3-PIDs nach dem Film korrekt aus der GUI gelöscht.

Der zapit lieferts richtig (das sieht man im Neutrino-WebInterface), also muß das wohl ein Problem vom GUI sein.

Wenn ich mir die Neutrino.cpp so anschaue, dann sehe ich nur ein APIDSelector.addItem(.......) bzw. werden in der remotecontrol.cpp in der Function processAPIDnames() nur die AC3-Pids gelöscht.

while ( e != current_PIDs.APIDs.end() )
{
if ( e->is_ac3 )
{
if ( e->component_tag != -1 )
{
current_PIDs.APIDs.erase( e );
continue;
}
else
has_ac3 = true;
}
e++;
}


Müßte man da nicht das "if ( e->is_ac3 )" rausnehmen ? - oder liege ich da komplett falsch.



Gruß
Ryker

[Zwen]

Ich würde sagen nein.

SelectAPID() in neutrino.cpp baut das Auswahlmenüs bei jedem Druck auf die "grüne" Taste neu auf und fügt dann alle APIDs aus
g_RemoteControl->current_PIDs.APIDs
ein. Das Menü überlebt das Funktionsende nicht, deswegen muss da auch nichts gelöscht werden.

in remotecontrol.cpp wird jedesmall vor ProcessAPIDNames()

g_Zapit->getPIDS( current_PIDs )

aufgerufen. Dieser Aufruf holt sich die aktuellen PIDs (also auch die APIDs von zapit). Gelöscht müssen die APIDs also hier auch nicht werden.
Mir ist jetzt auch nicht ganz klar, welche APIDs dann später noch in ProcessAPIDNames gelöscht werden (die mit dem component_tag == -1) aber ich denke mal, das wird irgendwas sein, das die dbox eh nicht spielt...

Ich könnte mir 2 Ursachen für das Problem zusammen reimen:

1.) In irgendeiner Konstellation wird vergessen die PIDs neu von zapit zu holen. Testen könnte man das z.B. durch nen Debug-Ausgabe in processAPIDNames, am besten dann per Schleife alle APIDs ausgeben lassen. Im Betrieb dann später schauen, ob die Logausgaben kommen, wenn eine neue Sendung anfängt...

2.) Das Event (CURRENTNEXT_EPG) das das Neulesen der PIDs triggern kommt ja vom sectionsd. Ich könnte mir vorstellen, dass der den Programmwechsel ein bisserl schneller als die zapit mitbekommt. Unmittelbar nachdem der sectionsd neutrino das Anfangen der neuen Sendung signalisiert, holt sich Neutrino die PIDs von zapit neu. Evtl. hat zapit zu diesem Zeitpunk die neuen PIDs noch gar nicht und liefert hier nochmal die alten. Das könnte man mir ein paar Logausgaben auch schnell rausfinden...

Ich persönliche Tippe auf 2. ;-)

So, und nun freiwillige Tester/debugger vor

Zwen

[kerlimann]

Ich persönliche Tippe auf 2. ;-)

wirste mit recht haben. wenn du naemlich en epg reset (also restart der sectionsd) machst, und einmal vor/zurueck zappst, sind die apid es OK. selbiges gilt auch fuer die NVOD zeiten.

wie man das nun eibauen kann, so dass es ohne umzuzappen geht, no idea. wohlmoeglich garnicht. aber ich kann mit diesem kleinen uebel gut leben. und eijn automatischer sectionsd restart nach jedem umschalten ist ja auch nicht das wahre.

[Zwen]

Also so wich ich das Verstanden habe, geht es immer, wenn man zappt. Problematisch ist nur eine neue Sendung mit geänderten Apids auf dem selben Kanal. Beim zappen greift da ja nen anderer Mechanismus, das sagt zapit neutrino, wann der zap fertig ist und erst dann holt sich neutrino von zapit die neuen PIDs. Problematisch ist halt, wenn der sectionsd den Ton an gibt - wobei man den hier ausnahmsweise mal nicht verantwortlich machen kann

Zwen

[obi]

das problem ist, dass zapit keinerlei sections im hintergrund liest. somit bekommt es auch keine aenderung der PMT mit, in der die audio pids stehen. die PMT wird nach jedem umschalten einmal gelesen.

[Zwen]

Sollten wir dann nicht das Interface aufbohren, so alla
reallyDoReloadApids(apids)... ?

Zwen

[kerlimann]

Problematisch ist nur eine neue Sendung mit geänderten Apids auf dem selben Kanal.

ja, davon sprach ich ja. allerdings kommt sowas so selten vor, das die apid es sich aendern. mir ist das nur bei NVOD aufgefallen. dann steht auf dem info portal von direkt z.B. start 15:30, aber auf den gelben tasten isses noch nicht aktualisiert. durch hin/herzappen kriegt man das auch nicht weg, da hilft nur sectionsd restart.

aber stoerend finde ich das eigentlich nicht. wer sich en film bestellt, soll halt vorher kurz epg resetten und gut - kein akt.

ps: bei premiere aendern sich die apids eh nie (nur das manchmal halt 5.1 dabei ist, und manchmal nicht). die sind immer (bleistift) 200, 201, 203. wobei die reihenfolge deutsch, oton, ac3 ist. beim aufnehmen mit wingrabe stoert es also nicht, wenn man die syntax kennt. daher verstehe ich nicht, wo da nun das grosse problem liegt?

[kerlimann]

moment mal..

Neutrino hat ja das Problem, daß keine AudioPIDS mehr aus der GUI herausgelöscht werden, wenn der nachfolgende Film weniger AudioOptionen hat, als der vorhergehende.
Beispiel.
20:15 Film blah -> deutsch, DD5.1, englisch
21:45 Film fasel -> stereo, DD2.0
Neutrino meldet aber:
21:45 Film fasel -> stereo, DD2.0, german ....german ist dann noch die APID vom verhergehenden Film, die es jetzt eigentlich nicht mehr gibt.

bei welchem sender kommt das denn vor? vielleicht uebersehe ich jetzt ja was. bei premiere bleibt die APID immer gleich. ausser bei den NVOD kanaelen, weil die sich ja komplett im laufe des tages verschieben koennen.

[obi]

Sollten wir dann nicht das Interface aufbohren, so alla
reallyDoReloadApids(apids)... ?

Zwen

ich waere dann fuer sowas wie reparsePmt(), was recht schnell implementiert waere. damit erwischt man dann auch wechselnde video pids usw.

oder vielleicht gleich zapit mit der libdvb++ neu schreiben

[kerlimann]

ich waere dann fuer sowas wie reparsePmt(), was recht schnell implementiert waere. damit erwischt man dann auch wechselnde video pids usw.

wann sollte dieses reparsen der pid es denn erfolgen? weiter oben schreibst du, die pmt wird nur beim umzappen gelesen. soll die dann in gewissen zeitabstaenden gelesen werden, oder wie? hmm, wuerde das gerne mal verstehen, aber kann da nicht ganz folgen..

ferner.. wechselnde videopids? also hierbei kann es sich doch nun wirklich nur um direkt kanaele handeln, oder? irgendwie komm ich nicht mehr mit

[obi]

man koennte es einfach dann machen, wenn ein neuer event (neue sendung) beginnt. das ist aber sowieso nur ein hack.. um es richtig ordentlich zu machen muesste man sehr viel in zapit aendern.

wechselnde video pids gibt es bei premiere direkt nicht. ich weiss nur von einem testsender (Test-R) und irgendwas oeffentlich rechtliches, das 1x taeglich auf lokales zeugs umschaltet.. dazu steht was im forum, selbst angeschaut hab ich es mir bisher nicht.

ferner koennte ein sender auch abends verschluesseln und tagsueber frei empfangbar sein (wie z.b. bei zik/xxl). auch das wuerde man nur durch neu lesen der pmt erfahren. da das premiere und orf nicht machen (digikabel auch nicht?) ist das allerdings ein bug, den kaum einer bemerkt

[Zwen]

ich waere dann fuer sowas wie reparsePmt(), was recht schnell implementiert waere. damit erwischt man dann auch wechselnde video pids usw.

Machst du das zapit-seitig rein? ist ja nicht der erste Hack ...

oder vielleicht gleich zapit mit der libdvb++ neu schreiben

Na dann, las mal krachen ;-)

[obi]

ja, komme aber erst wieder fruehestens ende der woche zu meinen boxen.

[Zwen]

ja, komme aber erst wieder fruehestens ende der woche zu meinen boxen.

Oha, zittern die Hände schon ?