[GH-ISSUE #173] get_album() results in KeyError: 'frameworkUpdates' #134

Closed
opened 2026-02-27 22:08:13 +03:00 by kerem · 20 comments
Owner

Originally created by @jake-g on GitHub (Mar 11, 2021).
Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/173

Have never had issues before (aside from my auth key going expired) until recently. Most of the other api calls work fine such as : search() get_liked_songs() ect, so i assume my auth key is still valid. I only see this issue with get_album().

To be sure my problem is repeatable, i was able to replicate in. a fresh python 3.9 venv with the following

$ python3 -m venv ./test
$ source test/bin/activate
(test) $ pip install ytmusicapi --upgrade
(test) $ python

...then in the python console

(note i tried other browseId values for get_album() like get_album("MPREb_4pL8gzRtw1p") from test.py

Python 3.9.2 (default, Feb 24 2021, 13:26:09)
[Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from ytmusicapi import YTMusic
>>> yt = YTMusic('headers_auth.json')
>>> yt.get_album('MPREb_EW11k5ujKg4')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/site-packages/ytmusicapi/mixins/browsing.py", line 433, in get_album
    data = nav(response, FRAMEWORK_MUTATIONS)
  File "/usr/local/lib/python3.9/site-packages/ytmusicapi/parsers/utils.py", line 210, in nav
    raise err
  File "/usr/local/lib/python3.9/site-packages/ytmusicapi/parsers/utils.py", line 204, in nav
    root = root[k]
KeyError: 'frameworkUpdates'
>>>

any ideas? I saw some closed issues with similar errors, but i think this issue recently popped up, my code worked fine about a month ago

Originally created by @jake-g on GitHub (Mar 11, 2021). Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/173 Have never had issues before (aside from my auth key going expired) until recently. Most of the other api calls work fine such as : `search()` `get_liked_songs()` ect, so i assume my auth key is still valid. I only see this issue with `get_album()`. To be sure my problem is repeatable, i was able to replicate in. a fresh python 3.9 venv with the following ``` $ python3 -m venv ./test $ source test/bin/activate (test) $ pip install ytmusicapi --upgrade (test) $ python ``` ...then in the python console (note i tried other `browseId` values for `get_album()` like `get_album("MPREb_4pL8gzRtw1p")` from `test.py` ``` Python 3.9.2 (default, Feb 24 2021, 13:26:09) [Clang 12.0.0 (clang-1200.0.32.29)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from ytmusicapi import YTMusic >>> yt = YTMusic('headers_auth.json') >>> yt.get_album('MPREb_EW11k5ujKg4') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/lib/python3.9/site-packages/ytmusicapi/mixins/browsing.py", line 433, in get_album data = nav(response, FRAMEWORK_MUTATIONS) File "/usr/local/lib/python3.9/site-packages/ytmusicapi/parsers/utils.py", line 210, in nav raise err File "/usr/local/lib/python3.9/site-packages/ytmusicapi/parsers/utils.py", line 204, in nav root = root[k] KeyError: 'frameworkUpdates' >>> ``` any ideas? I saw some closed issues with similar errors, but i think this issue recently popped up, my code worked fine about a month ago
kerem 2026-02-27 22:08:13 +03:00
  • closed this issue
  • added the
    yt-update
    label
Author
Owner

@sigma67 commented on GitHub (Mar 11, 2021):

It still works fine for me. Are you perhaps part of some beta program? Odd that only this endpoint should stop working for you. Do you also get this error when you are not using a headers file?

<!-- gh-comment-id:796649347 --> @sigma67 commented on GitHub (Mar 11, 2021): It still works fine for me. Are you perhaps part of some beta program? Odd that only this endpoint should stop working for you. Do you also get this error when you are not using a headers file?
Author
Owner

@jake-g commented on GitHub (Mar 12, 2021):

huh, strange works fine if it initialize without referencing my header, i.e yt = YTMusic(). I just tried to make a fresh headers_auth.json by pasting what is described in the Manual file creation
File
then getting a Cookie string from my browser

<!-- gh-comment-id:797266088 --> @jake-g commented on GitHub (Mar 12, 2021): huh, strange works fine if it initialize without referencing my header, i.e `yt = YTMusic()`. I just tried to make a fresh `headers_auth.json` by pasting what is described in the [Manual file creation File](https://ytmusicapi.readthedocs.io/en/latest/setup.html) then getting a Cookie string from my browser
Author
Owner

@jake-g commented on GitHub (Mar 13, 2021):

Ahh fixed it, I had wrongfully assumed X-Goog-Visitor-Id stayed the same and the Cookie was the only field in headers_auth.json that might change over time.

I used the method of pasting the raw text from the cookie into the following:
YTMusic.setup(filepath="headers_auth.json", headers_raw=cookie)

(note in the docs there is a slight typo, there should be quotes around the filepath string arg as i show above)

Which saves a header_auth.json.

When i compared this too the header file I created manually i noticed they were identical except X-Goog-Visitor-Id. My id must have changed for some reason and that is what caused my issues.

<!-- gh-comment-id:797949496 --> @jake-g commented on GitHub (Mar 13, 2021): Ahh fixed it, I had wrongfully assumed `X-Goog-Visitor-Id` stayed the same and the `Cookie` was the only field in `headers_auth.json` that might change over time. I used the method of pasting the raw text from the cookie into the following: `YTMusic.setup(filepath="headers_auth.json", headers_raw=cookie)` (note in the docs there is a slight typo, there should be quotes around the filepath string arg as i show above) Which saves a `header_auth.json`. When i compared this too the header file I created manually i noticed they were identical except `X-Goog-Visitor-Id`. My id must have changed for some reason and that is what caused my issues.
Author
Owner

@sigma67 commented on GitHub (Mar 13, 2021):

In that case we should probably add X-Goog-Visitor-Id to required cookies and fix that doc typo. Thanks for the taking the time to figure this out.

<!-- gh-comment-id:798017728 --> @sigma67 commented on GitHub (Mar 13, 2021): In that case we should probably add `X-Goog-Visitor-Id` to required cookies and fix that doc typo. Thanks for the taking the time to figure this out.
Author
Owner

@jake-g commented on GitHub (Mar 13, 2021):

i may have jumped the gun with my above resolution. with my current header_auth.json saved as described above, I can make most authenticated requests, but i once again have the same error when using get_album() (i didnt realize this until later).

It seems get_album() is fine when i am not authenticated, but as soon as i authenticate, it gives me a framework error

continuing to experiment around

<!-- gh-comment-id:798025431 --> @jake-g commented on GitHub (Mar 13, 2021): i may have jumped the gun with my above resolution. with my current `header_auth.json` saved as described above, I can make most authenticated requests, but i once again have the same error when using `get_album()` (i didnt realize this until later). It seems `get_album()` is fine when i am not authenticated, but as soon as i authenticate, it gives me a framework error continuing to experiment around
Author
Owner

@sigma67 commented on GitHub (Mar 13, 2021):

That error indicates that data is missing from the response. Perhaps you can post your full response here? Then we can figure out if it's in a different format (beta user) or just missing altogether (auth issue, probably what's happening). That would involve setting a breakpoint at l.433 in mixins/browsing.py and dumping the data of the response variable.

<!-- gh-comment-id:798038852 --> @sigma67 commented on GitHub (Mar 13, 2021): That error indicates that data is missing from the response. Perhaps you can post your full response here? Then we can figure out if it's in a different format (beta user) or just missing altogether (auth issue, probably what's happening). That would involve setting a breakpoint at l.433 in mixins/browsing.py and dumping the data of the response variable.
Author
Owner

@jake-g commented on GitHub (Mar 13, 2021):

>>> yt = YTMusic('headers_auth.json')
>>> yt
<ytmusicapi.ytmusic.YTMusic object at 0x108c0a6d0>              
>>> yt.get_album('MPREb_THra6CyCfb4')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/site-packages/ytmusicapi/mixins/browsing.py", line 433, in get_album
    data = nav(response, FRAMEWORK_MUTATIONS)
  File "/usr/local/lib/python3.9/site-packages/ytmusicapi/parsers/utils.py", line 210, in nav
    raise err
  File "/usr/local/lib/python3.9/site-packages/ytmusicapi/parsers/utils.py", line 204, in nav
    root = root[k]
KeyError: 'frameworkUpdates'
>>> 

Here is the full error. It seems to point to the same part of browsing.py that your reference

<!-- gh-comment-id:798667015 --> @jake-g commented on GitHub (Mar 13, 2021): ``` >>> yt = YTMusic('headers_auth.json') >>> yt <ytmusicapi.ytmusic.YTMusic object at 0x108c0a6d0> >>> yt.get_album('MPREb_THra6CyCfb4') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/lib/python3.9/site-packages/ytmusicapi/mixins/browsing.py", line 433, in get_album data = nav(response, FRAMEWORK_MUTATIONS) File "/usr/local/lib/python3.9/site-packages/ytmusicapi/parsers/utils.py", line 210, in nav raise err File "/usr/local/lib/python3.9/site-packages/ytmusicapi/parsers/utils.py", line 204, in nav root = root[k] KeyError: 'frameworkUpdates' >>> ``` Here is the full error. It seems to point to the same part of `browsing.py` that your reference
Author
Owner

@sigma67 commented on GitHub (Mar 15, 2021):

Yes, that's the same error message you posted above. That doesn't provide much information except that part of the response is missing that is usually there.

I was referring to the full response, i.e. if there is something new in the response that we aren't seeing on regular accounts ( if you are a beta user ). You can dump the response by debugging locally.

Alternatively, if you want me to debug this for you you can also send the headers_auth.json to ytmusicapi@gmail.com and I'll have a look. You can invalidate those credentials later by logging out in the browser that you captured them from.

Something else you can try is using a different brand account to see if the error persists (i.e. change the user parameter of YTMusic()).

<!-- gh-comment-id:799363305 --> @sigma67 commented on GitHub (Mar 15, 2021): Yes, that's the same error message you posted above. That doesn't provide much information except that part of the response is missing that is usually there. I was referring to the full response, i.e. if there is something new in the response that we aren't seeing on regular accounts ( if you are a beta user ). You can dump the response by debugging locally. Alternatively, if you want me to debug this for you you can also send the headers_auth.json to ytmusicapi@gmail.com and I'll have a look. You can invalidate those credentials later by logging out in the browser that you captured them from. Something else you can try is using a different brand account to see if the error persists (i.e. change the [user parameter of YTMusic()](https://ytmusicapi.readthedocs.io/en/latest/reference.html)).
Author
Owner

@jake-g commented on GitHub (Mar 16, 2021):

ok, i see, thanks. I don't think the 'brand account' applies to me, perhaps some sort of beta (I've had a monthly script which has worked fine for 6+ mo until recently).
I tried starting from scratch again logging in from an incognito browser and still no luck. Ill send you an email as im not totally sure what i should be looking for in the full response.

<!-- gh-comment-id:800009970 --> @jake-g commented on GitHub (Mar 16, 2021): ok, i see, thanks. I don't think the 'brand account' applies to me, perhaps some sort of beta (I've had a monthly script which has worked fine for 6+ mo until recently). I tried starting from scratch again logging in from an incognito browser and still no luck. Ill send you an email as im not totally sure what i should be looking for in the full response.
Author
Owner

@sigma67 commented on GitHub (Mar 16, 2021):

Thanks for providing the cookie! You are indeed part of a beta program or early rollout. Seems they are finally adjusting the album endpoint to match all the other endpoints with lists of songs.

On the upside, this will probably simplify the code of ytmusicapi quite a bit. However, we will no longer have access to durationMs and lengthMs, only the formatted durations we have with playlists now.

Not sure if we should implement this now or wait until it's generally available. Testing will certainly be difficult if it these responses are only available to some users.

<!-- gh-comment-id:800336204 --> @sigma67 commented on GitHub (Mar 16, 2021): Thanks for providing the cookie! You are indeed part of a beta program or early rollout. Seems they are finally adjusting the album endpoint to match all the other endpoints with lists of songs. On the upside, this will probably simplify the code of ytmusicapi quite a bit. However, we will no longer have access to durationMs and lengthMs, only the formatted durations we have with playlists now. Not sure if we should implement this now or wait until it's generally available. Testing will certainly be difficult if it these responses are only available to some users.
Author
Owner

@jake-g commented on GitHub (Mar 18, 2021):

thanks for the support! Im thinking i may be the only one with this issue right now so maybe an official implementation isnt necessary...but i would be happy to help figure out (and benefit from) a fix, maybe just locally or in a 'future' branch.

<!-- gh-comment-id:801667225 --> @jake-g commented on GitHub (Mar 18, 2021): thanks for the support! Im thinking i may be the only one with this issue right now so maybe an official implementation isnt necessary...but i would be happy to help figure out (and benefit from) a fix, maybe just locally or in a 'future' branch.
Author
Owner

@sigma67 commented on GitHub (Mar 18, 2021):

Sure! I'll have a go when I have some free time.

<!-- gh-comment-id:801838819 --> @sigma67 commented on GitHub (Mar 18, 2021): Sure! I'll have a go when I have some free time.
Author
Owner

@rowannicholls commented on GitHub (Mar 30, 2021):

Hi, I'm experiencing the exact same issue as described above; .get_album() stopped working after upgrading to v0.15.0. My error message looks the same and other methods like .get_library_songs() still work so I doubt it's an issue with the authentication.

<!-- gh-comment-id:810349397 --> @rowannicholls commented on GitHub (Mar 30, 2021): Hi, I'm experiencing the exact same issue as described above; `.get_album()` stopped working after upgrading to v0.15.0. My error message looks the same and other methods like `.get_library_songs()` still work so I doubt it's an issue with the authentication.
Author
Owner

@rowannicholls commented on GitHub (Mar 30, 2021):

Actually, the problem persists after downgrading to previous versions, so it doesn't look something introduced in 0.15.0

<!-- gh-comment-id:810352445 --> @rowannicholls commented on GitHub (Mar 30, 2021): Actually, the problem persists after downgrading to previous versions, so it doesn't look something introduced in 0.15.0
Author
Owner

@sigma67 commented on GitHub (Mar 30, 2021):

Yes, nothing changed in that version. I presume more and more users are getting moved to the build OP was on, so should probably start work on the change soon.

<!-- gh-comment-id:810404566 --> @sigma67 commented on GitHub (Mar 30, 2021): Yes, nothing changed in that version. I presume more and more users are getting moved to the build OP was on, so should probably start work on the change soon.
Author
Owner

@sigma67 commented on GitHub (Apr 1, 2021):

Hi guys, I'd appreciate if you could test with latest master and param beta=True.

<!-- gh-comment-id:811934649 --> @sigma67 commented on GitHub (Apr 1, 2021): Hi guys, I'd appreciate if you could test with latest master and param `beta=True`.
Author
Owner

@matclab commented on GitHub (Apr 1, 2021):

Nice job !
It seems to work well here (at least no more frameworkUpdates exception and a sensible json response… As it is my first try to use ytmusicapi, I can not say if it works as intended… I have to use it a bit more).
Thank you.

<!-- gh-comment-id:811946407 --> @matclab commented on GitHub (Apr 1, 2021): Nice job ! It seems to work well here (at least no more `frameworkUpdates` exception and a sensible json response… As it is my first try to use ytmusicapi, I can not say if it works as intended… I have to use it a bit more). Thank you.
Author
Owner

@rowannicholls commented on GitHub (Apr 1, 2021):

Yip, looking good for me

<!-- gh-comment-id:812020499 --> @rowannicholls commented on GitHub (Apr 1, 2021): Yip, looking good for me
Author
Owner

@jake-g commented on GitHub (Apr 6, 2021):

yeess! working for me

<!-- gh-comment-id:813864015 --> @jake-g commented on GitHub (Apr 6, 2021): yeess! working for me
Author
Owner

@sigma67 commented on GitHub (Oct 28, 2021):

Old code has now been removed in 7a49cd7 as it seems it's no longer being used. Please report back if the new code isn't working for someone.

<!-- gh-comment-id:954179694 --> @sigma67 commented on GitHub (Oct 28, 2021): Old code has now been removed in 7a49cd7 as it seems it's no longer being used. Please report back if the new code isn't working for someone.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/ytmusicapi#134
No description provided.