[GH-ISSUE #325] [Request] An async version of the client that uses aiohttp instead of requests #251

New issue

Closed

opened 2026-02-27 22:08:49 +03:00 by kerem · 3 comments

kerem commented

2026-02-27 22:08:49 +03:00

Owner

Originally created by @OmLanke on GitHub (Dec 10, 2022).
Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/325

It will be great to have an async version of this library that can be used in asynchronous projects. I needed one for a discord bot and couldn't use the blocking version.

I did manage to make a fork and get it working but it becomes out of date with the main library pretty quickly (shoutout to the devs who are very active). Don't judge my code. It was a edit I did to have it working

Originally created by @OmLanke on GitHub (Dec 10, 2022). Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/325 It will be great to have an async version of this library that can be used in asynchronous projects. I needed one for a discord bot and couldn't use the blocking version. I did manage to make a [fork](https://github.com/Om1609/async-ytmusicapi) and get it working but it becomes out of date with the main library pretty quickly (shoutout to the devs who are very active). Don't judge my code. It was a edit I did to have it working

kerem

2026-02-27 22:08:49 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 22:08:50 +03:00

Author

Owner

@sigma67 commented on GitHub (Dec 12, 2022):

It's nice that you got this working, but I don't see a way to integrate this into the main project right now. Perhaps it's possible to wrap library functionality in async threads to avoid having to maintain a separate version of the library.

@sigma67 commented on GitHub (Dec 12, 2022): It's nice that you got this working, but I don't see a way to integrate this into the main project right now. Perhaps it's possible to wrap library functionality in async threads to avoid having to maintain a separate version of the library.

kerem commented

2026-02-27 22:08:50 +03:00

Author

Owner

@OmLanke commented on GitHub (Dec 22, 2022):

One way would be having the main working in an async version of the client, and the sync client just called methods on the async client using asyncio.create_task, but this doesn't make any sense even to me.

As you said, async threads would be the best option (using asyncio.to_thread)

@OmLanke commented on GitHub (Dec 22, 2022): One way would be having the main working in an async version of the client, and the sync client just called methods on the async client using `asyncio.create_task`, but this doesn't make any sense even to me. As you said, async threads would be the best option (using `asyncio.to_thread`)

kerem commented

2026-02-27 22:08:50 +03:00

Author

Owner

@sigma67 commented on GitHub (Aug 20, 2023):

Sorry, I'm going to go ahead and close this as Not Planned. None of the other Python music streaming service clients support async (i.e. spotipy, gmusicapi, python-tidal, etc.), and I don't think it's worth the effort to support.

Another consideration is also the likelihood to run into more issues with rate limits, as parallel requests are even more suspicious than sequential ones.

@sigma67 commented on GitHub (Aug 20, 2023): Sorry, I'm going to go ahead and close this as Not Planned. None of the other Python music streaming service clients support async (i.e. spotipy, gmusicapi, python-tidal, etc.), and I don't think it's worth the effort to support. Another consideration is also the likelihood to run into more issues with rate limits, as parallel requests are even more suspicious than sequential ones.