Jfritz kann Anrufliste seit FritzBox Labor nicht holen

[Tippfehler]

Das Problem wurde dort schon vor längerer Zeit gemeldet.

 

[derneueFritz]

oder eine Spende an Robert P. anregen. Habe von 2015 das spendenkonto noch.

 

[mroko]

Würde mich gerne mit einer Spende beteiligen - JFritz ist eigentlich genau das richtige für mich - würde ich gerne weiter nutzen.
Wenn möglich, bitte Spendenkonto bekannt geben - danke

 

[derneueFritz]

alte Mailadresse von Robert P. habe ich noch. Wer würden noch mitmachen? Fragen kostest kein Geld.
Schaue gerade die mailadresse, wurde witer oben auch schon mal erwähnt.: "robot..."

 

[Brown]

Viele in meinen bekannten Kreis nutzen SpamBlockUp. Und alle sind damit zufrieden! Könnte ja eine Alternative für euch sein. Da man da auch die Liste von PhoneBlock nutzen kann, für Spam anrufe. Ist halt das Kostenlose zu tellows.

 

[Zwanzigeinundzwanzig]

Fragen kostest kein Geld.

Frag einfach an, ob er das Programm überhaupt aktualisieren könnte und wenn, was er dafür gern hätte. Dann kann man konkreter damit umgehen...

 

[derneueFritz]

mail ist soeben raus und nicht zurückgekommen. Adresse nach 9 Jahren gültig??
Vielleicht meldet sich jemand.

 

[sprotte24]

Ich habe KEINE LABORversion von FritzOS.
Am 28.10.2024 endet meine Anrufliste.
Von Hand Anrufaktualierung, da passiert nichts. Verbindung zur Fritzbox ist offenbar vorhanden.
Seit dem keine Signalisierung und Fortführung mehr.
Am 31.10.2024 wurde meine Fritzbox 7590 auf 8.00 aktualisiert.

 

[Zwanzigeinundzwanzig]

Welche Version war vorher drauf? Bei mir ging es bis zur 7.90-113235
Zufällig zwischen dem 28. und 31. nicht telefoniert?

 

[sprotte24]

Vollzitat gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ entfernt by stoney

Vorher war es die neueste, die es für die FB7590 gab. Ich glaube 7.51?
Doch, zwischen dem 28. und 31. 10. wurde durchaus telefonniert. Kann ich mit meiner BoxToGoPro-App auf Android auch gut nachvollziehen.
In diesem Zeitraum gab es auch kein Java-Update.

 

[mroko]

Bei mir war bis 13.11.24 folgende Version im Einsatz

Produktname:	FRITZ!Box 7590 (UI)
FRITZ!OS-Version:	7.59

Bis zu diesem Datum wurde die Telefonliste aktualisiert.
Am 14.11.2024 Update auf V8

Bisher verwendet:	FRITZ!OS-Version 7.59
Jetzt installiert:	FRITZ!OS-Version 8.00

Danach keine Einträge bzw. Aktualisierungen mehr in der Anrufliste von JFritz V 0.7.8
Bin mir sicher, wenn ich die Box auf V7.59 downgrade, wird die Anrufliste wieder aktualisiert.
Aber dieses aufwendige Downgraden der Fritz!Box werde ich nicht machen und bringt ja auch nix außer der Erkenntnis, dass ich unter V8 JFritz nicht mehr die Anrufliste abholen kann.
Wäre echt Klasse, wenn die Entwickler von JFritz die Software kompatibel zur Fritz!Box V8 machen könnten.
Bin gerne bereit, dafür etwas zu bezahlen.

 

[armin56]

Die linux_fs_start Methode sollte eigentlich relativ einfach umzusetzen sein, so dass man auf die alte Version einfach umschalten können sollte.

 

[PeterPawn]

Ihr habt aber schon irgendwo mitbekommen, daß bereits im Juni 2024 eine Issue in GitHub zu diesem Problem eröffnet wurde? https://github.com/jfritz-org/jfritz/issues/44

Da erstaunt einen dann die "Überraschung" und das "Rätselraten" hinsichtlich der Ursachen und Gründe, was hier so umgeht und nachzulesen ist, schon ein wenig.

Das Problem sollte auch weniger die Korrektur in den Quellen sein, dazu würde hier: https://github.com/jfritz-org/jfrit...lower/jfritz/callerlist/CallerList.java#L1082 wohl schon ein weiterer else-Zweig ausreichen, wo mit der neuen Header-Line in der exportierten Anruferliste verglichen wird und alle Spalten hinter der neu hinzugekommenen für Landes-/Ortsnetzbereich um einen Indexwert verschoben werden (die Spalte ebenfalls zu importieren dürfte sinnlos sein, denn das sucht JFritz ja selbst noch einmal raus).

Aber heute hat vermutlich kaum noch jemand das für den Build notwendige System bereits aufgesetzt und von einer CI-/CD-Queue für automatische Builds ist in dem Projekt nichts zu sehen. Damit läge der Löwenanteil der Arbeit gar nicht im Fixen des eigentlichen Problems, sondern in dem, was "drumherum" für die Bereitstellung installationsfähiger Pakete noch zu leisten wäre. Da Java (nach meiner Überzeugung zumindest) heutzutage eigentlich tot ist, wird das wohl nur ein wirklicher Enthusiast (entweder als Java-Fan per se oder als Nutzer dieser Software hier) auch leisten WOLLEN.

---

Bliebe allerdings noch eine weitere Option (nur, um sie nicht unerwähnt zu lassen) ... man kann auch in der 8.0 (natürlich nur mit einer eigenen Firmware) die Anrufliste weiterhin im alten Format (also ohne die neue Spalte für LKZ/ONKZ) exportieren, dazu muß man nur die Datei usr/www/$OEM/fon_num/foncalls_list.lua ein wenig patchen:

--- foncalls_list.lua
+++ foncalls_list.lua
@@ -289,7 +289,6 @@
     [[{?3310:661?}]],
     [[{?3310:740?}]],
     [[{?3310:947?}]],
-    [[{?3310:465?}]],
     [[{?3310:572?}]],
     [[{?3310:258?}]],
     [[{?3310:544?}]]
@@ -302,7 +301,6 @@
       call.date or "",
       call.name or "",
       call.number or "",
-      call.area or "",
       foncalls.port_display(call),
       (call.msn_type == 2 and txt_inet or "") .. (call.msn or ""),
       call.duration or ""

Macht man das gleich mit bei den anderen Änderungen, die man ja üblicherweise so an seinem FRITZ!OS-Image vornimmt (und wer täte das nicht), ist das auch kein wirklicher Aufwand - wer JFritz nutzen will, braucht sicherlich die neue Spalte in der AVM-Liste auch nicht wirklich. Allerdings ist die dann auch bei Push-Mails nicht länger dabei ... but who cares? Natürlich kann man auch einen weiteren Parameter für den Download-Request hinzufügen, um zwischen dem alten und dem neuen Format zu unterscheiden ... nur müßte man dann ja dennoch das alte Format zum Standard erklären, damit keine weiteren Änderungen an JFritz erforderlich sind.

Unschwer zu erraten, für welchen Weg ich mich entscheiden würde, FALLS ich JFritz einsetzen WÜRDE. Vielleicht gibt es irgendwann (oder gar jetzt schon, ich verfolge das nicht mehr) auch mal einen passenden Patch für Freetz-NG - das ist ja alles keine "rocket science" und wie oben schon erwähnt, läge der eigentliche Aufwand beim Anpassen von JFritz gar nicht in den notwendigen Änderungen der Quellen (das sind vielleicht 8 zusätzliche Zeilen, wenn man den originalen Stil beibehalten würde), sondern im Zusammenstellen eines Build-Systems und damit dann dem Erstellen der Installationspakete (auch wenn da entsprechende Targets vorhanden sind) für andere und ggf. dann wieder in der weiteren Wartung solcher Pakete und da würde ich (zumindest persönlich) den Weg des deutlich geringeren Aufwands wählen. Blöd halt nur, wenn man seine Firmware nicht anpassen kann (oder wohl eher nicht will) ... aber ich würde auch nicht den Änderungen bei AVM hinterherlaufen wollen, denn niemand weiß, wann sich da das Format erneut ändert (auch wenn es wohl über sehr lange Jahre relativ konstant war, aber nun ist der Damm ja gebrochen).

 

[ejo48]

Seit kurzem ist das Journal leer.

mfg

e.jost

 

[q12345678]

Was soll uns diese Info bringen mit der knappen Beschreibung??
Das Problem wird hier schon bearbeitet.

 

[stoney]

Die Posts #54 + #55 wurden aus einem eigenständigen Thread (breits schon vor Stunden) hier her verschoben.

 

[teimue]

Aber heute hat vermutlich kaum noch jemand das für den Build notwendige System bereits aufgesetzt und von einer CI-/CD-Queue für automatische Builds ist in dem Projekt nichts zu sehen. Damit läge der Löwenanteil der Arbeit gar nicht im Fixen des eigentlichen Problems, sondern in dem, was "drumherum" für die Bereitstellung installationsfähiger Pakete noch zu leisten wäre. Da Java (nach meiner Überzeugung zumindest) heutzutage eigentlich tot ist, wird das wohl nur ein wirklicher Enthusiast (entweder als Java-Fan per se oder als Nutzer dieser Software hier) auch leisten WOLLEN.

---

Ich stimme dir zu, dass bereits eine kleine Codeanpassung (allerdings in CallListCsvLineParser.java) dazu führen würde, dass jfritz wieder die Anruferliste abholen könnte.
Ich habe mir das komplette Repository geladen und bis auf den letzten Schritt (jfritz selbst) übersetzen können. D.h. die Module FritzTR064, fboxlib, proxy und reverseLookup sind compilierbar. Nur jfritz selber eben nicht. Da bleibt der Maven Build Prozess hängen, weil eine Abhängigkeit auf 'de.bausdorf.fritz' nicht auflösbar ist.
Das bedeutet, dass der Buildprozess mit Maven schon normal funktioniert aber ein abhängiges Projekt nicht (mehr?) existiert.

 

[PeterPawn]

allerdings in CallListCsvLineParser.java

Hmm - ich will mich ja nicht streiten (erst recht nicht nur "rein theoretisch"), aber die einzige Stelle, wo ein MAPPING für die Spalten der zu importierenden Datei in der von Dir genannten Quelltext-Datei erfolgt, wäre diese: https://github.com/jfritz-org/jfrit...tz/importexport/CSVCallerListImport.java#L274 und das ist lediglich eine statische Methode für Tests.

Das Format der zu importierenden Daten wird hier: https://github.com/jfritz-org/jfrit...lower/jfritz/callerlist/CallerList.java#L1050 ermittelt und dabei anhand der ersten Zeile mit den Feldnamen (die entsprechenden Zeilen sind als Konstanten am Beginn der Datei definiert: https://github.com/jfritz-org/jfrit...nflower/jfritz/callerlist/CallerList.java#L81) entschieden, welches Format vorliegt und welche Spalte in der Datei auf welchen Inhalt "gemappt" werden soll (mapColumn-Funktion des CSVCallerListImport-Objekts).

BTW - ich habe keinen Schimmer, ob AVM in den anderen Sprachversionen auch diese Header-Zeile angepaßt hat (wie man auch andere Sprachvarianten "untersuchen" kann, habe ich hier: https://github.com/PeterPawn/YourFritz/blob/main/tools/get_page mal gezeigt und das funktioniert auch für die weiter vorne erwähnte Lua-Datei zum Erstellen der Exportdatei im FRITZ!OS) - aber JFritz kennt bisher ja offensichtlich (siehe Link auf Zeile 81) auch nur die deutsche und eine englische Variante, obwohl wohl weitere Sprachen in JFritz selbst verfügbar sind: https://github.com/jfritz-org/jfritz/tree/develop/lang

Will man also nicht den gesamten Parser umschreiben (eine Option wäre es ja, anhand des NAMENS der Spalte auf den Inhalt zu schließen und für verschiedene Sprachen über eine Konfigurationsdatei festzulegen, wie die Spaltennamen in welcher Sprachversion lauten - vermutlich könnte man dann schon anhand der Namen die im FRITZ!OS verwendete Sprache erkennen), dann fügt man nur die zwei neuen Zeichenketten für Deutsch und Englisch mit der zusätzlichen Spalte am Beginn der von mir angegebenen Datei ein und testet dann in dem Zweig, der für die erste Zeile mit sep=; ausgeführt wird (das ist dieser: https://github.com/jfritz-org/jfrit...lower/jfritz/callerlist/CallerList.java#L1061), noch auf diese zwei neuen Header-Zeilen.

Allerdings muß man das - da AVM die neue Spalte irgendwo in der Mitte eingefügt hat und damit die vorhandenen Mappings für die alten Formate nicht länger passen - in einem neuen else-Zweig (hinter DIESER Zeile: https://github.com/jfritz-org/jfrit...lower/jfritz/callerlist/CallerList.java#L1081) machen, da eben die Mappings für alle Spalten hinter der Rufnummer einen um eins höheren Index verwenden müssen, um die Spalte Landes-/Ortsnetzbereich zu ignorieren. Wollte man diese tatsächlich mit importieren (wozu?), müßte man die Behandlung der einzelnen Datenfelder in der CSVCallerListImport.java noch um die Behandlung für diesen Inhalt ergänzen - m.E. die einzige Notwendigkeit einer Änderung in DIESER Datei, wobei ich das eben gar nicht für erforderlich halte.

Das Dependency-Problem mußt Du halt selbst genauer untersuchen - das referenzierte Projekt sollte das hier sein: https://github.com/robbyb67/FritzTR064 und was da in den Projekt-Properties nicht stimmt (bzw. warum das nicht aufgelöst werden kann bei Dir), ist durch "reines Betrachten" nur schwer herauszufinden. Am ehesten würde ich auf eine falsche Versionsnummer o.ä. tippen, aber ohne die entsprechenden Fehlermeldungen des Build-Prozesses ist das auch nur Stochern im Nebel. Vermutlich könnte/müßte man sogar mal genauer nachsehen, was genau diese Version vom Original (https://github.com/mirthas/FritzTR064) unterscheidet, denn mittlerweile ist das Original auch 13 Commits weiter als zum Zeitpunkt des Forks (bzw. der letzten Synchronisation).

Andererseits finde ich das Projekt auch nicht in der Maven-Registry (https://mvnrepository.com/repos/central) - aber mit einer lokalen Installation (https://maven.apache.org/pom.html#Dependencies) sollte sich auch das beheben lassen.

 

[teimue]

Hmm - ich will mich ja nicht streiten (erst recht nicht nur "rein theoretisch"), aber die einzige Stelle, wo ein MAPPING für die Spalten der zu importierenden Datei in der von Dir genannten Quelltext-Datei erfolgt, wäre diese: https://github.com/jfritz-org/jfrit...tz/importexport/CSVCallerListImport.java#L274 und das ist lediglich eine statische Methode für Tests.

Das kann sein. Brauchen wir nicht streiten. Ich hatte nur kurz nach der Fehlermeldung gesucht und diese Fundstelle gefunden. Mag sein, dass dort nur der Import einer CSV Callerlist erfolgt. Dann ist aber der Code redundant.
Aber egal solange ich den Ist-Stand nicht vollständig übersetzen kann, brauche ich nicht nach dem Fix zu schauen.
Einig sind wir uns aber, das das Problem trivial ist und deswegen umso ärgerlicher.
Mir fehlt die Anruferliste auf dem Desktop ungemein...

 

[PeterPawn]

Allerdings gibt es im "Parser" (https://github.com/jfritz-org/jfrit...ritzbox/callerlist/CallListCsvLineParser.java) tatsächlich noch eine Stelle, wo darauf abgestellt wird, daß da nur sieben Spalten in der Import-Datei sein sollen: https://github.com/jfritz-org/jfrit...box/callerlist/CallListCsvLineParser.java#L42 - für mich eine vollkommen unverständliche Redundanz, allerdings wohl tatsächlich die richtige Stelle, wo das direkte Auslesen aus der FRITZ!Box dann scheitert. Nur macht das (für mich zumindest) ja nun überhaupt gar keinen Sinn mehr (wie gesagt, ich nutze das Programm selbst gar nicht und weiß daher auch nicht genau, was es für Funktionen bietet bzw. wie die Fehlermeldung bei neuem FRITZ!OS genau lautet), wenn da mehr als eine "Import-Funktion" existieren sollte und das direkte Einlesen einen anderen Weg nimmt, als der Import aus einer "Textdatei", denn genau diese bietet das FRITZ!OS ja an - sowohl über TR-064 als auch als Download im GUI. Du kannst also doch recht haben mit der zu ändernden Stelle - bzw. mit einer weiteren.

Was man also genau ändern muß (auch die von mir genannte Stelle würde ja dazugehören, wenn man es "umfassend" machen wollte), muß man dann später schauen, wenn erst mal der Build funktioniert.

EDIT:

solange ich den Ist-Stand nicht vollständig übersetzen kann

Probierst Du das weiter (mit einer geänderten Referenz auf ein lokales Projekt) oder gibst Du hier auf?