starred/ytmusicapi

Fork 0

mirror of https://github.com/sigma67/ytmusicapi.git synced 2026-04-25 07:16:00 +03:00

[GH-ISSUE #539] KeyError 'runs' on get_library_playlists() #385

New issue

Closed

opened 2026-02-27 23:00:31 +03:00 by kerem · 5 comments

kerem commented

2026-02-27 23:00:31 +03:00

Owner

Originally created by @linsomniac on GitHub (Feb 10, 2024).
Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/539

Describe the bug
I have a user over in https://github.com/linsomniac/spotify_to_ytmusic/issues/31 that is reporting the following traceback:

Traceback (most recent call last):
  File "/usr/local/bin/s2yt_copy_all_playlists", line 8, in <module>
    sys.exit(copy_all_playlists())
  File "/usr/local/lib/python3.10/site-packages/spotify2ytmusic/cli.py", line 264, in copy_all_playlists
    backend.copy_all_playlists(
  File "/usr/local/lib/python3.10/site-packages/spotify2ytmusic/backend.py", line 441, in copy_all_playlists
    dst_pl_id = get_playlist_id_by_name(yt, pl_name)
  File "/usr/local/lib/python3.10/site-packages/spotify2ytmusic/backend.py", line 163, in get_playlist_id_by_name
    for pl in yt.get_library_playlists(limit=5000):
  File "/usr/local/lib/python3.10/site-packages/ytmusicapi/mixins/library.py", line 35, in get_library_playlists
    playlists = parse_content_list(results["items"][1:], parse_playlist)
  File "/usr/local/lib/python3.10/site-packages/ytmusicapi/parsers/browsing.py", line 48, in parse_content_list
    contents.append(parse_func(result[key]))
  File "/usr/local/lib/python3.10/site-packages/ytmusicapi/parsers/browsing.py", line 126, in parse_playlist
    "title": nav(data, TITLE_TEXT),
  File "/usr/local/lib/python3.10/site-packages/ytmusicapi/navigation.py", line 103, in nav
    raise err
  File "/usr/local/lib/python3.10/site-packages/ytmusicapi/navigation.py", line 97, in nav
    root = root[k]
KeyError: 'runs'

It looks like this comes from "ytmusicapi/parsers/browsing.py" in line 126, which reads: "title": nav(data, TITLE_TEXT),, and "TITLE_TEXT" appears to be ["title", "runs", 0, "text"]. The record it is on apparently does not have a "runs" key. Perhaps that call to "nav()" should have the "none_if_absent=True" argument set?

I don't really understand the code in question so I'm reluctant to suggest a fix, especially as I don't have direct access to the data that is triggering this issue (it's reported by a user of my software, issue linked above).

To Reproduce
It seems to largely be dependent on the users ytmusic environment, as I am not able to reproduce this.

Additional context
None.

Originally created by @linsomniac on GitHub (Feb 10, 2024). Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/539 **Describe the bug** I have a user over in https://github.com/linsomniac/spotify_to_ytmusic/issues/31 that is reporting the following traceback: ``` Traceback (most recent call last): File "/usr/local/bin/s2yt_copy_all_playlists", line 8, in <module> sys.exit(copy_all_playlists()) File "/usr/local/lib/python3.10/site-packages/spotify2ytmusic/cli.py", line 264, in copy_all_playlists backend.copy_all_playlists( File "/usr/local/lib/python3.10/site-packages/spotify2ytmusic/backend.py", line 441, in copy_all_playlists dst_pl_id = get_playlist_id_by_name(yt, pl_name) File "/usr/local/lib/python3.10/site-packages/spotify2ytmusic/backend.py", line 163, in get_playlist_id_by_name for pl in yt.get_library_playlists(limit=5000): File "/usr/local/lib/python3.10/site-packages/ytmusicapi/mixins/library.py", line 35, in get_library_playlists playlists = parse_content_list(results["items"][1:], parse_playlist) File "/usr/local/lib/python3.10/site-packages/ytmusicapi/parsers/browsing.py", line 48, in parse_content_list contents.append(parse_func(result[key])) File "/usr/local/lib/python3.10/site-packages/ytmusicapi/parsers/browsing.py", line 126, in parse_playlist "title": nav(data, TITLE_TEXT), File "/usr/local/lib/python3.10/site-packages/ytmusicapi/navigation.py", line 103, in nav raise err File "/usr/local/lib/python3.10/site-packages/ytmusicapi/navigation.py", line 97, in nav root = root[k] KeyError: 'runs' ``` It looks like this comes from "ytmusicapi/parsers/browsing.py" in line 126, which reads: `"title": nav(data, TITLE_TEXT),`, and "TITLE_TEXT" appears to be `["title", "runs", 0, "text"]`. The record it is on apparently does not have a "runs" key. Perhaps that call to "nav()" should have the "none_if_absent=True" argument set? I don't really understand the code in question so I'm reluctant to suggest a fix, especially as I don't have direct access to the data that is triggering this issue (it's reported by a user of my software, issue linked above). **To Reproduce** It seems to largely be dependent on the users ytmusic environment, as I am not able to reproduce this. **Additional context** None.

kerem

2026-02-27 23:00:31 +03:00

closed this issue
added the
invalid
label

kerem commented

2026-02-27 23:00:32 +03:00

Author

Owner

@sigma67 commented on GitHub (Feb 10, 2024):

Can't fix without a reproduction. At least provide a screenshot of the library (record) in question?

@sigma67 commented on GitHub (Feb 10, 2024): Can't fix without a reproduction. At least provide a screenshot of the library (record) in question?

kerem commented

2026-02-27 23:00:32 +03:00

Author

Owner

@linsomniac commented on GitHub (Feb 10, 2024):

I've create PR #540 which detects this problem and outputs some debugging information in this situation. I also removed the "catch Exception" which seemed like it was really just meant to catch KeyError, but the revised code will detect the missing key and directly return None.

@linsomniac commented on GitHub (Feb 10, 2024): I've create PR #540 which detects this problem and outputs some debugging information in this situation. I also removed the "catch Exception" which seemed like it was really just meant to catch KeyError, but the revised code will detect the missing key and directly return None.

kerem commented

2026-02-27 23:00:32 +03:00

Author

Owner

@sigma67 commented on GitHub (Feb 13, 2024):

I fail to see how the PR addresses the issue. It would be good to know what the invalid record looks like that is causing the bug

@sigma67 commented on GitHub (Feb 13, 2024): I fail to see how the PR addresses the issue. It would be good to know what the invalid record looks like that is causing the bug

kerem commented

2026-02-27 23:00:32 +03:00

Author

Owner

@linsomniac commented on GitHub (Feb 13, 2024):

This PR addresses this issue because this issue has demonstrated a "blind spot in the code": a place where an error occurs but that there is insufficient information to diagnose. Unfortunately, not all users have the ability to hook up a debugger and get that information to us. I tried monkey-patching the nav() function in my code, but it didn't "take".

The user who reported this issue has worked around the problem by deleting a playlist they had with no songs in it, so I'm afraid we've lost the ability to reproduce this. I tried to reproduce it by creating some empty playlists based on their descriptions, but I was unable to reproduce it.

I'd recommend you consider the changes in the PR, so that future occurrences of this will provide the information that is needed for resolution or reproduction, plus the "catch Exception" way of capturing "item not in dict" has some issues (over-broad exception, try/catch performance).

@linsomniac commented on GitHub (Feb 13, 2024): This PR addresses this issue because this issue has demonstrated a "blind spot in the code": a place where an error occurs but that there is insufficient information to diagnose. Unfortunately, not all users have the ability to hook up a debugger and get that information to us. I tried monkey-patching the nav() function in my code, but it didn't "take". The user who reported this issue has worked around the problem by deleting a playlist they had with no songs in it, so I'm afraid we've lost the ability to reproduce this. I tried to reproduce it by creating some empty playlists based on their descriptions, but I was unable to reproduce it. I'd recommend you consider the changes in the PR, so that future occurrences of this will provide the information that is needed for resolution or reproduction, plus the "catch Exception" way of capturing "item not in dict" has some issues (over-broad exception, try/catch performance).

kerem commented

2026-02-27 23:00:32 +03:00

Author

Owner

@sigma67 commented on GitHub (Feb 13, 2024):

Your argument has merit, I had a look

@sigma67 commented on GitHub (Feb 13, 2024): Your argument has merit, I had a look