Using loop_move_x_forward/backward on a track that has no set loop freezes mixxx

[mixxxbot]

Reported by: doodlebro
Date: 2014-07-16T18:19:01Z
Status: Fix Released
Importance: Medium
Launchpad Issue: lp1342888

---

latest nightly 1.12 (Master r4509)
Linux Mint 17

Very reproducible for myself.

[mixxxbot]

Commented by: ywwg
Date: 2014-07-22T16:01:49Z

---

do you know how to make a backtrace? That would help the most. http://mixxx.org/wiki/doku.php/creating_backtraces

[mixxxbot]

Commented by: doodlebro
Date: 2014-08-19T22:40:08Z

---

It appears the crashes are gone, but the functionality is still bugged.

For the case of a song which does not have a set loop or set in and out points, this is where most of the bugs lie. The expected use of loop move when a loop is not set would be to do nothing. In the current nightly using loop move in this case tricks the loop into thinking it is on (while keeping all GUI indications of the loop being on unchanged), effects playback by cutting to the end of the new loop, and when the loop is disabled it freezes at the end point until a new song is loaded.

For the case where a song does have a set loop, functionality works fine if you are currently inside of the loop as well as it is enabled. When the loop is disabled, loop move is expected to simply move the loop but not enable it. In the current nightly this is unfortunately not the case. The loop does move, but if it is off it will always be enabled. I think moving the loop when it is off is a desirable feature for all as we all have a dedicated reloop/loop enabled button.

[mixxxbot]

Commented by: ywwg
Date: 2014-08-20T00:14:18Z

---

Let's see if this does it: 1b51688

[mixxxbot]

Commented by: rryan
Date: 2014-11-18T02:31:44Z

---

I'm guessing that did the trick...

[mixxxbot]

Issue closed with status Fix Released.