-
-
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
Restore invalid cover image hashes #2508
Conversation
Needs to be rebased on master after #2511 has been merged to fix the spurious test errors. |
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 for the PR. I have left some comments, the manual test is pending.
src/library/coverart.cpp
Outdated
<< *this; | ||
// Preserve the track location, i.e. slicing during | ||
// assignment is intended here! | ||
static_cast<CoverInfoRelative&>(*this) = CoverInfoRelative(); |
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 would prefer a separate function to reset the cover info. I can imagine that even with this comment, the code cannot be understand by a less experienced contributor.
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.
Done
Let's see if the tests will succeed after the database issues have been fixed. |
Still segfaults with ctest on Travis |
After a long search for the spurious segfaults during tests I have rebuilt the whole branch and reorganized the commits into small, correlated work packages. Hopefully all tests will pass now. |
The remaining CI failures are now really unrelated. |
@daschuer: Ready, finally. The concurrent guessing of cover art was poorly documented and designed with lots of implicit assumptions and dependencies. It worked more or less by chance. This investigation and fix has cost me a LOT of time! #2525 contains a separate fix for the application, independent of any test setup. |
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.
The API is still a bit cluttered. It would be nice to clean up.
The manual test was successful. So it is already merge-able.
CoverArtCache::~CoverArtCache() { | ||
qDebug() << "~CoverArtCache()"; | ||
//static | ||
void CoverArtCache::requestCover( |
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.
Request cover implies to respond with a cover. Is this always the case here?
What happens if the cover is returned instantly?
I think the called tryLoadCover() name needs to be adjusted as well. ... Or split into two functions.
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've just tried to preserve the original naming that used "request" for asynchronous invocations.
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.
request is always called with a pRequestor that expects to receive the result as a signal. What's wrong with this? Returning a QFuture from tryLoad would be nice, but it doesn't allow to return immediate results. Aynway, I'm not planning to rewrite this.
<< requestInfo << pRequestor << | ||
desiredWidth << onlyCached << signalWhenDone; | ||
//static | ||
void CoverArtCache::requestTrackCover( |
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 the request that unlike all direct calls to requestCover also updates the Track.
I think we should get rid of the default null track parameter in requestCover and call pCache->tryLoadCover expicite will pTrack or TrackPointer()
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.
Done
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.
The request functions are static and return nothing. Both (public) variants boil down to a single, special-case invocation of tryLoad. The tryLoad function is non-static and may return something immediately, later, or never.
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.
The use cases are already split. How and why does this need to be split even further?
kLogger.info() | ||
<< "Updating cover info of track" | ||
<< coverInfo.trackLocation; | ||
pTrack->setCoverInfo(coverInfo); |
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 redundant if we pass the track into the request.
Can't we do it at one place only?
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.
No, we don't. The CoverArtDelegate accesses query results directly. Track objects are only loaded if the CoverArtCache signals that the cover info has been updated.
Only support two distinct use cases, either with or without a Track object at hand.
Ok, no need to overengineer this. It is already a good step forward.
|
Backward compatibility with legacy Qt versions strikes once again. |
Anything else to do? CI failures are unrelated. |
@daschuer Ping. I have more changes ready on top of this PR that will allow to share UI code between the internal track collection and external track collections like aoide. Mainly additional base classes and a signal/slot optimization for the CoverArtDelegate. I already experienced inconsistencies due to redundant code that I want to prevent in the future. |
No issues found during manual tests. LGTM. Thank you. |
Invalid cover image hashes with the value 0 are not handled correctly and wrong cover images are displayed. Instead those hashes need to be fixed and updated on-the-fly when the images are loaded the next time by
CoverArtCache
.The updating is done in
CoverArtDelegate
that has access toTrackModel
.CoverArtCache
does not have direct access toTrack
objects or the library and I don't want to introduce such a dependency. Updating the hashes when tracks are loaded is too late, because first the images are loaded and displayed in the track table view without instantiating anyTrack
objects. Not ideal but a clean solution that fits into our current design.Follow-up
PR #2524: SHA-256 digest and (background) color