v2.1.44 b490: Logging problem with 'waiting' items

Archive mAirList 2.x (English)
1

I’m pleased to say that logging in b490 is generally 100% working.

BUT I just found a slightly obscure logging bug. I don’t know if this has always been the case or not, because it’s only recently that I’ve had this exact situation.

My Playlist has 2 Players and I have recently been trying out some playlists where both players have items the same duration in them, and item 1 has a StartNext of 0,01s, so that item 2 will start in sync with item 1. These are the first two items in the Playlist, incidentally.

When the two items end, there is a slight delay of maybe 0,5s while both Players are fading and unloading, thus item 3 is still ‘waiting’ for an empty Player to load itself into. When this happens, the log for item 1 does not have a STOP entry written. Admittedly it would be better to use 3 Players so that the short ‘wait’ does not happen (in that 3-Player situation, the logging is AOK), but in the 2-Players Playlist, the non-appearance of the STOP log entry still looks and feels like a bug!

Interestingly, removing the FadeOut cue point from item 1 seems to correct the problem, even with a 2-Player Playlist. I can only assume that this action gives the engine just enough time to properly STOP and log item 1 (no fadeout delay).

I can’t think of any more to say to help you with this one, Torben, other than perhaps e-mailing you the MLP and the two or 3 MP3s I’m using (should only be a very few MB) so that you can check it out at your end.

Thanks in advance for any insights you may have on this!

BFN
CAD

2

I think I’ve found the reason. The first item is detached from the player so that item #3 can be loaded, while item #1 is still fading in the background. For that purpose, the item and its associated IAudioSource object (responsible for the actual playback) is handed over to a class called “liquidator”, which waits for the fade to finish and then frees the objects. However, the liquidator does not inform its parent IPlaybackControl about the EOF, and no stop log entry is created.

At least if don’t use stop logging with HTTP - I found a bug similar to the other one lately, causing the duration to be 0 ;).

3

Nice one! Happy to help find these little niggly ones.

I’m familiar with the concept of a liquidator class; aka a destructor class; or in MS-speak (VB, pre-.NET) a Class_Terminate. :slight_smile:

And also with my programming hat on, I’m probably one of the few programmers who actively enjoys writing logging code; and user messages. I think that clear user messages are a huge factor in the general usability of any application. For example, it’s always better to tell the user what to do to fix an error, rather than a bald statement of what failed:

You typed 12, which is not allowed. Type a number between 0 and 10, then try again.
and NOT:

Invalid number entered.

–
BFN
CAD