Stream URL getting "Connection Reset by Peer"

[abettadapur]

Hey. I am using VLC to play URLs returned from getStreamUrl(). I only get the URL when I am about to play it, so as to avoid the URL expiring. However, periodically, VLC will skip the track and complain that the "Connection was Reset by Peer." Do you have any insight on this issue? Is Google closing the connection?

[simon-weber]

Hm, url expiry would have been my guess (hough I think you actually get a descriptive error in that case).

Can you try adding retry logic? I realize it might be a pain if you're using vlc to consume the streams =/

[abettadapur]

Ok I'll try that. Do you know how Google expires the URLs? It seems like if you play it within a minute, it generally plays the entire song

[simon-weber]

I don't remember off the top of my head, but I don't think it's much longer than a minute.

[thebigmunch]

FYI, the expiry time seems to be 90 seconds from my quick testing. And you get a 403 Forbidden error with a message saying "Your client does not have permission to get URL..." on URL expiry.

@abettadapur: As long as you've already started playing it, the expiry of the URL won't cut you off, and you can access it any number of times until the URL expires. But, if you hit back in your browser or switch to another file in your media player, you'd have to get a new URL if it's past the expiry time. The expiry time is in the URL in Unix epoch format (http://www.epochconverter.com/), if that ends up being useful to you.

[abettadapur]

Thanks for the information. I'll keep trying to pin down the error and report back if I find anything

[simon-weber]

This issue hasn't been updated in a while, so I'm closing it. Feel free to reopen if you're still having trouble.

[simon-weber]

@vmurillo seems to be able to recreate this (copied from #362):

Whenever I trye to play a podcast, after a small period of time I got this console error: [00007f3940c09938] core access error: read error: Connection reset by peer I am using VLC 2.2.1buildd@lgw01-37.buildd Jul 20 2015 23:42:41 under Ubuntu 14.04

I wonder if it's something specific to how vlc reads the stream? If it's doing something like requesting it multiple times and using range headers, it might be running into what @thebigmunch described earlier.

[kettenbach-it]

Hi,

I think this problem with Logitech Squeezeboxserver comes from the TCP-RST as well: https://github.com/Logitech/slimserver/issues/130#issuecomment-279213259

For the Squeezeboxserver this is really a problem: the Google Music Plugin is almost useless now

[simon-weber]

Interesting. Unfortunately, I don't have a good way of getting that to the Music team aside from lots of people independently reporting it.

[kettenbach-it]

I don't think it would make sense to report it to google, since this is not an official API.

How about that: the URL that Google returns on playing music contains the expiry date of the URL. Wouldn't it make sense to call that URL shortly before it's expiry to refresh it?

(I don't know anything about the way this API works, so please excuse any stupid ideas).

I tried gmusicproxy: with gmusicproxy I don't have problems and there are no RST-packages. Maybe we have to check how gmusicproxy handles this.

[thebigmunch]

Your solution would be something that happens outside of gmusicapi. As far as gmusicapi's involvement, it makes the call to get the URL and gives it to the caller. It's up to the caller to do whatever it wants with it. So, you'd have to propose something like that to the application.

That being said, it also probably wouldn't solve anything, as the issue described here is that the connection is getting reset after streaming has already begun. This could still happen before the streaming ends even if the application gives itself the ~90 second buffer of reloading right before the expiry. And if you're talking about getting a new URL entirely (the only way to get a later expiry is to get a new URL), then the application would have to handle that.

There's nothing to be done about this in gmusicapi itself. And, as Simon said, there's little recourse in getting the Google Music team's input on it. But things have been done when many independent reports have been sent to the Google Music team in the past.

[kettenbach-it]

Your right. I digged in to gmusicproxy as a reference. And I see, that this problem has to be handled by https://github.com/squeezebox-googlemusic/squeezebox-googlemusic

[MichaelCDormann]

Has anyone figured out a fix for this? Just found this Python module last night and was very excited about it. Sucks that when I had some stuff working I ran into this same issue.

[kettenbach-it]

I switched to Spotify

[simon-weber]

Maybe Google expects clients to buffer the stream locally for playback? That'd make if they're looking to minimize their number of open connections and should be easy enough to try out. I think their clients do this (I haven't confirmed it, but I know the web client will continue playing even if you lose connection in the middle of a song).

[thebigmunch]

The mobile client has an option to cache while streaming.

[MichaelCDormann]

Yea, I was thinking about possibly buffering the stream. That's probably what I'll have to do.

[MichaelCDormann]

So I used urllib to open the stream url and write it to a local mp3 file. After that it's simple enough to play the mp3 file, and you don't have to worry about the stream url expiring. Kind of an ugly way of "buffering" and I might look into doing it another way, but it works.

Example (segments from my working code):

import urllib.request

stream_url = api.get_stream_url(song_id=self.song_id, quality=u'hi')

mp3file = urllib.request.urlopen(stream_url)
with open('./test.mp3', 'wb') as output:
    output.write(mp3file.read())

vlc.MediaPlayer('./test.mp3')

[sundown94]

Hi Everyone! I think I got this working. My configuration (after lots of trial and error) is Raspian Jessie, LMS 7.9.1 (logitechmediaserver_7.9.1~1489384180_arm.deb), gmusicapi v10.1.1, and the latest Google Music plugin (along with the HTTPS change to line 5 in it's protocolhandler.pm file).

Sorry if this is already old news, but I couldn't find this resolution documented anywhere. I also posted a similar response over on Logitech/slimserver#130.

EDIT (03-28-2017): OK, never mind. The problem is back, but only infrequently. So when it happens, I stop and re-start LMS and it seems to go away for a while (until the next day). Based on what I have been reading on this issue, I suspect that when the problem does occur, it is because LMS is unable to read/buffer the entire song before the URL times out. But I think the problem goes away when I get good network performance either through LMS, the RPi, or my provider. Maybe I should put an LMS restart into Crontab (to run everyday). Lastly, is it possible to reduce the bitrate from 320k to 160k so that the file size is smaller and easier to download prior to the URL expiring?