403 HTTP Error

Here's a log:

ERROR:root:Gstreamer error: Could not open resource for reading., gstsouphttpsrc.c(1115): gst_soup_http_src_parse_status (): /GstPlayBin2:player/GstURIDecodeBin:uridecodebin182/GstSoupHTTPSrc:source:
Forbidden (403), URL: http://audio-ash-t2-1.pandora.com/access/?version=4&lid=78225981&token=kdRv8UrQRq64stKTKJ7cYeF%2BJ8gi3TVALy32nX3IBuTUFks5tpeq%2Ben22C1wdKuO4HhiKsdVX5BiQIJcXzyL%2BXA2sP4PADbX7U6TOGFk%2B7uMpQ4r02fKhHtbLNOG46BYq%2BJSNNpqdAqTeFEmwl8av1oKXNXxA3av%2Bxyga1DCnP%2Br96ZolIIcOnTMD6DLymdpqxgafbmylkcFgPAyoztkjrhN3bEFZdT21LIW1WHRl5wWonh9L5v54717irHTaZmvLvf6FKz%2FE8k9ZfHGj5vtbwmVjLyWV9am46KA571AfQXsuM9wRBlbwAJ4Yi1nUUHG3zuMvOgBkGMCsqpuiVx4%2Bw%3D%3D
ERROR:root:Gstreamer error: Your GStreamer installation is missing a plug-in., gstdecodebin2.c(3135): gst_decode_bin_expose (): /GstPlayBin2:player/GstURIDecodeBin:uridecodebin182/GstDecodeBin2:decodebin2182:
no suitable plugins found
ERROR:root:Gstreamer error: There is no codec present that can handle the stream's type., gstdecodebin2.c(1548): analyze_new_pad (): /GstPlayBin2:player/GstURIDecodeBin:uridecodebin182/GstDecodeBin2:decodebin2182:
No decoder to handle media type 'text/html'
ERROR:root:Gstreamer error: GStreamer encountered a general stream error., gstqueue2.c(2348): gst_queue2_loop (): /GstPlayBin2:player/GstURIDecodeBin:uridecodebin182/GstQueue2:queue2182:
streaming task paused, reason not-linked (-1)

I think all that's needed is to handle the 403 error by reauthorizing as if Pithos was just launched, rather than passing whatever comes back to GStreamer, even if it's a 403 with HTML.

This happens to me when I put my laptop to sleep and come back many hours later. I think it's simply the song access URLs expiring.

One way to handle it is by using a HTTP HEAD request to get the status code for the URL. If it's a 403, reauthorize and get a new playlist. I have this working in this branch I've made but I don't know how to make it play automatically.

But I also see the is_still_valid() function. Maybe it's not calculating correctly, or is thinking the validity time is too long. This could also fix it, and avoid an extra HTTP request for every song play. But how do we know the true expire time? And we still need to handle the 403 errors if they happen.

Should we parse the Gstreamer error instead of using a HEAD request?

lp:~launchpad-alphapapa/pithos/620854

Ok, here are some notes about what I just figured out:

By default, GStreamer errors call self.next_song(). If the auth token is still valid, this goes through the rest of the songs in the list, and if it runs out, it gets a new playlist and keeps playing.

But if the auth token is invalid, it ends up in eb() and retries. So all that's needed, apparently, is to advance to the next song--which Pithos already does!

The problem may be this error I just encountered:

INFO - pithos:eb:307 - Automatic reconnect after invalid auth token
ERROR - pandora:xmlrpc_call:135 - fault: org.apache.xmlrpc.XmlRpcException: For input string: "91198140128"
WARNING - pithos:eb:314 - Traceback (most recent call last):
  File "/home/me/Projects/Python/Pithos/620854/./pithos/gobject_worker.py", line 34, in _run
    result = command(*args)
  File "/home/me/Projects/Python/Pithos/620854/./pithos/pandora/pandora.py", line 169, in connect
    user = self.xmlrpc_call('listener.authenticateListener', [user, password], [], secure=True)
  File "/home/me/Projects/Python/Pithos/620854/./pithos/pandora/pandora.py", line 136, in xmlrpc_call
    code, msg = fault.split('|')[2:]
ValueError: need more than 0 values to unpack

This same error can happen whenever Pithos connects, even on startup. And I filed this as lp:905204.

So, if I understand everything correctly (and I may not), this bug is occurring because lp:905204 is happening sometimes--otherwise it's already handled.

Well, apparently Pandora got tired of me logging in over and over again while I was debugging this: now I get PLAYLIST_END, and can't even play through the Web site. I am a Pandora One subscriber, too. I hope this apparent ban is temporary.

In the meantime, I pushed some more code that adds checks to the xmlrpc_call() function. Still not sure if this is an "autopilot" fix--it may still pop up an error box. I tried to make it retry connection attempts 3 times instead of once, but I can't test that since my account stopped working, so I removed that code. That may be the final solution, though.