Deck/Spinny Coverart is randomly not read #11131
Labels
Milestone
Comments
|
I noticed, that after switching the Skin or the Color scheme the cover art is always drawn correct for all decks. |
JoergAtGithub
changed the title
|
Note, that the Library Coverart is always shown - this bug affects only the Deck/Spinny Coverart |
|
Can you play the track if there's no cover? |
|
Yes, everything works, just the Coverart image in the Deck/Spinny is randomly ~50% missing |
|
This still occurs with any 2.4 build for me, while 2.3.5 work flawless. Occurs on two laptops with Win7 and Win11. |
|
Do you see any related warnings when loading a track? |
|
1.) The only messages about cover art are these, which I posted in the descriptions. But I'm not sure if these are related here. 2.) The default cover is shown if no CoverArt is displayed 3.) When I switch skins in the preferences, the CoverArt appears for all decks where a track is loaded Any idea how to debug this? |
|
Maybe an issue in |
|
If I set a breakpoint in Line 70 of mixxx/src/library/coverartcache.cpp Lines 64 to 74 in 3de2963 it fails always. I guess this is some kind of race condition. |
|
CoverArtCache::requestTrackCover is always executed, the breakpoint always triggers, for cases where the CoverArt is loaded and for the cases, where it does not. |
|
I think you could inspect the cover data in |
|
I'm a step further. The following function is executed three times, when a track is loaded into a deck. mixxx/src/widget/wspinnybase.cpp Lines 377 to 386 in 4a51c39 |
|
In case of not displayed CoverArt, |
|
I'd like to reproduce this but on macOS I've never seen this happen. Are there any specific steps to make this more likely to occur? |
|
This occurs on Windows most of the times (roughly 90% of the track loads the CoverArt in the spinnies is missing). I don't need to do anything special. |
|
I don't think this will make a difference, but just in case, can you check with the old spinny implementation by returned a new WSpinny instead of a new WSpinnyGLSL in LegacySkinParser::parseSpinny ? |
|
As running this in the debugger is tricky, you could add some more logging in the CoverArtCache and WSpinnyBase code to see where the difference between successful and null pixmaps occurs exactly. Btw, while looking at the code, this std::move seems very strange to me. |
Good catch, but since the signal parameters just take/pass lvalue refs, I'm pretty sure it doesn't do anything. |
Yes, I tried to change this already, but it doesn't fix this bug. |
|
Could you add a lot of logging in all the functions involved and share the logs of a cover does and a cover that doesn't load? |
|
I added a debug statement after each Only the last loaded track showed the CoverArt in the Spinny.txt |
Merged
|
Maybe related test fails are in the Qt6 CI builds: https://github.com/mixxxdj/mixxx/actions/runs/6021023487/job/16343828636 |
|
Sorry for not getting back to you, @JoergAtGithub . I have been very busy. I will try to find some time to look into this this weekend. In the meantime, maybe you already tried this, if not can you try if this also happens with the non-GLSL spinnies, by returned new WSpinny instead of WSpinnyGLSL in the legacyskinparser.cpp around line 1322 ? |
|
This bug occurs with all waveform types. |
|
Some takeaways:
So it looks like the file becomes invalid somehow. Can you uncomment this and check if the file name is still valid? |
Maybe the vcpkg build environment for Windows is broken somehow? |
|
Wow, that's wild (Qt6, main + ...): All this happens while loading a single file into a deck. The cover art of the file is imported 9 times! The subsequent read failures reported by FFmpeg are really worrisome. |
|
And the winner is: DlgCoverArtFullSize. Even though it should not be involved at all! With WSpinnyBase as a close follower. Which should also not be involved, because I don't have any spinnies with cover art enabled. The only expected request is the one from WCoverArt. |
|
Looks like there are some serious issues in the application's control flow. |
|
On Windows, the file access of Mixxx in general, is rather slow. I guess that this increases the likelyhood that the race condition results in a not loaded CoverArt. |
|
The results from a Qt5 build don't look any better: Things are seriously broken. Unfortunately no crashes yet, which could have helped to identify the root cause timely. Now someone has to start bisecting the repo. |
|
@uklotzde If this is the log from loading a track to a deck, and you use Deere for example, I'm pretty sure all those requests are to be expected.
If you use Deere for example the spinnies are instantiated even if you disabled the in the skin settings. |
|
The failures of FFmpeg are unrelated and caused by a recent regression: #11923 |
|
Adding some conditionals in DlgCoverArtFullSize and WSpinnyBase fixes the excessive loading and everything still seems to work as expected. But I can't proove why, don't expect a PR. |
This was referenced Sep 7, 2023
Merged
This was referenced Oct 11, 2023
|
Thi fix can be found here: #12103 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Description
If I load a track into a deck, the CoveArt is sometimes displayed, and sometimes not. This doesn't depend on the track, it can be reproduced for any track after some retries.
This doesn't happen with 2.3, only with Main.
In the --developer output I see in cases without loaded coverart:
Version
2.4
OS
Windows7 & Windows11
The text was updated successfully, but these errors were encountered: