Deleting track from disk leaves track listed in playlists, even though track no longer exists

Bug #1779584 reported by Paul Felts
18
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Mixxx
Confirmed
Medium
Unassigned

Bug Description

I deleted a track from my hard drive. In Mixxx, I ran "rescan library." This, correctly, removed the track from appearing in search results in my list of TRACKS in the Mixxx Library. However, the track still appears as available in my PLAYLISTS. Trying to PLAY the track fails with "track not found." In the middle of a DJ set, this is BAD, BAD, BAD. I assumed that PLAYLISTS were just links to tracks in the Master Library and that PLAYLIST track listings would be updated when "rescan library" was run. Apparently, this is not so. Unplayable, nonexistent tracks seem to be left in PLAYLISTS. There is no "rescan library" option for PLAYLISTS. Running ANALYZE on PLAYLISTS does not remove the bad listings. I thought that I remembered there being a toggle for "display unplayable tracks", but I couldn't find any such option. I have tracks added to several of my PLAYLISTS which point to the same, now nonexistent, track in Master Library. It will be painful to manually edit them all out. Thanks!

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

I can confirm that there is an issue. But a solution is not that easy. We cannot remove the tracks unconditionally from the play list, because the file missing might be a temporary issue, because of a missing hard drive or such.
A possible solution is probably to gray the file out. The remaining question its: when should the greyed out status be updated.

Changed in mixxx:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
ronso0 (ronso0) wrote :

I can confirm the issue, I ran into only a few times though.

How long would it take mixxx to check the existence of all files in a playlist (let's say 200 tracks) when that playlist is displayed the first time during a session? Could that scan happen in background without hindering GUI performance and with a small 'updating...' indicator somewhere?

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

Yes, that can be an option, but I am a bit afraid disturbing the caching reader.

Revision history for this message
Paul Felts (h-pa5l-v) wrote :

Oh, I see that the track appears under MISSING TRACKS. Sorry, I had not noticed that. So, the track's absence DOES get detected during SCAN LIBRARY. That's great! Also, I see that applying PURGE TRACK FROM LIBRARY to a MISSING TRACK removes the track's listing from ALL playlists that point to it! That solves my original issue! The only thing I would suggest is, maybe, a pop-up or other notification which appears after RESCAN LIBRARY that says something like: "Some playlists are now invalid / pointing to tracks which are not found. Check MISSING TRACKS in LIBRARY." Thanks!

Revision history for this message
Be (be.ing) wrote :

I don't think there should be any sort of indication that a track is hidden or any user interaction required. If a track is hidden or missing, I don't think it should be shown in playlists. I think ronso0's idea to check whether tracks are hidden when displaying a playlist is a good idea.

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

We cant remove it from the playlist, because if the missing state is temporary the play-list is broken.

Revision history for this message
geozubuntu (geozubuntu) wrote :

A different color of the letters of the missing track name could be of a great help.
Missing tracks shouldn't be removed from the playlists but somehow they have to be distinguished.

Example: I got a new hard disk. Now I have plenty of space so I ripped some tracks in best lossless quality and deleted the inferior low bitrate mp3s.

Now I have to check ALL playlists for ALL changed tracks to change them with the new better ones which is a huge work.

If they were written -let's say- in Red letters then when I need to use the playlist I would know immediately that there are 3 tracks missing, so I could search for and change them in seconds. That way neither my playlists would be damaged nor I had to manually check all its tracks one by one.

Thanks.

summary: - Mixxx 2.2.0: deleting track from disk leaves track listed in playlists,
- even though track no longer exists
+ Deleting track from disk leaves track listed in playlists, even though
+ track no longer exists
ronso0 (ronso0)
Changed in mixxx:
assignee: nobody → ronso0 (ronso0)
status: Confirmed → In Progress
milestone: none → 2.3.3
ronso0 (ronso0)
Changed in mixxx:
assignee: ronso0 (ronso0) → nobody
Revision history for this message
ronso0 (ronso0) wrote (last edit ):

FWIW I'd prefer greying out missing tracks. Even though I don't know how this would be done it feels like that would be the simplest solution.
Because keeping the track references and playlist positions to allow restoring the previous playlist state requires something like keeping a complicated record of playlist changes to resolve situations where multiple tracks were removed (maybe at different points in time).

Another improvement for the library rescan would be a summary, like

  Library rescan finished.
  * 235 new tracks were found
  * 41 tracks have been moved
  * 12 tracks are missing

Changed in mixxx:
milestone: 2.3.3 → none
status: In Progress → Confirmed
Revision history for this message
ronso0 (ronso0) wrote :

Manually purging tracks is a different story. Then, tracks should be removed.

Revision history for this message
nPrevail (nprevail) wrote (last edit ):

I agree with @geozubuntu and @ronso0 suggestion; tracks shouldn't be deleted from playlists, but they should be indicated as "missing" somehow. That way it gives the user the ability to "find/repair" the missing track.

In Traktor, they use a "question mark" to indicate missing tracks from the library and playlist. I think "greying out the whole track row" would be a better solution since it could be viewed anywhere within the library.

"Missing tracks" in the library tree is helpful as well. Playlists aren't as consolidated to have a "missing tracks" category (or maybe it is?), but an indication (greyed out row) that tracks are missing is helpful.

Also, a library rescan summary would be nice!

Revision history for this message
ronso0 (ronso0) wrote :

FYI the rescan summary is tracked here lp:1970393

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/9365

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.