channel_id verändert?

[sumisu]

Das ist schon möglich - hier aber nicht das Prob. Problem ist, dass momentan die channel_id mal so / mal so erzeugt wird (unterschiedlicher Aufbau).

Sumisu

[mb405]

@Nirvana
Danke, das du dir das problem annimmst. das epg speichern funkt ja nicht mehr seit den änderungen von arzka im sectionsd. ein neues diff wäre net schlecht. aber komm nur erstmal wieder.

[mb405]

ich hab nochmal komplett frisch ausgecheckt. jetzt stimmt auch wieder die channel_id. keine ahnung, warum das nicht ging ??

44d00016dca Das Erste
43700016d66 ZDF
44100012ee3 RTL Television
44100012ef4 RTL2
210085002e SAT.1
44100012f1c VOX
2100850382 ProSieben
500850701 DAS VIERTE
2100850383 KABEL1
43100016e2c MDR FERNSEHEN
43100016e41 NDR FS HH
43100016e2e rbb Berlin
44d00016dcb Bayerisches FS
43100016e29 EinsExtra
43100016e2b EinsPlus
43100016e2a EinsFestival
43700016d6e ZDFdokukanal
43700016d6b ZDFinfokanal
43700016d70 ZDFtheaterkanal
44d00016dd0 BR-alpha

nur bei brummiere ist das so auch richtig? oder haben die was gedreht ?

200850008 PREMIERE START
20085000a PREMIERE 1
20085000b PREMIERE 2
20085002b PREMIERE 3
200850009 PREMIERE 4
20085001d PREMIERE 5
200850029 PREMIERE 6
200850014 PREMIERE 7
110085000c Animal Planet
110085000e Discovery
110085000d DISCOVERY GESCHICHTE
110085000f FOCUS GESUNDHEIT
40085002a 13TH STREET
1100850024 Sci Fi
1100850203 MGM
400850017 PREMIERE KRIMI
400850010 PREMIERE SERIE
400850204 PREMIERE NOSTALGIE
700850035 PREMIERE Austria
1100850022 DISNEY
110085001c JETIX
1100850013 Junior
100850016 HEIMATKANAL
100850206 GOLDSTAR TV

[sumisu]

Die IDs wie von Dir aufgeführt (auch Premiere) sind nach der bisherigen Logik (TSID/ONID/SID) korrekt. ABER lt. Info von Nirvana soll sie ja wie folgt aussehen:

Die Reihenfolge ist hierarchisch so korrekt und nicht anders:

Original Network ID
Transport Stream ID
Service ID

Das war ja offenbar auch bei Dir VOR dem erneuten Aus- und Einschecken der Fall. Da ist man sich also offenbar noch uneinig.

Darüber hinaus ist es so, dass (ohne Aus- und Einschecken) die Änderung in der zapittypes.h von:

Code: Alles auswählen

#define CREATE_BOUQUETENTRY_ID(bouquet_id,original_network_id,transport_stream_id,service_id) ((((t_bouquetentry_id) bouquet_id) << 48) | (((t_bouquetentry_id) original_network_id) << 32) | (((t_bouquetentry_id) transport_stream_id) << 16) | (t_bouquetentry_id) service_id)

NACH

Code: Alles auswählen

#define CREATE_BOUQUETENTRY_ID(bouquet_id,original_network_id,transport_stream_id,service_id) ((((t_bouquetentry_id) bouquet_id) << 48) | (((t_bouquetentry_id) transport_stream_id) << 32) | (((t_bouquetentry_id) original_network_id) << 16) | (t_bouquetentry_id) service_id)

dazu führt, dass die channel_id auch wieder passt (gem. bisheriger Logik). Hier wurde also irgendwo an den Makro-Zugriffen gedreht.

Meine Meinung ist daher noch immer: Entweder man ändert die zapittypes.h wie oben angegeben und die channel_id bleibt im Aufbau wie gehabt. ODER aber man passt auch die "alten" Makros auf die neue Reihenfolge an. Ansonsten ist das in meinem Augen inkonsistent.

Vielleicht kann sich Nirvana ja nochmal dazu äussern.

Grüße,
Sumisu

[mb405]

also nach neu auschecken klappt das bei mir wie gesagt wieder prima. nur die timerprogramierung macht mir sorgen. kann sich das mal einer nochmal anschauen ? ich erhalte beim manuellen timererstellen in der timerliste folgenden eintrag.

RTL Television:"

da fehlt der epg eintrag.
erstelle ich den timer aber rot->rot->gelb, dann steht alles wunderbar dort. ich nehme an, das es mit den einchecken folgenden datums zu tun hat. 28.02. oder 01.03. die ganze timerlist geschichte

- make record timer default on "new timer" (gui/web)
- save EPG title in timerd.conf and use it as backup if epg is not available
(timerlist, web-timerlist, recording)

[sumisu]

Es mag sein, dass es nach dem Auschecken wieder prima klappt: Dennoch stehen hier Aussagen im Raum (siehe oben), die sich mit dem momentanen Status nicht decken und die beiden zitierten Teile der Makros widersprechen sich.

Was den Timer angeht: Wenn Du einen manuellen Umschalttimer setzt, war es m.W. schon immer so, dass er sich die dazugehörigen EPG-Daten nicht geholt hat. Die Anzeige von "RTL Television:" " bedeutet nur, dass er nicht weiss, was kommt. M.E. ist das nur Kosmetik.

Auch wenns nervt: Vielleicht kann sich ja Nirvana nochmal zum channel_id-Aufbau äussern (was ist tatsächlich geplant und wie sieht nun die Entscheidung aus, da ggf. nochmal zu korrigieren).

Grüße,
Sumisu

[Nirvana]

Was mir fehlt, ist die Analyse, woran das Drehen der Channel ID nun liegt/lag. Hattest du den EPG-speichern Patch mal drauf oder nicht?

Aus meiner Sicht ist die Sache so:
CreateBouquetEntryID: Das Makro wurde von mir eingeführt und ist deshalb richtig. Ich kann mir nicht vorstellen, dass andere das benutzen, also kann das so bleiben.
CreateChannelID: Das habe ich fürs EPG speichern umgedreht, aber das ist bisher nicht ins CVS gekommen, also kann das auch nicht schuld sein.
Wenn es nach mir geht, kommt das ins CVS und dann ist die ChannelID gedreht und aus meiner Sicht richtig.

Bleibt zu klären, warum bei dir gedreht wurde.

[Barf]

Diese Technik mit Makroprogrammierung ist so Fehlerauffällig und schwierig sowohl zu lesen als auch zu debuggen. Debuggen in sinn von gdb etc ist nicht möglich. Weitere Argumente befinden sich in jeden guten Programmierungslehrbuch.

Bjarne Stroustrup (erfinder von C++) sagt in seinem C++-Buch, dass fast jede Benutzung von Makros in Programme deutete eine Schäche an, entweder in der Programmierspache, oder in dem Programmierer. Oder Beide.

Ich schlage vor, anstatt diese Makros als C++-Funktionen umzuschreiben. In einem Bibliothek (damit wird das Erstellen von Testprogramme möglich). Benutze die Typenüberprüfung in C++, soweit möglich.

Ist wahrschenlich schneller als die versteckte Fehlern zu finden.

Der ganze Thread ist wahrscheinlich ein gutes Beispiel über den Wahnsinn der Makroprogrammieren.

[Nirvana]

*prinzipiell zustimm* aber das ist eine Lösung für ein anderes Problem. Bzw. wir haben ja nicht einmal ein Problem.

[Nico 77]

Was mir fehlt, ist die Analyse, woran das Drehen der Channel ID nun liegt/lag. Hattest du den EPG-speichern Patch mal drauf oder nicht?

Aus meiner Sicht ist die Sache so:
CreateBouquetEntryID: Das Makro wurde von mir eingeführt und ist deshalb richtig. Ich kann mir nicht vorstellen, dass andere das benutzen, also kann das so bleiben.
CreateChannelID: Das habe ich fürs EPG speichern umgedreht, aber das ist bisher nicht ins CVS gekommen, also kann das auch nicht schuld sein.
Wenn es nach mir geht, kommt das ins CVS und dann ist die ChannelID gedreht und aus meiner Sicht richtig.

Bleibt zu klären, warum bei dir gedreht wurde.

Ich denke mal wie rum das gedreht wird ist sumisu egal, wichtig wäre das nicht unterschiedliche Werte ausgegeben werden was ja anscheinend der Fall ist.

[sumisu]

erstmal danke, dass meine Ausführungen doch nicht ungehört bleiben. Es ist letztendlich so, wie nico_77 geschrieben hat: "Glücklich" bin ich dann, wenn die Makros einheitlich definiert werden. Die Reihenfolge, die dabei rauskommt, ist mir egal, da ich die problemlos anpassen kann - zudem wird die mit yjogols Erweiterungen (Ermittlung der channel_id) ohnehin irrelevant.

@Nirvana
Was die Analyse angeht, da tue ich mich letztendlich schwer, da in der zunächst getesteten Variante zwar der EPG-Patch drin war, dieser aber nicht zog. Anyway - meines Erachtens stellt sich diese Frage aber auch nicht. Meine VERMUTUNG ist, dass hier - derzeit leider nicht nachvollziehbar - mal auf das eine und mal auf das andere Makro zugegriffen wird. Alleinig dieser Sachverhalt führt zu Inkonsistenzen und eben diesen Verwirrungen.

Meine Bitte: Was auch immer entschieden wird: macht es einheitlich und pflegt es bitte auch asap ins cvs. Bitte beachtet aber dabei, dass ich nicht der einzige bin, der via Web-Interface auf die channel_id zugreift. Wird man sich also umentscheiden und die Reihenfolge ändern, hagelt es meines Erachten Fehlermeldungen.

Was ich noch nicht ganz begriffen habe: Wie kanne es sein, dass die channel_id derzeit wieder wie früher (also in der aus Nirvanas Sicht falschen Reihenfolge) erzeugt wird? Nach Deinen Ausführungen wäre es ja getauscht. Passiert das dann, wenn Deine Sachen ins cvs eingepflegt werden?

Viele Grüße,
Sumisu

[Nirvana]

Nochmal zur Verdeutlichung: Es IST einheitlich. Nur CreateChannelID entscheidet. Das andere ist mein privater Kram. Es ist NICHT mal so und mal so.
Korrekt ist: Ich hätte es gerne gedreht und wenn EPG speicheren ins CVS käme, wäre es gedreht.
ABER: wenn es gravierende Probleme bereiten würde, könnte ich auch drauf verzichten es zu drehen. Der Sinn liegt darin, dass die EPG Dateien der Sender übersichtlich gruppiert werden und in der richtigen Reihenfolge abgehandelt werden.

[sumisu]

ok - dann nochmal zusammenfassend:

- es sind nunmal 2 Makros da, die letztendlich beide ne channel_id aufbereiten
- auch, wenns Dein privater Kram ist - man weiss ja nie, ob sich da nicht zuffällig oder absichtlich mal jemand das falsche der beiden raussucht (es ist ja im cvs und daher besteht diese Gefahr)
- dadurch ist es meiner Meinung eben NICHT mehr einheitlich (und es ist ja auch in bestimmten Konstellationen schon passiert, dass Dreher auftauchten)
- man sollte CREATE_BOUQUETENTRY_ID wie von mir dargelegt anpassen und alles wäre gut (dann kanns keine Dreher mehr geben)
- sollte man hier der Meinung sein, dass es andersrum gehört und dies auch Sinn macht, um irgendwo andere Sortierungen zu erhalten, dann passt bitte die CREATE_CHANNEL_ID... an (dann wäre es zwar neu und ich bin mir sicher, dass es dann Beschwerden hagelt, aber auch dann wäre die Gefahr nicht gegeben, dass die channel_id nicht "mal so und mal so" erzeugt wird)

Danke,
Sumisu

[Nirvana]

Also langsam werde ich noch wuschig. Wie kannst du derartige Schlussfolgerungen ziehen? Wenn du CreateBouquetEntry veränderst, wird die Sortierung der Sender in ihre Bouquets nicht funktionieren.
Wenn die Mehrheit der Meinung ist, das Drehen der ChannelID führt zu Problemen, dann lassen wir es halt und nehmen eine falsche Gruppierung beim EPG-speichern in Kauf. mb405 hat es ja gestestet und meint das klappt auch. Ist doch kein Thema.
Wenn da nur ein paar Links nicht mehr stimmen, sollte trotzdem gedreht werden, aber das ist nur meine bescheidene Einzelmeinung.
Langsam würde ich mich gerne wichtigeren Problemen zuwenden.

[sumisu]

Nu werd ma nich gleich wuschig - die Schlussfolgerungen ziehe ich aus der Historie der letzten Woche. Wenn es beim Rumdrehen zu einer falschen Gruppierung beim EPG-speichern kommen kann, dann weiss ich leider noch nicht, was das letztendlich zur Folge hat. Anyway - das ganze Hickhack und auch meine Penetranz zu diesem Thema ist auch dadurch entstanden, da noch Deine Aussage im Raum steht, dass Du das andere Makro auch noch umdrehen willst, weil Du es für die richtige Reihenfolge hälst. Die Auswirkungen habe ich beschrieben. Wenn sichergestellt ist, dass auf Dein Makro nur Du zugreifst, ist mir das letztendlich auch egal. Dann kann alles so bleiben wie es ist. Wenns diesbezüglich zu Problemen kommen sollte, erinnert man sich ja vielleicht an diesen Thread...

Peace,
Sumisu

[Nirvana]

Na siehste. Dann lassen wir eben alles wie gehabt und halten fest, dass die Reihenfolge prinzipiell falsch ist, dass das nervt und dass nichts wichtiger ist als dass das noch ein paar Jährchen so bleiben kann.

[Nico 77]

Das heißt jetzt also man lässt eine Ausgabe die technisch richtig, aber trotzdem falsch ist weil sie 2 verschiedene Ausgabewerte ergibt?

Naja mir soll egal sein....

[Nirvana]

Nein, das ist mehr eine Geschmacksfrage, als in die Kategorie richtig und falsch einzuordnen.
Neutrino spricht TSID-ONID-SID und identifiziert die Services so.
Der Rest der Welt spricht: ONID-TSID-SID und nennt die Services so. (siehe google: dvb triplet)
Dadurch werden die Services logisch besser geordnet. Nicht mehr und nicht weniger. Richtig, weil eindeutig ist beides.

[Barf]

Ich kann mich durchaus vorstellen, dass irgendwie liegt ein Problem, vielleicht sogar ein Bug. Dagegen sind die Aussagen leider so weich, vermutungen statt Fakten. sumisu, kannst du ein wirkliger Bug finden und dokumentieren? Ich kann mich durchaus verstehen, dass Nirvana von den jetztige Vermutingen und "mal so, mal so" genervt ist.

Aber damit bin ich nicht fertig.

CreateBouquetEntryID: Das Makro wurde von mir eingeführt und ist deshalb richtig. Ich kann mir nicht vorstellen, dass andere das benutzen, also kann das so bleiben.

(Gibt es ein Grund warum du sagst "CreateBouquetEntryID", wenn es CREATE_BOUQUETENTRY_ID ist?) Ich verstehe, dass du private Funktionen benutzen will, und kann verstehen dass du dich genervt fühlst, wenn jemanden darüber "meckert". Die C++-Programmiersprache gibt aber hervoragende Möglichkeiten private Funktionen zu definieren. Anstatt machst du ein MAKRO in ganz andere (include-)Datei. Das ist nicht sauber Programmierung. Ich halte die Bemerkung

- auch, wenns Dein privater Kram ist - man weiss ja nie, ob sich da nicht zuffällig oder absichtlich mal jemand das falsche der beiden raussucht (es ist ja im cvs und daher besteht diese Gefahr)

für gültig und legitim. Bitte sehe es als freundliche und konstruktive Kritik.

[mb405]

nicht streiten jungs
mir ist auch aufgefallen, das Nirvana das in seinen epg-speichern patch gedreht hat. bei allen anderen images ohne das epg-speichern ist die drehung nicht drin.
am besten man einigt sich auf eine schreibweise. ob die dann absolut richtig ist,kann niemand genau sagen. also eine schreibweise, und gut.
es ist ja im prinzip egal, ob tsid-onid-sid, oder onid-tsid-sid . nur sollte man an einer schreibweise festhalten.

[sumisu]

sumisu, kannst du ein wirkliger Bug finden und dokumentieren? Ich kann mich durchaus verstehen, dass Nirvana von den jetztige Vermutingen und "mal so, mal so" genervt ist.

Ich habe 2 Images, bei der jeweils der Aufbau der channel_id mit http://dbox/control/channellist unterschiedlich erfolgte. Woran dies konkret liegt, konnte ich leider nicht feststellen. Ich stelle jedoch fest, dass damit belegt ist, dass über das Web-Interface beim einen Image Makro a) und beim anderen Image Makro b) verwendet wurde. Nachdem bei Image a) die von mir bereits dargelegte Änderung in "#define CREATE_BOUQUETENTRY_ID" vorgenommen wurde, erfolgt der Aufbau wieder korrekt. Auch dies belegt meine geschildterte Feststellung. Bei Image b) wurde die Änderung in "#define CREATE_BOUQUETENTRY_ID" nicht vorgenommen. Es wurde jedoch komplett neu aus- und eingecheckt. Damit erfolgte der Aufbau auch wieder korrekt. Damit ist belegt, dass NICHT auf das Makro "#define CREATE_BOUQUETENTRY_ID" zugegriffen wird.

Ich konnte somit zwar nicht herausfinden, an welcher Stelle im Web-Interface genau auf das neue Makro zugegriffen wurde, dafür aber belegen, DASS es passierte.

Genau aus diesem Grund möchte ich einfach nur, dass es einheitlich gemacht wird, damit derartige Konstellationen zukünftig ausgeschlossen sind. Ich denke, diese Meinung deckt sich mit der Mehrheit.

Und streiten möchte ich hier auch nicht. Ich fühle mich zum Teil nur leider unverstanden bzw. nicht ernst genommen.

Viele Grüße,
Sumisu

[Nirvana]

„Diskussion ist ein Austausch von Wissen. Ein Streit ein Austausch von Ignoranz.“ – Robert Quillen

Ich halte mich hier ausschließlich an den Austausch von Wissen. Dass ich hier meine Aussagen gleich einer tibetanischen Gebetsmühle wiederholen muss, lässt mich allerdings glauben, dass sie von einigen ignoriert werden.

Und ich weiß, dass die Wahrheit im Quellcode liegt. Sumisu, du schreibst von Image a und b und hättest daran herumgeändert. Images sind für mich compilierte CVS-Stände, meinst du also CVS-Stände? Wenn ja, dann könntest du ja bestimmt durch Posten der entsprechenden Zeile beweisen, dass CREATE_BOUQUETENTRY_ID außerhalb von SIbouquet.hpp benutzt wird. Alles andere sind keine Belege oder Beweise, sondern Behauptungen, Spekulationen und Fehlinterpretationen.
Dir ist wahrscheinlich nicht klar, dass die beiden Makros CREATE_BOUQUETENTRY_ID und CREATE_CHANNEL_ID nicht synonym zu verwenden sind, sondern für unterschiedliche Dinge da sind. Deshalb ist es schon rein von der Logik her nicht möglich sie zu verwechseln.

Falls der obige Beweis nicht erbracht werden kann, können wir annehmen, dass CREATE_BOUQUETENTRY_ID aus dem Spiel ist und so bleiben kann, weil es so bleiben MUSS.
Jetzt können wir uns noch darüber unterhalten, ob der eigenlich Schuldige CREATE_CHANNEL_ID verändert werden soll oder nicht. Sumisu plädiert dafür, weil die Makros dann einheitlich wären. Ich bin auch dafür, weil es der hierarchischen Ordnung entspricht. Es resultierte daraus eine veränderte Anzeige der ChannelID im Webinterface. Dies ist kein Bug sondern ein Feature. Die Frage, ob dies gewünscht ist oder nicht, wollte ich hier eigentlich diskutieren.

@Barf. Zu deiner Fragestellung nehme ich gesondert Stellung, wenn ich mehr Zeit habe.

Gruß

[sumisu]

Ich halte mich hier ausschließlich an den Austausch von Wissen. Dass ich hier meine Aussagen gleich einer tibetanischen Gebetsmühle wiederholen muss, lässt mich allerdings glauben, dass sie von einigen ignoriert werden.

Sorry, aber ich habe genau den gleichen Eindruck. Auch lässt Dieser Absatz mich daran zweifeln, dass Du Dich nicht wirklich an den Eingangssatz halten willst. Aber ich denke mal, wir bewegen uns da im Kreis...

Sumisu, du schreibst von Image a und b und hättest daran herumgeändert. Images sind für mich compilierte CVS-Stände, meinst du also CVS-Stände?

Ich weiss zwar nicht, wo ich das geschrieben habe - aber das war dann falsch. Ich selbst bin lediglich Bauer des TV-Guides und bekomme hin und wieder Images (= in meinem Sinne CVS-Stände), um dort zu testen, ob der TV-Guide damit noch ordentlich läuft. Die von mir dargelegten unterschiedlichen Ergebnisse der channel_id stammen aus 2 verschiedenen Images.

Wenn ja, dann könntest du ja bestimmt durch Posten der entsprechenden Zeile beweisen, dass CREATE_BOUQUETENTRY_ID außerhalb von SIbouquet.hpp benutzt wird. Alles andere sind keine Belege oder Beweise, sondern Behauptungen, Spekulationen und Fehlinterpretationen.

Nein, ich kann den Ursprung nicht beweisen - nur das Ergebnis (siehe meine etlichen Wiederholungen zu dem Punkt...). Ich bin irritiert, dass das Ergebnis einer Abfrage via Web-Interface als Interpretation meinerseits ausgelegt wird. Auch befremdet es mich, dass man mir Behauptungen und Spekulationen vorwirft. Alles, was ich bisher an Feststellungen aufgeführt habe, beruht auf Tests. Nicht mehr und nicht weniger. Ich war bis dato eigentlich der Meinung, dass man sich derartiger FESTSTELLUNGEN annimmt und versucht, darauf einzugehen. Aber leider scheint man das nur als persönlichen Angriff zu verstehen und in selbigen überzugehen (so kommt es jedenfalls bei mir an). Alles andere hätte meines Erachtens eine andere Reaktion Deinerseits hervorgerufen.

Dir ist wahrscheinlich nicht klar, dass die beiden Makros CREATE_BOUQUETENTRY_ID und CREATE_CHANNEL_ID nicht synonym zu verwenden sind, sondern für unterschiedliche Dinge da sind. Deshalb ist es schon rein von der Logik her nicht möglich sie zu verwechseln.

Das ist mir schon klar. Allerdings gelingt es mir nicht, Dir klarzumachen, dass beide Makro mit unterschiedlichen channel_id-reihenfolgen im cvs sind und - seis mit einem Patch - seis mit einem fehlerhaften Einchecken - seis mit was auch immer - in einer nach dem erneuten Aus-/Einchecken nicht mehr reproduzierbaren Konstellation bereits auf das NEUE Makro zugegriffen wurde. Und da kein anderes die im Ergebnis vorliegende Reihenfolge hat, sehe ich das nicht als Spekulation. Und auch stelle ich fest, dass das immer wieder passieren kann - nämlich dann, wenn jemand unbewusst / bewusst das andere Makro nimmt. Und damit stelle ich auch fest, dass es damit nicht mehr einheitlich ist.

Falls der obige Beweis nicht erbracht werden kann, können wir annehmen, dass CREATE_BOUQUETENTRY_ID aus dem Spiel ist und so bleiben kann, weil es so bleiben MUSS.

Annehmen? Warum spekulieren und nicht einfach beide konsistent machen?

Jetzt können wir uns noch darüber unterhalten, ob der eigenlich Schuldige CREATE_CHANNEL_ID verändert werden soll oder nicht.

Solange hier nicht erkennbar ist, dass konstruktiv auch an den "eigenen" Sachen analysiert wird, halte ich mich zukünftig aus der Sache raus (was ja augenscheinlich einigen entgegen kommt). Ich bin kein Neutrino-Guru, jedoch in der EDV-Branche tätig und äusserst verärgert darüber, wie derartige Punkte hier angegangen werden.

Sumisu plädiert dafür, weil die Makros dann einheitlich wären. Ich bin auch dafür, weil es der hierarchischen Ordnung entspricht. Es resultierte daraus eine veränderte Anzeige der ChannelID im Webinterface. Dies ist kein Bug sondern ein Feature. Die Frage, ob dies gewünscht ist oder nicht, wollte ich hier eigentlich diskutieren.

Diese Haltung halte ich für nicht korrekt. Du triffst für Dich die Entscheidung, dass DEINE Reihenfolge die richtige ist, lässt davon nicht ab und stellst nur noch zur Diskussion, ob jetzt die andere auch angepasst wird. Meines Erachtens muss zunächst geklärt werden, für welche Reihenfolge man sich einigt. Auch wenn sie hierarchisch korrekt sein sollte, gibt es Faktoren (bspw. bestehende 3rd-Party-Anwendungen, die ggf. darauf zugreifen), die man nicht ausser Acht lassen sollte.

Sumisu

[Nirvana]

Ich weiss zwar nicht, wo ich das geschrieben habe...

Mir ging es darum:

Nachdem bei Image a) die von mir bereits dargelegte Änderung in "#define CREATE_BOUQUETENTRY_ID" vorgenommen wurde, erfolgt der Aufbau wieder korrekt.

Das kann nicht sein. Siehe Source.

...in einer nach dem erneuten Aus-/Einchecken nicht mehr reproduzierbaren Konstellation bereits auf das NEUE Makro zugegriffen wurde...

Was verstehst du unter neues Makro? CREATE_BOUQUETENTRY_ID? Nein. Nein. Nein. Siehe obige Ausführungen, es war eine modifizierte Fassung von CREATE_CHANNEL_ID auf die zugegriffen wurde - mehr nicht. Du siehst im WebIF eine verdrehte channelID. Unbestritten eine Tatsache, aber du nimmst sie als Beweis, dass die ID von CREATE_BOUQUETENTRY_ID kam. Eine nicht belegbare und noch dazu falsche Behauptung! Das meinte ich.

Und auch stelle ich fest, dass das immer wieder passieren kann - nämlich dann, wenn jemand unbewusst / bewusst das andere Makro nimmt.

Eben nicht. Es ist nie passiert und wird nie passieren, weil es unterschiedliche Dinge sind.

Solange hier nicht erkennbar ist, dass konstruktiv auch an den "eigenen" Sachen analysiert wird

Was meinst du mit eigenen Sachen? CREATE_BOUQUETENTRY_ID? Geht nicht zu ändern, dann stimmt die Reihenfolge in den Bouquets nicht mehr. Siehe oben.

Du triffst für Dich die Entscheidung, dass DEINE Reihenfolge die richtige ist, lässt davon nicht ab und stellst nur noch zur Diskussion, ob jetzt die andere auch angepasst wird. Meines Erachtens muss zunächst geklärt werden, für welche Reihenfolge man sich einigt.

Ich beharre in keiner Weise auf meinem Standpunkt. Ich habe schon ganz oben gesagt: Dann lassen wir CREATE_CHANNEL_ID und CREATE_BOUQUETENTRY_ID wie sie sind und alle sind glücklich. Aber dann kamst du und hast unterstellt, CREATE_BOUQUETENTRY_ID wäre verkehrt und an der verdrehten Anzeige im WebIF schuld. Das kann ich nicht unwidersprochen stehen lassen. Seit dem versuche ich dir klarzumachen, dass CREATE_CHANNEL_ID die Channel ID macht und kein anderer. Und ich werde CREATE_BOUQUETENTRY_ID verteidigen bis auch du einsiehst, dass es mit der Sache nichts zu tun hat und alle deine Befürchtungen bzgl. der Verwechslungsgefahr grundlos sind.

Nirvana