Randomly stops playing after few minutes #161
Comments
|
Same here, sample debug output: |
|
Issue seems to be on Google's side. With the server returning HTTP 403, there's not much one can do. |
|
Grabbing the whole track at once would probably fix the issue but that's not as simple as it should be. |
|
@wf1nder Can you try a different gstreamer package and let us know? I removed |
|
This issue started to happen for me in last few weeks - it was working stable before. Didn't update gstreamer. |
|
I have this problem too. I dont make any update |
|
Same happens here, "GStreamer error: gst-resource-error-quark: Forbidden (15)" |
|
BTW - not a proper solution, but I run now simple watchdog on the logs, and just tell mpd to play next song when this happens. It sucks, but better than a full stop.
|
|
Spotify uses a very different method of accessing gstreamer so it'd be interesting if any of the other backends showed this issue. Literally any other backend. |
|
I'd be interested in seeing if there's anything useful in the gmusicapi logs... That's located at ~/.cache/gmusicapi/log/gmusicapi.log on linux. Please note that this may contain the clientID/deviceID, so you may want to edit those out. |
|
No, nothing in that file when error, only the info about opening a new file, the normal things. |
|
@sphaugh
Tried different versions of gstreamer before, in different linux distros, and have the same issue. |
|
Affects me as well and it's annoying as hell - literally can't listen to Google music anymore because of this, it just stops after a couple of minutes. Since it's on Google's side, can't we mimic Google Music app and download the songs in a similar fashion? |
|
I'd love to do that, but then we'd need to manage our own cache directory and handle that sort of thing so we can hand mopidy local URLs... which would be possible since we're given IDs... but it would be a fairly large rewrite of the playback portion. |
|
Well, if it makes anyone here feel better, I can finally reproduce it. I'll see if I can nail it down and get an update here soon-ish. |
This aims to fix mopidy/mopidy-gmusic#161 by grabbing the whole song at once rather than buffering.
|
There's an experimental fix against mopidy here: mopidy/mopidy#1608 I'm testing this locally, but this should fix the issue 🤞. I've made it through 6 tracks so far and it's worked fine (before it would trigger after 1 or 2). If anyone here is familiar with running mopidy from git and has been running into this, I'd appreciate more testers. If you're not comfortable with that, it may help to set the bitrate to 160 rather than 320, but that's a temporary fix. |
|
There are a number of possibilities here, but the main complications are that gmusic stream URLs expire after 90 seconds and gstreamer will sometimes hit the URL more than once, possibly if the connection is closed (I didn't get that deep into debugging it). Mopidy attempts to make this less of an issue by providing a fairly large buffer (5M) but also limits it to 5 seconds. I'm not sure how these values interact. So, what I think is happening:
Other possibilities are weird interactions between the internal bitrate and what we're guessing... and the possibility that Google changed the default to 320. However, I don't have any insight into what happens at Google, so I can't know for sure what caused this. I've now made it through a full album without any issues, so I think my hunch may be correct. :) |
|
I've installed it using I created a playlist with 6 podcasts (30-60') and I'm listening to them already for a couple of hours - works great! Thanks a lot! |
|
Found a track that still stops, pretty much reproducible every time, it stops around 4:10: After it stops, if I press the "|<<" (previous) button, it (probably retries the download and then) continues to play from where it stopped. I can provide os & software versions / logs / other info as requested, can test PRs/commits if necessary. |
|
Is that an uploaded track, or an All Access track? |
|
All Access, that's why I gave its id :)
…On Apr 3, 2017 20:30, "Kaleb Elwert" ***@***.***> wrote:
Is that an uploaded track, or an All Access track?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#161 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAgSP__2shWAtN7pgx-ohzexckPXq433ks5rsSy3gaJpZM4LVN1z>
.
|
|
Hm, I can't reproduce it with |
|
Got it using chrome's devtools (right click, inspect). It's probably worth
mentioning that I'm not using a raspberry pie, mopidy is installed using
pip on a Ubuntu 14.04 server. Can provide more details if needed (versions,
logs, etc).
On Apr 3, 2017 20:52, "Kaleb Elwert" <notifications@github.com> wrote:
Hm, I can't reproduce it with gmusic:track:Tuicpadq7f2stsgqw34rrkza6dq
which seems to correspond to the song you mentioned. All Access track IDs
should always start with a T, so I'm not sure where that UUID is even
coming from.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#161 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAgSP9wxmKRe8VOj6aXmj1jh_sE8jSShks5rsTHYgaJpZM4LVN1z>
.
|
|
Easiest way is to get it from the "share" link on the official web frontend. That works for albums, artists and tracks. |
|
This issue does seem to happen much more on the rPI... I guess my fix doesn't fix it everywhere. |
|
pip install 'git+https://github.com/belak/mopidy@0d87a2a#egg=mopidy' --upgrade |
Can you tell me please which one is the official frontend? I have a couple of them installed but none has a "share" link on a album/artist.
|
|
I think he's referring to https://play.google.com/music |
|
I've been digging through the gstsouphttp source and I can't see where it has support for bypassing specific domains. I'll investigate more and take it up with the gstreamer folks. |
|
I've been running @kingosticks' proxy branch for a few weeks now and it's working wonderfully. I know it doesn't necessarily work well with proxy support, but if there's a way to get that working, I'd suggest using the branch: it appears to have fully fixed this issue. |
|
The proxy support in gstreamer is a total mess, it's implemented differently for each element. The only thing that appears consistent across the elements is that the proxy option mopidy uses will override all other proxy/noproxy environment variables. Unfortunately i don't see how my workaround can be made http proxy compatible so I guess it's no good. Shame. |
|
I'm having this issue as well. Some music will play through a whole album with no issues, some stop 1-2 mins into the track. same error every time: |
This aims to fix mopidy/mopidy-gmusic#161 by grabbing the whole song at once rather than buffering.
|
I can see that mopidy/mopidy#1608 is not merged yet. Is it still the best workaround or is there some other way? |
|
@morgoth I'm running it with the patch locally and it has worked wonders for me |
|
@lieuwex It doesn't work for me - I applied a change by hand in |
|
@lieuwex can you point me to directions to do this? |
|
@morgoth I'm not that experienced with python but I guess it has some cache ( In your shell ((ba)sh): You can now run |
|
I wasn't having this issue until like a month ago when I reinstalled Arch. Now some tracks will play perfectly without interruption from beginning to end, and some will just randomly stop after 1-2 minutes of playback with the following error: I have installed the following versions from the official repos and from aur: |
|
I can confirm that the fix mopidy/mopidy#1608 worked for me. I also manually applied the change to the actor.py file I was having the exact same issue Yaroslav-95. I began having this issue only last week. I have been using mopidy-gmusic with Snapcast (snapserver / snapclient) setup. I am running Ubuntu 18.04.1 LTS with Mopidy 2.2.2 & Mopidy-GMusic 3.0.0 installed as local user. I re-installed mopidy and all extensions prior to making the change. I checked through network monitor that gmusic did download the entire file just prior to starting playback of a track. |
|
Thank you very much, that seems to have fixed the problem at least for now. For anybody else that is figuring out how to fix this problem by adding the download flag, the actor.py file is located in /lib/python2.7/site-packages/mopidy/audio/actor.py (at least in Arch). Just modify this line: So that it looks like this |
|
unfortunately the "download" flag fix (mopidy/mopidy#1608) doesn't seem to work on rPi raspbian installations (mopidy 2.2.2). still getting same error (GStreamer error: gst-resource-error-quark: Forbidden (15)) |
|
I've been having play randomly stop recently. I need to check the logs and see if it's the same issue. |
|
@karladolfeichmann That pull request hasn't been merged yet. The fix is only available in a branch. |
|
proposal: i think the issue might be due to a change in the URI signature. if you focus on the signature and port numbers, you'll see a change in both when this error occurs. it does happen intermittently like it did in this example. this seems to happen within the time frame that @belak and others mentioned earlier in this thread. once a certain amount of time has elapsed, the URI changes and generates a new signature and sometimes uses a different port number. i think it's important to note that the key always stays the same during the stream. this tells me that balek's fix is really just a workaround. pulling the full stream down first and then playing it back by cache just skirts around the fact that google sent a new response that seems to interrupt playback. following the previous logic that balek proposed we can then assume that the frame buffer allots what it can, does not run out of space, and then the request times out... once the request times out, google's server generates a new signature, responds with a new URI containing the new signature, and sends it to the client. the client compares the signature, and because the signature is different from the previous, and it then triggers the error. a potential fix to the problem would be to update the signature once the timeout has occurred. this would effectively stop the signature comparison from failing. keep in mind that this is just a rough guess. i have not taken the time to look at mopidy or mopidy-gmusic source code yet. i'll report back if i have any success because i am interested in getting this resolved for my self and i might as well contribute if i come up with a fix. notes and observations: lowering the bit rate also seems to help, but barely at all. the reason being that the URI changed after a certain amount of time had elapsed triggering the error anyway regardless of the buffer status. its also important to note the 403 error that is occurring. this means that the server understands the request but isn't allowing it. hashes are used to compare data securely and if it changes, it will fail when a comparison finally occurs.
source: Mozilla Developer Network This could be a potential hint to the need to update the signature before the timeout occurs. that way when a request is finally made again (after mopidy has idled for x amount of time), google receives the hash it's expecting to see. full debug log: debug error: |
|
I've got this PR open at the moment, which either fixes or works around the issue by enabling the progressive download buffering option in gstreamer. Not sure why it wasn't mentioned here before. It's probably a generally nice to have feature that could potentially help with a variety of streaming issues. @averydark thanks for investigating. If there's a way to fix this specific issue for this backend we should probably do that too. |
|
We've covered all of this and I thought we understood the problem so I'm confused by this post. We've very much established (maybe elsewhere if it's news here) that download buffering is a workaround. But we should finally merge that PR and I'll do that today. Adjusting the bitrate makes a difference because gstreamer can then buffer a different amount. I think you misunderstand what the proxy is doing, which is fair enough if you have not looked at how Gstreamer works. I'll try again:
Hopefully you can now see what the proxy hack was doing and why it works. But it's just another workaround. A better fix here would be develop a variant of gapless playback that let's us use the new uri but somehow suppress the track changing. I'm really not sure if that is possible without looking again at it. There might also be something in gstreamers new streams support that we could leverage. But as a workaround, download buffering is the best choice right now. |
|
Thanks Nick. If can get that merged I'll open a PR here to set the download flag. |
|
@jjok i will be doing more investigating until i find a fix or give up. i'm just surprised this hasn't been fixed yet because it is a 4 year old problem.
this happens when the client request session expires after a time limit has occurred. that's why setting the bit rate doesn't really fix this issue. caching the whole song isn't a solution mainly because it resorts to downloading the song until it has played it. at that point, you might as well hold on to the song.
that is what i was suggesting as a potential fix.
this is a good starting point.
this is something to look further into. |
Changing the bitrate is absolutely not a fix. It's not even a workaround.
I don't know what you mean here but you can read about Gstreamer's different buffering stgrategies here. It is a fix, it will work, but it's not ideal.
Great. We are all on the same page. I'm not sure what their sterams support entails. It might not be useful at all. One more option is to ask Gstreamer to provide a mechanism in souphttpsrc to support what we want to do. Problem is even if they did that tomorrow it would take a long time to filter down for us to use. |
google has a 30 day policy that allows you to download the song for offline usage. the token expires after the 30 days have passed and you have to check in with your account to keep the downloaded content active. i'm not sure how to go about implementing this kind of behaviour, but it's this is a feature rather than a fix. it's also not what i'm interested in focusing on anyways.
thanks. i will take a look when i get around to it. i already forked the code base and i need to start with the docs first so i can get acquainted with it. i'll make a PR if i come up with anything. unfortunately, it could be a few days, or more, before i even touch the code and come up with a decent solution. i can do some testing once i get there, report my findings, and we can go from there. |
|
Ah I see. We are not talking about saving this download data in any form. That's something else entirely and subject to 30 day policies/whatever licensing, as you say. The data that gstreamer has in its playback buffer won't touch disk and is discarded once the track changes. The term "download buffering" is just the gstreamer name to distinguish it from other buffering strategies. |
|
Closing because Google Play Music has been shut down, and this project is being discontinued. |
and others
Can’t get gmusic plugin to work normally. It starts playing, but after a some time (few minutes) randomly stops. There appears message on console:
ERROR GStreamer error: gst-resource-error-quark: Forbidden (15)Switching to next track fixes problem for the next few minutes.
Tried on my Raspberry PI 1, Raspberry PI 2, Odroid C2, and on PC. Distros: Ubuntu, Debian, Raspbian, Volumio, Ubuntu on C2. Tried on 3 diffirent USB dacs, and on I2S dac. Also, mopidy was installed from deb-repo, or from pip. In all cases problem appears.
Now using last versions of mopidy and mopidy from pip: mopidy=2.0.1, mopidy-gmusic=2.0.0. Also, gstreamer1.0.
The text was updated successfully, but these errors were encountered: