Skip to content

fix(youtube): tolerate missing fields in channel-search playlist items#74

Open
Priveetee wants to merge 1 commit into
InfinityLoop1308:mainfrom
Priveetee:fix/2546-channel-search-playlist-items
Open

fix(youtube): tolerate missing fields in channel-search playlist items#74
Priveetee wants to merge 1 commit into
InfinityLoop1308:mainfrom
Priveetee:fix/2546-channel-search-playlist-items

Conversation

@Priveetee

Copy link
Copy Markdown
Contributor

Fixes the "Could not get url" error reported when searching inside a YouTube channel whose results include a channel playlist.

Tracking: InfinityLoop1308/PipePipe#2546

Summary

Channel-search results (channel//search?query=...) can surface regular channel playlists via playlistRenderer. YoutubeChannelTabExtractor routes those to YoutubeMixOrPlaylistInfoItemExtractor, which only read shareUrl and threw ParsingException("Could not get url") when it was absent. The throw aborted the whole item commit and, because PlaylistInfoItemsCollector funnels per-field errors into ChannelTabInfo.getErrors(), surfaced as a user-facing snackbar while every other result still loaded fine (the reporter's "all functions work as usual"). The same extractor also threw on missing thumbnails and missing item counts, feeding the same snackbar.

This makes the three optional fields tolerant: rebuild the URL from playlistId when shareUrl is missing, return null for a thumbnail that cannot be parsed, and report ITEM_COUNT_UNKNOWN when the count text is missing.

Why

shareUrl is a mix/radio renderer field. Regular channel playlistRenderer items do not carry it, they carry playlistId, exactly like the sibling YoutubePlaylistInfoItemExtractor.getUrl() already builds the URL from playlistId + YoutubePlaylistLinkHandlerFactory. The fallback reuses that existing, correct path instead of inventing a new one.

Thumbnails and item counts are optional metadata. A missing thumbnail should show a placeholder, a missing count should show nothing, neither should break the item or nag the user. The collector already try/catches these three methods and pushes every exception into ChannelTabInfo.getErrors(), which SearchFragment.handleChannelSearchResult turns into a snackbar for any non-empty error list. Stopping the throw at the source removes the spurious snackbar without touching the client's error-surfacing policy.

Changes

  • getUrl(): return shareUrl when present; otherwise rebuild the canonical playlist URL from playlistId via YoutubePlaylistLinkHandlerFactory; throw only when neither is available.
  • getThumbnailUrl(): catch the helper's ParsingException and return null instead of propagating.
  • getStreamCount(): return ListExtractor.ITEM_COUNT_UNKNOWN when videoCountShortText is missing instead of throwing.

Validation

  • ./gradlew :extractor:compileJava (clean)
  • On-device repro on my Pixel 8, app debug build with the extractor substituted through includeBuild:
    • Reproduced the bug first: channel-search for 1 inside the Brawl Stars channel (UCooVYzDxdwTtGYAkcPmOgOw), content locale zh-TW/TW. SearchFragment.showSnackBarError() fired with ParsingException: Could not get url from YoutubeMixOrPlaylistInfoItemExtractor.getUrl:38, while the 20 result items still loaded.
    • After the change, same channel + same query: showSnackBarError() no longer fires, no ParsingException during extraction, and the same 20 items (videos plus the Brawl Talk playlist card) still display.

Reproduction was network-dependent: YouTube returned an empty result set for this query from EU/datacenter IPs. The on-device repro required me to connect the Pixel 8 to a Taiwan VPN to get the same response YouTube gives the reporter. I did not test on the emulator.

Notes

The fix is extractor-only. The client was temporarily instrumented with a Log.e to capture the stack and the raw renderer JSON during diagnosis, then reverted; its working tree is clean. The captured renderer confirmed the item is a regular playlistRenderer carrying playlistId but no shareUrl.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant