[Bug] Scarce seekbar thumbnails for YouTube #215
Comments
|
https://github.com/InfinityLoop1308/PipePipe/actions/runs/7854116332 fixed the issue. You can download the apk there but a new release will take more time. |
|
thumbnails within thumbnails fixed |
|
the preview used to stay on display while moving the seek position to hazard a guess, Edit: ok, opened embed in desktop edge and it fetched 800x450, so that was a hazard, i guess 💦
|
|
|
maybe either public static RequestCreator loadSeekbarThumbnailPreview(final String url) {
//return picassoInstance.load(url).transform(transformation);
return picassoInstance.load(url);
}or // Cut out the corresponding bitmap form the "srcBitMap"
return Bitmap.createBitmap(srcBitMap, bounds[1], bounds[2],
frameset.getFrameWidth() - 1, frameset.getFrameHeight() - 2);since def print_height(source_width, source_height, label='', *, inverse=True):
notif_thumb_width = min(4000, source_width)
width = notif_thumb_width - 1
# https://codeberg.org/NullPointerException/PipePipeClient/src/commit/9b78286703/app/src/main/java/org/schabi/newpipe/util/PicassoHelper.java#L59
# (int) (source.getHeight() / (source.getWidth()
# / (notificationThumbnailWidth - 1))),
f_height = source_height / (source_width / (notif_thumb_width - 1))
i_height = int(f_height)
w_diff = width - source_width
h_diff = i_height - source_height
if label: tail = f'; {label}'
print(f'{source_width}x{source_height} \u21d2 {width}x{i_height} ({w_diff}x{h_diff}; {width}x{f_height:.02f}{tail})')
if inverse:
print_height(source_height, source_width, label, inverse=False)
print_height(800, 450, 'embed in edge desktop')
#print_height(3840, 2160, '4K')
#print_height(7680, 4320, '8K')prints |
|
I rollbacked the changes. It should work now. |
|
thank you, but somehow no ci entry or commit at codeberg frameset.getFrameWidth()-1, frameset.getFrameHeight()-2(int) notificationThumbnailWidth + 1,
...
/ (notificationThumbnailWidth + 1))),both seem to work
|
|
Here bug this: SM-G935F_20240216210115.mp4
|
|
Is this the latest version? That shouldn't happen as it is just the same code before 3.2.1🤔 |
|
Before it further complicates. My understanding is that v3.2.1 introduced the 800px width limit for "framesets", which are the concatenated seekbar preview thumbnail sprites (tiles?). All framesets beyond that limit would be reduced to 800px in width, proportionate in height. I guess that might render these patchwork thumbnails. The first hotfix (which is not released, but only exists in the ci entry) adjusted that limit to 4000px, but has still retained the minus-one pixel reduction because it is necessary to force Android to create a new My comment mentioning the plus-one fix and the minus-two fix was based on the first hotfix, not v3.2.1 proper, elaborating on the remaining sparsity issue. NewPipe originally introduced the minus-one pixel reduction for some devices the System UI of which crashes if the bitmap wasn't copied anew for the notification background image. It had never been applied to seekbar preview thumbnails in the first place. |
Your suggestion is very likely to be better but for stability I have to choose the safest option. Sorry for that. Thanks for your feedback and discovery |
|
no problem |
|
Fixed in 3.3.0 |
ghost
mentioned this issue
Since installing v3.2.1 over v3.2.0, there shows only one for somewhere around every fifteen seconds. Some of them look like a cropped sprite source image. Thumbnails of other sorts appear as normal.
Regrettably though I will not be useful in any way fixing the problem, I am mollified that it is unlikely that there will be any serious dispute as to why it is related to this particular version and hope any relevant entity blesses so that a peaceful solution is discovered.
The text was updated successfully, but these errors were encountered: