# of items in history playlist isn't adjusted when tracks are deleted from library

[Eve00000]

Bug Description

number of items in historic playlist isn't adjusted when tracks are deleted from library.
A historic playlist can indicate (2) tracks while there aren't tracks in the playlist (displayed) anymore.
extra: Merging (jopoining) historic playlists adds the total of the tracks, does not recalculate the real # of items.

Version

main

OS

win 10

[ronso0]

Thanks for the report, I can confirm.
While the sidebar update can be fixed, this (again) raises the question how to deal with deleted tracks.

IMHO 'rewriting history' is bad, unless you manually delete a track from a History playlist.
I think when purging a track we should keep the entries if that track is in a history playlist. Though it's difficult/cumbersome to

• exclude it from the Missing view
• finally purge the track if it is deleted from the last History playlist that contains it

edit
Actually the track (ids) are currently kept in the History playlists, but there's no track metadata available anymore, hence the inconsistency between sidebar (playlist tracks count) and tracks view (actual tracks).

[Eve00000]

You 've got a good point there.
There should be a difference between automatic changing a historic playlist and manual changing it (fi replacing a lossy track by the lossless version of that track.).
Or when you clean up your library and leave 1 version of 2 identical versions of a song. Then you want to replace all occurences of the 'track to delete' with the other one. (In itunes I made scripts for all this possibilities)

Let me think about it please,
PS, ADD: A historic playlist should always contain all played songs, even songs that are deleted, then maybe tracks should get a (del) prefix/addendum in title/artist en logically not appear in the library (or maybe in a deleted tracks list)

[Eve00000]

I don't know if this is the right place to write a proposition... (we can always continue on zulip if needed)
I would introduce some new Mixxx-special filetypes:

• a Mixxx-del-xxxxx type: when track that occurs in the historic playlists is deleted, the filetype hets the prefix Mixxx-del. so there could be Mixxx-del-mp3, Mixxx-del-wav, Mixxx-del-stem.mp4 ... These files don't occur in the liibrary, except in a dedicated list.
• in the same effort a Mixxx-txt filetype can be created, there were users that asked for a way to refer to tracks which are not in Mixxx's library (vinyl, cd..) in playlists. The possibility to let these references occur in the library could be an option.
• there could be a demand for other Mixxx-own-types ...

PS: #13580 demands a solution for 'voice' in broadcast-cue files, thixs could be fi a Mixxx-voice type

[ronso0]

Thanks for your ideas, though I think creating files is not the easiest solution, and it's not really related to the "file missing" case here.

All tracks are stored in the database, so what could work would be a new column in the library table that can be set 1 for missing tracks (both file and db entry) that are in History playlists.

Re: voice/vinyl/aux "tracks"
Mixxx could allow storing tracks without attached files.
Such tracks could be added automatically (voiceover, aux) or manually (vinyl tracks, notes etc. in playlists), and all metadata incl. duration can be edited.
But yeah, this doesn't really belong here, probably better to discuss it in #11727

[Eve00000]

You misunderstood, I meant virtual filetypes, insread of the mp3, wav,... only exissting in the database as records...

[ronso0]

Ah okay. Still, I think the database provides better ways to mark tracks.

[ronso0]

Idea:
we could mark deleted tracks that are still in History playlists with 2 in the track_locations table.
This would happen in TrackDAO::onPurgingTracks and requires some more modifications in PlaylistDAO and other units.
1 file missing, listed in Missing and all playlists
2 file missing and marked as 'purged, ignore', not listed in Missing, only kept in History playlists

[Eve00000]

Hi @ronso0 ,
Thank you for picking this up.
So you propose to make a virtual location instead of a virtual filetype, fine.
But the most important is how the 'deleted' file is shown in the history lists (not with a colour please) so that it is clear that the file is deleted and can't be dragged/dropped in a player, can't be added to a playlist/crate, no editing possible.
Maybe with a prefix in the artist & title? The #played / last played / added columns should be left as they are.
How will the user be able to find all 'deleted tracks occuring in historylists' ?

[ronso0]

So you propose to make a virtual location instead of a virtual filetype, fine.

Hmm, no, entirely unrelated.
All I propose is to extend the fs_deleted flag options (fs for file system)
0 (track is assumed to exist) and
1 (track file missing)
with
2 (track file missing, but keep in History).

The track metadata simply remains in the database, exactly as with missing tracks currently.
These tracks' metadata can still be edited (why not?) and the can't be loaded currently anyway if marked missing.
Of course "The #played / last played / added columns should be left as they are."

The 'missing' color is what we have right now, but of course we can create other 'markers' like make the 'deleted' column visble and show an icon or something (no hacks like tag prefixes please).

---

The work is just ™️ that library DAOs have to handle this flag properly:

• when tracks are purged (check if they are in History playlists, maybe allow to remove them from these, too)
• when playlists are populated (show only fs_deleted=1 as before)
• when the Missing view is populated (show only fs_deleted=1 as before)
• when missing tracks are removed from History playlists (finally purge)

[ronso0]

Btw we can close this bug since the original issue has been fixed by #13579

[ronso0]

So with my comment #13578 (comment) this has morphed into a discussion / feature request.