On Fri, 2006-01-20 at 10:47 -0800, Peter Johanson wrote: > On Fri, Jan 20, 2006 at 01:26:46PM +0100, Oliver Lemke wrote: > > > > I think the scrobbler plugin is also confused because when the > > SongChangedEvent is fired, the player.Position is still pointing to the > > end of the last song. That's why muinescrobbler thinks the song started > > late and is not submitting it: > > AHA! Now that does seem like a bug to me. It certainly seems to make > sense that the position should be reset to 0 *before* the SongChanged > event (which is certainly what happened previously in muine). However, > accomplishing this without first getting a tick event at position 0 may > actually require some trickery (maybe not, i'm at work and don't have > the code in front of me right now). > > Any reason not to try to fix this so the position==0 when the > SongChanged event happens? 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? :-( Side effect of this is that the GabouPlugin segfaults because it expects a SongChanged event before the first TickEvent to initialize the currentSong variable. -- 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