changing terminology "Remove" to "Hide"

Bug #949828 reported by Angel on 2012-03-08
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Low
Max Linke

Bug Description

In 1.10 (using Ubuntu) I accidentally deleted my library files. After I rescanned the library, it still doesn't get my library back.
It even removed ALL the playlist and crates content! Thankfully, the files are not deleted...

Daniel Schürmann (daschuer) wrote :

This looks like the "desired" behavior of Mixxx.
Is it this what happens?:

* Slect Library view
* Ctrl+A
* delete tracks via context menu.
** This clears all playlists an crates content as well
** This marks all tracks as deleted
* rescan library
* The library scanner discards all found songs because the are marked as deleted.

The only workaround I know for this case now, is to use Ubuntu's "Search for files" feature and Drop all files back to the library view. This must be a bitchy task if you have a big library.

Mixxx misses an "Undelete all" function. This could be placed in the application's menu bar.

Daniel is right -- when you delete tracks from the library we mark them
deleted so they do not show up on a re-scan. If you ask us to remove a
track from the library you might be annoyed if they all came right back
after a re-scan.

The only work-around is that we un-delete tracks when you drag them back
into the library from a file browser.

I agree with Daniel -- we need some way for the user to ask us to undelete
everything.

2012/3/8 Daniel Schürmann <email address hidden>

> This looks like the "desired" behavior of Mixxx.
> Is it this what happens?:
>
> * Slect Library view
> * Ctrl+A
> * delete tracks via context menu.
> ** This clears all playlists an crates content as well
> ** This marks all tracks as deleted
> * rescan library
> * The library scanner discards all found songs because the are marked as
> deleted.
>
> The only workaround I know for this case now, is to use Ubuntu's "Search
> for files" feature and Drop all files back to the library view. This
> must be a bitchy task if you have a big library.
>
> Mixxx misses an "Undelete all" function. This could be placed in the
> application's menu bar.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/949828
>
> Title:
> Rescan library doesn't work
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/949828/+subscriptions
>

I've been confused about the "delete" terminology myself, so maybe we should change it. How about calling these tracks "hidden" instead. Then we can make a special library view that shows *only* the hidden tracks. The user can go into this view, select the tracks, and unhide them.

Angel (ronald-delvax-hotmail) wrote :

Where does Mixxx keep track of settings like this?
I'm not yet too familiar with Linux to find files like that...

I also found a problem when I try to drag the width of a section in a list...
It automatically creates a space that I can't delete... By manually edditing the settings I might correct this...
1.8 didn't have this problem tho... And 1.10 on Windows has the same problem.

BTW, thanx for the quick reply.

Daniel Schürmann (daschuer) wrote :

@Owen: I like your idea to change the naming to "hide" and have a tree view child for "Hidden tracks".

@Angel: Mixxx keeps its library at ~/.mixxx/mixxxdb.sqlite. If you are brave enough, you may install sqlitebrowser and "unhide" the tracks manually due to to reset the value of "mixxx_deleted" in the "library" table to 0. Please exit mixxx first and don’t forget to backup the mixxxdb.sqlite file.

The collumn resize issue is tracked in bug #925619. You may klick that this bug effects you too.

summary: - Rescan library doesn't work
+ changing terminology "Remove" to "Hide"
Daniel Schürmann (daschuer) wrote :

The attached patch renames "Remove" into "Hide from library" and it introduces "purgeTracks" for remove track from missing tracks view and from browser view.

Changed in mixxx:
assignee: nobody → Daniel Schürmann (daschuer)
status: New → Confirmed
Changed in mixxx:
status: Confirmed → In Progress
Daniel Schürmann (daschuer) wrote :

Updated patch for lp:mixxx #3023
Additional removed unused functions.

jus (jus) on 2012-04-23
Changed in mixxx:
importance: Undecided → Low
milestone: none → 1.11.0
Max Linke (max-linke) on 2012-06-10
Changed in mixxx:
assignee: Daniel Schürmann (daschuer) → Max Linke (max-linke)
Daniel Schürmann (daschuer) wrote :

Hi Max,

I am please that you pickup this one.
I am just wondering whats the best time line for it.
Since this bug is a Milestone 1.11 fix and you are panning to add additional features which will take place in a later milestone.
Do you think its possible to prepare a "preview" based on the current patch that is suitable for 1.11 but dos not complicate your planed work?

Kind regards

Daniel

Max Linke (max-linke) wrote :

I don't know when RJ wants to start the beta-phase for 1.11 so I can't say for sure.

For 1.11 I could imagine to add a hiddenTM and add a undo option for this TM in addition to your patch (see #406365) to wrap this one up nicely. If you can give me a patchfile of your work on a undo function this should be manageable in the next 1-2 weeks and also helpful for me on my work for 1.12.

Max Linke (max-linke) wrote :

OK this was done faster then I thought.

This patch against trunk r. 3254

It adds a hiddentablemodel that is shown as a in addition to the missingtablemodel.
In this TM it's possible to unhide the tracks or purge them. Also I've changed "Remove" in
the missingTM to "Purge from Library", this is because we also use "Remove" in Playlists and Crates
but there "Remove" does not mean delete this track from the library and in the context of the
hiddenTM and missingTM it should be clear what purge means. The rest is from Daniels patch

Daniel Schürmann (daschuer) wrote :

Hi Max,

Good work!

I head a little time for test.
Here are my results:
* In general it works like expected :-)
* After purging a track, the directory hash should become invalid so that it will be found on a library scan.
* Open in a file browser did not work for deleted tracks. The former directory should be open or the menu entry should be removed.
* The track is not purged from the Cue table ( My fault :-( ) Are there additional references?

RJ Skerry-Ryan (rryan) wrote :

Just took a quick pass over the code and it looks good to me. I'll give it a more thorough review later.

In TrackDAO::purgeTracks make sure to use ScopedTransaction instead of manually beginning and rolling back in every error case.

Max Linke (max-linke) wrote :

This version uses ScopedTransactions, please comment if I've used it correctly

All references I've found in the library are also deleted. If the track is in a subdir of libraryPath the track will be added on the next rescan.

Show in Browser now falls back to the home directory in case the file is not found.
I'd prefer to use QDir::cdUp() but this will do nothing if the directory still does not
exist.

I have a question about performance. I see a lot that we use QString(...).arg and "..." + variable a lot
which one of these is faster? If one has a performance benefit we should stick to that one. This is important since we handle a lot of our DB-code in the GUI-Thread.

RJ Skerry-Ryan (rryan) wrote :

Thanks Max! I reworked your patch a little bit in purgeTracks(). Also I moved hideTracks() to BSTM instead of LibraryTableModel since hiding from crates / playlists / analyze / etc. doesn't work otherwise.

Changed in mixxx:
status: In Progress → Fix Committed
Max Linke (max-linke) wrote :

This addresses the TODO's you've added

RJ Skerry-Ryan (rryan) wrote :

Thanks -- committed.

RJ Skerry-Ryan (rryan) on 2013-05-09
Changed in mixxx:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers