Track is not reanalysed when changing preferences

Bug #1403638 reported by Daniel Schürmann
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Low
Unassigned

Bug Description

When you switch from const to not const and back the beatgrid does not change. A Mixxx restart does not change this.
I also notice that a track is always "analyzed" (the white bar is moving) even when it was just loaded before.

Changed in mixxx:
milestone: none → 1.12.0
Revision history for this message
Owen Williams (ywwg) wrote :

changing the preferences absolutely should not cause tracks to be automatically reanalyzed. I have tracks where the beatgrid has been very carefully tweaked, and if just changing a preference causes that work to get thrown away that would be extremely bad.

Right now I can "clear beatgrid" and the track will reanalyze as expected.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Yes, thats why we have a preference option for this and we have the Bpm lock for set this at a track base.
But even if you have unset both the beatgrid is not reanalyzed.

Revision history for this message
Owen Williams (ywwg) wrote :

ah ok -- once again I don't know why anyone would want to do that, but we do have a preference for it.

(Wouldn't it make sense to get rid of all the bpm locking and just make the user explicitly ask to reanalyze? Who reanalyzes so often except a developer testing the analysis code?)

Anyway as implemented, if this isn't working, it's a bug

Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 1403638] Re: Track is not reanalysed when changing preferences

Yea, I noticed this was broken at some point too. I haven't had time to dig
into it.

On Wed, Dec 17, 2014 at 5:27 PM, Owen Williams <email address hidden> wrote:
>
> ah ok -- once again I don't know why anyone would want to do that, but
> we do have a preference for it.
>
> (Wouldn't it make sense to get rid of all the bpm locking and just make
> the user explicitly ask to reanalyze? Who reanalyzes so often except a
> developer testing the analysis code?)
>
> Anyway as implemented, if this isn't working, it's a bug
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1403638
>
> Title:
> Track is not reanalysed when changing preferences
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1403638/+subscriptions
>

Revision history for this message
Owen Williams (ywwg) wrote :

partially fixed, the reanalyze member wasn't getting updated. But, there's still something wrong because the track's beats metadata appears not to get updated. https://github.com/mixxxdj/mixxx/commit/4039a62dad46a8bd884c97ed1b0438ca29910767

Revision history for this message
Owen Williams (ywwg) wrote :

(to be specific -- if I load a track that has a different beat detection method, it does get reanalyzed. And if I print some debug info, I see it calling setBeats. But if I load that track again, it reanalyzes again)

Revision history for this message
Owen Williams (ywwg) wrote :

(and printing out debug info shows the old beat version info)

RJ Skerry-Ryan (rryan)
Changed in mixxx:
importance: Undecided → Low
Revision history for this message
Daniel Schürmann (daschuer) wrote :

This is fully fixed now.

Changed in mixxx:
status: New → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7739

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.