Writer hängt ein paar Sekunden nach dem Speichern - 5.2.6.2 Win7 64bit

de-users
#1

Hallo Matthias,

in Ergänzung zu meiner Mail " ... OoOHWHOoO, Thu Jun 01 11:52:47 GMT 2017":

Wenn man eine "odt"-Datei mit z.B. "7-Zip" entpackt, dann hat man i.d.R. Zugriff auf nachfolgende

1. Verzeichnisse

1.1 Configurations2
1.2 META-INF
1.3 Pictures
1.4 Thumbnails

2. Dateien

2.1 content.xml
2.2 ayout-cache
2.3 manifest.rdf
2.4 meta.xml
2.5 mimetype
2.6 settings.xml
2.7 styles.xml
2.8 Thumbnails

Da ich bei meiner Testdatei die Bilder in die LO-WRITER-Datei kopiert habe, sind diese in dem Verzeichnis "[1.3] Pictures" abgelegt.

Wenn man o.a. Verzeichnisse und Dateien wieder packt und das Archiv von "~.zip" in "~.odt" umbenennt, hat man wieder eine funktionsfähige "LO WRITER"-Datei.

3 Tests

3.1 Alle Bilder aus "[1.3] Pictures" gelöscht. Keinerlei bemerkbare Verzögerung nach dem Speichern-Fortschrittsbalken.
3.2 Je mehr Bilder ich in dem Verzeichnis "[1.3] Pictures" belassen habe, desto länger wurde die dann immer mehr wahrnehmbare Verzögerung nach der Anzeige des Speichern-Fortschrittsbalkens.

4 Schlussfolgerungen

Nach der Anzeige des Speichern-Fortschrittsbalkens ist "soffice.bin" noch mit irgendwelchen Arbeiten beschäftigt, wobei der Zeitaufwand dafür durchaus proportional zur Anzahl der Bilder im Dokument ist. Es wird wohl keine Zeit durch eine "Fehler-Schleife" verbraucht. Ich denke, dann würde die Verzögerungszeit nach der Anzeige des Speichern-Fortschrittsbalkens nicht proportional zur Anzahl der zu verarbeitenden Bilder zunehmen.

So kann man wohl 2 mögliche Fehlerursachen annehmen:

4.1.1 Die "soffice.bin" Arbeiten nach Anzeige des Speichern-Fortschrittsbalkens haben sich in neueren LO-Versionen so verlangsamt, dass der Benutzer eine deutliche Verzögerung wahr nimmt.

und/oder

4.1.2 Während der "soffice.bin" Arbeiten nach Anzeige des Speichern-Fortschrittsbalkens wird in neueren LO-Versionen kein zweiter Fortschrittsbalken mehr angezeigt, so dass der Benutzer den Eindruck gewinnt, "LO" wäre in einem fehlerhaften Zustand.

4.2 Auf "bugs.documentfoundation.org" findet sich durchaus ein Eintrag, der das von Dir geschilderte Problem kommuniziert: "Progress bar is not a good indicator for filesave progress" ( https://bugs.documentfoundation.org/show_bug.cgi?id=98731 ).

Gruß
Hans-Werner

#2

Hallo Matthias,

Nur leider scheinen solche Probleme die meisten kaum zu
interessieren. Entweder das Nutzerverhalten ist anders
oder die Nutzer nehmen dann halt ein anderes Programm.

So stehen die Chancen wohl schlecht . . .

wie bereits in meiner vorherigen Mail (HansWernerHerold, Fri Jun 02 15:55:49 GMT 2017) erwähnt, ist das Problem erkannt und offensichtlich seit 26.05.17 (wieder) in Bearbeitung:

Auf "bugs.documentfoundation.org" findet sich durchaus ein Eintrag, der das von Dir geschilderte Problem kommuniziert: "Progress bar is not a good indicator for filesave progress" ( https://bugs.documentfoundation.org/show_bug.cgi?id=98731 ).

So stehen die Chancen doch gar nicht so schlecht ...

Gruß
Hans-Werner

------ Originalnachricht ------

#3

Vielen Dank Hans-Werner für die positive Einschätzung
und für die große Mühe die Du Dir mit der Testdatei
und der Analyse gemacht hast.

Ich werde mir das durch den Kopf gehen lassen.

Die Idee ist gut daß man das odt auspacken kann.
Bei mir wird das "Pictures"-Verzeichnis wohl leer sein.
Ich habe ja nur links zu Bildern.

Eigentlich sollte es dann keinerlei bemerkbare Verzögerung
nach dem Speichern-Fortschrittsbalken geben - so wie
ich Dich verstand. Nur woher kommt dann bei meinem
Text diese Verzögerung?

Werden jedesmal Thumbnails noch erzeugt und dies
dauert halt? Falls es so sein sollte - warum nur?
An den Bildern selbst hat sich ja nichts verändert.

Solange ich nicht weiß was LO da macht in dieser
Zeit - so lange ist da ein ungutes Gefühl im Vergleich
zur 4er Version wo ich das so nicht erlebte.

"Die "soffice.bin" Arbeiten nach Anzeige des Speichern-Fortschrittsbalkens haben sich in neueren LO-Versionen so verlangsamt, dass der Benutzer eine deutliche Verzögerung wahr nimmt."

Keine Ahnung ob dies so ist. Falls es so sein sollte
so wäre wichtig zu wissen warum es langsamer wurde
und was der Nutzen dieser Wartezeit für den Anwender ist.
Wartezeiten sollten kein Selbstzweck sein - nur um die
CPU auszulasten. Daher wäre Transparenz hier wichtig -
was macht LO da.

"Während der "soffice.bin" Arbeiten nach Anzeige des Speichern-Fortschrittsbalkens wird in neueren LO-Versionen kein zweiter Fortschrittsbalken mehr angezeigt, so dass der Benutzer den Eindruck gewinnt, "LO" wäre in einem fehlerhaften Zustand."

Einen zweiten Fortschrittsbalken habe ich bisher nicht bewusst wahrgenommen.
Gibt es denn einen solchen?

"Auf "bugs.documentfoundation.org" findet sich durchaus ein Eintrag, der das von Dir geschilderte Problem kommuniziert"

Prima wenn auf diese Weise eine Abhilfe geschähe !
Es ist halt schade wenn neuere Versionen scheinbar weniger performant laufen. Das stört schon wenn man es von den Vorgängerversionen anders kennt.

Gruss
Matthias