murphy's dashboard

Hallo Bernd,

der Fehler ist funktional behoben. Vielen Dank, dass ihr euch auch dieser Kleinigkeit angenommen habt, und schön dass sie so schnell beseitigt werden konnte!

Etwas ist meinem peniblen QS/QE-Auge dabei noch aufgefallen ;) Beim ersten MouseOver erscheint der Tooltip unmittelbar, bei jedem weiteren mit ein paar 100 ms Verzögerung. Merkt vermutlich kaum jemand außer mir, könnte aber darauf hindeuten, dass der Code an der Stelle noch nicht ganz sauber ist =)

P.S.: Kann ich von mir gepostete Probleme irgendwie selbst auf gelöst setzen?

So, nun habe ich herausgefunden, wann genau der Fehler auftritt – er existiert also doch reproduzierbar!

Bewegt man den Cursor über den Dateinamen UND wartet, bis der angezeigte Tooltip ausgeblendet wird, erscheint dieser eben DOCH NICHT wieder – solange man nicht zwischendurch über ein anderes Feld fährt, wo ebenfalls ein Tooltip angezeigt wird.

Um auch den letzten, möglichen Missverständnissen vorzubeugen:

1. Mauscursor über den Dateinamen in den Details bewegen -> sobald Tooltip erscheint, Mauscursor wegbewegen -> Mauscursor zurück auf den Dateinamen -> Tooltip erscheint.

2. Mauscursor über den Dateinamen bewegen -> warten, bis der Tooltip ausgeblendet wird -> Mauscursor auf ein anderes Feld mit Tooltip bewegen -> Mauscursor zurück auf den Dateinamen -> Tooltip erscheint.

3. Mauscursor über den Dateinamen bewegen -> warten, bis der Tooltip ausgeblendet wird -> Mauscursor ein Stück wegbewegen (z.B. nach oben) -> Mauscursor zurück auf den Dateinamen -> Tooltip erscheint NICHT!

Offenbar wird der Status des Tooltips nach AUSBLENDEN desselben nicht korrekt zurück gesetzt. Ich denke, mit dieser detaillierten Beschreibung und Hilfestellung dürfte es ein Leichtes sein, den Fehler zu finden und auch zu beheben ...

Vor allem andere Prioritäten, als nur mal EINEN guten Grund GEGEN die Implementation einer Listenansicht zu benennen ;]
Die Filterung ist in bestimmten Fällen sehr hilfreich und wird von mir in sofern auch gern genutzt, hinsichtlich einer generellen Verbesserung der Übersichtlichkeit insbesondere bei Dateinamen mit mehr als ca. 50 Zeichen (bei mir fast alle Wuala-Dateien) stellt sie jedoch leider nur eine Art mäßig effektiven Workaround dar :|

Die gute Nachricht: Die Störung bei der Tooltip-Anzeige war anscheinend ein einmaliger Ausreißer oder zumindest sehr selten auftretender Sonderfall. – murphy, on October 11, 2009 09:45

Okay, die Dateinamen unter den Icons habe ich natürlich nicht gemeint, denn da bekommt vermutlich niemand einen Tooltip ;) ... Wäre allerdings nur konsequent, wenn er dort auch erschiene, zumal aus nach wie vor unerfindlichen und nie genannten Gründen keine Listenansicht der Dateien existiert.

In der Tat meinte ich den Dateinamen in den Details, welche allerdings auch erst dann dargestellt werden, wenn man eine Datei auswählt – d.h. zur Anzeige des vollen Dateinamens sind also jeweils mindestens zwei Schritte nötig, wenn der Platz in den Details nicht ausreicht.

Zum beschriebenen Fehler: Der war zum Zeitpunkt des Reports mehrfach reproduzierbar, tritt aber nun nicht mehr auf. Mal beobachten, ob es dabei bleibt ...

Ergänzung: Beim Einsatz von FSI werden oft nicht alle Filetransfers abgearbeitet, sodass – wie pillo schon schrieb – mehrere Durchläufe erforderlich sind. Ärgerlich ... ansonsten aber keine Fehlermeldungen. (Vielleicht aber auch nur, weil die beim Upload nie auftraten :] Download muss ich noch testen.) – murphy, on October 09, 2009 08:25

So, hier mein erster detaillierter Bug Report ...

Bei Download von 31 Files à 3 MB per Drag and Drop Fehlermeldung:

"Der Remotespeicherdienst konnte die Datei nicht zurückrufen."

Trat auch bei mehrfachen Versuchen immer schon nach dem 1. File auf.

Bei Download per Rechtsklick und "Herunterladen nach ..." Fehlermeldung:

'********.JPG' konnte nicht heruntergeladen werden.
Grund: Wuala konnte keine Verbindung mit den Internet aufbauen.
com.wuala.common.exception.CouldNotConnectException: Error.CouldNotConnectException.msg, empty 188.40.96.207-LIST could not connect to 188.40.96.207, ports=50035, null

Trat während des Kopierens beim 14. von 31 Files auf, danach kam ein längerer Hänger, danach Download der restlichen Files.
Das fehlende File konnte scheinbar im Download-Fenster "nachgestartet" werden, lief bis 100%, wurde aber nicht gespeichert.

Anschließend Zielordner und Cache restlos geleert (auch manuell = 0 Byte) und zweites Verfahren wiederholt.
Im Gegensatz zum ursprünglichen Download (Minuten) Transfer aller (!) Files nun rasend schnell (Sekunden).
Dabei Anzeige bei den Files im Downloadfenster unmittelbar nach Kopierstart bereits 100%!
(Kann mir das jemand erklären?!)

Anschließend erstes Verfahren wiederholt, selbes Ergebnis wie beim zweiten Versuch des zweiten Verfahrens. Weitere Tests mit denselben Files daher offenbar sinnlos.

Wenn's mal wieder was zum downloaden gibt, nächster Bericht.

Was is mit pillo? Verfrühter Winterschlaf? Urlaub? :)

Nee, genau damit fing es ja an (siehe pillos erste Postings). Ersatzweise per FIS zu synchronisieren hat dann leider auch nicht funktioniert ...

Vielleicht kann pillo ja noch mal einen präzisen und detaillierten Bug-Report abliefern, und sofern ich dazu komme (bzw. es dazu kommt) werde ich das dann auch tun!

Das versteht sich natürlich alles von selbst, und vor allem an kostenlose Software habe ich auch keine übertrieben hohen Erwartungen. Doch in diesem Falle reibe ich mich an zwei Punkten:

1. Der Fehler ist definitiv plötzlich und dann auch wiederholt aufgetreten, davor jedoch nie. Daraus würde ich den Umkehrschluss ableiten, dass er durch eine Veränderung am Code ausgelöst wird, die a) vermutlich nicht unbedingt etwas mit timeouts zu tun hat und b) theoretisch reversiebel bzw. – sofern der Fehler lokalisierbar wäre – durch stabileren Code ersetzbar sein müsste.

2. Der Fehler trat bei pillo und mir durch Nutzung von absoluten Grundfunktionen auf (Download einer mittelgroßen Anzahl mittelgroßer Dateien) und scheint sich daher nicht auf seltene Sonderkonstellationen verschiedenster Faktoren zu beschränken. Andererseits erstaunlich, dass sich bisher "nur" 5 Leute zu dem Problem gemeldet haben ... vielleicht eine Wechselwirkung mit anderer Software oder einer bestimmten Netzwerkkonfiguration, wer weiss.

Gerade deshalb erhoffe ich mir von einer grundsätzlich neu gestrickten FSI, dass die eigentliche Fehlerursache, sollte sie nicht mit bekannten Bugs in direktem Zusammenhang stehen, sich quasi per Zufall gleich mit erübrigt.

Eine Bitte hätte ich jedoch: Sobald die neue FSI verteilt wird, im nachfolgenden Newsletter vielleicht einen der selbstwerbenden Sätze streichen und dafür eine kurze Mitteilung über das grundlegende Update einflechten ;o) Optimalerweise kombiniert mit einem Link für Rückmeldungen im Forum, dann haben wir auch wirklich alle was davon ... inklusive Blogmuffel =)

Soweit ich den Newsletter vom 20. August 2009 verstehe, erschliesst sich die Verwendung von Backup-Ordnern ausschließlich Pro-Usern (siehe Flag neben der Überschrift). Daher habe ich mich mit dem Thema gar nicht erst weiter beschäftigt ... – murphy, on October 05, 2009 15:26

Zumindest die von pillo und mir (vorwiegend) verwendete Datei-Synchronisierung basiert darauf, weshalb große Hoffnung besteht, dass der Fehler wenigstens bei Gebrauch entsprechender Tools nicht mehr auftreten wird ... und vielleicht erübrigt er sich dann ja auch (tatsächlich zufällig) bei manuellen Kopiervorgängen ;>

Vor allem gehe ich aber davon aus, dass so etwas wie hier http://getsatisfaction.com/wuala/topi... beschrieben nicht noch einmal vorkommt. Thread ebenfalls komplett unbeantwortet, da vermutlich ein (evtl. auch nicht reproduzierbarer, hab's seitdem nicht mehr drauf ankommen lassen) Einzelfall.

Insofern bin ich sehr neugierig auf eine vollständig überarbeitete Filesystem Integration; selbst wenn der ursprünglich beschriebene Fehler damit nicht behoben wird, lässt er sich doch immerhin dadurch umgehen ...

Dem ist im Grunde schon so, da auf den Fehler hier (wie schon in zahlreichen anderen Threads zuvor) nicht direkt eingegangen wurde – sowie die Vermutung, dass er (hoffentlich, wenn auch nicht zufällig) im Rahmen eines grundsätzlichen Updates verschwinden wird, offenbar auch zutreffend ist.

Generell bin ich natürlich auch ein Freund grundsätzlicher Problemlösungen, anstatt an einzelnen Symptomen herumzudoktorn, aber das hätte dann auch schon vor Monaten und nicht erst jetzt hier Erwähnung finden können ... denn nicht jeder ist mit Wuala so eng verbandelt, dass er ständig irgendwelche Blogs (dortiger Eintrag erst wenige Wochen alt!) oder welche "diversen Stellen" auch sonst durchstöbert :)

An geeigneter Stelle wie z.B. den seit Bestehen des Problems erschienenen Newslettern, die jeden User erreichen, stand (neben reichlich Selbstlob und Eigenwerbung 8) von solch wichtigen Entwicklungsschritten jedenfalls nichts ...

Siehe mein letztes Posting ... seitens Wuala ist offenbar den Fehler aussitzen angesagt, und unsererseits hoffen, dass er bei irgendeinem Update irgendwie zufällig verschwindet :]

Mit oder ohne* interessiert sie** nicht die Bohne!

Mal so Fanta4 zitier ... =)

* den hinreichend beschriebenen Fehler
** die Nasen von Wuala

Das dürfte daran liegen, dass es wie alle anderen Probleme, die nicht mindestens 10.000 Nutzer betreffen, entgegen aller beteuernden Phrasen an anderer Stelle einfach weiter ignoriert wird =]

Habe soeben Bekanntschaft mit demselben bzw. einem ähnlichen Fehler geschlossen:

http://getsatisfaction.com/wuala/topi...

Ziemlich üble Sache, so ein heftiger Bug ist mir bisher noch nicht untergekommen :(

Scheint auf der Prioritätenliste nicht weit oben zu stehen ;]
Ich habe Windows XP Professional SP3, just for the records.

Ja, ok, hatte ich eigentlich auch nicht anders erwartet ... nix für ungut! ;D
Deine Erklärung wirft jedoch eine weitere Frage auf:
Das mit dem "unlöschbaren Cache" kenne ich wiederum auch vom Internet Explorer, dagegen hilft nur manuelles löschen des Ordners "Temporary Internet Files".
Wenn dich die 20 MB wirklich stören, warum klappt bei dir analog dazu ein Löschen des Ordners "Wuala\Data" nicht?