Session hangs indefinitely #221
Comments
|
Good point, I didn't have this issue yet so I never noticed. The primary concern that could be affected negatively by a timeout would be Since the primary concern is to avoid rare indefinite hangups, we could set a conservative value. Do you think 30 seconds is appropriate? I don't think we need to make it a parameter if it only happens rarely. Besides, it is already possible to pass a requests Session object as the Additionally, requests doesn't really support timeouts on a session level, you need to modify the session object like this: psf/requests#2011 (comment) s = requests.Session()
s.request = functools.partial(s.request, timeout=3)
# this should now timeout
s.get('https://httpbin.org/delay/6') |
|
I agree! A conservative value makes sense to avoid the hangups, and since it is only to keep a program moving in rare cases, a long timeout seems reasonable as a default value. However, I think it would be very useful to have a timeout argument in the ytmusic constructor. If it happens that I have a bad internet connection and I get timeouts frequently, it could be very useful to pass a parameter from my user code so I can set the timeout as short as possible without interfering with normal request operations. That way, my program wouldn't have to wait a full 30s before raising exception for me to try again. Having any timeout, even hard-coded, would fix the issue I'm observing. Having a variable timeout would just be "nice to have" |
|
Setting a timeout is possible right now, it's a two-liner (which is what I was trying to say above). Here's an example for a 3 second timeout, feel free to try it out: s = requests.Session()
s.request = functools.partial(s.request, timeout=3)
ytm = YTMusic(session=s)I think that should cover the variable timeout part. |
|
Thanks for the suggestion, sigma! I have tried the above recommendation (with a change to the YTMusic argument to avoid a kwarg typo): s = requests.Session()
s.request = partial(s.request, timeout=10)
ytmusic = YTMusic(auth="youtube_auth_1.json", requests_session=s)It took me a while to get back to you because I wanted to try your solution pretty thoroughly. I was able to capture the following exception and traceback when the session inevitably timed out: I am able to successfully handle this exception: for item in my_list:
item_complete = False
while not item_complete:
try:
function_that_uses_ytm()
item_complete = True
except requests.exceptions.ReadTimeout as e:
# log the timeout occurrences so I can see how often they happen
with open("timeout_log.txt", 'a') as fout:
fout.write(str(datetime.now())) |
|
That's great, thanks for the detailed feedback. Will add some documentation and the default timeout. |
I have found that while using this API in programs that run for a long time, the program will sometimes hang up indefinitely (for several days at least).
When the program hangs up, sending a ctrl+c sigkill results in a traceback showing that the program was in the middle of a session request, specifically in the
get_playlists()method. (Unfortunately I lost the traceback and cannot copy it here).The requests documentation page recommends passing a timeout parameter to all session instances to avoid such an indefinite hangup: https://docs.python-requests.org/en/master/user/quickstart/#timeouts
Such a parameter is not passed when the
requests.Session()is initialized here: https://github.com/sigma67/ytmusicapi/blob/master/ytmusicapi/ytmusic.py#L62I think that adding a timeout of a few seconds should allow the program to timeout when appropriate and avoid hangups. Perhaps the timeout can be a parameter passed when instantiating ytmusic if adjustability is desired.
The text was updated successfully, but these errors were encountered: