1.5.43: Right-click Playlist item can cause Access Violation

Dear Torben,

This may be happening because of my saved Playlist files being buggy (?), but it sometimes happens that when I right-click an item in a loaded Playlist, the context menu is not displayed and an Access Violation is thrown. It does sometimes also happen to items which have been dragged and dropped on a Playlist from a Browser directory tree pane, or from the Played Items pane.

Other items in the same Playlist, and other Playlists, are unaffected and display the menu as expected.

Sometimes when this error occurs, dragging the item into a Player (or out of a Player) can cure the problem; sometimes it makes the problem occur with other items in the same Playlist which previously worked correctly (?). Sometimes it happens after an item has been PFLd; sometimes it happens even if the item has not been PFLd.

I have tried without success to ‘nail down’ precisely what causes this error: it seems to be possible for it to happen to both tagged and non-tagged items, and unfortunately I have not been able to find an exact reproducible series of steps which causes the error :(.

The only clues I can offer are the pairs of code addresses and the addresses being read, which are:

Addr 00407BA6, read addr 00000000.
(this is usually the first address pair, when the error starts to happen)

Addr 00407BA6, read addr 34330000.
Addr 0070C7BC, read addr 00000000.
Addr 21797470, read addr 00000000.
Addr 00407BA6, read addr FFFFFFFF.
Addr 00407BA6, read addr 000F0100.

I am not aware of any problems in my INI files, and everything fits correctly in the mAirList window (no Players, Playlist, etc. which does not fit on the screen).

Sorry I cannot provide any more help with this, but please do feel free to ask any questions! Hopefully the code addresses above will provide a clue?

I will post any further different address pairs in this thread, if the error happens again.


I’m sorry to say that this irritating bug is still happening sometimes in 1.5.45, though again it seems mainly to happen when I load an MLP file which was saved by a previous beta version of mAirList.

It may also be because I have changed the cue points for some (or all) of the items between saving the MLP file in the earlier version of mAirList and loading the MLP file in 1.5.45…?

Creating and saving a new MLP file in 1.5.45 which contains the same items as the ‘buggy’ MLP (then saving and loading this new MLP file) seems to stop the problem happening, but it such an intermittent and unpredictable bug that it is difficult to be certain that the new MLP file has completely cured it. :frowning:


Can you provide me one of these modified playlists, perhaps along with the information which items were manually changed in it? I will take a look at it. Maybe I’ll find anything suspicious.


I had this, too - whilst experimenting. I had some songs inserted, then a BREAK and COMMAND item. If I right-clicked or double-clicked the these two items, the Access Violation would appear. I also had 3 played/greyed-out item (playlist history) at the top of the playlist - I suspect that may be the reason why ?

From memory, it looked a bit like this:


I seem to get access violation at adress 006EC1EB in module ‘mAirList.exe’ when I press the Properties button if there has never been anything in the playlist when the program is first started…it’s nothing major - just so you know!

I seem to get access violation at adress 006EC1EB in module 'mAirList.exe' when I press the Properties button if there has never been anything in the playlist when the program is first started...it's nothing major - just so you know!

Ok, this Properties button bug is confirmed and will be fixed in 1.5.46.

I have also found some mistakes in the function which prepares the popup menu which might have caused the above mentioned AVs, in particular in situations when the history is longer than the remaining active playlist.


That’s wonderful news, Torben!


I had been wondering how I could possibly ‘gloss over’ that bug to my senior techie. I know he would (rightly!) reject a program for on-air use if a bug like that were still present.

And to be fair, it’s the ONLY semi-major bug I’ve found in mAirList, so congratulations! I’m delighted it will be fixed.