BayWotch Support Forum

Verfasst: **29.09.2004, 01:14**

Hallo alle

Wenn ich über Nacht mittels:
baywotch /catupdate /scanfav /scanincomplete /scanjobs
'alle Favoriten abgleiche', die 'nicht abgeglichene Artikel abgleiche' und die 'offenen Jobs abgleiche' erhalte ich regelmässig bis zu 5% 'ungültige Artikel'. Wenn ich diese danach wieder anwähle und erneut abgleiche, werden diese wieder 'gültig' und werden z.B. danach als 'erfolgreich', 'laufend' oder 'nicht erfolgreich' erkannt d.h. nicht alle 'ungültigen Artikel' sind ungültig...

(Die wirklich ungültigen bleiben dabei natürlich 'ungültig').

Ich habe das jetzt gerade nochmals ohne Befehlszeilenparameter getestet:
1. Favoriten abgleichen
2. alle 'nicht abgeglichenen Artikel' suchen
3. alle markieren und abgleichen
Resultat:
von 600 Datensätzen sind 6 'ungültig'
4. diese 6 Artikel markieren und manuell nochmals abgleichen
Resultat:
alle 6 Artikel werden in 'laufende' Auktionen umgewandelt.

Ist das sonst auch noch jemandem aufgefallen?

Ausserdem tritt dabei folgendes zusätzliche Problem auf (vor dem erneuten manuellen Abgleich der falschen 'ungültigen Artikel'): Die Artikel werden offenbar als 'abgeglichen' markiert und mit dem Icon der 'orangen Kamera' im Suchfenster nicht mehr gefunden. Dies führt dazu, dass ich in der Datenbank Artikel mit 'oranger Kamera' habe, die mit demselben Symbol im Suchfenster nicht mehr gefunden werden, d.h. da ist was nicht konsistent.

Verfasst: **29.09.2004, 09:47**

Hi Daniel!

Daniel hat geschrieben:Wenn ich über Nacht mittels:
baywotch /catupdate /scanfav /scanincomplete /scanjobs
'alle Favoriten abgleiche', die 'nicht abgeglichene Artikel abgleiche' und die 'offenen Jobs abgleiche' erhalte ich regelmässig bis zu 5% 'ungültige Artikel'. Wenn ich diese danach wieder anwähle und erneut abgleiche, werden diese wieder 'gültig' und werden z.B. danach als 'erfolgreich', 'laufend' oder 'nicht erfolgreich' erkannt d.h. nicht alle 'ungültigen Artikel' sind ungültig... (Die wirklich ungültigen bleiben dabei natürlich 'ungültig').

Das höre ich zum ersten mal.

Verstehe ich Dich also richtig, daß es bei Dir vorkommt, daß ein bereits abgeglichener (vollständiger) ungültiger Artikel durch einen erneuten Abgleich "wiederbelebt" wird? Das wäre mir wirklich neu!

Das Prozedere, wie Du die Daten beschaffst, sollte dabei nebensächlich sein. Wird der Artikel abgeglichen, lädt BayWotch die kompletten Artikeldetails von der entsprechenden eBay Seite. Dabei spielt es keine Rolle, ob der Artikel durch Favoritenabgleich oder Onlinesuche - mit oder ohne Kommandozeilenparameter - in die Datenbank gekommen ist.

Die Frage ist diese: Warum wird der Artikel zuerst als ungültig erkannt? Dazu gibt es in BayWotch verschiedene Möglichkeiten:

1. Der Artikel wird seitens eBay als ungültig oder nicht mehr existent gemeldet. Der Artikel ist als älter als ca. 90 Tage, existiert wirklich nicht (falsche Artikelnummer bei Soforteingabe), wurde von eBay "gelöscht" (bei illegalen Angeboten z.B.) oder liegt in einer sog. "Erwachsenen-Katgorie".

2. Der Artikel liegt auf einer nicht unterstützten Plattform, z.B. eBay Motors (die Seiten werden auf ebay.com umgelenkt) und Live Auktionen (gibt's nur auf ebay.com).

3. Es handelt sich um das neue Anzeigen-Format (Immobilien), welches erst ab BayWotch V3 unterstützt wird.

Die o.g. Begründung wird in der Datenbank im Feld "invalid_err_code" gespeichert:

Wertigkeiten:
10 = Artikel nicht gefunden oder ungültig
20 = nicht unterstützte Plattform, z.B. ebay Motors
30 = Anzeigen-Format

Nicht-Professional User können den Fehlercode sehen, indem sie in der Details-Ansicht den Mauszeiger auf dem Ungültig-Symbol ( Bild

) plazieren und den Tooltip abwarten. Der Code wird dann in Klammern angezeigt.

Es wäre also nun sehr interessant, zu wissen, welche Form von ungültigem Artikel bei Dir diese magische Verwandlung erfahren hat. Momentan kann ich nur vermuten, daß eBay hier unterschiedliche Seiten gesendet hat. Also beim ersten Abgleich eine "Artikel nicht gefunden" Seite, beim zweiten mal dann die korrekte Artikelseite. Anders könnte ich mir das Phänomen nicht erklären.

Vielleicht findest Du ja Beispiele, bei denen das Problem immer wieder auftritt und bei denen ich das mal nachspielen kann.

Ausserdem tritt dabei folgendes zusätzliche Problem auf (vor dem erneuten manuellen Abgleich der falschen 'ungültigen Artikel'): Die Artikel werden offenbar als 'abgeglichen' markiert und mit dem Icon der 'orangen Kamera' im Suchfenster nicht mehr gefunden. Dies führt dazu, dass ich in der Datenbank Artikel mit 'oranger Kamera' habe, die mit demselben Symbol im Suchfenster nicht mehr gefunden werden, d.h. da ist was nicht konsistent.

Natürlich werden als ungültig erkannte Artikel mit dem Status "vollständig abgeglichen" versehen, ansonsten würden ungültige Artikel immer wieder neu abgeglichen.

Verfasst: **29.09.2004, 17:18**

Hallo Elmar

Momentan kann ich nur vermuten, daß eBay hier unterschiedliche Seiten gesendet hat. Also beim ersten Abgleich eine "Artikel nicht gefunden" Seite, beim zweiten mal dann die korrekte Artikelseite.

Ja, so sieht's aus. Alle übrigen Gründe für 'ungültige Artikel', die Du angegeben hast, scheiden bei mir aus.
Dann bliebe die Frage, warum eBay unterschiedlich antwortet. Könnte dies ein Timing-Problem sein? Ich fahre mit 25 Übertragungskanälen, einem Timeout von 10 Sek. bei 3 Neuversuchen (Optionen/Internet). Dies mit einer ADSL-Verbindung von 1200kbps Download und 200kbps Upload. Hast Du Erfahrungswerde für diese Einstellungen? Es ist mir schon aufgefallen, dass bei z.B. 200 abzugleichenden Artikeln der Zähler z.B. bei 197 für längere Zeit (1-2 min) stehenbleibt, bis der Abgleich abgeschlossen wird. Vielleicht hängengebliebene Kanäle??

Es handelt sich bei den falsch erkannten 'ungültigen Artikeln' nicht um identifizierbare Artikel, bei welchen das Problem mehrfach auftritt. Das Problem ist zwar bei mir dauernd reproduzierbar, aber nicht mit denselben Artikeln.

Ich mache noch ein paar Tests und melde mich wieder.

Verfasst: **29.09.2004, 17:27**

Hi Daniel!

Daniel hat geschrieben:Hast Du Erfahrungswerde für diese Einstellungen?

Ich halte die Werte für praktikabel.

Jedoch dürften diese Einstellungen auf den beschriebenen Effekt kaum Einfluß haben. Ein Timing-Problem schließe ich aus.

Ich mache noch ein paar Tests und melde mich wieder.

Wenn es wirklich an eBay liegt, kannst Du am besten testen, indem Du einen betroffenen Artikel immer und immer wieder aktualisierst. Irgendwann sollte sich der Artikel dann auch wieder in einen ungültigen Artikel verwandeln. Dann hättest Du zumindest den Error-Code.

Verfasst: **29.09.2004, 23:04**

Hallo Elmar

Also hier mein Testverfahren und meine Testergebnisse:

Ich habe eine neue, leere Datenbank erzeugt. Anschliessend habe ich einen Favoriten angelegt: \\Audio & Hi-Fi\Hi-Fi-Raritäten\Radios (nur Deutschland). Diesen Favoriten habe ich abgeglichen, was als Resultat 540 Datensätze (Artikel/Auktionen) ergab. Diese Datenbank habe ich sechsmal kopiert und anschliessend im Verlauf von ca. 1.5 h jeweils alle 540 Artikel abgeglichen. Hier die Resultate:

1. Versuch: Abgleich aller nicht abgeglichenen Artikel (=alle Artikel suchen und auf 'Abgleich'-Icon mit den zwei grünen Pfeilen drücken)
Übertragungskanäle:99 Timeout:750sek Wiederholungen:3
Resultat: 4 ungültige Artikel (Code 20), die nach erneutem Abgleich alle wieder gültig werden.

3842359741
3842500588
3842933227
3843098397

2. Versuch: Abgleich aller nicht abgeglichenen Artikel (=alle Artikel suchen und auf 'Abgleich'-Icon mit den zwei grünen Pfeilen drücken)
Übertragungskanäle:99 Timeout:750sek Wiederholungen:3
Resultat: 2 ungültige Artikel (Code 20), die nach erneutem Abgleich alle wieder gültig werden.

3841750471
3842184139

3. Versuch: Abgleich aller nicht abgeglichenen Artikel (=keinen Artikel suchen, sondern sofort im Menü Artikel auf 'Alle nicht abgeglichenen Artikel abgleichen' drücken)
Übertragungskanäle:99 Timeout:750sek Wiederholungen:3
Resultat: 1 ungültiger Artikel (Code 20), der nach erneutem Abgleich wieder gültig wird.

3841442833

4. Versuch: Abgleich aller nicht abgeglichenen Artikel (=Zuerst Kategorienupdate ausgeführt, dann DB reorganisiert, dann: keinen Artikel suchen, sondern sofort im Menü Artikel auf 'Alle nicht abgeglichenen Artikel abgleichen' drücken)
Übertragungskanäle:99 Timeout:750sek Wiederholungen:3
Resultat: 2 ungültige Artikel (Code 20), die nach erneutem Abgleich alle wieder gültig werden.

3842472614
3842976460

5. Versuch: Abgleich aller nicht abgeglichenen Artikel (=Zuerst Kategorienupdate ausgeführt, dann DB reorganisiert, dann: alle Artikel suchen und auf 'Abgleich'-Icon mit den zwei grünen Pfeilen drücken)
Übertragungskanäle:25 Timeout:20sek Wiederholungen:3
Resultat: 5 ungültige Artikel (Code 20), die nach erneutem Abgleich alle wieder gültig werden.

3841949024
3842303815
3842448314
3842875208
3843131967

6. Versuch: Abgleich aller nicht abgeglichenen Artikel (=Zuerst Kategorienupdate ausgeführt, dann DB reorganisiert, dann: alle Artikel suchen und auf 'Abgleich'-Icon mit den zwei grünen Pfeilen drücken)
Übertragungskanäle:1 Timeout:20sek Wiederholungen:3
Resultat: 6 ungültige Artikel (Code 20), die nach erneutem Abgleich alle wieder gültig werden.

2272650480
3841380750
3841981404
3841985704
3842232967
3842315641

Falls es Dir etwas nützt, könnte ich Dir die erwähnten Datenbanken irgendwohin uploaden bzw. irgendwo zum Download online stellen, ev. auch in Auszügen, da doch recht voluminös, trotz nur 540 Datensätzen.

Gemäss Deiner Aussage ist Code 20 eine 'nicht unterstützte Plattform'. Wie erkennt BayWotch diesen Tatbestand? Gibt es da die Möglichkeit einer Fehlinterpretation oder gibt eBay wahllos Falschinformationen an BayWotch weiter??

@alle
Ist dieses Verhalten noch niemandem aufgefallen? Kann das jemand reproduzieren?

Bis auf weiteres bin ich ratlos

Verfasst: **30.09.2004, 10:33**

Hi Daniel!

Wow, das nenne ich mal einen Test.

Daniel hat geschrieben:Übertragungskanäle:99 Timeout:750sek Wiederholungen:3

Ich halte diese Einstellungen zwar für etwas unünstig, aber natürlich könnte man eventuell so ein Fehlverhalten besser provozieren.

Ein Timeout von 30 Sek. sollte in jedem Fall ausreichen, sonst wartet man sich im Extremfall "den Wolf".

Die 99 Kanäle sind - zumindest aus meiner Erfahrung - eher eine Bremse... ideal sind bei heutigen PC- und Leitungsbedingungen so zwischen 15 und 30. Aber das sollte jeder für sich testen.

Ich habe mit Deinen Einstellungen den Fall komplett nachgestellt. Aber auch nach 4 Versuchen konnte ich nicht einen einzigen ungültigen Artikel ernten.

Wenn das Phänomen bei Dir so stabil auftritt, empfehle ich einen Härtetest:

Starte BayWotch mit dem Parameter /htmllog und fahre dann einen Abgleich. In diesem Fall legt BayWotch für jede empfangene Seite eine HTML Datei im BayWotch Programmverzeichnis an. Wenn sich auch nur ein ungültiger Artikel zeigt, hast Du ihn in einer der 540 Dateien isoliert. Die Dateien heißen htmllog_kn.htm, wobei "n" für einen laufenden Zähler steht.

Den gesuchten ungültigen Artikel könnte man mit einer Volltextsuche anhand der Artikelnummer im Verzeichnis aufspüren. Dann weisst Du ganz genau, was eBay da gesendet hat.

Würde mich ebenfalls sehr interessieren!

Verfasst: **30.09.2004, 15:05**

Hallo Elmar

Ich halte diese Einstellungen zwar für etwas unünstig, aber natürlich könnte man eventuell so ein Fehlverhalten besser provozieren.

Ja, deshalb habe ich das auch mal so eingestellt. Wie gesagt, sonst habe ich 25 Kanäle, 10 - 20 sek. und 3 Wiederholungen. Das läuft eigentlich recht ordentlich.

Starte BayWotch mit dem Parameter /htmllog ...

OK, das nehme ich mir für's Wochenende mal vor (sofern die Familie das zulässt).

Ich würde dem schon mal gerne auf den Grund gehen.

Verfasst: **06.10.2004, 17:09**

Hallo Elmar

Das Wochende war zu sonnig, d.h. keine Computerzeit

Aber nun die Resultate eines kurzen Tests mit /HTMLLOG.

Meine Datenbank mit 540 Artikeln wurde im ersten Anlauf problemlos abgearbeitet, d.h. kein ungültiger Artikel.

Da dachte ich: das kann doch nicht sein? Und habe alle 540 Artikel gerade noch einmal markiert und nochmals abgeglichen. Und siehe da: 8 der vorher bereits als 'gültig', d.h. 'verkauft' oder 'nicht verkauft' markierten Artikel wurden plötzlich ungültig. Aha: es geht also auch in die Gegenrichtung...

Sofort wurden die 8 Artikel wieder markiert, erneut abgeglichen und: tataaa - wir sind wieder gültig...

Und nun die spannenden HTMLLOG-Resultate:
7 der 8 Artikel zeigen: 400 Bad Request
und einer zeigt: The parameter is incorrect

Und damit bist wieder Du gefragt: Was soll das bedeuten??

Gruss
Daniel

Verfasst: **06.10.2004, 17:13**

Hi Daniel!

Danke für Deine Tests!

Daniel hat geschrieben:Und nun die spannenden HTMLLOG-Resultate:
7 der 8 Artikel zeigen: 400 Bad Request
und einer zeigt: The parameter is incorrect

Und damit bist wieder Du gefragt: Was soll das bedeuten??

Kannst Du mir bitte die zwei Varianten der Logs per Email senden?

Verfasst: **06.10.2004, 21:02**

Alles klar. Mail ist unterwegs.

Verfasst: **07.10.2004, 09:47**

Hi Daniel!

Vielen Dank für die Zusendung der Logfiles.

Die Daten geben zwar Auskunft darüber, was passiert, jedoch leider nicht, warum das passiert.

"The parameter is incorrect." ist eine Meldung vom eBay Server. Ich erhalte sie hier und da schon mal beim Experimentieren mit den eBay URL Kommandos, wenn man ein Kommando nicht korrekt formuliert.

Da aber BayWotch alle URL's im gleichen Schema verschickt, schließe ich einen tatsächlich falschen Parameter aus, zumal es ja beim nächsten Versuch dann funktioniert.

"400 Bad Request" ist eine Fehlermeldung vom eBay Server, die besagt, daß die HTTP Anforderung nicht verstanden wurde. Hier gilt gas gleiche wie oben schon geschrieben.

Natürlich kann ich einen tief verborgenen Bug in BayWotch nicht 100% ausschließen. Ohne genaues Logfiles kann ich das aber unmöglich klären.

Es gibt in BayWotch noch eine weitere Protokolloption: /inetlog. Wird BayWotch mit diesem Startparameter aufgerufen, werden sämtliche Onlineaktivitäten in der Datei inet.log protokolliert. Wäre dieser Modus in Deinem Fall aktiv, könnte man genau das Frage-Antwort-Spiel zwischen BayWotch und eBay Server verfolgen. Nur wird das Logfile gewaltig groß, wenn Du dann 500 Artikel abgleichst. Dies macht also nur Sinn, wenn sich der Fehler bei ein paar Artikeln bereits zeigen würde.

Ein anderer User schrieb ebenfalls etwas zu diesem Phänomen:
http://www.baywotch.de/phpbb/viewtopic.php?p=3159
Vielleicht bekommen wir von ihm noch ein paar neue Erfahrungswerte.

Verfasst: **07.10.2004, 11:02**

Hallo!

Ich hatte im letzten Jahr ähnliche Probleme mit div. Fehlermeldungen, wenn ich im www unterwegs war. Bei mir lag es am T-DSL 1500, auf denn ich damals gewechselt habe. Nach der Rückumstellung auf den "normalen" T-DSL 768" waren die Probleme vorbei. Die Hotline sprach damals von "gelegentlichen" Leitungs- und Datenproblemen.

Da Daniel auch einen schnellen DSL-Zugang hat, wäre eine Probe in diese Richtung auch mal interessant.

Verfasst: **07.10.2004, 13:02**

Hallo alle

@Elmar:

Ich habe schon gedacht, dass Dir die Logfiles nicht wahnsinnig viel Infos liefern.
Aus Übermut habe ich über Nacht noch meinen Gesamtabgleich mit /htmllog laufen lassen mit folgendem statistischen Resultat:
Rund 13'000 Html-Dateien, davon 46 'ungültige Artikel', davon 19 mit '400 Bad Request' und 27 mit 'The parameter is incorrect'. Datenvolumen über 500MB

(Ist nun wieder gelöscht). Dies wie gesagt nur zur statistischen Abrundung.
Ich werde den /inetlog mal testen und Dir Bescheid geben. Wenn das resultierende File nicht 20 GB sprengt, habe ich genug Platz auf der Harddisk.

Nur das Ding dann auszuwerten...

@Tim:

Beim sonstigen (manuellen) Surfen habe ich keine Verbindungsprobleme. Wie war das bei Dir? Hattest Du die Fehlermeldungen nur innerhalb von BayWotch oder auch beim gelegentlichen Surfen?

Ich hatte ja am Anfang auch mal eine Vermutung in Richtung Timingprobleme, die ja auch Datenleitungsprobleme bzw. Server-Responseprobleme im weiteren Sinn sein könnten. In diesem Zusammenhang stelle ich ja auch immer wieder fest, dass BayWotch bei mir am Ende eines Abgleichs von z.B. 500 Artikeln immer noch für eine, zwei, drei Minuten bei z.B. 497 Artikeln und 99 oder 100% hängenbleibt, bis dann BayWotch wieder antwortet. Das könnten entweder unfertige Datenbankjobs im Hintergrund oder eben auch Verbindungsprobleme im weiteren Sinne sein. Haben andere BayWotcher auch solche Beobachtungen gemacht? Gibt es da Erklärungsversuche?

Verfasst: **07.10.2004, 14:07**

Hallo Elmar

Hier nun das Ergebnis des /inetlog-Tests. Das Logfile hat lächerliche
25 MB, gezippt knapp 5MB, also problemlos zum Auswerten. Ich kann
Dir das Ding für Deine Detailauswertung gerne zukommen lassen

Es hat sechs 'ungültige' Artikel darin:
Artikelnummer
2271522642
3842228012
3842362339
3842533938
3842926746
6120624053

Und hier der Auszug aus dem Logfile mit einem der 400-er Errors:

Code: Alles auswählen

07.10.04 13:06:26 SEND REQUEST HEADER key=k148
<<< REQUEST HEADER START >>>
GET /ws/eBayISAPI.dll?ViewItem&item=2271522642 HTTP/1.1
Host: cgi.ebay.de
Connection: close
Proxy-Connection: close
Accept-Encoding: gzip
Accept: */*
Accept-Language: de
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Pragma: no-cache
<<< REQUEST HEADER END >>>

(snip...)

07.10.04 13:06:26 WINSOCK CLOSE key=k148
<<< RESPONSE HEADER START >>>
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Thu, 07 Oct 2004 11:06:25 GMT
Content-Type: text/html
Content-Length: 87
<<< RESPONSE HEADER END >>>
07.10.04 13:06:26 RESPONSE 400 BUT DATA!
07.10.04 13:06:26 HTML RECEIVED size=87 replace_160=Falsch key=k148
<<< HTML START >>>
<html><head><title>Error</title></head><body>The parameter is incorrect. </body></html>
<<< HTML END >>>

Nach erneutem Abgleich der 'ungültigen Artikel' steht im Log:

Code: Alles auswählen

07.10.04 13:14:51 SEND REQUEST HEADER key=k642
<<< REQUEST HEADER START >>>
GET /ws/eBayISAPI.dll?ViewItem&item=2271522642 HTTP/1.1
Host: cgi.ebay.de
Connection: close
Proxy-Connection: close
Accept-Encoding: gzip
Accept: */*
Accept-Language: de
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
Pragma: no-cache
<<< REQUEST HEADER END >>>

(snip...)

07.10.04 13:14:52 WINSOCK CLOSE key=k642
<<< RESPONSE HEADER START >>>
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Thu, 07 Oct 2004 11:14:50 GMT
Connection: close
Server: WebSphere Application Server/4.0
Content-Type: text/html;charset=iso-8859-1
Set-Cookie: nonsession=AQAAAAMAAADLAAAACgAAAColZUEyLGVBMDEIAAAAUwAAAColZUEqsoxBMDEwOTcxNDc2OTB4NjBodHRwOi8vY2dpLmViYXkuZGUvd3MvZUJheUlTQVBJLmRsbD9WaWV3SXRlbSZpdGVtPTIyNzE1MjI2

NDJOygAAACkAAAAqJWVBqibLSjA3MzE5MmYyNDBhMDEwZjVkMDBlODAyODQwMDA2MzdkYQ**f;Domain=.ebay.de;Expires=Fri, 07-Oct-2005 11:14:50 GMT;Path=/
Set-Cookie: recent_vi=MjI3MTUyMjY0MgY5MzMGMTA5NjU3NTMwMAZHSUdBTlRJU0NIRVMgU3RlcmVvIFL2aHJlbiBSYWRpbyBSZXNvbmFyICBSQVJJVMRUICEhIQYHn;Domain=.ebay.de;Path=/
Set-Cookie: LVM=1|0|2271522642|;Domain=.ebay.de;Path=/
Content-Encoding: gzip
Content-Language: en
Content-Length: 7579


<<< RESPONSE HEADER END >>>
07.10.04 13:14:52 UNZIP file=F:\Programme\baywotch2\gzip.tmp size_unzipped=37102 size_zipped=7579
07.10.04 13:14:52 HTML RECEIVED size=37102 replace_160=Wahr key=k642
<<< HTML START >>>
<html><!--srcId: ViewItem--><head>
<!--eBay V3- msxml 4.0 XXXXXXXXXXXXXXXXXXXXXXXXXX-->

(snip...)

//--></script></td></tr></table></span><script language="javascript" src="http://include.ebaystatic.com/aw/pics/js/help/help_contextual_rebranding.js"></script><script language="

javascript"><!--
				function Localize(pStr){return pStr;}
				ebHelpContextualRebrand("buy");
			//--></script></body></html>
<<< HTML END >>>

Und was sagt dies dem Meister??

So, nun ist der Mittag vorbei und ich muss mich wieder den Wichtigkeiten des Lebens widmen...

Verfasst: **07.10.2004, 21:04**

Hallo Daniel!

Die Probleme waren: Keine Anmeldung beim Webzugang; Seiten wurden nicht gefunden bzw. wurden nicht angezeigt.
Diese Fehler waren mal da und mal nicht. Es gab keine Gesetzmäßigkeit. Aber sie waren so nervig, dass ich zurück in den alten Tarif gewechselt habe.

BayWotch Support Forum

Ungültige 'ungültige Artikel'

Ungültige 'ungültige Artikel'

Re: Ungültige 'ungültige Artikel'