[Problem] TR-064 Problem(e) mit 6.98 Inhouse/Labor

[fipsy]

Was ist das denn für 'ne Antwort? Es ist überhaupt kein Problem, in der Fritzbox Telefonbücher mit einer Größe von mehreren tausend Rufnummern zu speichern. Die von Tellows für die Fritzbox angebotenen CardDAV Telefonbücher haben z.B. 7000 Rufnummern. Es ist offenbar lediglich nicht möglich, diese mit TR-064 herunterzuladen. Und dafür gibt es keinen erkennbaren Grund. Die Begrenzung auf 999 Rufnummern erscheint vollkommen willkürlich.

 

[Grisu_]

Dann melde den Umstand AVM und viel Spaß beim Warten ob es je geändert wird, hier wird dir damit ja keiner helfen können.

 

[PeterPawn]

Die Begrenzung auf 999 Rufnummern erscheint vollkommen willkürlich.

Die steht nun mal so in der phonebook.lua - wenn das jemandem zu wenig ist, kann/muß er halt die Firmware ändern oder das eben als Fehlermeldung bei AVM einreichen.

Vermutlich stammen diese Zeilen noch aus der Ära deutlich eingeschränkterer Telefonbücher:

136 if (nil == param_max) then
137 param_max = tonumber (box.post.max);
138 end
139 if (nil == param_max or param_max < 1 or param_max > 999) then
140 param_max = 999;
141 end

oder sie wurden doch absichtlich (dann sicherlich am ehesten aus Performance-Gründen, denn das muß alles auch noch in einer Glue-Library von "FRITZ!OS" nach Lua "übersetzt" werden, bevor es in der phonebook.lua nur noch in XML-Strukturen gepackt wird) hinzugefügt.

Da jetzt den Teil or param_max > 999 aus den Bedingungen zu nehmen, ist aber eben auch nur eine Fingerübung - die "Standardbegrenzung" auf 999 Einträge (die sicherlich aus Performance-Gründen absoluten Sinn macht, denn wer hat schon Telefonbücher mit > 1000 Einträgen auf einer FRITZ!Box - das dürfte eben nur bei denen für die Anrufsperren der Fall sein) bliebe ja trotzdem bestehen. Eine Art "Paging" beim Auslesen der Daten scheint da schon die Glue-Library nicht zu kennen ... jedenfalls ist kein Wert für den ersten auszulesenden Eintrag zu erkennen, den man für die nächsten 1000 Datensätze dann entsprechend auswählen könnte. Wenn's ganz schlecht läuft, setzt nicht nur der Lua-Code den Wert entsprechend, sondern dann wird er auch noch einmal in der Glue-Library irgendwie begrenzt - selbst wenn das doppelte Vorsorge wäre - oder die Ausführung stirbt gleich, weil die Library mit größeren Werten nicht umgehen kann (was bei "dezimalen Angaben" wie "999" sicherlich unerwartet wäre) und das eben NICHT selbst richtig testet, so daß entsprechende Vorkehrungen im Lua-Code erforderlich waren.

Aber wer wollte das schon testen, wenn er dafür erst einmal ein Telefonbuch mit mehr als 1000 Einträgen anlegen muß - sicherlich auch das schon mit Auswirkungen auf die Performance des Gesamtsystems (und sei es nur, weil die Daten irgendwie im RAM vorgehalten werden müssen und der damit nicht mehr für anderes zur Verfügung steht).

 

[fipsy]

Danke für diese wirklich hilfreiche und gut erklärende Antwort! Du würdest dich wundern, wie viele tausend Nutzer mittlerweile Telefonbücher mit 7.000 Einträgen und mehr haben. Seitdem FRITZ!OS die Einbindung von CardDAV Telefonbüchern unterstützt und Tellows die passenden Sperrlisten im Abo anbietet, ist die Zahl der Nutzer mit so vielen Einträgen sehr groß. Eine Verlangsamung der Box ist dabei nicht zu erkennen. Zumindest nicht bei Boxen ab 7490 aufwärts. Das Telefonbuch in Segmenten auszulesen, wäre eine durchaus charmante Option. Das hatte ich auch schon gedacht. Aber sowas ist ja nicht vorgesehen.

Das Problem ist, dass mein Programm SpamBlockUp nicht mehr richtig funktioniert, wenn die Telefonbücher in der Fritzbox nicht mit denen übereinstimmen, die ich auslese. Es kann dann zu eventuell sogar katastrophalem Fehlverhalten kommen. Und hiervon sind potentiell über 10.000 Nutzer betroffen, die ich mittlerweile habe. Die kann ich ja schlecht alle zum Patchen ihrer Firmware auffordern.

Ich habe das Problem jetzt auch an den AVM Entwicklersupport gesendet. Aber da mache ich mir keine großen Hoffnungen. Vor genau 4 Jahren hatten sie mir zugesagt, dass in absehbarer Zeit auch online synchronisierte Telefonbücher über SOAP zu bearbeiten wären. Das geht bis heute nicht, obwohl sie mittlerweile über die Weboberfläche bearbeitet werden können.

Ich werde also einen Test einbauen müssen und die Nutzer bei Telefonbüchern mit über 998 Einträgen darauf hinweisen, dass sie diese in mehrere Telefonbücher aufteilen sollen. Absolut unschön!

Aber nochmal vielen Dank für deinen Beitrag!