[GH-ISSUE #296] get_watch_playlist() fails with 404: Requested entity not found #230

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

Originally created by @toasterofbread on GitHub (Sep 19, 2022).
Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/296

A project I'm working on involving ytmusicapi suddenly stopped working today. Whenever get_watch_playlist is called it fails with the following error regardless of whether the client is authenticated:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "~/.local/lib/python3.10/site-packages/ytmusicapi/mixins/watch.py", line 120, in get_watch_playlist
    response = self._send_request(endpoint, body)
  File "~/.local/lib/python3.10/site-packages/ytmusicapi/ytmusic.py", line 144, in _send_request
    raise Exception(message + error)
Exception: Server returned HTTP 404: Not Found.
Requested entity was not found.

I've tried multiple valid ids, invalid ids, and using a VPN, none of which seem to make a difference. Other functions like search seem to work fine, and YouTube Music works as usual in a browser.

Originally created by @toasterofbread on GitHub (Sep 19, 2022). Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/296 A project I'm working on involving ytmusicapi suddenly stopped working today. Whenever get_watch_playlist is called it fails with the following error regardless of whether the client is authenticated: ``` Traceback (most recent call last): File "<stdin>", line 1, in <module> File "~/.local/lib/python3.10/site-packages/ytmusicapi/mixins/watch.py", line 120, in get_watch_playlist response = self._send_request(endpoint, body) File "~/.local/lib/python3.10/site-packages/ytmusicapi/ytmusic.py", line 144, in _send_request raise Exception(message + error) Exception: Server returned HTTP 404: Not Found. Requested entity was not found. ``` I've tried multiple valid ids, invalid ids, and using a VPN, none of which seem to make a difference. Other functions like search seem to work fine, and YouTube Music works as usual in a browser.
kerem 2026-02-27 22:08:43 +03:00
  • closed this issue
  • added the
    yt-update
    label
Author
Owner

@simu commented on GitHub (Sep 19, 2022):

From what I've found the error can be avoided by changing github.com/sigma67/ytmusicapi@20b4631c31/ytmusicapi/helpers.py (L26) to 1.20220912.01.00 (as found when inspecting traffic generated by the web app).

Since there's a date in the new version string, I wonder whether this may need to be dynamically updated when new versions of the web app are released.

<!-- gh-comment-id:1251218466 --> @simu commented on GitHub (Sep 19, 2022): From what I've found the error can be avoided by changing https://github.com/sigma67/ytmusicapi/blob/20b4631c31b65d5d40caf89b5db5fd661e82a979/ytmusicapi/helpers.py#L26 to `1.20220912.01.00` (as found when inspecting traffic generated by the web app). Since there's a date in the new version string, I wonder whether this may need to be dynamically updated when new versions of the web app are released.
Author
Owner

@MarvinSchenkel commented on GitHub (Sep 19, 2022):

From what I've found the error can be avoided by changing

github.com/sigma67/ytmusicapi@20b4631c31/ytmusicapi/helpers.py (L26)

to 1.20220912.01.00 (as found when inspecting traffic generated by the web app).
Since there's a date in the new version string, I wonder whether this may need to be dynamically updated when new versions of the web app are released.

Does this actually work for you? I tried the suggested change, but I still get the same 404 error.

{
   "context": {
      "client": {"clientName": "WEB_REMIX", "clientVersion": "1.20220912.01.00"},
      "user": {},
   }
}
<!-- gh-comment-id:1251395271 --> @MarvinSchenkel commented on GitHub (Sep 19, 2022): > From what I've found the error can be avoided by changing > > https://github.com/sigma67/ytmusicapi/blob/20b4631c31b65d5d40caf89b5db5fd661e82a979/ytmusicapi/helpers.py#L26 > > to `1.20220912.01.00` (as found when inspecting traffic generated by the web app). > Since there's a date in the new version string, I wonder whether this may need to be dynamically updated when new versions of the web app are released. Does this actually work for you? I tried the suggested change, but I still get the same 404 error. ```json { "context": { "client": {"clientName": "WEB_REMIX", "clientVersion": "1.20220912.01.00"}, "user": {}, } } ```
Author
Owner

@simu commented on GitHub (Sep 19, 2022):

Does this actually work for you? I tried the suggested change, but I still get the same 404 error.

Yes, it worked for me (approximately 10 hours ago), however I'm not 100% if that ended up being the only change that I had to make (I'll have to check that tomorrow). Additionally, I also used a fresh cookie copied from the web app today.

<!-- gh-comment-id:1251403675 --> @simu commented on GitHub (Sep 19, 2022): > Does this actually work for you? I tried the suggested change, but I still get the same 404 error. Yes, it worked for me (approximately 10 hours ago), however I'm not 100% if that ended up being the only change that I had to make (I'll have to check that tomorrow). Additionally, I also used a fresh cookie copied from the web app today.
Author
Owner

@MarvinSchenkel commented on GitHub (Sep 20, 2022):

Guess what, this morning my get_watch_playlist started working again, even without the change of clientVersion. Did YT Music revert some changes on their side?

<!-- gh-comment-id:1251916312 --> @MarvinSchenkel commented on GitHub (Sep 20, 2022): Guess what, this morning my `get_watch_playlist` started working again, even without the change of `clientVersion`. Did YT Music revert some changes on their side?
Author
Owner

@sigma67 commented on GitHub (Sep 20, 2022):

Might have been some sort of A/B testing? I cannot reproduce the error currently.

We may need to find a way to dynamically get a viable clientVersion if this turns out to be the cause. My current version on the web interface is 1.20220914.01.00.

<!-- gh-comment-id:1251951369 --> @sigma67 commented on GitHub (Sep 20, 2022): Might have been some sort of A/B testing? I cannot reproduce the error currently. We may need to find a way to dynamically get a viable `clientVersion` if this turns out to be the cause. My current version on the web interface is `1.20220914.01.00`.
Author
Owner

@simu commented on GitHub (Sep 20, 2022):

Might have been some sort of A/B testing? I cannot reproduce the error currently.

Looks like it, I can't reproduce it anymore either (side-note: the web app has version 1.20220914.01.00 for me today as well).

Does this actually work for you? I tried the suggested change, but I still get the same 404 error.

Yes, it worked for me (approximately 10 hours ago), however I'm not 100% if that ended up being the only change that I had to make (I'll have to check that tomorrow).

I checked again, the only change I made yesterday (after some trial and error) was setting the clientVersion to the value if found in the web app.

<!-- gh-comment-id:1252196083 --> @simu commented on GitHub (Sep 20, 2022): > Might have been some sort of A/B testing? I cannot reproduce the error currently. Looks like it, I can't reproduce it anymore either (side-note: the web app has version `1.20220914.01.00` for me today as well). > > Does this actually work for you? I tried the suggested change, but I still get the same 404 error. > > Yes, it worked for me (approximately 10 hours ago), however I'm not 100% if that ended up being the only change that I had to make (I'll have to check that tomorrow). I checked again, the only change I made yesterday (after some trial and error) was setting the `clientVersion` to the value if found in the web app.
Author
Owner

@sigma67 commented on GitHub (Sep 20, 2022):

I preemptively changed the version string to the current date, which seems to be working for now. I'd like to avoid having to retrieve or set the version on init, and a fake version seems to work right now.

<!-- gh-comment-id:1252551523 --> @sigma67 commented on GitHub (Sep 20, 2022): I preemptively changed the version string to the current date, which seems to be working for now. I'd like to avoid having to retrieve or set the version on init, and a fake version seems to work right now.
Author
Owner

@sigma67 commented on GitHub (Oct 1, 2022):

Seems to be resolved for now, can reopen if needed in the future.

<!-- gh-comment-id:1264369302 --> @sigma67 commented on GitHub (Oct 1, 2022): Seems to be resolved for now, can reopen if needed in the future.
Author
Owner

@MarvinSchenkel commented on GitHub (Oct 1, 2022):

Amazing! Will wait for the next release to include it in my product!

Op za 1 okt. 2022 om 15:42 schreef sigma67 @.***>

Closed #296 https://github.com/sigma67/ytmusicapi/issues/296 as
completed.


Reply to this email directly, view it on GitHub
https://github.com/sigma67/ytmusicapi/issues/296#event-7500446583, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AEG2MJYTMWCTRJZ2GHXUMODWBA5VTANCNFSM6AAAAAAQQGPLPI
.
You are receiving this because you commented.Message ID:
@.***>

<!-- gh-comment-id:1264375065 --> @MarvinSchenkel commented on GitHub (Oct 1, 2022): Amazing! Will wait for the next release to include it in my product! Op za 1 okt. 2022 om 15:42 schreef sigma67 ***@***.***> > Closed #296 <https://github.com/sigma67/ytmusicapi/issues/296> as > completed. > > — > Reply to this email directly, view it on GitHub > <https://github.com/sigma67/ytmusicapi/issues/296#event-7500446583>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AEG2MJYTMWCTRJZ2GHXUMODWBA5VTANCNFSM6AAAAAAQQGPLPI> > . > You are receiving this because you commented.Message ID: > ***@***.***> >
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#230
No description provided.