Support Request #3429
closedReceive samples after Stop() - how to adapt order of Stop() call ?
Description
Supportanfrage
Ich habe einen Filter, welcher Status-Messages von mehreren anderen Filtern empfängt und auswertet.
In der Funktion "Stop" dieses Filters schreibe ich eine Ergebnisdatei.
Nun habe ich festgestellt, dass nach dem Aufruf von "Stop" immer noch Samples an den Eingangspins auftauchen
und damit mein Ergebnis manchmal nicht korrekt ist.
Wie kann ich sicherstellen, dass nach "Stop" alle Messages empfangen wurden, bzw. in welcher Funktion/Event
kann ich die Ergebnisdatei noch erzeugen, um keine unvorhersagbaren Ergebnisse zu erhalten? Muss ich evtl.
einen Timer aufsetzen und einige Zeit warten, bis ich die Datei erzeuge?! Wäre aber eine Notlösung....
Das Ergebnis sollte bei geöffnetem ADTF bereitgestellt werden und nicht durch das Schließen von ADTF.
Lösung
Du musst sicherstellen, dass der Sammelfilter als letztes runtergefahren wird und alle Daten verarbeitet hat.
Das kannst du über die Filter Prio im CE konfigurieren.
Updated by hidden almost 6 years ago
- Project changed from Public Support to 5
- Status changed from New to In Progress
- Topic set to ADTF::Common
Updated by hidden almost 6 years ago
- Status changed from In Progress to Customer Feedback Required
Hallo Gerd,
eigentlich sollten die Events nicht von einen Filter empfangen, sondern von einem Service.
Nur dann kannst du gewährleisten, dass der Filtergraph State darauf keinen Einfluss nimmt.
Schreibe lieber einen Service der die Events empfängt, damit du sicher sein kannst, dass alle für dich relevanten Daten nicht durch eine Filter-Stop Reihenfolge unvollständig werden.
Updated by hidden almost 6 years ago
Hallo Florian,
danke für die Info. Kann man einen Service auch in einem Filter realisieren?
Mein „Ergebnissammelfilter“ hat einen dyn. Eingangspin, um noch weitere Filter „anzuschließen“.
Updated by hidden almost 6 years ago
Hallo Gerd,
Kann man einen Service auch in einem Filter realisieren?
Nein, ein Filter ist eine Komponente im Filter Graphen zur Datenübertragung (z.B. Player), ein Service ist ab einen im Manifest definierten Runlevel verfügbare Komponente (z.B. Console View) und sendet keine Samples sondern handelt Hintergrundaktionen, stellt UIs bereit oder reagiert auf Events.
Mein „Ergebnissammelfilter“ hat einen dyn. Eingangspin, um noch weitere Filter „anzuschließen“
Sorry, ich denke ich habe deinen Use Case beim ersten Lesen falsch verstanden.
Ich dachte zunächst du verschickst Events und schreibst diese irgendwo hin.
Wenn ich dich nun richtig verstanden habe, verbindest du einfach alle relevanten Filter mit deinem Sammelfilter und schreibst Infos aus den ankommenden Samples irgendwo hin.
Dann musst du sicherstellen, dass der Sammelfilter als letztes runtergefahren wird und alle Daten verarbeitet hat.
Das kannst du über die Filter Prio im CE konfigurieren.
Updated by hidden almost 6 years ago
Hallo Florian,
Ja, korrekt, Du hast es jetzt richtig verstanden. Wenn der Sammelfilter die niedrigste Prio hat, dann funktioniert es.
Ich denke nicht, dass ein Anwender an den Prios rumspielt….
Das Gesamtergebnis wird aus den Teilergebnissen der vorgeschalteten Einzelfilter gebildet und deshalb benötige
ich erst sämtliche Einzelergebnisse, um dann das Endergebnis zu bilden.
Updated by hidden almost 6 years ago
Hallo Gerd,
bedeutet das Ticket für dich gelöst oder sind noch Fragen offen ?
Updated by hidden almost 6 years ago
Danke Florian,
das Ticket kann (öffentlich) geschlossen werden.
Gruß Gerd
Updated by hidden almost 6 years ago
- Project changed from 5 to Public Support
- Subject changed from Empfangen von Samples nach Aufruf von Stop() to Receive samples after Stop() - how to adapt order of Stop() call ?
- Description updated (diff)
- Status changed from Customer Feedback Required to To Be Closed
- Private changed from Yes to No
- Resolution set to Solved Issue