Solved! -- I debugged a bit further and get to the root of the problem.
Unitymedia BW (a local internet provider here in Germany) drops idle sockets rather aggressively: any socket open for more than 2 min without any activity, will be dropped. Qobuz plug-in (upmpdcli) uses Python "requests" library, which should handle keep alive automatically (e.g. reopen closed connection etc). However, it seems that the library fails to detect the socket has been closed by internet provider side. Thus when it tries to use this "seemingly open" socket after some idle time, the action always fails.
So basically, this is a (hidden) bug of Python requests library. (Or maybe rather the local internet provider cuts idle sockets in a non-standard way.) On my Moode audio instance, I changed the source code to not to reuse sockets (by explicitly sending Connection: close on request header to Qobuz server), so this problem no longer happenes. I guess this is rather rare combination, and probably not worth a patch. So I am closing my case here. Well, it works nicely, and while doing so, I found out how to config Qobuz plug-in to support 192khz streaming ... so, I am happy.
Having the source code available is so... nice. If something broken, I can fix it. I couldn't do this with my closed-source streamer devices.
Unitymedia BW (a local internet provider here in Germany) drops idle sockets rather aggressively: any socket open for more than 2 min without any activity, will be dropped. Qobuz plug-in (upmpdcli) uses Python "requests" library, which should handle keep alive automatically (e.g. reopen closed connection etc). However, it seems that the library fails to detect the socket has been closed by internet provider side. Thus when it tries to use this "seemingly open" socket after some idle time, the action always fails.
So basically, this is a (hidden) bug of Python requests library. (Or maybe rather the local internet provider cuts idle sockets in a non-standard way.) On my Moode audio instance, I changed the source code to not to reuse sockets (by explicitly sending Connection: close on request header to Qobuz server), so this problem no longer happenes. I guess this is rather rare combination, and probably not worth a patch. So I am closing my case here. Well, it works nicely, and while doing so, I found out how to config Qobuz plug-in to support 192khz streaming ... so, I am happy.
Having the source code available is so... nice. If something broken, I can fix it. I couldn't do this with my closed-source streamer devices.
