ich habe keine ahnung warum es manchmal logdateien schreibt und manchmal nicht.
heute war der fall das vor einer halben stunde noch das logging funktionierte, danach hatten wir den rechner neustarten müssen, seitdem schreibt mairlist keine dateien mehr, auch nach dem neustart von mairlist nicht mehr.
mal nach der sendung schauen wie man es wieder anbekommt.
so haben mairlist wieder zum loggen gebracht.
wir haben mairlist beendet, mairlistconfig aufgerufen nichts geändert nur gespeichert und dann ging mairlist wieder.
Gute Frage. Am ehesten kann ich mir vorstellen, dass die Logdatei aus irgendeinem Grund schreibgesperrt war, zum Beispiel, weil ein anderer Prozess ein Lock darauf hatte. Ansonsten ist das in der Tat sehr mysteriös.
Genau, das ist bei uns immer wieder passiert. Wir haben per FTP-Client auf die Datei zugegriffen. Wenn nun zur gleichen Zeit mAirList den nächsten Titel ins File schreiben wollte, gab es eine Fehlermeldung und es wurde nichts mehr reingeschrieben (war Version 1.3.12). Beim Neustart des Programm schrieb es ganz normal weiter.
Wie kann man dieses Problem umgehen? Gäbe es nicht die Möglichkeit, dass mAirList einfach später wieder ganz normal weiter schreibt (spätestens bei einem neuen Titel oder am besten es nach z.B. 10 sec. nochmals versucht)?
Wäre es da nicht (imho) besser, wenn der FTP-Client eine Kopie öffnet, statt die Log-Datei zu sperren? Oder schreibt Ihr auch in Logdatei?
Nur mein Senf.
Gruß, Ph.
Ein Sync-Tool hat eine Kopie geschrieben. Trotzdem (praktisch immer in den News wenn Dateien kurz nacheinander abgespielt wurden) brach das Schreiben des Log-Files ab, bzw. kam eine Fehlermeldung.
Das klingt alles so, als würde der FTP-Server die Datei während des Übertragens sperren, so dass mAirList sie nicht mehr im Schreib-Modus öffnen darf. Was mir merkwürdig vorkommt - der FTP-Server will ja eigentlich nur lesen. Warum sperrt er sie also? Ist eigentlich überflüssig.
Davon ab gebe ich zu, dass ich die Fehlerbehandlung relativ “defensiv” programmiert habe. Geht was schief, wird das System sicherheitshalber deaktiviert. Davon ausgehend, dass nur was schiefläuft, wenn man was falsch konfiguriert hat (falschen Ordner angegeben oder so), ist das sicherlich ok, bei temporären Problemen aber offenbar der falsche Weg. Vielleicht wäre eine Sicherheitsabfrage “Soll das Logging deaktiviert werden?” besser.
Das klingt alles so, als würde der FTP-Server die Datei während des Übertragens sperren, so dass mAirList sie nicht mehr im Schreib-Modus öffnen darf. Was mir merkwürdig vorkommt - der FTP-Server will ja eigentlich nur lesen. Warum sperrt er sie also? Ist eigentlich überflüssig.
Genau das meinte ich auch. Mal nen anderen FTP-Sever versucht?
Anfreunden könnte ich mich damit nicht so wirklich. mAirList sollte so wenig “zweckfremde” Funktionalität haben (die eigentlich von externe Software bereitgestellt werden sollte) wie möglich.
Betreibt ihr zufällig eine SQL-Datenbank? Logging in die Datenbank ist m.E. die allersinnvollste Lösung. Weil sich da der Datenbankserver um die ganzen Zugriffskonflikte kümmert. Man kann das Datenbank-Logging auch nutzen, ohne die ganze eldoDB dafür aufzusetzen.
Damit sind wir wieder beim Thema (wurde schon an anderer Stelle diskutiert)…
Ja, wir arbeiten zwar mit MySQL. Allerdings ist unser Informatiker wenig davon begeistert diese mit dem Web zu verknüpfen…
Ich persönlich fände die Option mit einer Fehlermeldung, bei welcher das “Log-Schreiben” nicht deaktiviert würde, am besten. Dann würde nämlich auch unser jetziges System ohne Modifikation funktionieren.
… außer, dass dann hin und wieder ein Lied im Logfile fehlt.
Soll die Fehlermeldung als Dialogbox erscheinen, oder soll ich einfach einen kurzen Hinweis in die (bislang noch so gut wie unbenutzte) Log-Zeile ganz unten am Bildschirmrand schreiben?
Ich hab das nun so implementiert: Bei Zugriffsfehlern wird eine Meldung in die Statusleiste geschrieben, das Logging aber nicht deaktiviert. Eine neue Version gibt es vermutlich heute abend.
(wurde schon an anderer Stelle diskutiert)…