Can I first ask whether the (file) logging strings and file name entries in mAirList.ini are the same in V2.1.x as they were in V2.0.x?
I seem to be having serious problems with logging to a file in V2.1.31. If the INI file entries have significantly changed in V2.1.x, this might explain the problems I am seeing, which are:
I am encountering a lot of these errors:Error writing log file: Access violation at address 004D855E in module 'mAirList.exe.' Read of address 00000000
A STOP entry seems to be written every time a Player loads a file (?!!). Sometimes, but not always, this entry gets overwritten with a correct START entry.
STOP entries seem to be being written when items START and vice versa.
For the record, the relevant section in my mAirList.ini is:[Logging]
Enabled=on
Logfile=C:\Documents and Settings\Cad.TARDIS\My Documents\mAirList\%Y-%M-%D.LOG
Format=%D-%M-%Y %h:%m:%s%tSTART%t%1%t%b%t%a%t%t%i{TALB}%t%i{TRCK}%t%i{TYER}
EndLogging=on
EndLogfile=C:\Documents and Settings\Cad.TARDIS\My Documents\mAirList\%Y-%M-%D.LOG
EndFormat=%D-%M-%Y %h:%m:%s%tSTOP%t%1%t%b%t%a%t%e%t%i{TALB}%t%i{TRCK}%t%i{TYER}
Any thoughts about these problems, Torben?
The ini file format hasn’t changed since v2.0. Here’s what I have found out:
There is a bug in v.31 which prevents the STOP logging when a track is stopped manually. You will only see a STOP entry when the file is played to EOF. This will be fixed in v.32.
The error address points to a piece of code where BASS.DLL is loaded. It should not be related to logging. Are you sure that you use the BASS.DLL which is provided with the download archive?
You will only see a STOP entry when the file is played to EOF.
In most cases, my files [b]were[/b] played to EOF (in AUTO mode), though for a few of them, I did click the NEXT button in the Playlist control bar.
Are you sure that you use the BASS.DLL which is provided with the download archive?
I'm certain that I am, yes. My 2.1.31 was installed into a brand new directory using the EXE version of the install file. The only thing that could possibly be going wrong is that the install directory is a subdirectory of my v2.0.x install directory.
In other words:
v2.0.x is in c:\Program Files\mAirList
v2.1.x is in c:\Program Files\mAirList\Dev
The BASS.DLL in the Dev directory is V2.3.0.2 dated 25/02/2007.
I think I forgot to say that the Access Violation messages are appearing in the Status Bar (yeah, I know: ‘where ELSE could they be?!!’). I will try to take more notice of precisely WHEN each message appears, but am I correct in saying that the Status Bar only contains the three most recent error (or status) messages? There only ever seem to be three Access Violation messages in the list, no matter how many tracks are played (?).
This logging problem is MUCH stranger than I had first thought, but at least now I am not seeing any Access Violation errors.
Here is what I tried just now, and what mAirList wrote to the log file as a result. Let’s call the tracks A, B, C, etc. for reference.
Starting with a new, empty instance of mAirList, with the Playlist in ASSIST mode:
Manually load one track (track A) into the Playlist (two Players BTW), then click PLAY on Player #1. This correctly logs a START record for track A.
Load an (error-free!) MLP into the Playlist, then click AUTO. Track B loads into Player #2. Nothing added to the log file at this point.
Click the NEXT button to start track B in Player #2. This correctly logs a START record for track B. Track A then ‘ejects’ from Player #1 and track C loads into Player #1. This writes a false STOP record for track C (!) with a logged time of the time the track is loaded into Player #1, and a duration of (current time - start time of track A)?!!
Allow track B to play to the end. No STOP record is written for track B. Track C now plays from Player #1. This correctly writes a START record for track C. Track B then ‘ejects’ from Player #2 and track D loads into Player #2. This writes a false STOP record for track D with a logged time of the time the track is loaded into Player #2, and duration of APPROXIMATELY (current time - start time of track B).
If the Playlist is allowed to play in AUTO, this cycle repeats; with each auto-load of a track into a Player creating a false STOP log record, and no STOP records being written when any track actually ends.
Quite a strange bug, isn’t it? I hope the above description will help Torben replicate this odd behaviour, and also correct the bug!
Sorry to be a pest, Torben ;D, but is there any progress on the logging bug about an ‘empty’ (zero) Duration value on all STOP log entries?
We are planning to implement mAirList for our presenters very soon and logging is extremely important to us. If logging isn’t working properly, I will find it difficult to persuade our Board to use mAirList on-air.
