Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove from disk: add to deck track menu, fix undeleted message #4560
Remove from disk: add to deck track menu, fix undeleted message #4560
Changes from all commits
b32addd
fda4ed1
b9d5a4c
e89aedf
23b9581
3c6e33d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Linux you can delete the file while playing.
It is actually removed after the last reference to the file has been closed.
On Windows the file is locked until all file handles are closed.
I am not sure how it relates to caching. The file is kept in cache after rejecting.
We need to check if the lock is released than.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code drags dependencies into WTrackMenu that don't belong here. Another example of the spaghetti control flow in Mixxx, unmaintainable.
Is this side-effect even synchronous? Can we guarantee that the track is ejected immediately? Probably not, because decoding is done concurrently in a separate thread -> CachingReaderWorker.
I suppose this doesn't work as intended.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is only supposed to have a clean UX: it would be confusing if the deleted track was still loaded and could still be played.
Please clarify your technical concerns (for example the libmad issue) and give an estimation if this can be solved at all (by me, with guidance, of course). Because, if there are issues to be expected they apply to the delete and purge action in general, not just to the deck option, since we're not checking if a track queued for deletion is analyzed or loaded anywhere. If there are serious concerns it'd be sad they pop up just now because we'd then have wasted quite some time implementing the feature in the first place :\ (what I've learned along the way would be persist, but still..)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't imagine an easy fix considering the current state of the code base. Merging the code for deleting files directly from within Mixxx without any chance to detect if those files are still accessed by Mixxx probably was a mistake. We didn't consider all the consequences.
I don't veto against merging this PR, but on the other hand I won't merge it myself. Someone else may decide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, that's unfortunate.
I'm puzzled why you approve the changes even though you have serious technical objections.
I still don't overlook the potential consequences:
The worst case would be Mixxx crashing when deleting mp3 files due to the libmad / SoundSourceMP3 / mmap issue, right? In that case I wouldn't mind removing the entire feature.
Besides that, what could happen that harms the database or puts Mixxx into an inconsistent state?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could only delete the entire review or keep the rejection. Both are not an option for me. "Disagree and merge" or "Disagree and let others merge" (for a second opinion).
I don't really care enough and I also don't have a better proposal. The code is just ugly with the entanglement of the control proxies for triggering a side-effect in another component directly. It works somehow, but probably not always.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, then thanks for your review!
I'll leave to others to judge the remove feature.