Hey, sorry to dump another bug on you, but if you're looping and you load a new track, it doesn't clear the loop points or something internally. (The waveform doesn't show the loop points, but the track will start looping at the same point as in the previous track).
To repro: 1) Load track into player 1, set loop in/out points near start for convenience 2) Drag and drop new track from library onto player 1 A second bug is that dragging the waveform doesn't seek if the player is stopped. If the player is playing, dragging the waveform works fine. Other quick comments inline below: On Tue, Sep 22, 2009 at 6:05 PM, Russell Ryan <[email protected]> wrote: > Hey Albert, > > Albert Santoni wrote: >> >> Hi RJ, >> >> (CCing mixxx-devel in case anyone wants to help.) >> >> Played around with the looping branch a bit and hit some problems: >> >> 1) I managed to lock up the Reader by clicking a waveform, and dragging >> it back to the start to rewind the track. There were no loops set. This >> was using vinyl emulation as well. >> > > Were you in 'stop' end of track mode? Did you check that it didn't just stop > the player? I tried to repro this and what happend to me was that every now > and then the track would stop at the start. The reason it was only every > couple times was because there's a bug that causes end of track mode to > sometimes not trigger. With EOT mode in STOP, if the start of the track is > hit, our 1.7 behavior was to stop the player. Can you repro and verify that > it is a reader/player hang and not just the player stopping? I haven't been able to repro yet, but I've only been playing around for a few mins. >> >> 2) I deadlocked Mixxx by changing from vinyl emu to PITS in the >> preferences, and clicking OK. I didn't get a backtrace from this one. >> >> > > This has happened to me too a little while back, but hasn't happened > recently. I'm not really sure why it happens yet. >> >> 3) I did manage to deadlock Mixxx another time though, just randomly. My >> gut feeling is that #2 is really the same deadlock as this one. >> > > Yea this is the deadlock I mentioned in the developer meeting. This is > within EBSDummy, which was turned on for development purposes in place of > EBSST. EBSDummy can actually infinite loop because it doesn't check for EOFs > from RAMAN. I'm a little surprised this happened randomly and not > specifically at the end of a track (when an EOF would happen). > > I just committed some fixes to the looping stuff. I restored the EBSST and I > fixed a few things here and there with looping. It should be nicer now. One > thing I notice that is wrong is that end-of-track modes don't work reliably > anymore. We should investigate that. I couldn't get the #2 deadlock to > happen anymore, but I found that sometimes EBSL asserts if you switch to it > while playing in EBSST. The assert revealed that (for a long time) when we > switched scalers they did not get updated rate information until the engine > internal rate changes. Oops. Anyway, added a fix for that too. > Ok, I'll keep my eyes peeled for anything relevant. Thanks, Albert ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
