Kommentare von

Ist mir momentan einfach schleierhaft...  Ich kann nur hoffen, dass das eine Regression der ersten Versuche ist.

Bei mir ist soetwas noch nicht aufgetreten bislang... und die 6 Monate sind auch noch nicht um...🤨

Ich auch nicht! 😲Nun bin ich wieder munter.

Erstmal über diese Zahl: https://de.numberworld.info/4294967295

Sie ist bedeutsam, denn sie bezeichnet das 32-Bit-Integer-Limit bei Computern. Laut Wikipedia:

4 294 967 295 (oder hexadezimal FFFF,FFFF16) ist der größte positive Wert, welcher in einem vorzeichenlosen 32-Bit Integer gespeichert werden kann, und hat dadurch eine besondere Bedeutung in Programmiersprachen und Rechnerarchitekturen, wenn negative Ganzzahlen nicht vorkommen können. So beispielsweise bei Speicheradressen und Indizes.

Computer mit einer 32-Bit-Architektur haben einen 32-Bit breiten Adressbus und (meist) auch 32-Bit breite CPU-Register und können daher maximal 232 Bytes adressieren. Dies entspricht 4 GiB (4 Gibibyte, meist fälschlich als 4 Gigabyte angegeben).

So kann sie als Fehlermeldung verschiedenster Art daherkommen zB., wenn die primary data Zahl bei MySQL Tabellen ihr Limit erreicht hat. Oder auch wenn Festplattenindizes überlaufen bzw an ihr Limit kommen, in Shell Zusammenhängen, usw.

Wie solches überhaupt geschehen kann - und das gerade hier - ist mir ein Rätsel...

-1 in two's complement signed number format (assuming 4 bytes long integers) is 0xffffffff which is the maximum unsigned value that can be stored in the 4 bytes. Two's complement format is used by almost all computers used nowadays (including your PC, Mac and any mobile phone)

Your shell is displaying the program return value as unsigned integer. The decimal representation of the 0xffffffff hex number is 4294967295

Laut dem hier haben wir es also mit einer return Rückgabe als unsigned integer zu tun. Warum gerade hier in einem 14 Jahre alten Blogeintrag... und nicht auch woanders ist mir schleierhaft. Gar ob plötzlich oder schon lange so...?

Am besten gibst du die Angelegenheit auch mal an den Support weiter ... aber schon komisch, denn laut den verschiedenen URLs hast du ja dasselbe auf Manitu und auf deine CH Servern, beides unterschiedliche Systeme mit unterschiedlichen Gegebenheiten. Sie beruhen aber beide auf dem selben Urzustand der Mysql Tabellen, nicht wahr?

Wie bist du darauf gekommen? Bzw hast das gefunden? Reiner Zufall?

Hast du schon weitergeforscht ob das auch in anderen alten Beiträgen auftaucht?

Hast du noch alte Tabellenbackups in denen du überprüfen kannst wieviel Kommentare dieser Eintrag hatte, oder ob da eventuell -1 drinnen steht, oder ob die Struktur der primary ID eine andere ist als andere serendipity comments Tabellen? (Reine Schüsse ins Blaue, meinerseits.)

Soweit erstmal....

Tatsächlich, jetzt 0. Ich würde auch behaupten dass das bis vor kurzem noch auf 4294967295 stand. Umso merkwürdiger ... !

Und alles löste sich in Wohlgefallen auf...

Genau jene dritte Query meinte ich.😎

Deine Wassergläser werden immer herausfordernder...😊

Höchstwahrscheinlich, wie ich schon schrieb, durch einem Übertragsfehler oder einen Fehler der beim Übertrag ausgelöst wurde, denn du hast ja eine neue Styx DB mit alten Daten befüttert, zB wenn dabei irgendeine Prozedur Errormeldung mit -1 geantwortet hat und diese dann dort eingefügt wurde. Da das aber ein comments int UNSIGNED default '0', Feld ist, dürfen nur positive Zahlen eingetragen werden, die Entsprechung von -1 wäre dann also 0xffffffff was dezimal zu 4294967295 wird. So - oder so ähnlich - erkläre ich mir das.  Das du sie dort persönlich hineingeschrieben hast um sie Jahre später als Knobelaufgabe zu verwenden ist daher eher unwahrscheinlich..." 😋

Edit: Oder aber durch einen solchen Error-Prozess bei der damaligen Erstellung des Entries oder danach, zB. durch einen verunglückten Kommentar-Versuch...

🙄 Bin da gerade überhaupt nicht drin und bräuchte mal echte Langeweile um das mir das noch mal grundsätzlich zu Gemüte zu führen.

Irgendwie ähnelt diese Frage auch einer - so ich mich dunkel erinnere - die du schon einmal in diesem Zusammenhang gestellt hast ( ich meine es ging da um den Endjahresvergleich ) und ich zusammenfassend antwortete, dass das wesentlich einfacher wäre, wenn du dir (vorher) einem screenshot machst. Dann kam erst das rollende Jahr für die Anzeige ( meine ich )...

Wäre es deshalb nicht viel einfacher und praktischer dir viertel- oder halbjährlich einen solchen zu erstellen und damit deine Vergleiche anzustellen?

Kurze Frage: Könnte man in den Statistiken unter: Besucher, auf den Monat bezogen (rolling year) auch 13 Monate anzeigen? So könnte man den aktuellen Monat mit dem gleichen Monat vor einem Jahr vergleichen und so feststellen, ob man Besucher gewinnt oder verliert.

Wenn du es bitte mal ausprobieren willst.... 😎

Gehe auf Zeile 1067 und ändere mal die -11 in eine -12

https://github.com/ophian/additional_plugins/blob/master/serendipity_event_statistics/serendipity_event_statistics.php#L1067

und setzte mal

#statistics_yearbox table tr:nth-child(3) td:nth-child(2) {
  background-image: linear-gradient(#ddd, #eee);
}
[data-color-mode="dark"] #statistics_yearbox table tr:nth-child(3) td:nth-child(2) {
  background-image: linear-gradient(var(--color-auto-gray-5), var(--color-auto-gray-0));
  border: 1px dashed var(--color-auto-gray-4);
  border-bottom: 1px inset var(--color-auto-gray-1);
}
#statistics_yearbox table tr:nth-child(-n+2) td:nth-child(2) {
  background-color: #8b008b1c;
  color: blueviolet;
}
[data-color-mode="dark"] #statistics_yearbox table tr:nth-child(-n+2) td:nth-child(2) {
  background-color: darkmagenta;
  color: #d99b9b;
}

in die Zeile 580

https://github.com/ophian/additional_plugins/blob/master/serendipity_event_statistics/serendipity_event_statistics.php#L580

Dann können wir mal reden....