Comment 3 for bug 890423

I have not looked at the code, but it sounds like we have two concurrent track info objects.
These info objects are stored back the database once the fall out of scope and out of a strong track cache.
So once we have two of them, the last on wins.

An other reason could be that a changed cue is not stored into the track info object at the right time.

Uwe has recently done some work that the track management that will finally prevent such duplicates.
With some luck this bug is already fixed in master.