Current&Next während einer Aufnahme

[Gaucho316]

Eine Sache, die mich jetzt schon seit einiger Zeit stört, ist die Anzeige der aktuellen und der folgenden Sendung in der Infobar und auf dem LCD während einer Aufnahme (also wenn der sectionsd angehalten wurde). Current&Next wird dann leider nicht mehr aktualisiert. Warum das so ist, weiß ich schon. Aber kann man nicht etwas dagegen machen? Ich hab's mal versucht zu verstehen und bin auf die Funktion commandCurrentNextInfoChannelID des sectionsd gestoßen. Würde es reichen in sectionsd.cpp in Zeile 3081 die if-Abfrage so zu erweitern, dass auch abgefragt wird, ob der sectionsd angehalten wurde, so dass nicht myCurrentEvent und myNextEvent übergeben werden, sondern die richtigen EPG-Daten anhand der Uhrzeit ermittelt werden, wie es ab Zeile 3110 geschieht?

Edit: Die Funktion commandActualEPGchannelID müsste dann wohl auch auf dieses Weise erweitert werden. In Zeile 3473 von sectionsd.cpp kommt nämlich die gleiche if-Abfrage vor.

Edit: Oder kann man vielleicht das Löschen von myCurrentEvent und myNextEvent ab Zeile 2175 von sectionsd.cpp irgendwie hochziehen in den Teil ab Zeile 2150?

[seife]

Man könnte auch einfach den CNThread weiterlaufen lassen, der sollte nicht soviele Ressourcen verbrauchen, dass es die Aufnahme wirklich stört...

[Gaucho316]

Man könnte auch einfach den CNThread weiterlaufen lassen, der sollte nicht soviele Ressourcen verbrauchen, dass es die Aufnahme wirklich stört...

Da weiß ich leider nicht, wo ich ansetzen muss. Meine anderen Vorschläge kann ich dagegen leicht selbst ausprobieren. Oder sind die völliger Humbug?

[rhabarber1848]

Da weiß ich leider nicht, wo ich ansetzen muss.

Vielleicht sind es diese Befehle?

Code: Alles auswählen

dmxCN.request_pause();
dmxCN.request_unpause();

[Gaucho316]

Ob das reicht, weiß ich nicht. Dazu kann bestimmt seife mehr sagen.

Oder kann man vielleicht das Löschen von myCurrentEvent und myNextEvent ab Zeile 2175 von sectionsd.cpp irgendwie hochziehen in den Teil ab Zeile 2150?

Ich habe jetzt erst einmal diesen Ansatz ausprobiert. Scheint gut zu funktionieren.

Link zum Patch entfernt

[Gaucho316]

Was noch fehlt, ist die automatische Aktualisierung der Infobar und des LCD. Als Ergänzung müsste es doch reichen, in infoviewer.cpp die Zeilen 625 bis 639 und 1939 bis 1944 wieder für den Fall zu aktivieren, dass der sectionsd angehalten wurde. Oder sehe ich das falsch? Ich werde das wohl mal die Tage einfach ausprobieren.

Edit: Ich denke, dass man die Änderung im Infoviewer doch noch ein klein wenig anders machen könnte. Das LCD wird nämlich auch auf den Sky-Sport- und Sky-Select-Feeds nicht aktualisiert und das nicht nur während einer Aufnahme. Dort erkennt der sectionsd den Sendungswechsel nicht. Ins Blaue hineingetippt würde ich in infoviewer.cpp die Zeilen wie oben beschrieben wieder reinnehmen, aber die if-Abfrage umändern, so dass immer dann, wenn myCurrentEvent und myNextEvent NULL sind, die Events beim sectionsd angefragt werden.
Alt:

Code: Alles auswählen

!(info_CurrentNext.flags & CSectionsdClient::epgflags::has_current)

Neu:

Code: Alles auswählen

!(info_CurrentNext.flags & CSectionsdClient::epgflags::not_broadcast)

Oder wäre das völliger Unsinn und habe ich not_broadcast falsch verstanden?

[seife]

IIRC habe heisst epgflags::not_broadcast, dass der sender kein current / next sendet.

Ich kann nur davon abraten, wieder polling für events einzubauen. Das Entfernen dieses üblen verhaus war eine der Sachen, die das Neutrino auf der dbox IMHO wieder wesentlich bedien- / benutzbarer gemacht hat und die diversen lockingprobleme wesentlich entschärft hat.

Wegen der sky-feeds: wenn, dann müsste man im sectionsd einbauen, dass die NVOD-Events signalisiert werden, also dass der sectionsd feststellt, wenns sich das aktuelle Event ändert und das dann dem neutrino signalisiert. Aber dafür jedes mal vom Neutrino aus über den socket den sectionsd zu pollen - inklusive der ganzen Locking-Schlange die man da nachzieht - das kann ich wirklich nicht empfehlen.

Dummerweise habe ich keine Ahnung, wie die sky-feeds ihr epg übertragen, und wie die NVOD-Events (wenn es denn welche sind? keine Ahnung) signalisiert werden. Das private-EPG gibts ja IIUC nicht mehr, aber so standard-current/next ist es wohl auch nicht.
Mangels sky und mangels kisten, die noch neutrino verwenden, kann ich das auch schlecht testen

[Gaucho316]

Ahh ok, dann habe ich not_broadcast wirklich falsch verstanden. Das Private-EPG-Zeug gibt es wirklich nicht mehr. Der EPG wird jetzt im Standardformat übertragen. So wie es aussieht, haben die einfach nur kein Current&Next auf den Feeds. Kann man das nicht irgendwie nachbilden?

Nochmal zurück zum Infoviewer, das mit dem ständigen Polling kann man doch verhindern, indem man ein flag einführt, dass zeigt, dass es kein Current&Next gibt und eben nur dann pollt. Das war das, was ich mit dem not_broadcast-flag machen wollte. Oder ist das auch Mist?

[seife]

Ich finde, das macht es unnötig komplex.
Ich würde in dem fall eher im sectionsd ein current/next "simulieren", nach dem Motto:
"wenn NVOD-Feed, dann schicke nicht die current/next des Portals, sondern die des NVOD-Feeds.

Oder, alternativ, im Infoviewer: (pseudocode)

Code: Alles auswählen

cn-event-handler() {
     if (is_nvod_channel)
           currentNextEvent = request_what_runs_now_from_sectionsd(current_nvod_channel);
     else
           currentNextEvent = current_next_event_that_sectionsd_sent_us();
}

Irgendwo im infoviewer muss es ja den Code geben, der für NVOD die passenden Events raussucht. Und es scheint auch so, als ob ein EIT-Update kommt, aber halt das CN-Event sich nicht wirklich ändert:

Code: Alles auswählen

11:27:26.550 addevent-cn: added running (4) event 0x897a 'Rund um die Uhr bestellbar'
11:27:26.646 [cnThread] got current_next (0x3) - sending event!
11:27:26.648 dmxCN: going to sleep...
11:27:26.649 eit_set_update_filter, servicekey = 0x400850012, current version 3
11:27:26.656 Connection from UDS
11:27:26.656 version: 5, cmd: 17, numbytes: 1
11:27:26.656 data length: 8
11:27:26.657 commandCurrentNextInfoChannelID
11:27:26.657 [sectionsd] Request of current/next information for        400850012
[sectionsd] linkage in current EPG found.
11:27:26.657 currentEvt: 'Rund um die Uhr bestellbar' (897a) nextEvt: 'Rund um die Uhr bestellbar' (897b) flag: 0x55 fsk: 0
11:27:26.683 Connection from UDS
11:27:26.683 version: 5, cmd: 20, numbytes: 1
11:27:26.683 data length: 8
11:27:26.684 commandComponentTagsUniqueKey
11:27:26.684 Request of ComponentTags for 0x400850012897a
11:27:26.684 ComponentTags found.
11:27:26.684 components.size 4 
11:27:26.685  16:9 
11:27:26.686  Tonoption 1 
11:27:26.686  Tonoption 2 
11:27:26.686  Dolby Digital 
11:27:26.710 Connection from UDS
11:27:26.710 version: 5, cmd: 26, numbytes: 1
11:27:26.710 data length: 8
11:27:26.711 commandLinkageDescriptorsUniqueKey
11:27:26.711 Request of LinkageDescriptors for 0x400850012897a
11:27:26.711 LinkageDescriptors found.
11:27:26.711 linkage_descs.size 8 
11:27:26.712  Sky Select
11:27:26.712  436 - 10:45 
11:27:26.712  429 - 10:30 
11:27:26.712  429 - 11:30 
11:27:26.712  437 - 10:00 
11:27:26.712  437 - 11:00 
11:27:26.712  484 - 10:30 
11:27:26.713  484 - 11:15 
11:27:34.909 [eitThread] skipping to next filter(2) (> DMX_HAS_ALL_SECTIONS_SKIPPING)
[...]
11:29:30.980 EIT Update Filter: Activate cnThread
11:29:30.981 --> 'changeDMX: before pthread_mutex_lock(&start_stop_mutex)' 86543.944
11:29:30.981 --> 'changeDMX: after pthread_mutex_lock(&start_stop_mutex)' 0.390
11:29:30.981 changeDMX [12]-> 0 (0x4e/0xff) (128 seconds)
11:29:30.982 --> 'after DMX_SET_FILTER' 0.960
11:29:30.983 eit_stop_update_filter
11:29:30.983 dmxCN: waking up again - requested from .change()
11:29:31.077 waiting for eit_version...
11:29:31.924 EIT old: 255 new version: 4
11:29:31.925 addevent-cn: not add runn. (4) event 0x897a 'Rund um die Uhr bestellbar'
11:29:32.864 addevent-cn: not added next(2) event 0x897b 'Rund um die Uhr bestellbar'
[...]
11:30:00.423 addevent-cn: not add runn. (4) event 0x897a 'Rund um die Uhr bestellbar'
11:30:01.361 addevent-cn: not added next(2) event 0x897b 'Rund um die Uhr bestellbar'
11:30:02.320 EIT old: 4 new version: 5
11:30:02.321 addevent-cn: removing next-event
11:30:02.321 addevent-cn: added running (4) event 0x897b 'Rund um die Uhr bestellbar'
11:30:02.422 [cnThread] got current_next (0x1) - sending event!
11:30:02.443 Connection from UDS
11:30:02.444 version: 5, cmd: 17, numbytes: 1
11:30:02.444 data length: 8
11:30:02.444 commandCurrentNextInfoChannelID
11:30:02.444 [sectionsd] Request of current/next information for        400850012
11:30:02.445 !myNextEvent 11:30:02.445 [sectionsd] current EPG found. service_id: 12, flag: 0x5
11:30:02.445 *nextEvt not from cur/next V1!
11:30:02.459 commandCurrentNextInfoChannelID change2 flag: 0x05
[sectionsd] linkage in current EPG found.
11:30:02.459 currentEvt: 'Rund um die Uhr bestellbar' (897b) nextEvt: '' (0000) flag: 0x45 fsk: 0
11:30:02.484 Connection from UDS
11:30:02.485 version: 5, cmd: 26, numbytes: 1
11:30:02.485 data length: 8
11:30:02.486 commandLinkageDescriptorsUniqueKey
11:30:02.486 Request of LinkageDescriptors for 0x400850012897b
11:30:02.486 LinkageDescriptors found.
11:30:02.486 linkage_descs.size 8 
11:30:02.486  Sky Select 
11:30:02.487  436 - 10:45 
11:30:02.487  429 - 10:30 
11:30:02.487  429 - 11:30 
11:30:02.487  437 - 10:00 
11:30:02.487  437 - 11:00 
11:30:02.487  484 - 10:30 
11:30:02.487  484 - 11:15 
11:30:03.265 addevent-cn: added next    (0) event 0x897c 'Rund um die Uhr bestellbar'
11:30:03.366 [cnThread] got current_next (0x3) - sending event!
11:30:03.369 dmxCN: going to sleep...
11:30:03.369 eit_set_update_filter, servicekey = 0x400850012, current version 5
11:30:03.382 Connection from UDS
11:30:03.382 version: 5, cmd: 17, numbytes: 1
11:30:03.383 data length: 8
11:30:03.383 commandCurrentNextInfoChannelID
11:30:03.383 [sectionsd] Request of current/next information for        400850012
[sectionsd] linkage in current EPG found.
11:30:03.384 currentEvt: 'Rund um die Uhr bestellbar' (897b) nextEvt: 'Rund um die Uhr bestellbar' (897c) flag: 0x55 fsk: 0

11:27:26.550: nach dem zappen ist CN vorhanden 0x897a (current) und 0x897b (next)
=> dann fragt der infoviewer die daten ab
11:29:30.980: EIT-Update kommt, CN-Thread wird aktiv
11:30:02.321: neues current event 0x897b
11:30:03.265: neues next event 0x897c

Wie man nach dem neuen current-Event sieht, fragt schon jemand (infoviewer?, Channellist?) die Linkage-Descriptors ab, damit hinzugekommene Feeds etc. neu eingelesen werden.
Ich vermute, an dieser Stelle könnte man auch die passenden events abfragen.

Das wäre dann immer noch polling, aber "polling on demand"

[Gaucho316]

Die einzelnen Feeds bei Sky sind feste Kanäle, die man sich auch einzeln mit Hilfe der myservices.xml abspeichern und ansehen kann. Dann sieht man den EPG des entsprechenden Feeds. Und hier funktioniert Current&Next auch nicht, wenn ich mich richtig erinnern kann. Ich sitze im Moment leider nicht davor. Wenn man vom Portal per gelber Taste auf einen Feed schaltet, geht es aber definitiv nicht. Aber das hast du ja schon selbst beobachtet. Ach Mist, ich weiß nicht so recht, was ich geenau tun muss. Lösen würde ich das Problem aber schon gerne.

[seife]

wobei -- wenn ich mich da an frühere diskussionen richtig erinnere -- die zwar auf festen SIDs kommen, aber halt unterschiedliche Feeds (mal Boxen, mal Formel 1, mal Fussball) auf einer SID. Also sind sie schon dynamisch. Und ich vermute mal, dass halt die current/next nur für den "Hauptkanal" gesendet werden.
Davorsitzen tu ich auch nicht, drum kann ich nicht schaun

Ansonsten sollte es nicht allzu schwer sein, das wie oben beschrieben zu machen, das wäre dann immer noch praktisch nur im infoviewer, aber anstelle dauernd zu pollen würde man halt nur dann, wenn auf einem nvod ein cn-event kommt pollen, und dann halt nicht nach den cn-events fragen sondern nach den "normalen".

[Gaucho316]

Danke, ich denke, dass ich jetzt schon ein Stück weiter bin. Gehe ich recht in der Annahme, dass ich "einfach" nur in infoviewer.cpp von Zeile 1319 bis 1331 rumfummeln muss? Natürlich gilt das alles nur unter der Voraussetzung, dass die Message EVT_CURRENTNEXT_EPG wirklich im Infoviewer ankommt, richtig?

[seife]

Ja, im prinzip schon. Du kannst ja dort mal ein paar printf's einbauen, damit du siehst, was dort ankommt.

In Zeile 413-417 wird für showTitle die channel_id entsprechend gesetzt, wenn es ein NVOD feed ist, in Zeile 482 dann der entsprechende Current/Next event geholt.

irgendwas in der art:

Code: Alles auswählen

diff --git a/tuxbox/neutrino/src/gui/infoviewer.cpp b/tuxbox/neutrino/src/gui/infoviewer.cpp
index 4df5188..668f2a6 100644
--- a/tuxbox/neutrino/src/gui/infoviewer.cpp
+++ b/tuxbox/neutrino/src/gui/infoviewer.cpp
@@ -1327,6 +1327,14 @@ int CInfoViewer::handleMsg(const neutrino_msg_t msg, neutrino_msg_data_t data)
                                show_Data( true );
                        showLcdPercentOver();
                }
+               else if (!g_RemoteControl->subChannels.empty() && g_RemoteControl->selected_subchannel > 0)
+               {
+                       g_Sectionsd->getCurrentNextServiceKey(channel_id, info_CurrentNext);
+                       CLCD::getInstance()->setEPGTitle(info_CurrentNext.current_name);
+                       if (is_visible && showButtonBar)
+                               show_Data( true );
+                       showLcdPercentOver();
+               }
                return messages_return::handled;
        }
        else if ( msg == NeutrinoMessages::EVT_TIMER )

(unkompiliert und ungetestet). Ich tät aber auch im if() drüber, in Zeile 1324, ein printf einbauen, damit du siehst, wo der code reinläuft. Und vor Zeile 1322 auch und vor 1319 auch, wenn du grad dabei bist ;-)

Prüfen müsste man dann noch, ob das "Infobar bei EPG-Änderung einblenden" funktioniert, wenn man auf so einem feed ist, aber das wären dann details...

[Gaucho316]

Erst einmal danke. Ich probier das die Tage auf alle Fälle mal aus. Irgendwie sind wir aber vom ursprünglichen Thema abgewichen. Wie bringe ich dem sectionsd bei, den cnThread nie abzuschalten? Ging rhabarber1848s Idee schon in die richtige Richtung?

Edit: Vielleicht sollte man dann auch den timeThread laufen lassen. Ich schätze, dass der auch nicht so viel Rechenzeit braucht.

[Gaucho316]

Ich habe den Code nun mal getestet. Leider kommt wohl auf den Unterkanälen kein NeutrinoMessages::EVT_CURRENTNEXT_EPG im Infoviewer an. Er geht nämlich nicht in den Teil rein. D.h. dann wohl, dass es wirklich kein Current&Next gibt und CSectionsdClient::EVT_GOT_CN_EPG nicht abgeschickt wird. Hast du noch 'ne andere Idee?

[seife]

Das ist komisch, weil mein sectionsd-Log oben zeigt, dass ein Event geschickt wurde. Das war aber auch auf dem "Portal", ohne den Feed umzuschalten. Evtl. müsste man dem sectionsd tatsächlich sagen, dass er sozusagen "auf dem Portal bleiben" soll, wenn auf den feed geschaltet wird.

Starte mal sectionsd mit debug, ("killall sectionsd; sectionsd -d", danach neutrino neu starten), dann siehst du, was da passiert.

[Gaucho316]

Ich habe jetzt mal auf einen der Feed-Kanäle geschaltet und mit dvbsnoop 5000 EIT-Datensätze gesammelt. Dann habe ich mal nach Elementen in der Tabelle 0x4e für den eingestellten Kanal gesucht und habe das Current-Element und das Next-Element gefunden. Aber warum findet der cnThread die nicht? Wartet der nicht lange genug bis die im Datenstrom wieder auftauchen?

[seife]

für die korrekte ID? Der sectionsd filtert ja vermutlich auf die ID des feeds, aber die EIT wird für den Hauptkanal kommen.

Die Current/Next die da kommen, sind die vom Hauptkanal, vermute ich mal so.

[Gaucho316]

Mist, ich hab's mir falsch gemerkt. Auf den einzeln abgespeicherten Feeds per myservices.xml funktioniert das CN-Update. Rufe ich einen Feed per gelber Taste auf dem Sky-Select-Portal auf, geht das CN-Update nicht. Auch dann nicht, wenn ich zwischendurch den Infoviewer per ?-Taste aufrufe. Hat 'ne neue Sendung angefangen und rufe ich dann den Infoviewer auf, wird das LCD natürlich aktualisiert, aber nie automatisch. Da scheint noch irgendetwas zu fehlen.

Wie bringe ich dem sectionsd bei, den cnThread nie abzuschalten? ... Vielleicht sollte man dann auch den timeThread laufen lassen. Ich schätze, dass der auch nicht so viel Rechenzeit braucht.

Kannst du hierauf bitte auch mal eingehen?

[Gaucho316]

Ich bin mal dem Code gefolgt, der abläuft, wenn man auf einen Unterkanal des Portals schaltet. Das eigentliche Umschalten geschieht in der Methode setSubChannel der Klasse CRemoteControl in remotecontrol.cpp. Als ich mir dann die Historie der Datei angesehen habe, ist mir aufgefallen, dass zeitweilig zwischen Zeile 565 und 566 folgender Code drin war:

Code: Alles auswählen

// Houdini: to restart reading the private EPG when switching to a new option
g_Sectionsd->setServiceChanged( current_sub_channel_id , true );

Ich denke, dass nach g_Zapit->zapTo_subServiceID_NOWAIT() hier einfach g_Sectionsd->setServiceChanged(...) fehlt. Der sectionsd bekommt ja gar nicht mit, dass umgeschaltet wurde. Warum der Code dann allerdings später wieder rausgeflogen ist, weiß ich nicht. Das geschah nämlich noch lange vor Abschaltung des Premiere-Private-EPG. In der Methode zapTo_ChannelID wird nämlich auch g_Sectionsd->setServiceChanged(...) (Zeile 640) nach dem Umschalten per g_Zapit->zapTo_serviceID_NOWAIT(...) aufgerufen.

[seife]

Dann probier's doch mal aus

Das mit dem CN-Thread weiterlaufenlassen ist vermutlich fast so einfach, wie vermutet, allerdings muss der CN-Thread dann auch das "scanning" flag ignorieren.
Dann reagiert er aber auch nicht mehr auf die blacklist, was momentan nicht so schlimm ist, aber als die kisten auf bestimmten kanälen crashten doch probleme gemacht hätte.

[Gaucho316]

Ich werde es auf alle Fälle heute Abend ausprobieren. Ich hoffe, dass ich damit nicht das automatische Update der Bildoptionen bei eingeschaltetem PMT-Update kaputt mache. Die Änderung am cnThread lasse ich wohl lieber sein. Ich will ja nicht die Blacklist-Funktionalität kaputt machen. Mir würde schon meine Änderung aus einem der ersten Postings reichen. Dann müsste man zwar immernoch die ?-Taste drücken, damit der Sendungstitel auf dem LCD während der Aufnahme aktualisiert wird, aber dann ist er wenigstens aktuell.

[seife]

Das PMT-Update hat damit eigentlich nichts zu tun, das ist ja im Zapit...

sectionsd-for-gaucho316.diff sollte ein kleinerer Weg zum selben Ziel wie dein Patch von oben sein: ich setze nicht die events auf NULL, sondern checke einfach bei der Auswertung, ob "scanning" true ist, und wenn nicht ignoriere ich die current/next, damit dann die anderen zur Zeit passenden genommen werden.

Dein Patch ist nicht schlechter, aber meiner ändert weniger - was beim sectionsd immer eine gute idee ist
Allerdings habe ich ihn nicht ausprobiert, noch nicht mal kompiliert.

[Gaucho316]

Danke für den Patch. Den teste ich dann auch gleich mit. Weniger ist halt manchmal mehr.

Das PMT-Update hat damit eigentlich nichts zu tun, das ist ja im Zapit...

Dann ist ja alles ok. Ich dachte nur (ohne tatsächlich nachgesehen zu haben), dass die Infos über die vorhandenen Unterkanäle vom sectionsd geliefert werden. Und durch g_Sectionsd->setServiceChanged(...) "schalten" wir dann ja quasi weg vom Portalkanal. Wenn die Infos aber nicht nur dort geliefert werden, ist das natürlich kein Problem. Vielleicht habe ich mir einige Zusammenhänge aber auch nur falsch zusammengereimt. Der große, allesumfassende Überblick fehlt mir. Aber den hast du ja. Das reicht mir.

[Gaucho316]

Dein Patch für den sectionsd funktioniert und kann ins CVS.

Den Fix für den EPG auf Unterkanälen musste ich noch um eine kleine Änderung im Infoviewer ergänzen. Ansonsten klappt das aber nun auch endlich.

Link zum Patch entfernt