mirror of
https://github.com/sigma67/ytmusicapi.git
synced 2026-04-25 07:16:00 +03:00
[GH-ISSUE #582] Songs mistaken for Albums when .search() with language is not "en" #405
Labels
No labels
a/b
bug
documentation
enhancement
good first issue
help wanted
invalid
pull-request
question
wontfix
yt-error
yt-update
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/ytmusicapi#405
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @shibotto on GitHub (May 12, 2024).
Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/582
Describe the bug
When doing
.search(), songs in the "Songs" category are mistaken for albums if language is not English. The problem started with version 1.7.1.To Reproduce
(曲 = Songs)
with 1.7.0:
with 1.7.1:
@shibotto commented on GitHub (May 13, 2024):
I'm exploring this issue a bit because I have time. Before
614999c77dinparse_search_result()if an element hadvideo_typeit was assumed to be either a song or a video, elseget_search_result_type()would be called to try and determine what we are dealing with.Now this behavior has been (somewhat) reversed. The problem is that
get_search_result_type()is unable to identify songs/videos and evaluates everything it doesn't recognize as an album, and since it's now an album it never gets a chance to become a song or a video further down the code.I thought about reversing that part back, but I also noticed that now

parse_search_result()is always called with some dirty value (category[:-1]) forresult_type:due to changes in here:
github.com/sigma67/ytmusicapi@ae966bb96a/ytmusicapi/mixins/search.py (L220-L225)@sigma67 commented on GitHub (May 13, 2024):
Thanks!
Sorry the code is so obscure, it's just hard to handle all the different cases. I've been trying to add more tests and make it more readable. I think I got a better grasp on some of the edge cases now, please check #583
@shibotto commented on GitHub (May 13, 2024):
I'm sorry to inform you that now English is broken as well :D
The original behavior, as I understood it, was to
[:-1].lower()the category as a first step, which works well for English (Songs -> song, Albums -> album, etc). Then if nothing matched, which in most cases meant a language different than English, try to guess from the available data. Now this doesn't happen ascategoryis never taken into account before callingparse_search_results(), and honestly I think it's a good thing as at least everything fails equally.The fundamental problem however remains, maybe the last part I added later overshadowed it a little:

get_search_result_type()is the first one to be fed, butget_item_text()feeds it the wrong data. As an example:And as a consequence the next step,
result_type = 'album'. I took just a quick look, but nowhere inside the data structure of a song element I saw something that could actually be used byparse_search_results().We have MUSIC_VIDEO_TYPE_ATV though, which as far as I can observe always identifies songs.
Oh, don't worry about the code, I once tried to do something similar for generic Youtube. After few months I trashed everything because the many edge cases and my poor skill made the thing incomprehensible. Kudos for hanging on for so many years.
@sigma67 commented on GitHub (May 15, 2024):
Thanks for your diligence.
The heuristic of using the first sub-run as an indicator is inherently broken because it's so inconsistent server-side. Depending on where a Song appears the Song indicator is sometimes there and sometimes not - it's just guesswork that's bound to change at their whim.
The problem was that that bad heuristic was actually covering up the better one that came after.
So I removed that part entirely and am only using the browseId (and MUSIC_VIDEO_TYPE_ATV) now, which seems to work pretty well. It uses the mapping in your screenshot (from the FAQ and my experience basically).
@sigma67 commented on GitHub (May 15, 2024):
Please check again if the results are good now. There might be some
browseIdedge cases I've missed.@shibotto commented on GitHub (May 16, 2024):
I tried trowing a bunch of different queries at it, observing each element returned and yep, everything matches perfectly now! If I was simply lucky enough to miss any obscure
browseIdI'll get back to you.Thank you very much! 😀