Skip to content
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

Fix uploader and subchannel avatars being swapped and disable loading thumbnail message failure on content details page #10066

Merged
merged 1 commit into from Jun 5, 2023

Conversation

Stypox
Copy link
Member

@Stypox Stypox commented May 3, 2023

What is it?

  • Bugfix (user facing)
  • Feature (user facing)
  • Codebase improvement (dev facing)
  • Meta improvement to the project (dev facing)

Description of the changes in your PR

  • In the XML of video details, the uploader and sub-channel images were swapped. Moreover, the code in VideoDetailFragment didn't really take into account the fact that when no sub-channel is present, the uploader is shown as sub-channel. So I fixed both of these things.
  • When there is no sub-channel, now the logic is the same regardless of whether the uploader name is empty (which would likely be caused by an extractor error) or not. So now when there is not even an uploader name, the subscribers and avatar are still shown.
  • I removed the error reporting snackbar that popped up when the video thumbnail failed loading: it's not really needed as if there is an issue with thumbnails not loading, we can just ask users to send us the thumbnail URL that can be found in the description. This is even more true after Allow selecting image quality among multiple images #10062 will be merged.
  • I tested both YouTube and PeerTube on a phone (normal layout) and on a table (large-land layout).

Before/After Screenshots/Screen Record

Before:
image
After:
image
The NewPipe channel page is correct: https://tube.tchncs.de/video-channels/she_drives_mobility
image

Fixes the following issue(s)

Closes #7416.

APK testing

The APK can be found by going to the "Checks" tab below the title. On the left pane, click on "CI", scroll down to "artifacts" and click "app" to download the zip file which contains the debug APK of this PR.

Due diligence

@Stypox Stypox marked this pull request as ready for review May 3, 2023 08:48
@sonarcloud
Copy link

sonarcloud bot commented May 3, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 1 Code Smell

0.0% 0.0% Coverage
0.0% 0.0% Duplication

@TobiGr TobiGr added bug Issue is related to a bug GUI Issue is related to the graphical user interface peertube Service, https://joinpeertube.org/ labels May 3, 2023
Copy link
Member

@TobiGr TobiGr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@AudricV AudricV changed the title Fix uploader and subchannel avatars being swapped Fix uploader and subchannel avatars being swapped and disable loading thumbnail message failure on content details page May 14, 2023
@TobiGr TobiGr merged commit 72c6ed2 into TeamNewPipe:dev Jun 5, 2023
6 of 7 checks passed
This was referenced Jul 31, 2023
Stypox added a commit to Stypox/NewPipe that referenced this pull request Nov 16, 2023
The fix just involves removing some really outdated code (6 years ago) added in 33e29be#diff-38bd2cf1b92659b499c08e1cf6ac9ef384c7e13381b906f2f98c57cbb758756dR778 (blame: https://github.com/Stypox/NewPipe/blame/9318bb530619898c1e1f3f8a8c866f3d2e35ab0c/app/src/main/java/org/schabi/newpipe/detail/VideoItemDetailActivity.java#L778).
What that code did was setting the 'buddy' image to the uploader avatar as a placeholder, and then setting the actual image if it existed and after it had loaded.
That code remained there up until now, but now it doesn't make sense anymore, since Picasso already takes care of setting placeholders.
The problem is, starting from TeamNewPipe#10066 the actual uploader image is set before (not after) those lines of code, making them do the wrong thing, i.e. always overwrite the currently set image.
But then why did the channel avatar image work normally sometimes?
My guess is that since Picasso loads images in the background, when opening a video from scratch setting the placeholder still happened before Picasso finished loading the image.
However when the image is already cached it's loaded much faster and therefore setting the placeholder happens after, effectively hiding the loaded image.
Stypox added a commit to Stypox/NewPipe that referenced this pull request Nov 16, 2023
The fix just involves removing some really outdated code (6 years ago) added in TeamNewPipe@33e29be#diff-38bd2cf1b92659b499c08e1cf6ac9ef384c7e13381b906f2f98c57cbb758756dR778 (blame: https://github.com/TeamNewPipe/NewPipe/blame/9318bb530619898c1e1f3f8a8c866f3d2e35ab0c/app/src/main/java/org/schabi/newpipe/detail/VideoItemDetailActivity.java#L778).
What that code did was setting the 'buddy' image to the uploader avatar as a placeholder, and then setting the actual image if it existed and after it had loaded.
That code remained there up until now, but now it doesn't make sense anymore, since Picasso already takes care of setting placeholders.
The problem is, starting from TeamNewPipe#10066 the actual uploader image is set before (not after) those lines of code, making them do the wrong thing, i.e. always overwrite the currently set image.
But then why did the channel avatar image work normally sometimes?
My guess is that since Picasso loads images in the background, when opening a video from scratch setting the placeholder still happened before Picasso finished loading the image.
However when the image is already cached it's loaded much faster and therefore setting the placeholder happens after, effectively hiding the loaded image.
Stypox added a commit that referenced this pull request Dec 7, 2023
The fix just involves removing some really outdated code (6 years ago) added in 33e29be#diff-38bd2cf1b92659b499c08e1cf6ac9ef384c7e13381b906f2f98c57cbb758756dR778 (blame: https://github.com/TeamNewPipe/NewPipe/blame/9318bb530619898c1e1f3f8a8c866f3d2e35ab0c/app/src/main/java/org/schabi/newpipe/detail/VideoItemDetailActivity.java#L778).
What that code did was setting the 'buddy' image to the uploader avatar as a placeholder, and then setting the actual image if it existed and after it had loaded.
That code remained there up until now, but now it doesn't make sense anymore, since Picasso already takes care of setting placeholders.
The problem is, starting from #10066 the actual uploader image is set before (not after) those lines of code, making them do the wrong thing, i.e. always overwrite the currently set image.
But then why did the channel avatar image work normally sometimes?
My guess is that since Picasso loads images in the background, when opening a video from scratch setting the placeholder still happened before Picasso finished loading the image.
However when the image is already cached it's loaded much faster and therefore setting the placeholder happens after, effectively hiding the loaded image.
Stypox added a commit that referenced this pull request Dec 10, 2023
The fix just involves removing some really outdated code (6 years ago) added in 33e29be#diff-38bd2cf1b92659b499c08e1cf6ac9ef384c7e13381b906f2f98c57cbb758756dR778 (blame: https://github.com/TeamNewPipe/NewPipe/blame/9318bb530619898c1e1f3f8a8c866f3d2e35ab0c/app/src/main/java/org/schabi/newpipe/detail/VideoItemDetailActivity.java#L778).
What that code did was setting the 'buddy' image to the uploader avatar as a placeholder, and then setting the actual image if it existed and after it had loaded.
That code remained there up until now, but now it doesn't make sense anymore, since Picasso already takes care of setting placeholders.
The problem is, starting from #10066 the actual uploader image is set before (not after) those lines of code, making them do the wrong thing, i.e. always overwrite the currently set image.
But then why did the channel avatar image work normally sometimes?
My guess is that since Picasso loads images in the background, when opening a video from scratch setting the placeholder still happened before Picasso finished loading the image.
However when the image is already cached it's loaded much faster and therefore setting the placeholder happens after, effectively hiding the loaded image.
javulticat pushed a commit to NewPipeX/NewPipeX that referenced this pull request Dec 30, 2023
The fix just involves removing some really outdated code (6 years ago) added in TeamNewPipe@33e29be#diff-38bd2cf1b92659b499c08e1cf6ac9ef384c7e13381b906f2f98c57cbb758756dR778 (blame: https://github.com/TeamNewPipe/NewPipe/blame/9318bb530619898c1e1f3f8a8c866f3d2e35ab0c/app/src/main/java/org/schabi/newpipe/detail/VideoItemDetailActivity.java#L778).
What that code did was setting the 'buddy' image to the uploader avatar as a placeholder, and then setting the actual image if it existed and after it had loaded.
That code remained there up until now, but now it doesn't make sense anymore, since Picasso already takes care of setting placeholders.
The problem is, starting from TeamNewPipe#10066 the actual uploader image is set before (not after) those lines of code, making them do the wrong thing, i.e. always overwrite the currently set image.
But then why did the channel avatar image work normally sometimes?
My guess is that since Picasso loads images in the background, when opening a video from scratch setting the placeholder still happened before Picasso finished loading the image.
However when the image is already cached it's loaded much faster and therefore setting the placeholder happens after, effectively hiding the loaded image.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue is related to a bug GUI Issue is related to the graphical user interface peertube Service, https://joinpeertube.org/
Projects
None yet
Development

Successfully merging this pull request may close these issues.

404 HTTP error when loading thumbnail of a video
2 participants