Was läuft da schief:
Leute, ich habe heute wieder mal zu viel Zeit mit PiCtory Ärger verbracht.
Nach Umstellen des Timeouts in den Usersettings und anschließendem abspeichern und Neustart von PiCtory bekomme ich trotz F5 mit dem Firefox immer noch den alten Wert angezeigt, wenn ich wieder in die Usersettings gehe. Ein Blick in die Datei _usersettings.json sagt mir allerdings, dass meine Aktion erfolgreich war.
Also (mal wieder) das alte Browser Cache Problem. Das müsste wirklich mal beseitigt werden. Und bitte Frank sag nicht wieder, dass das nicht geht oder zu schwer zu realisieren wäre. Ich kenne keine andere Web-basierte Konfigurationssoftware, die so ein Problem hat. Das nevt ind kostet den Kunden sehr viel Ärger und Zeit.
Ein Löschen des kompletten Browser-caches über das Firefoxmenü ist ein absolutes no go!!! Ich will doch nicht nur wegen der Unfähigkeit von PiCtory mit geänderten Dateien umzugehen jedesmal nach der Konfiguration meinen kompletten Cache leeren müssen. Und sag nun bitte nicht ich soll in PiCtory den Cache ausstellen. Denn genau diese Funktion ist ja selber vom Caching betroffen und holt sich nicht den neuen Wert aus der aktuellen Datei.
Nach vier Jahren erwarte ich einfach, dass so was mal beseitigt wurde und reibungslos funktioniert.
PicTory timeout wird nicht übernommen
Re: PicTory timeout wird nicht übernommen
Nachtrag:
Offenbar gibt es zusätzlich zu dem Cache Problem sogar noch ein zweites Problem: Trotz Einstellung von Timeout "off" bekomme ich ein Session timeout. Offenbar wirkt sich die Einstellung nicht auf das Login der Session aus. Geht gar nicht!!! Hat Eigentlich endlich mal einer der Entwickler selber Projekte mit dem RevPi gemacht? Hat Frank endlich mal mit dem Teil aktiv gearbeitet und nicht nur den RevPi auf seinem Schreibtisch als Kommunikationspartner betrieben? Dann wäre Euch klar, dass allein die Tatsache, dass ich bei einem abgelaufenen Timeout noch munter weiter konfigurieren kann und dann aber erst beim Abspeichern erfahre, dass meine Arbeit für die Tonne war, ein absolutes no-go ist.
Offenbar gibt es zusätzlich zu dem Cache Problem sogar noch ein zweites Problem: Trotz Einstellung von Timeout "off" bekomme ich ein Session timeout. Offenbar wirkt sich die Einstellung nicht auf das Login der Session aus. Geht gar nicht!!! Hat Eigentlich endlich mal einer der Entwickler selber Projekte mit dem RevPi gemacht? Hat Frank endlich mal mit dem Teil aktiv gearbeitet und nicht nur den RevPi auf seinem Schreibtisch als Kommunikationspartner betrieben? Dann wäre Euch klar, dass allein die Tatsache, dass ich bei einem abgelaufenen Timeout noch munter weiter konfigurieren kann und dann aber erst beim Abspeichern erfahre, dass meine Arbeit für die Tonne war, ein absolutes no-go ist.
Re: PicTory timeout wird nicht übernommen
Hallo Volker,
Deine Feststellungen sind richtig - allerdings gab es seit der Einführung des 'RevPi' darüber praktisch keine Beschwerden, so dass bisher nicht die Notwendigkeit bestand, hier einzugreifen. Ich gehe davon aus, dass die allermeisten Nutzer schlicht auf eine Art und Weise mit 'PiCtory' arbeiten, bei der sie erst gar nicht auf die von Dir beschriebenen Probleme stoßen - indem sie zum Beispiel einfach oft manuell zwischenspeichern und deshalb die 'Timeout' Problematik bei ihnen nicht zuschlägt. Grundsätzlich hast Du aber, wie gesagt, völlig recht - es handelt sich um zwei getrennte Fehler, von denen ich den ersten für das kommende Release bereits behoben habe: die _userSetting.json Datei wird zukünftig automatisch von jedem Caching ausgenommen, so dass sicher gestellt ist, dass man tatsächlich immer und in jedem Browser die zuletzt gespeicherte Version aktiv hat, auch wenn man den Cache nicht manuell löscht.
Der zweite von Dir festgestellte Punkt ist etwas schwerer zu adressieren: es gibt nämlich nicht EINEN, sondern tatsächlich ZWEI Timeouts. Der erste wird auf der Browser-Seite aktiviert und kann, wenn das Setting korrekt gespeichert und (aktuell noch) nach Cache-Löschung auch in -PiCtory- aktiv ist, auch bei jeder Änderung in -PiCtory-, zum Beispiel schon beim Eingeben eines Wertes im Werte-Editor, oder beim Ziehen eines Geräts in den Arbeitsbereich, geprüft und gemeldet. DIESER Fehler kann also nicht bewirken, dass man viele Änderung gemacht hat, die dann erst beim versuchten Speichern plötzlich flöten gehen.
Das eigentliche Problem ist der ZWEITE Timeout, auf der auf der Server-Seite die PHP-Session betrifft und dort nur indirekt und nicht trivial manipuliert werden kann. Dieser Timeout wird aktuell nicht mit dem Browser-Timeout abgeglichen, das stimmt, und habe ich bereits auf meiner ToDo-Liste. Dieses Problem ist schon länger bekannt, und ich kann nur noch einmal betonen, dass ich diese Maßnahme sicher bereits schon länger durchgeführt hätte, wenn sich User darüber reihenweise beschwert hätten. Da das nicht der Fall war ist es in meiner Prioritäten-Liste leider weit nach hinten gerutscht; ich danke Dir aber ausdrücklich dafür, dass Du es wieder in den Fokus gerückt hast.
viele Grüße & bleib gesund
Frank
Deine Feststellungen sind richtig - allerdings gab es seit der Einführung des 'RevPi' darüber praktisch keine Beschwerden, so dass bisher nicht die Notwendigkeit bestand, hier einzugreifen. Ich gehe davon aus, dass die allermeisten Nutzer schlicht auf eine Art und Weise mit 'PiCtory' arbeiten, bei der sie erst gar nicht auf die von Dir beschriebenen Probleme stoßen - indem sie zum Beispiel einfach oft manuell zwischenspeichern und deshalb die 'Timeout' Problematik bei ihnen nicht zuschlägt. Grundsätzlich hast Du aber, wie gesagt, völlig recht - es handelt sich um zwei getrennte Fehler, von denen ich den ersten für das kommende Release bereits behoben habe: die _userSetting.json Datei wird zukünftig automatisch von jedem Caching ausgenommen, so dass sicher gestellt ist, dass man tatsächlich immer und in jedem Browser die zuletzt gespeicherte Version aktiv hat, auch wenn man den Cache nicht manuell löscht.
Der zweite von Dir festgestellte Punkt ist etwas schwerer zu adressieren: es gibt nämlich nicht EINEN, sondern tatsächlich ZWEI Timeouts. Der erste wird auf der Browser-Seite aktiviert und kann, wenn das Setting korrekt gespeichert und (aktuell noch) nach Cache-Löschung auch in -PiCtory- aktiv ist, auch bei jeder Änderung in -PiCtory-, zum Beispiel schon beim Eingeben eines Wertes im Werte-Editor, oder beim Ziehen eines Geräts in den Arbeitsbereich, geprüft und gemeldet. DIESER Fehler kann also nicht bewirken, dass man viele Änderung gemacht hat, die dann erst beim versuchten Speichern plötzlich flöten gehen.
Das eigentliche Problem ist der ZWEITE Timeout, auf der auf der Server-Seite die PHP-Session betrifft und dort nur indirekt und nicht trivial manipuliert werden kann. Dieser Timeout wird aktuell nicht mit dem Browser-Timeout abgeglichen, das stimmt, und habe ich bereits auf meiner ToDo-Liste. Dieses Problem ist schon länger bekannt, und ich kann nur noch einmal betonen, dass ich diese Maßnahme sicher bereits schon länger durchgeführt hätte, wenn sich User darüber reihenweise beschwert hätten. Da das nicht der Fall war ist es in meiner Prioritäten-Liste leider weit nach hinten gerutscht; ich danke Dir aber ausdrücklich dafür, dass Du es wieder in den Fokus gerückt hast.
viele Grüße & bleib gesund
Frank
Re: PicTory timeout wird nicht übernommen
Ich möchte ungern "nachtreten", aber ist das eine neue Produktmanagementmethode: "Design by complains"???
Re: PicTory timeout wird nicht übernommen
Hallo Volker, Danke für Dein Feedback.
Wir nehmen Deine Anregungen gerne auf.
KUNBUS lebt einen Prozess zur kontinuierlichen Verbesserung des Revolution Pis.
Das Feedback aus dem Forum ist dabei ein wichtiger Aspekt,
da es uns hilft zu erkennen, wo Themenschwerpunkte der Community liegen.
Bei der Priorisierung neuer Features, funktionaler Optimierungen
und Bugfixes für die Software Releases berücksichtigen wir selbstverständlich
diesen Input.
Wir nehmen Deine Anregungen gerne auf.
KUNBUS lebt einen Prozess zur kontinuierlichen Verbesserung des Revolution Pis.
Das Feedback aus dem Forum ist dabei ein wichtiger Aspekt,
da es uns hilft zu erkennen, wo Themenschwerpunkte der Community liegen.
Bei der Priorisierung neuer Features, funktionaler Optimierungen
und Bugfixes für die Software Releases berücksichtigen wir selbstverständlich
diesen Input.
