On Sat, 2006-01-21 at 02:31 -0800, Peter Johanson wrote: > On Fri, Jan 20, 2006 at 11:28:17AM -0800, Peter Johanson wrote: > > On Fri, Jan 20, 2006 at 08:17:33PM +0100, Oliver Lemke wrote: > > > > > > Just inserting a player.Position=0 before firing the SongChangedEvent > > > works... sort of. ;-) When the property player.Position is set to zero, > > > a TickEvent is fired before the SongChangedEvent. Actually not what we > > > want, right? :-( > > > > Yeah, I had a sneaking suspicion this would happen if we tried to do > > that simple change. Thus my warning that it might require some trickery. > > (: > > Ok, let's give the attached form of trickery some testing. We switch > back the order of the 'fire the event, set the song', but now setting > the song doesn't actually fire the TickEvent right then, it does it in > the idle callback which is actually changing the song. End result, > afaict, and the problem is fixed. No duplicate SongChanged events, and > our Position == 0 for both the SongChanged, and all subsequent tick > events after that. > > This make that pesky, 'asking for sanity during events' muinescrobbler > plugin happy now? (/me crosses fingers) Yes! It works like a charme now. > -pete > > PS - this message brought to you by the "Holy crap, why did I start > looking at fixing this bug at 2AM in the morning" Foundation. The usual > disclaimers apply. Enjoy your sleep. You really deserve it. :-) Thanks a lot Peter! -- so long, oliver Public GPG Key: http://www.core-dump.info/olemke-public.asc Fingerprint: 2389 0B2C 1AA8 4E3E D5AD 3B72 00DB ABDC 73ED C558
Attachment:
signature.asc
Description: This is a digitally signed message part