[Gelöst] Limit für gespeicherte Nachrichten auf dem Anrufbeantworter des FRITZ!OS?

[PeterPawn]

(für Telefonie-Probleme gibt's wohl kein "Unterforum")

Kennt irgendjemand eine AVM-Dokumentation, in der ein Limit für die Anzahl der (alten) Nachrichten auf dem AB angegeben wäre? Ich habe eine Weile gesucht, aber nichts gefunden.

Warum interessiert mich das?

Bei einer Installation in einer kleinen Firma werden die AB-Nachrichten per E-Mail versandt, OHNE sie gleichzeitig vom Speicher zu entfernen. So hatten sich im Laufe der Zeit dann 254 Nachrichten dort angesammelt, weil natürlich niemand löscht, solange sich keiner dafür zuständig fühlt bzw. dafür eingeteilt wurde.

Im Ergebnis war der AB nicht mehr benutzbar - weder konnten Anrufer weitere Nachrichten hinterlassen, noch ließ er sich von einem der vorhandenen FRITZ!Fons abhören oder gar "bedienen" ... es war also auch nicht mehr möglich, mit dem Telefon die alten Nachrichten zu löschen. Die einzige Mitteilung beim Versuch des Zugriffs auf den AB (am Telefon) lautet sinngemäß: Richten Sie den AB in der FRITZ!Box ein.

Nun stellt sich natürlich die Frage, warum das genau bei so einer "krummen" Zahl von Anrufen geschehen sollte und ob die Probleme tatsächlich an deren Zahl liegen würden. Wenn man jetzt weiß, daß man in einem "single byte counter" (also einem einzelnen Byte, welches aus 8 Bit besteht) genau die Zahlen von 0 bis 255 darstellen kann, wobei negative Werte üblicherweise als Zweierkomplement gespeichert werden (wo dann nur noch Werte von -127 bis +127 dargestellt werden können), dann kommt man auch schnell zu der Überlegung, daß natürlich ein Programmierer, der für einen deaktivierten Anrufbeantworter eine "-1" (als einzelnes Byte - in C halt als "[unsigned] char") verwenden möchte, auf diesem Wege zu demselben Wert gelangen würde, der bei der 255. gespeicherten Nachricht vorliegen sollte.

Ausgestattet mit dieser Theorie zur Ursache des Problems habe ich dann erst einmal zwei einzelne Nachrichten vom AB gelöscht (über das GUI der Box) und siehe da ... plötzlich sprang der AB bei einem eingehenden Anruf auch wieder an und sogar die Bedienung desselben war über die FRITZ!Fons wieder möglich. Danach habe ich dann natürlich auch alle anderen alten Nachrichten entfernt ... damit ist wieder etwas Zeit gewonnen, bis das Problem (sofern sich an der Organisation der Zuständigkeiten nichts ändert) erneut akut wird.

Solange AVM jetzt nicht tatsächlich irgendwo ein entsprechendes Limit veröffentlicht hat (und eines mit 254 wäre mir vermutlich auch wg. des Wertes schon aufgefallen), halte ich das für einen Bug in der Firmware - nur melde ich halt ungerne "auf Verdacht" (und liege am Ende gar noch falsch damit) und daher richte ich die Frage aus dem Titel hier auch an andere. Sicherlich sind 254 Nachrichten auf einem AB nicht das tägliche Brot für FRITZ!Box-Besitzer (es ging auch nicht um "neue Nachrichten", sondern um die Gesamtzahl), da könnten solche Bugs sich dann allerdings auch recht lange "verstecken".

Aber vielleicht hilft es dem Nächsten ja auch, wenn er vor einem ähnlichen Problem steht ... sicherlich kann man das auch durch Löschen des AB (mit anschließendem Neueinrichten) erreichen, weil dabei auch die Nachrichten in der Rundablage landen. Aber dann hat man ggf. noch einige weitere Einstellungen vorzunehmen (von Zeitplänen bis zum eigenen Spruch) und das kann man vermeiden, wenn's wirklich am "Füllstand" scheitern sollte. Hier würde ich mir von AVM dann aber auch eine entsprechende Nachricht im GUI und auf den Telefonen (zumindest auf den hauseigenen Modellen) wünschen ... denn bei einem rechtzeitigen "AB ist (fast) voll" im Display wäre das Problem sicherlich auch viel leichter zu identifizieren und zu verhindern gewesen.

EDIT: Kommando zurück ... es gibt die 254 tatsächlich bei AVM - ich habe sie nur nicht gefunden (eigene Dummheit): https://avm.de/service/fritzbox/fri...ufbeantworter-zeichnet-keine-Nachrichten-auf/

EDIT2: Von "Speicher voll" (wie bei AVM beschrieben) war auf den FRITZ!Fons trotzdem nichts zu sehen (und im GUI auch nicht, wo das dann natürlich hilfreich wäre - ebenso in der Online-Hilfe) und das "Richten Sie den AB ein." (beim langen Druck auf die "1" - also dem direkten Anruf des AB vom FRITZ!Fon C5) ist ebenfalls verbürgt. Also ein Mittelding aus Bug und "beschrieben" - es steht zwar irgendwo die Zahl, aber die Reaktion der restlichen Komponenten ist nicht die beschriebene.

 

[Grisu_]

Dann wird die Beschreibung eben für "Speicher voll" gelten (müßte man halt verifizieren) und im anderen benannten Fall bei Überschreitung der Anzahl schaltet sie nur den AB ab durch vereinfachte Programmierung.

 

[eisbaerin]

Eine Meldung sollte kommen:
https://avm.de/service/fritzfon/fri...tion/show/147_FRITZ-Fon-meldet-Speicher-voll/

 

[PeterPawn]

Mir wurde versichert (das war ja meinerseits nur Fernwartung), daß eine solche Meldung nicht zu sehen war - zumindest nicht auf den zwei vorhandenen C4 (und das glaube ich auch, denn ein "Speicher voll" hätten die Mitarbeiter*innen dort auch verstanden). Vielleicht kommt die ja nur einmalig oder für eine gewisse Zeit, wenn die 254. Nachricht aufgenommen wurde - das wäre natürlich (zumindest bei einer Firma, obendrein noch im Lockdown, wo nicht ständig jemand vor Ort den AB abhören kann) blöd.

Andererseits erklärt es die "Besonderheiten" ("keine Nachrichten" beim Druck auf die "Umschlag"-Taste und "Richten Sie den AB in der FRITZ!Box ein." beim versuchten Anruf des AB über die "1") an der Stelle ja auch nicht ... und ich hätte immer noch gerne auch einen entsprechenden Hinweis im GUI der Box, daß das Limit erreicht ist bzw. sogar schon eine Warnung, wenn sich die Zahl dem Maximum bis auf einen einstellbaren Wert (meinetwegen auch Prozentsatz) genähert hat - je nach Anrufaufkommen (wie gesagt, im Lockdown ist das alles noch "unwägbarer") muß man da ja schon früher einschreiten.

Selbst in den E-Mails des AB wäre es m.E. angezeigt, dann eine entsprechende Warnung zu platzieren - erst recht dann, wenn dieses (krumme) Limit offenbar doch bekannt ist (und mich wohl nur meine eigene Dummheit in den ersten Anläufen davon abhielt, entsprechende Ergebnisse bei AVM zu finden - es ist halt nicht jeder in der Lage, sinnvoll zu suchen und ich übe weiter) und sich doch gehörig von den 400 möglichen Einträgen in der Anrufliste unterscheidet. Da gehört es dann zur guten UX, daß man den Benutzer darauf hinweist - wenn man's schon bei allem möglichen anderen Quatsch auch macht, wo man über die Notwendigkeit doch eher geteilter Meinung sein kann.

Wenn man schon weiß, wonach man suchen muß (nämlich zusammen mit "254", was die Treffer doch deutlich einschränkt), findet man das allerdings sogar in der Online-Hilfe: https://service.avm.de/help/de/FRITZ-Box-5490-avme/018/hilfe_tam_edit - halt nur nicht da, wo ich es erwartet hatte (und das weiterhin erwarten würde): https://service.avm.de/help/de/FRITZ-Box-5490-avme/018/hilfe_tam_list

Was dann noch die "ganz hohe Schule" wäre, ist ein passender Link in den E-Mails mit den AB-Nachrichten (wenn der nicht auf "Nach dem Versand löschen" eingestellt ist), mit der auch ein Benutzer mit "nur Phone"-Rechten die Nachricht (wenn das GUI extern freigeschaltet ist) nach entsprechender Anmeldung direkt löschen kann - gerade in Lockdown-Zeiten, wo auch "ungeübte Mitarbeiterinnen" von daheim den Telefon-Dienst abwickeln sollen, wäre das schon eine Erleichterung. Einerseits kann/will man die Nachrichten nicht gleich beim Versand entfernen, weil man nie sicher sein kann, daß der Umgang mit dem E-Mail-Client (oder gar irgendeinem muchtigen HTML-GUI für den Mail-Account) auch tatsächlich "sitzt" und dann nicht Nachrichten "aus Versehen" gelöscht werden und andererseits läuft dann eben auch schnell der AB voll.

Die Nerven, jetzt jemandem die Bedienung des FRITZ!OS-GUI zu erklären (mal abgesehen von der Notwendigkeit des passenden Accounts, wenn das dann nicht mit "nur Phone"-Berechtigungen klappt), der gerade mal halbwegs unfallfrei einen Web-Browser bedienen kann, habe ich jedenfalls (erst recht derzeit) nicht und alles andere, was es von AVM da gibt (bis hin zu den Apps), braucht wieder passende Gerätschaften (und einzelne Accounts, abgesehen davon, daß man die Apps heutzutage "aus der Ferne" praktisch nicht mehr konfigurieren kann und dazu jeweils das Gerät im WLAN der Box sein müßte) und ist auch vor "Fehlbedienungen" nicht sicher. Wenn so ein Link gezielt eine einzelne Nachricht löscht (und auch noch die richtige), ist das jedenfalls deutlich einfacher, als alles andere, was derzeit zur Verfügung steht.

Allerdings müßte AVM dazu den Nachrichten wohl tatsächlich passende (GU)IDs zuordnen, weil dann mit "Lösche die vierte Nachricht aus der Liste." auch kein Blumentopf mehr zu gewinnen ist - das limitiert auch die Möglichkeiten (neben dem Problem der Bearbeitung des E-Mail-Templates) für eigene Erweiterungen an dieser Stelle (gut, man könnte auch mit dem Hash über die Nummern, Datum/Uhrzeit und Dauer arbeiten, dann wird nur die Suche nach der richtigen Nachricht etwas aufwändiger).

EDIT: Ich habe mir die Seite mit den AB-Messages im GUI gerade noch einmal angesehen ... die "Identifikation" der Nachrichten beim Abhören/Löschen erfolgt da tatsächlich nur mit einem "Index" in der Liste und wenn es wirklich zur parallelen Bearbeitung von Nachrichten kommt (gut, wenn's keinen Lockdown gibt, kommt das sicherlich eher selten vor), dann geht das auch schnell durcheinander - selbst wenn der Index nicht von 0 bis zum Maximum läuft, sondern dekrementiert wird, so daß die letzte Nachricht in der angezeigten Liste den Index 0 hat.

Das stellt zumindest schon mal sicher, daß eine gerade erst eingegangene Nachricht nicht die komplette Liste durcheinander wirbelt - deren Index ist dann halt noch gar nicht in der älteren Seite enthalten.

Aber wenn jetzt Benutzer A eine Nachricht löscht und Benutzer B dasselbe für eine zweite macht, die (zeitlich) nach der ersten liegt (also jünger ist und damit einen höheren Index-Wert hat), dann würde - sogar wenn die Anzeige in den Browsern der beiden Benutzer tatsächlich dieselbe Liste darstellen sollte - trotzdem die falsche Nachricht gelöscht ... weil beim Löschen der Index natürlich auf die aktuell vorhandene Liste angewandt wird und da haben sich die Indizes durch das Löschen von Benutzer A schon um eins "nach unten" verschoben (beim Abhören über das GUI gilt dann ähnliches, auch da kann die Firmware schnell mal eins daneben langen).

Wenn AVM sich tatsächlich auch als SOHO-Anbieter positionieren will, sollte es m.E. auch möglich sein, daß mehrere Personen (aka Mitarbeiter*innen) das GUI unfallfrei parallel benutzen können bei der Arbeit - erst recht dann, wenn die sich nicht länger "in Rufweite" zueinander befinden und aus dem Home-Office auf die FRITZ!Box zugreifen müssen/wollen.

 

[Ralf-Fritz]

Das Limit für die Sprachnachriten auf den AB hochsetzen, damit es möglich ist mehr als 254 Sprachnachrichten zu speichern.

Ich hatte dein Problem auch mal 2019 bei einem Freund (kleine Firma), es war genügend Speicher vorhanden aber es wurden keine Sprachnachriten mehr aufgezeichnet. Soweit ich mich erinnern kann, hat er eine Meldung bekommen "Speicher voll" aber er hatte es nicht richtig interpretieren können, weil ja noch Speicher frei war. Eine Meldung wie "Maximale Anzahl der Sprachnachriten vorhanden" ist für den Benutzer eigentlich Sinnvoller, die ist Eindeutig. "Speicher voll" obwohl noch freier Speicher verfügbar ist, ist für den Anwender schwierig zu verstehen.

 

[eisbaerin]

und dann nicht Nachrichten "aus Versehen" gelöscht werden

Als Schnellhilfe:
Ist es möglich mehrere E-Mail Adressen anzugeben?

 

[PeterPawn]

Das läuft derzeit über einen Verteiler, der ggf. die Nachrichten an mehrere Empfänger*innen vervielfältigt - allerdings ergeben sich (wg. der Lockdown-Verlängerung gibt's halt neue Ideen/Notwendigkeiten) dabei dann auch wieder "Reibungsverluste", weil bei entsprechendem Anrufvolumen ein zeitlicher Wechsel nicht mehr ausreicht und es nun parallel gehen soll bei der Bearbeitung von Anrufen (bzw. AB-Nachrichten).

Daher werde ich wohl aus dem Verteiler ein IMAP-Postfach machen und dann dafür sorgen, daß das "Verschieben" der eingegangenen Nachrichten in einen "In Bearbeitung"-Ordner (einen pro Bearbeiter) zumindest mal als Semaphore dafür dient, wer denn nun diese eine Nachricht bearbeiten will/soll. Der zweite Zugriff kann dann die Message nicht mehr verschieben und endet (wenn der IMAP-Client nicht zuvor schon automatisch aktualisiert) mit einem entsprechenden Fehler. Das regelt dann zumindest mal mein Problem mit den konkurrierenden Zugriffen ... für das Löschen bin ich noch am Suchen und (nachdem die Liste bei AVM tatsächlich nur mit den Indizes arbeitet, siehe EDIT oben) muß vielleicht sogar für das (normale) Löschen über das GUI tatsächlich die Firmware noch modifizieren, damit an die Stelle der "Zählung" der Nachrichten eine eindeutige ID tritt und auch beim parallelen Arbeiten mit dem GUI (zum Löschen der abgearbeiteten Nachrichten) keine Unfälle auftreten können.

Ob tatsächlich die Angabe von mehreren Empfängern für die Push-Mails möglich ist, habe ich gar nicht erst geprüft (für mich fast wieder ein Security-Problem, wenn man einen Empfänger "dazuschmuggeln" kann, ohne daß der Rest der Empfänger etwas bemerkt) - der SMTP-Server steht unter meiner eigenen Kontrolle und da kann ich die Nachrichten so verteilen (und duplizieren), wie ich es brauche.

 

[eisbaerin]

Reicht es dann nicht, daß du die E-Mails noch in ein Backup schickst und auf der FB gleich löschen läßt?
Wer kommt denn im Notfall auf die FB?
Ist es da nicht einfacher eine Kopie aus dem Backup bereit zu stellen?

 

[PeterPawn]

Dazu muß man ja erst mal bemerken, daß da bei der Verarbeitung etwas schiefgegangen ist - hier ist ja weder die Anzahl der eingehenden (und zu bearbeitenden) Nachrichten vorher bekannt, noch die jeweiligen Bearbeiter*innen. Wenn da jemand versehentlich die falsche Nachricht löscht (egal ob in der E-Mail oder auch in der AB-Liste der Box), fällt das nicht wirklich auf (oft genug nicht mal der Bearbeiter*in) - das ist ja tatsächlich "versehentlich" und mangels besseren Wissens und nicht absichtlich. Selbst wenn ich die Nachricht irgendwo als zusätzliches Backup speichern würde - erst beim Löschen auf dem AB (was dann für die nicht richtig bearbeitete Nachricht nicht erfolgen würde) besteht die Chance zu erkennen, daß diese (verloren gegangene) Nachricht von niemandem bearbeitet wurde und fröhlich vor sich hin altert.

Das mit dem "Verteilen" an mehrere Empfänger ging halt solange gut, wie es "feste Bereitschaftszeiten" oder Zuständigkeiten gab und A z.B. die Nachrichten bearbeitete, die zwischen 09:00 Uhr und 11:00 Uhr hinterlassen wurden, während B dann von 11:00 Uhr bis 13:00 Uhr übernahm. Wenn es jetzt tatsächlich parallel gehen soll (first seen, first handled), wird es komplizierter - es gibt ja auch Gründe, warum es in "richtigen Call-Centern" dann ein Warteschlangen-Handling und eine "Zuteilung" von Tasks gibt. Das ist mit einer kleinen FRITZ!Box und ihren begrenzten Möglichkeiten halt nicht so einfach und trotzdem will ich hier nicht mit dem "großen Besteck" ran, weil das sicherlich keine permanente Lösung sein wird (hoffentlich jedenfalls) und der Aufwand sich im Rahmen halten soll.

Aber wenn so ein Rückruf als Beratungsgespräch dann im Schnitt 15 Minuten dauert, schafft eine einzelne Berater*in halt auch nur 4 Nachrichten pro Stunde - gehen dann 8 davon pro Stunde ein, braucht's einfach die zweite Arbeitskraft (sonst entsteht sofort ein unerwünschter Backlog und die Anrufer*innen wenden sich anderen Dingen zu (warten nicht länger auf den Rückruf) oder suchen sich Alternativen bei anderen Anbietern - schon das Hinterlassen der Nachricht ist oft eine Hürde, weil es dann nicht "sofort" weiter geht für die Anrufer*innen) und beide brauchen irgendwelche (halbwegs passenden) Werkzeuge, weil sie üblicherweise keine Ahnung von IT haben (sind i.d.R. schon ältere Semester) und ich tatsächlich schon froh bin, wenn die Browser-Benutzung mit passenden Lesezeichen soweit funktioniert, daß die AB-Nachrichten auch ihr Ziel erreichen. Und Kollisionen im Arbeitsablauf werden bei mehr als zwei handelnden Personen dann immer wahrscheinlicher ...

Im Moment ist halt auch vieles Improvisation - aber irgendeine Lösung findet sich eben immer. Es ist nur immer wieder frustrierend (wer kennt das nicht), wenn einem von vollkommen unerwarteter Stelle dann Knüppel zwischen die Beine geworfen werden. Und das alles natürlich dann bei Anforderungen, wo als Termin gerne "gestern" angegeben wird ... vermutlich weil die Verlängerung des Lockdowns genauso überraschend war, wie die Existenz von Jahreszeiten.

 

[NDiIPP]

Das Problem ist mir bei mehreren verschiedenen Boxen auch schon aufgefallen. Eine entsprechende Meldung "Speicher voll" gab es dabei m.W.n. jedoch nie. Zugegebenermaßen hatte ich in diesen Fällen nie nachgezählt, wie viele Nachrichten es genau waren. 254 kommt mir im Nachhinein sogar etwas wenig vor, hätte über 300 oder gar 400 geschätzt. Aber nun weiß ich, dass es max. 254 sind.

Was mich dabei noch viel mehr stört, das Löschen der Nachrichten über das Webif. Wenn man mehr als 200 Nachrichten einzeln löschen möchte, dann ist das kaum praktikabel da man dies bei jeder einzelnen Nachricht bestätigen und anschließend abwarten muss. Und "Alle löschen" ist kaum hilfreich, wenn man bspw. die letzten 20 oder 30 Nachrichten noch auf der Box behalten möchte.

Also neben einer Anzeige im Webif (falls diese Einschränkung nicht behoben werden kann/sollte), wie viele Nachrichten noch aufgenommen werden können (also bspw. "120 von 254" noch frei" o.ä.) wünsche ich mir insbesondere auch eine Möglichkeit zum löschen einzelner Nachrichten, indem man zuvor die zu löschenden bspw. per Auswahlkästchen auswählen kann. Denn letztlich bleibt einem bis jetzt wohl nicht anderes übrig, als auf "Alle löschen" zu klicken (wenn man da nicht jemanden hinsetzt der die Nachrichten in einer 8h-Schicht einzeln löscht).

 

[pw2812]

Ich kann zumindest für mein betagtes Fritz!Fon MT-C, welches an einer Fritz!Box 7490 angemeldet ist, bestätigen, dass im Display die Meldung "Speicher voll" erscheint, wenn die maximale Anzahl an AB-Nachrichten erreicht ist.

Anmerkung: Das Fritz!Fon MT-C ist das Mobilteil, welches auch zum sog. Fritz!Fon 7150 gehört. Baugleich gibt es das Modell auch von Swissvoice für die Baureihe Eurit 5x7. Im DECT-Monitor der FB steht beim MT-C als Hersteller übrigens "AVM/Swissvoice".

 

[127]

Benutze Thunderbird Labels um zu markieren.
Wenn fertig einfach Nummertaste 6 drucken und das Bericht wird braun.
Auch auf meine andere Computer.

 

[H´Sishi]

Ich denke es wäre für AVM wahrscheinlich eine schnelle Änderung, den Ein-Byte-Zähler auf den Typ "UInteger" (Werte von -16384 bis +16383) zu ändern. Der fehlende Komfort, gezielt *einige unter vielen* Nachrichten zu löschen, um Platz zu schaffen, ist umständlicher zu lösen, aber das muss man dann nicht sofort erledigen.

MMn. kann eine Funktion "Nachrichten älter als ... Tage löschen" ebenfalls zügig programmiert werden. Wenn ein Kunde nach zwei oder maximal 4 Wochen keine Antwort erhalten hat und den Angerufenen auch nicht über andere Wege kontaktiert hat, hat sich entweder das Problem erledigt - oder der Kunde. Letzteres tut weh, aber so lernen Verantwortliche evtl., was "schleifen lassen" und / oder Billiglösungen (Technik, Personal) für Auswirkungen haben.

 

[Grisu_]

Oder bei Erreichen des Limits anstelle des AB auf den oder einen dezidierten (AB voll) Absagetext umzuschalten. Dann erhält man möglicherweise wenigstens Kundenfeedback, daß der AB nicht abhebt.
Könnten auch ein Feld machen "auf Absage umschalten" oder "älteste Nachricht automatisch löschen" bei Erreichen des Limits.
Wobei letzeres vermutlich für das AVM-Kundensegment die beste Lösung wäre, da die ohnedies schon veraltet sind und der Anruf hat sich erledigt bzw. ist nicht mehr relevant.
Es bräuchte halt nur im Bemerkungstext daneben stehen und schon kennt man sich aus wie es sich wann verhält und warum.

 

[PeterPawn]

den Ein-Byte-Zähler auf den Typ "UInteger" (Werte von -16384 bis +16383) zu ändern.

Ich vermute mal (ohne das jetzt getestet zu haben), daß dieser Zähler sich in einer der binären Strukturen (fx_conf oder tamconf, etc.) befindet - und wenn da tatsächlich "aus Sparsamkeit" am Beginn nur ein einzelnes Byte vorgesehen war, wird schon die Programmierung der Unterscheidung zwischen alter und neuer Version des Formats aufrissig ... das wird AVM am Gluteus Maximus vorbeigehen, wenn das Limit an AB-Nachrichten erreicht wird, weil kleine Firmen im Lockdown halt auch mal längere Zeit "geschlossen" haben.

Es sind ja auch ein paar, eher spezielle Randbedingungen, die hier zu berücksichtigen sind/waren bzw. zu diesem Problem mit dem AB-Überlauf führten - was man auch organisatorisch lösen kann, indem man eben Zuständigkeiten bestimmt und dann muß sich eben tatsächlich jemand hinsetzen und die "abgearbeiteten" Nachrichten einzeln löschen, wenn es mit "alle auf einmal" nicht möglich ist. Aber es ist eben auch gut zu wissen, wo die Limits einer FRITZ!Box liegen.

==========================================================

Im Moment bin ich gerade dabei, das systematisch zu testen mit den konkurrierenden Zugriffen auf die Liste der Nachrichten ... bei der 113.07.21 (also 7490) werden komischerweise die Indizes nach dem Löschen gar nicht reorganisiert (obwohl ich beschwören würde, daß ich das gestern (bzw. heute morgen, denn es war schon nach 0 Uhr) genau so auf der 5490 mit ihrer 07.12 beobachtet habe) - wenn ich auf der 7490 die älteste Nachricht lösche (die hatte den Index 0 - der steht als "value" in den HTML-Properties des "button"-Elements), dann behält die zweitälteste ihren Indexwert von "1" und zwar auch in allen weiteren Fenstern und Browser-Instanzen, in denen ich die Seite derzeit aufrufe:

<button type="submit" class="icon delete" id="delete_1" name="delete" value="1" title="Löschen" onclick="return OnDelete(this.value)"></button>

DAS sorgt dann wieder dafür, daß auch konkurrierende Zugriffe auf die Liste beim Löschen nicht den falschen Eintrag entfernen - hier wäre das also absolut richtig umgesetzt. Nur stellt sich dann wieder die Frage, wann die Indizes von wem reorganisiert werden - also wann aus der "1" für den zweiten (und letzten noch vorhandenen) Anruf irgendwann die "0" wird. Und es bleibt (für mich) die Frage, ob meine Beobachtungen bei der 5490 (da gibt's halt bisher auch nur die 07.12 von AVM) nun falsch waren oder eben durch eine zwischendurch doch erfolgte Reorganisation der Indizes verfälscht - und genau um das zu erkennen, suche ich nach dem "Auslöser" einer solchen Reorganisation. Möglicherweise hat AVM das auch einfach gefixt - in der Info-Datei für die 07.21 habe ich dazu nichts gefunden.

Für diese Reorganisation der Indizes kommen ja mehrere denkbare Auslöser in Frage ... einer wäre der Neustart (der bei der 5490 halt auch zwischendrin erfolgte, um auszuschließen, daß sich der AB (bzw. der "telefon"-Daemon) da einfach nur verfranzt hatte), ein weiterer das "DeleteAll" (was hinter dem "Alle löschen"-Button liegt) und u.U. könnte das sogar bei der täglichen Hygiene der Box (Aktualisieren von Statistiken, Push-Mails, etc.) gegen 0 Uhr erfolgen - ich war ja über diesen Zeitpunkt hinaus mit dem Problem (auf der entfernten Box) befaßt.

Nach dem, was ich in der "foncalls.lua" bei AVM lese, kommen die Indizes (als Property "index" in der "Zeile" für eine Nachricht in der Lua-Table) auch direkt aus der (binären) Library "libcallloglua", mit der AVM sicherlich das (sonst eher langwierige) Handling der Anrufliste umgesetzt hat ... und offenbar verwaltet diese Library die AB-Nachrichten gesondert (zum Abruf gibt's die Funktion "GetTamCalls", zum Löschen "DeleteTamCall") zur normalen "Anrufliste".

Die Indizierung muß da auch gesondert erfolgen (und nicht von der Anrufliste allgemein vorgegeben sein), denn wenn die Anrufliste nicht mit einem ständig wachsenden Wert arbeitet (von dem nichts zu sehen ist nach meiner Ansicht) und ihrerseits auf 400 Einträge limitiert ist, muß da ja auch irgendwann mal etwas "nach unten rutschen". Wäre es ein immer weiter wachsender Index in der Anrufliste allgemein, ergäbe das ja auch für die AB-Nachrichten keinen Index "0" für die älteste Nachricht und keine monoton steigenden Werte (zumindest vor der Reorganisation der Indizes bzw. beim "ersten" Aufruf der Nachrichten-Liste).

Wobei eins auch ins Auge fällt - in der Anrufliste regelt AVM das alles ohne solche Index-Werte, da sind die Links zum Abspielen ein direkter Verweis auf die Datei und bei der Übernahme ins Telefonbuch stehen alle Daten ebenfalls in der URL, die hinter dem Button liegt ... das macht "Verwechselungen" durch abweichende Index-Werte dann natürlich auch unmöglich. Und das alles, obwohl dort ein Löschen einzelner Einträge mittendrin gar nicht möglich ist - somit auch keine "Verwirrung" durch (parallele) Benutzer-Aktionen auftreten kann, sondern nur durch Reorganisation seitens der Software oder durch "Bumpen", wo die ältesten Einträge automatisch rausgeworfen werden.

Also wird wohl irgendwo in der "libcallloglua" entschieden, wie diese "Indizes" für die AB-Nachrichten aussehen sollen bzw. sie werden dort generiert. Auch die gesonderte Property "index" spricht dafür, denn in Lua sind zwar Tables Arrays (assoziative) und Arrays Tables (mit numerischen Index, der durchaus auch mal "0" sein DARF), aber die Lua-eigenen Libraries arbeiten üblicherweise auch mit einem Index-Wert, der bei "1" beginnt (und so machen es dann die meisten Erweiterungsbibliotheken auch, wenn AVM hier nicht irgendwelche Sonderwege gehen will) - für viele Umsteiger von anderen Sprachen ist das auch erst einmal etwas gewöhnungsbedürftig, weil die meisten halt doch mit "0" starten bei einem Index. Und die AVM-Liste der AB-Nachrichten beginnt irgendwann einmal (auch wenn ich noch nicht weiß, wann das genau ist) mit einem Index von "0".

Ich muß wohl erst einmal die 7490 auf 07.12 setzen, damit wenigstens gleiche Bedingungen vorhanden sind beim Testen und ich nicht am Ende einem Problem hinterher laufe, was AVM wirlich genau von der 07.12 zur 07.21 mit gefixt hat. Jedenfalls trifft für die 113.07.21 wohl das oben von mir angenommene Problem bei parallelen Zugriffen doch nicht (mehr?) zu (üblicherweise teste ich solche Sachen ja zuerst ausführlich und schreibe dann - hier war's mal anders herum, weil das "aus dem praktischen Betrieb" und nicht aus der Suche nach Fehlern oder Security-Problemen entstand) ... das ist bedauerlich, denn es erschien als plausible Erklärung für "vermißte" AB-Nachrichten (die anhand der Anrufliste vorhanden sein mußten, aber nicht mehr existierten), wo davor und dahinter die Nachrichten (und die Sprachdateien zu diesen anderen Nachrichten) aber ebenfalls noch vorhanden waren, so daß es auch kein NAS-Problem gewesen sein sollte.

Aber das führt jetzt alles doch weiter vom Titel und dem Limit der Nachrichten auf dem AB weg ... und ehe ich hier weiter irgendwelche Schweine durchs Dorf treibe, was "entdeckte Fehler" angeht, teste ich lieber noch einmal gründlich und mit System - wie sonst üblicherweise auch - und fasse die Ergebnisse erst einmal für mich zusammen.

Für die Organisation der Arbeit dort, wo das Problem auftrat, bleibt's jetzt erst mal bei Zettel und Stift (bzw. Computer und Tastatur) und dem "Sammeln" der abgearbeiteten Messages - dann werden die Listen abends eingesammelt und die betreffenden Nachrichten auf einen Rutsch, aber durchaus noch selektiv, gelöscht. Wenn man das mit dem "DeleteTamCall" von Hand macht und in Lua eine Schleife über die Indizes laufen läßt bzw. die zu löschenden Indizes (wenn sie nicht fortlaufend sind) in einem Array hat, über das man iterieren läßt, geht das schon (vorübergehend) ... wobei bei AVM für "DeleteAll" dann wohl einfach wieder der Index-Wert "-1" verwendet wird (neben dem Index des jeweiligen AB - also erst Lesen, bevor man selbst dort herumexperimentiert).