-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Optionally reset metadata on reimport if file tags are missing #4873
Conversation
Context: https://mixxx.discourse.group/t/cannot-update-blank-tag-in-mixxx/25348 quodlibet/quodlibet#4065 The behavior is configurable, but the preference dialog has not been extended yet. The default behavior is as before, i.e. missing fields in file tags are silently ignored and their metadata is preserved. The only actual behavioral change affects the track properties dialog where missing fields in file tags are reset unconditionally, independent of the preference setting. The comment in the code explains why this behavior suitable.
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.
Thanks. I have a couple questions.
@@ -146,6 +156,9 @@ void importTrackMetadataFromTag(TrackMetadata* pTrackMetadata, const TagLib::APE | |||
&discTotal); | |||
pTrackMetadata->refTrackInfo().setDiscNumber(discNumber); | |||
pTrackMetadata->refTrackInfo().setDiscTotal(discTotal); | |||
} else if (resetMissingTagMetadata) { | |||
pTrackMetadata->refTrackInfo().setDiscNumber(QString{}); | |||
pTrackMetadata->refTrackInfo().setDiscTotal(QString{}); | |||
} | |||
#endif // __EXTRA_METADATA__ | |||
|
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.
Just curious, below we also parse bpm, trackgain, etc. Why are we not resetting those?
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.
Would have been extra work and for those the tags don't matter. You could reset them in Mixxx. Slightly inconsistent but acceptable.
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.
Sure. Would you mind adding a that sentence as a comment above the imports you didn't touch?
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.
A comment was already in place at the entry point. I have extended it: 5d1f73b
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.
Sorry I seem to have read past that. Thanks.
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.
Unfortunately, the code is a little bit scattered and the entry point is not obvious.
The boolean could be transformed into an enum for type safety, but the boolean was easier to handle while extending the implementation. That was a deliberate decision.
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 have decided to add the missing reset of both bpm and replay gain: c848725
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.
LGTM. anyone else willing to take a look?
I will have a look. |
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 have not yet understand why we treat reading from the file differently if it is called from the track properties dialog or from the context menu. Sure, the users have control via "Apply", but how will they find out that the context menu behaves differently? I would prefer that both behave the same for a reliable and predictable behavior.
I think we have originally not reset the not existing tags, because we where not able to write the data back. But now we can reconsider this.
There is a an issue with BPM, When I read from metadata, the BPM value is rest, but when I press apply it reappears. This should not happen.
Maybe we should treat the mandatory metadata that is Mixxx using itself differently.
I have BPM/Key and ReplayGain in mind.
I think we import these value only if Mixxx does not have them and we never reimport them again.
The same should also apply to a not existing value in the file tags.
There is clearly a use case for empty textual tags in a third party tool and pull that in as described in the forum, but there is IMHO no use case in clearing BPM, Kay and ReplayGain, read from file tags and than expect that Mixxx is analyzing this again.
src/library/browse/browsethread.cpp
Outdated
@@ -162,10 +162,12 @@ void BrowseThread::populateModel() { | |||
thisPath.token()); | |||
{ | |||
mixxx::TrackMetadata trackMetadata; | |||
constexpr auto resetMissingTagMetadata = false; // no effect |
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 do not understand the comment. Can we remove that, or make it more verbose?
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.
Comments are needed: a607187
bool isPeakValid = parseReplayGainPeak(&replayGain, strPeak); | ||
if (isPeakValid) { | ||
pTrackMetadata->refAlbumInfo().setReplayGain(replayGain); | ||
ReplayGain* pReplayGain = pTrackMetadata->refAlbumInfo().ptrReplayGain(); |
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 can be renamed to pAlbumReplayGain and the one above to pTrackReplayGain.
Did you consider to move the code into parseReplayGainPeak, to deduplicate it a bit?
The function is only used here.
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.
These are all still regular tags. Introducing some special case handling for some of them will only cause confusion. The behavior should be predictable. |
This PR allows to switch between 2 different modes of operation, i.e. lazy (traditional) or strict. I will not extend the scope. |
This is probably an unrelated issue with the dialog and should be resolved separately. |
Restored the original behavior: de88868 |
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.
Thank you. LGTM.
I think the underlying idea of removing non existing metadata is correct. However ther is an existing Bug with the BPM value that demonstrates the issue with the scalar BPM tag. This also applies to Key and partially to ReplayGain. I think after this is solved we have a clear view how to deal with this new preferences option.
Context:
https://mixxx.discourse.group/t/cannot-update-blank-tag-in-mixxx/25348
quodlibet/quodlibet#4065
The behavior is configurable, but the preference dialog has not been extended yet (I am not planning to do this). The default behavior is as before, i.e. missing fields in file tags are silently ignored and their metadata is preserved.
The only actual behavioral change affects the track properties dialog where missing fields in file tags are now reset unconditionally, independent of the new preference setting. The comment in the code explains why this behavior is suitable.