PMT Update überarbeiten
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
PMT Update überarbeiten
Hallo zusammen,
aus aktuellem Anlass (Formel1, Bundesliga usw.) möchte ich noch einmal
das Thema "Update der Bildoptionen" aufgreifen.
Ohne hin und her zappen geht da ja garnicht, auch wenn PMT Update
aktiv ist.
Wie wär es denn wenn sich unsere Spezialisten (Nirvana und Houdini)
dieser Sache mal annehmen?? Das nervt nämlich schon ziemlich...
Gruß
____Paule
aus aktuellem Anlass (Formel1, Bundesliga usw.) möchte ich noch einmal
das Thema "Update der Bildoptionen" aufgreifen.
Ohne hin und her zappen geht da ja garnicht, auch wenn PMT Update
aktiv ist.
Wie wär es denn wenn sich unsere Spezialisten (Nirvana und Houdini)
dieser Sache mal annehmen?? Das nervt nämlich schon ziemlich...
Gruß
____Paule
Zuletzt geändert von PauleFoul am Sonntag 12. März 2006, 18:54, insgesamt 1-mal geändert.
-
- Erleuchteter
- Beiträge: 646
- Registriert: Mittwoch 16. April 2003, 14:12
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
-
- Developer
- Beiträge: 2183
- Registriert: Mittwoch 10. Dezember 2003, 07:59
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
-
- Interessierter
- Beiträge: 64
- Registriert: Samstag 31. Juli 2004, 18:11
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
-
- Developer
- Beiträge: 2183
- Registriert: Mittwoch 10. Dezember 2003, 07:59
Also die Sache ist ganz einfach.
Neutrino holt den aktuellen Event vom sectionsd ab, darin sind die linkage descriptors. Wenn sich diese descriptors ändern bekommt das zwar sectionsd mit (bzw er müsste es mit überprüfen) aber Neutrino nicht. Sectionsd müsste Neutrino also ein Updateevent generieren...
Neutrino holt den aktuellen Event vom sectionsd ab, darin sind die linkage descriptors. Wenn sich diese descriptors ändern bekommt das zwar sectionsd mit (bzw er müsste es mit überprüfen) aber Neutrino nicht. Sectionsd müsste Neutrino also ein Updateevent generieren...
-
- Interessierter
- Beiträge: 64
- Registriert: Samstag 31. Juli 2004, 18:11
und das wird mit channelzap generiert.Houdini hat geschrieben:Also die Sache ist ganz einfach.
Neutrino holt den aktuellen Event vom sectionsd ab, darin sind die linkage descriptors. Wenn sich diese descriptors ändern bekommt das zwar sectionsd mit (bzw er müsste es mit überprüfen) aber Neutrino nicht. Sectionsd müsste Neutrino also ein Updateevent generieren...
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
Das müsste doch aber irgendwie machbar sein, oder??Houdini hat geschrieben:Also die Sache ist ganz einfach.
Neutrino holt den aktuellen Event vom sectionsd ab, darin sind die linkage descriptors. Wenn sich diese descriptors ändern bekommt das zwar sectionsd mit (bzw er müsste es mit überprüfen) aber Neutrino nicht. Sectionsd müsste Neutrino also ein Updateevent generieren...
Sectionsd sagt Zapit ich hab was neues...
Zapit holt ab und bestätigt dies...
Gruß
____Paule
-
- Interessierter
- Beiträge: 64
- Registriert: Samstag 31. Juli 2004, 18:11
-
- Erleuchteter
- Beiträge: 646
- Registriert: Mittwoch 16. April 2003, 14:12
-
- Interessierter
- Beiträge: 64
- Registriert: Samstag 31. Juli 2004, 18:11
Ja .Nirvana hat geschrieben:@Bimmel
Darf ich deinen ausführlichen Hinweis dahingehend interpretieren, dass wenn sich die pmt ändert, zapit dies bemerken soll und so tun soll, als würde der Sender umgeschaltet und sich so die aktuiellen Linkage Descriptors vom sectionsd beschafft?
Das macht pmt-update .zapit dies bemerken soll
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
Scheint aber nicht wirklich zu funktionieren...Bimmel hat geschrieben:Ja .Nirvana hat geschrieben:@Bimmel
Darf ich deinen ausführlichen Hinweis dahingehend interpretieren, dass wenn sich die pmt ändert, zapit dies bemerken soll und so tun soll, als würde der Sender umgeschaltet und sich so die aktuiellen Linkage Descriptors vom sectionsd beschafft?Das macht pmt-update .zapit dies bemerken soll
Gruß
____Paule
-
- Erleuchteter
- Beiträge: 646
- Registriert: Mittwoch 16. April 2003, 14:12
-
- Interessierter
- Beiträge: 64
- Registriert: Samstag 31. Juli 2004, 18:11
-
- Erleuchteter
- Beiträge: 646
- Registriert: Mittwoch 16. April 2003, 14:12
-
- Interessierter
- Beiträge: 64
- Registriert: Samstag 31. Juli 2004, 18:11
Jo , weil da muß/soll noch channelzap ausgelöst werden.PauleFoul hat geschrieben:Scheint aber nicht wirklich zu funktionieren...Bimmel hat geschrieben:Ja .Nirvana hat geschrieben:@Bimmel
Darf ich deinen ausführlichen Hinweis dahingehend interpretieren, dass wenn sich die pmt ändert, zapit dies bemerken soll und so tun soll, als würde der Sender umgeschaltet und sich so die aktuiellen Linkage Descriptors vom sectionsd beschafft?Das macht pmt-update .zapit dies bemerken soll
Gruß
____Paule
Sind alles nur Dämon's.
-
- Interessierter
- Beiträge: 64
- Registriert: Samstag 31. Juli 2004, 18:11
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
-
- Interessierter
- Beiträge: 64
- Registriert: Samstag 31. Juli 2004, 18:11
-
- Wissender
- Beiträge: 1839
- Registriert: Sonntag 17. August 2003, 01:39
-
- Interessierter
- Beiträge: 64
- Registriert: Samstag 31. Juli 2004, 18:11
Eine weitere socket Krücke bauen ?PauleFoul hat geschrieben:Dann gilt es folgendes zu tun:
1. Stellt Sectonsd die daten korrekt zur Verfügung??
2. Wie kann eine Schnittstelle zur "Datenübertragung" aussehen.
3. Zapit beibringen das es Sectionsd gibt...
Gruß
____Paule
Ich sehe es aber als übertrieben.
Ich denke , pmt-update von zapit sollte genügen.
-
- Tuxboxer
- Beiträge: 6044
- Registriert: Montag 17. November 2003, 06:48
Hmm - früher endeten Diskussionen schon immer wesentlich früher mit dem Hinweis darauf, das Sectionsd suckt, hier tut sich ja schonmal wesentlich mehr. Wenn ich das jetzt an dieser Stelle richtig verstehe, fehlt es an einer Schnittstelle zwischen Zapit und Sectionsd? Also vom Prinzip her, sollte Zapit die notwendigen Daten haben, aber kein Weg da sein, Sectionsd das wissen zu lassen?
Überlegung eines Nicht-Programmierers, mit Betrachtung von Seitens eines Plugins, das in neuer Form im CVS ist: Tuxcal.
Bei Tuxcal gibt es einen Thread von Tuxcald, der gleichfalls als Flag arbeitet. Wird dieser gekillt, schaltet sich die Darstellung der Uhr an bzw. ab. Also sollte es doch auch möglich sein, sowas für Sectionsd zu programmieren, so das ein Thread eine Quasi-Aktualisierung ohne Datenverlust der EPG-Daten machen kann. So das Zapit nur diesen Thread killen muß, um Sectionsd zu veranlassen, sich die neuen Daten einzuverleiben.
Oder ist das aus Sicht eines Programmierers unmöglich/zu kompliziert/nicht machbar?
cu
Jens
Überlegung eines Nicht-Programmierers, mit Betrachtung von Seitens eines Plugins, das in neuer Form im CVS ist: Tuxcal.
Bei Tuxcal gibt es einen Thread von Tuxcald, der gleichfalls als Flag arbeitet. Wird dieser gekillt, schaltet sich die Darstellung der Uhr an bzw. ab. Also sollte es doch auch möglich sein, sowas für Sectionsd zu programmieren, so das ein Thread eine Quasi-Aktualisierung ohne Datenverlust der EPG-Daten machen kann. So das Zapit nur diesen Thread killen muß, um Sectionsd zu veranlassen, sich die neuen Daten einzuverleiben.
Oder ist das aus Sicht eines Programmierers unmöglich/zu kompliziert/nicht machbar?
cu
Jens
-
- Erleuchteter
- Beiträge: 646
- Registriert: Mittwoch 16. April 2003, 14:12
Die beiden Strolche leben eben in ihrer eigenen Welt und wissen nicht was der andere treibt. Der einzig (halbwegs vernünftig) gangbare Weg ist der, den Houdini oben aufgezeigt hat. Aber das bedeutet eben einen Haufen if's. In etwa:
if (Event für Sportportal oder Direktportal) and (descriptiors neu <> descriptiors alt) then
generiere update-event
Die Machbarkeit hängt rein vom Willen im Verhältnis zum Aufwand ab.
P.S. sectionsd suckt.
if (Event für Sportportal oder Direktportal) and (descriptiors neu <> descriptiors alt) then
generiere update-event
Die Machbarkeit hängt rein vom Willen im Verhältnis zum Aufwand ab.
P.S. sectionsd suckt.