Files categorised as 'missing tracks' after reorganisation on harddisk and two (or more) library refreshs, although files are still present in correct folders

Bug #1791446 reported by Michael
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
New
Undecided
Unassigned

Bug Description

As I went from Mixxx unstable (2.2 git I guess), to 2.0.0 stable and then to 2.1.3 in the past month, I just deleted the whole .mixxx config folder, so that incompatibility issues should hopefully be ruled out.
It is still possible for me to replicate the issue after this 'cleanup'.

So here is the further description of what and how it happend:

After deleting the config files, I started Mixxx and added three different library folders.
The library got scanned and all tracks were found. Then I moved the three library folders on HD from their shared parent folder, to a new subfolder (which they then also shared).
Scanned the library again - the files went to 'missing tracks', as expected.
Then I relinked the three library folders to the new locations and rescanned the library another time. The tracks were found and removed from 'missing tracks' category, as they should.

Then however, when I pressed 'rescan library' again, for whatever reason, the files magically went to 'missing tracks' again, (which should not happen!) and they also remained there, no matter how often I pressed rescan after that.
I had to redo the whole described rearranging/relinking/rescanning procedure, in order to make Mixxx accept the new folders as new library again. The important thing was, not to press 'scan library' more than once, after that!

However, the only way to permanently fix this was, to restore the original (initial) library structure on harddisk, like it was, when the library got scanned for the very first time (after a fresh install, or deletion of the config folder e.g). In this case I could press 'refresh library' as much as I wanted, without the tracks being moved to 'missing tracks' category again.

Kind regards
Michael

Tags: library
Michael (ehmic)
description: updated
Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

Thank you for your detailed report, Michael. I've repeated the steps exactly as you described, but was not able to reproduce the behaviour.

The files are marked as missing after rescanning and before relinking the library folders. Then I relinked the 3 library folders to their new parent folder and rescanned the library. All tracks reappear and don't disappear after subsequent rescanning. The file paths in the database have been updated and reflect the new location as expected.

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

Do you use any symbolic links that could generate cyclic file paths?

Changed in mixxx:
status: New → Incomplete
Revision history for this message
Michael (ehmic) wrote : Re: [Bug 1791446] Re: Files categorised as 'missing tracks' after reorganisation on harddisk and two (or more) library refreshs, although files are still present in correct folders

Hi Uwe,

first of all, thanks for having a look!
I do not use any symbolic links in the library folders.
Just double checked to rule out, that I created one by accident in the past.

For the sake of completeness, although I guess it doesn't matter:

- The folders are on a partition which is not mounted at system start. I
do this manually (via Thunar) if needed.
- System is Ubuntu 16.04 with XFCE
- Meanwhile I upgraded to Mixxx 2.1.4 and I can still reproduce the
issue here
- Recently I fixed some folder permissions, but that did not fix the problem

I do have a workaround for the problem, so it is not really urgent for
me to get this fixed.
While you cannot reproduce the issue, it seems to be better to wait if
someone else is affected.
Maybe it is really just a special problem with my system.
Will report if I find something.

Am 26.09.2018 um 00:49 schrieb Uwe Klotz:
> Do you use any symbolic links that could generate cyclic file paths?
>
> ** Changed in: mixxx
> Status: New => Incomplete
>

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for Mixxx because there has been no activity for 60 days.]

Changed in mixxx:
status: Incomplete → Expired
Changed in mixxx:
status: Expired → New
tags: removed: missing tracks
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/9422

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.