Ich hätt da gerne mal wieder ein neues Problem. Ich hol mal etwas aus.
Mir hat da ja jemand den Floh ins Ohr gesetzt, unter die Scrobbler zu gehen. D.h. Ich mach hier Musik, und nebenbei läuft ein weiterer Thread, der die aktuellen Titel an meinen LastFM-Account "scrobbelt".
Beim Scrobbeln gibt es zwei Varianten. Die "Now Playing Notification" und die "Submission". Für die beiden gibt es zwei verschiedene URLs (die werden beim "Handshake" bei Beginn übermittelt), an die per Post gewisse Daten übertragen werden. Ersteres liefert nur ein kurzes "Ich spiele grade das hier ..." (was nach einigen Minuten wieder verschwindet), letzteres pflegt den übertragenen Titel auch in die LastFM Datenbank/Statistiken ein. Über diese können dann andere Nutzer meinen Musikgeschmack einsehen, Ähnlichkeiten finden, neues entdecken, ... Web2.0 halt.
Ersteres ("Now Playing") geht recht fix, letzteres bringt mich etwas zur Verzweiflung. Ich vermute mittlerweile, dass der Server hinter der Submussion-URL zu einigen Tageszeiten etwas überlastet ist - ich bekomme regelmäßig ConnectTimeouts und/oder ReadTimeouts, die heute morgen nicht auftraten. Nach einigen Versuchen klappt es dann meistens/oft/manchmal(?).
Im Code habe ich
Delphi-Quelltext
1: 2:
| fIDHttp.ConnectTimeout:= 20000; fIDHttp.ReadTimeout:= 20000; |
gesetzt.
Zum Senden habe ich prinzipiell eine
While Error do TryAgain-Schleife. Aber das kann es ja nicht so wirklich sein, oder? Wie geht man da sinnvoller ran?
Die Developer-Hinweise auf LastFM sagen: Bei drei "hard failures" hintereinander (da würde ich die Timeouts zu zählen), soll der "Handshake" neu aufgebaut werden. Geht dabei was schief: 1 Minute warten, und das Intervall bei weiteren Fehlern verdoppeln (bis max. 120 Minuten).
Das Tolle dabei ist nun, dass der Handshake über die "schnelle URL" geht und bisher immer direkt in Nullkommanix erledigt war. Dann kommen wieder die Timeouts bei dem lahmen Submission-Dingens.
Irgendwelche Ideen dazu?
We are, we were and will not be.