bei uns im Radio tritt folgendes Problem auf. Wenn ein längeres mp3 läuft (60min, unabhängig davon ob Automation an oder aus), dann bricht der Titel irgendwann mit der Meldung EOF ab.
Ich schätze mal der Lesebefehl bringt hier nen Fehler und mairlist startet nicht noch einen Leseversuch.
Warum der Lesebefehl fehlschlägt kann ich nur vermuten, die Files liegen auf nem Netzlaufwerk und bei hoher Netzwerklast bringt unser (billiger) switch kurze Aussetzer (im Millisekundenbereich). Der MediaPlayer bringt aber keine Fehler, da scheint der Lesevorgang also etwas robuster zu sein. Es ist nur eine Vermutung!
Kannst du da was machen…vielleicht bringt die Windows-API da ja auch was mit.
Ich befürchte, da habt ihr schlechte Karten. Ich kümmere mich selbst nicht um das Öffnen und Lesen von Dateien, das macht alles die BASS.DLL. Und ich glaube nicht, dass da solche Fehlerbehandlungsroutinen vorgesehen sind.
Ich habe diese EOF-Sprünge auch schon beobachtet, als bei uns das Netz mal wieder lahmte. Daher hab ich für eldoradio verordnet: Musik nur von der lokalen Platte spielen. Im Augenblick heißt das, dass man sich die Files vor der Sendung von Hand rüberkopieren wollen, später wollen wir das ganze Archiv spiegeln. Was anderes wird euch auch nicht übrig bleiben.
Uff, das ist aber schon ein KO-Kriterium, leider. Ich meine, wozu hat man denn ein zentrales Archiv? Mich wundert dieser Fehler trotzdem, schließlich puffert die bass.dll ja sicher auch intern dadurch müßte das abgefangen werden.
Du kriegst doch bei die im Code an irgendeiner Stelle den Fehler von der BASS zurück und machst die EOF-Ausschrift…kann man da nicht irgendwie drehen, das der Titel weitergespielt wird??
Gegenfrage: Was nützt einem ein zentrales Archiv, wenn die Hardware kaputt ist? So wie du das schilderst, ist das Problem nicht mAirList, sondern der Switch. Also sollte man prinzipiell doch da ansetzen, etwas zu verbessern, oder nicht? Alles andere wären nur “Workarounds” und keine Lösungen.
Ich will mal sehen, ob ich der BASS.DLL beibringen kann, den internen Lesepuffer zu vergrößern. Sollte es sich wirklich nur um kurze Dropouts kümmern, könnte das was bringen. Zur Not kontaktiere ich mal den BASS-Programmierer.
Wenn der Netzwerk-Dropout aber dazu führt, dass Windows die SMB-Verbindung zum Server beendet (damit kämpfen wir bei uns zur Zeit massiv), sieht es düster aus. Dann muss das File nämlich neu geöffnet, an die richtige Stelle gesprungen usw. werden.
Hab gerade in der Doku nachgesehen, man kann die Puffergröße tatsächlich frei definieren. Werde ich in der nächsten Version anbieten.
Apropros: Ich arbeite gerade an der 1.3.0 (1.2 überspringen wir mal, weil die ja laut Philosophie “stable” hätte sein müssen). Der Versionssprung ergibt sich vor allem dadurch, dass ich intern jede Menge umprogrammiert habe. Auf den ersten Blick bringt das wenig, schafft aber die Möglichkeit für jede Menge interessanter Erweiterungen. Fernsteuerung z.B. Ich werde die erste 1.3er Version in Kürze online stellen. Rechnet aber bitte damit, dass es ein bis zwei Versionen dauern wird, bis alle Bugs beseitigt und die 1.3 so stabil ist wie die letzten 1.1er Versionen.
was hälst Du denn von einem Caching-Verzeichnis ? Dann könnte man sich die Titel z.B. einer Stunde automatisch rüberkopieren lassen… liesse sich sowas in mAirList einbauen ?
Wenn der Netzwerk-Dropout aber dazu führt, dass Windows die >SMB-Verbindung zum Server beendet (damit kämpfen wir bei uns zur Zeit >massiv), sieht es düster aus. Dann muss das File nämlich neu geöffnet, an >die richtige Stelle gesprungen usw. werden.
Das mit dem Switch bei uns ist eine Vermutung, ja. Aber was verursacht bei Euch die Trennung der SMB-Verbindung? Wir hatten auch das Phänomen, das Netzlaufwerke als getrennt angezeigt werden, aber wenn man klickt ist alles in Ordnung … das ist seltsam, könnte aber der Punkt sein, das mairlist verunsichert.
Werde mal die Samba-Dokus wälzen, vielleicht steht da ja was.
Bis wir ihn ausgeschaltet haben, hat sich Windows 2000 bei uns immer automatisch in den “Offline-Modus” geschaltet. Den man sofort per Mausklick wieder deaktivieren, also wieder online gehen konnten. Dabei gehen aber natürlich die Verbindungen flöten.
Noch was zum Thema Netzlaufwerke: Ich kenne das Problem auch zur Genüge, und zwar von DRS2006PRO, das wir als Automation einsetzen (kommt noch aus vor-mAirList-Zeiten…). Da war das Problem daß die Automation bei hoher Netzwerkbelastung einfach stehenblieb. Die Lösung war ebenso simpel wie brachial: Eine Intel Pro1000-Netzwerkkarte im Fileserver und ein Switch (D-Link DES1010) mit Gigabit-Backplane und 2 Gigabit-Ports. An einem hängt logischerweise der Fileserver, der andere ist frei und die restlichen Rechner hängen an den 100er Ports.
