Playlists should preserve track titles even when audio files are gone

[spotlesscoder]

Feature Description

I had to offload a lot of music to external SSD because my internal SSD was full

Now all the tracks are missing in my old playlists

I want to see what tracks were in those playlists in what order so I can rebuild them

[Eve00000]

Hi,
In order to give you some advice first some questions:

• do you have a copy/backup of your mixxx libary database?
• did you configure your library (preferences -> library -> directories) with one directory or multiple directories?

If you configured your library as 1 directory you need to move the complete directory to the new location in order to let Mixxx relocate your tracks.
If you moved only subdirectories to the new location my 1st advice is: move the complete directory to the new loacation, restore the bu/copy of your mixxx database and start Mixxx. go to preferences -> library -> directories and replace the old location with the new location. Mixxx will relink your files and all playlists/crates and historylists will be as before.
more info: here in the forum

[spotlesscoder]

1. no
2. one directory

Ill try your recommendations

[Toneplay]

I just tried to reproduce this problem, and I'm having difficulty.

I added a folder to my library, and rescanned the library. The new folder just has 20 tracks or so that weren't already in the library.

I created a playlist that contained the 20 tracks.

I then renamed the folder with the 20 tracks, so that Mixxx couldn't find it.

The tracks were still in the playlist, and also in the library, even though I couldn't load them.

I then rescanned the library, and the tracks disappeared from the library, but they were still in the playlist, but I still couldn't play them because I hadn't relinked the folder yet.

Then I relinked the folder, and the playlist plays just fine.

So, I'm trying to figure out how to make the tracks in the playlist disappear as a result of moving the underlying files.

As I see it, everything works fine (this is version 2.5.0 on Windows).

[Toneplay]

I have found that the playlist is only altered if I remove the folder from the library and delete the track metadata. This appears to remove the tracks from the playlist.

But a mere rescan of the library, even though it removes the tracks from the library itself leaves the playlist unchanged, and therefore salvageable by using the Relink button in the library.

[ronso0]

@spotlesscoder

I had to offload a lot of music to external SSD because my internal SSD was full

How exactly did you do that and how will Mixxx know about the new file locations?
Did you add a new directory to the Mixxx library or did you create symlinks new directories in the old places?

I think in both cases Mixxx should detect moved tracks (new track has same duration (+- 1 sec) and same artist title file name as missing track), but for some reason that sometimes fails (see #11053 and #9411).
Missing tracks are not shown in Tracks anymore, only in Missing.
In any case missing tracks should still be in your playlists, they are marked 'missing' with red/pink track text (Mixxx 2.5).

[spotlesscoder]

I think I missed to mention an important step: I removed all tracks from the library. That might have been my mistake

However, I would expect playlists to remain intact even if I remove one of it's or even all tracks from my library

[ronso0]

I think I missed to mention an important step: I removed all tracks from the library

Uhhh, so you hit Purge in Tracks and/or Missing?
If yes, well, that does exactly what it says: it wipes all track metadata from the library.
What makes you think there would be an exception for playlists?
(not saying you did something wrong, just wondering if something in Mixxx makes you think so, and if so we should fix it)

[spotlesscoder]

Yes, that is what I was doing

To me, the library and the playlists are two completely different areas of the program

[ronso0]

To me, the library and the playlists are two completely different areas of the program

Hmm, I see.
We can add a warning to clarify that playlists and crates rely on the Tracks database and that purging any track will remove it from all track views.

edit
similar to the directory removal dialog, but compact

[Toneplay]

So, then, just to clarify (please tell me if I'm wrong): The Tracks database refers to files, and all the other views including playlists and crates refer to the Tracks database.

And Mixxx doesn't maintain dangling references from any view into the Tracks database. If a track is removed from the Tracks database, references to it from other views are removed.

The only dangling references MIXXX maintains are from the Tracks database to the underlying files. These dangling references can be fixed up with the Relink feature.

[ronso0]

So, then, just to clarify (please tell me if I'm wrong): The Tracks database refers to files, and all the other views including playlists and crates refer to the Tracks database.

Yes. Tracks shows all tracks whose files exist. Missing lists all tracks whose files were not found, Hidden all tracks that were hidden (note the inconsistency: permanently removed from playlists, still in crates but invisible)

The only dangling references MIXXX maintains are from the Tracks database to the underlying files. These dangling references can be fixed up with the Relink feature.

Actually moved or renamed files should be discovered by a rescan. If you moved entire directories anywhere outside the watched directories, you need to relink.

[Toneplay]

Actually moved or renamed files should be discovered by a rescan.

That's interesting. How do you tell that a renamed/moved file is the same file? Do you keep a hash of the file's contents?

[ronso0]

I was wrong: the scanner cleanup only checks if file name and duration (+- 1 sec) are identical.
FWIW the code is here

mixxx/src/library/dao/trackdao.cpp

Line 1817 in 052a9c8

bool TrackDAO::detectMovedTracks(

IIRC using the file hash has been discussed but dismissed since that would mean to hash every file in question during the scan whichis expensive.