Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Unknown HTTP Status code while retrieving song #355

crazedpsyc opened this Issue · 20 comments

6 participants


Every so often, while loading a new song:

Cannot access audio file: Unknown HTTP status code.

I sniffed the connections it made, and there is indeed an invalid HTTP packet:

4317    211.059959    HTTP    169 GET /access/$music.mp4?version=4&lid=$lid&token=$token HTTP/1.1 
10158   558.088210    HTTP/DL 1333    Connect[Malformed Packet]
10564   590.618363    HTTP    579 HTTP/1.1 400 Bad Request  (text/html)

The content of the request:

GET /access/$music.mp4?version=4&lid=$lid&token=$token HTTP/1.1
User-Agent: libwaitress
Connection: Close
Range: bytes=0-

And the 'malformed packet' response:

HTTP/1.1 206 Partial Content

It happens fairly reliably after the first 2-4 songs, so I can probably get any other debug info if you need it.


Maybe pandora is trying to mess with pianobar :)


I get no error. What operating system is this, and what version? Also, make sure that you have an up-to-date version of pianobar.


@four04 This is Archlinux, using from git, updated from master just a couple hours ago.


No proxy is configured, though I do have tor and privoxy running at the moment. I assume there is no autoconfiguration of any sort, so that doesn't seem right.


How about the possibly of pandora somehow knowing that non-pandora clients will receive malformed packets to skew experience?


@albeetu seems unlikely that this is intentional, given that it doesn't happen every time or to everyone.
Another occurance:

GET /access/$19_digit_number?version=4&lid=$9_digit_number&token=$base64_encoded_token HTTP/1.1
User-Agent: libwaitress
Connection: Close
Range: bytes=1517481-

HTTP/1.1 400 Bad Request
Date: Wed, 20 Mar 2013 23:06:35 GMT
Server: Apache
Content-Length: 347
Connection: close
Content-Type: text/html; charset=iso-8859-1

The range in this one does seem a bit odd, for the initial request


I don't have a lot of knowledge on the Range header. But given what I did find, a 206 seems like an appropriate response.


I get this as well now that I've updated to current git. However I haven't gone back to check to see if it happens in the stable release.

(Ubuntu 12.10, no proxy, and pretty sure no transparent proxy either.)


Been listening to songs with 2012.05.06 (Ubuntu 12.10 .deb), and haven't seen an Unknown HTTP status code despite many hours of playing. (Compared with the current github source, which will usually get one after three songs are played; I suspect there's something to do with retrieving playlists that triggers this...)


Sorry about that censoring -- wasn't sure if any of those fields were
specific/private to my account. This is the above request:

GET /access/2882332304598862500.mp4?version=4&lid=428518403&token=7tf3aXyVnO3o9i8JT8UgVIB1R2aDIGb3scpCTErDiCleKRb7%2F83bXbmZA6la3oN%2FvMeZx3pzt1Q0KN%2FX8CQ8J0tylXwXUrMFx%2BVdAA2IasudRa%2BQSHqoESaEZFzfStlRtvXFLpj61XOnLOjQ9RK5fIgfXla2eg3ZKdZg1co6M45hDB5w7OWual33njaM5zHWFLJowS64wASrz3%2B%2FEXTL%2F9h9gAMTXF3bhJU%2F4xOM0D9%2F9zuD8mZn6r9HojsHfy4i08twFXgPqXmvzs%2FH8H70L60r8NuK4tNn98TrDO9LW9R%2BdoJJJ1SGxHcbXA0jGNPEV9zVriwSB202j0%2BUKG69o76Ev3rD5eNPGdAEQx1z3HmXermuhqG0RSljlociWSDMHK%2BRwOHACosTvthlIXmP5RtyAVcRJ5yWdDAvoK3EzkjaG03YbXXtnXhl2GiS1QPc6otO%2Ft3eoGReBV0tzIJ%2BKb3LbSzKm1cvu14qDODR14BE9AcdKyqf%2F3N%2FLMy3%2F2hV1g2qL%2F5nfZX7VkO0ICn518BQHa2QxAvWNpj1pbfs3FBMLlnqeRPGgA%3D%3D HTTP/1.1

After adding a printf right where you pointed, most tracks spat out received 0, but with the one that failed:

received 1278019
/!\ Cannot access audio file: Unknown HTTP status code.

This is indeed the final bytesReceived from the previous track!


Tested! Applied the patch to b849ea7 , and got the error after two songs played through in full:

Welcome to pianobar (2012.12.01-dev)! Press ? for a list of commands.
(i) Control fifo at /home/pjf/.config/pianobar/ctl opened
(i) Login... Ok.
(i) Get stations... Ok.
|>  Station "QuickMix" (1192682010653966847)
(i) Receiving new playlist... Ok.
|>  "Please Be Nice To Me" by "SS501" on "Collection" @ Pop
|>  "Lights" by "Ellie Goulding" on "An Introduction To Ellie Goulding" @ 90's Dance-esque
/!\ Cannot access audio file: Unknown HTTP status code.

Without applying any patches or updating, I haven't seen this error again for several days. A temporary issue on Pandora's end, I guess?

@PromyLOPh PromyLOPh referenced this issue from a commit
@PromyLOPh Ignore HTTP status 400
Workaround for #355, fixes commit

I've updated to the lastest code in git and am running now. So far no problems in playback, but there are, I'll be sure to report. :)

Current music: Safety Dance. :D

@crazedpsyc crazedpsyc closed this

Definitely fixed on both ends -- thanks!


To this day i still have this problem
[/!\ Cannot access audio file: Forbidden]
But i managed a workaround if anyone still care:
1- I started creating new pandora accounts, but those got blocked with time.
2- I started to search for proxies pandora didn't block yet. But this has to be in the most automatic way possible, since pandora was gonna block it eventually.
With time i realized even if my account seems to be blocked somehow(even with browser it doesn't work-mediahint plugin) once i found white-list proxies i could still listen to pandora with pianobar.
So i started to search for nice proxies, but it is a boring task to search for proxies, change the pianobar configuration and test the proxy.
So set up a scheme and it is working nice ever since.
1- with a terminal command [hidemyass] i get all of the hidemyass proxies and write in a text foe inside piadobar configuration(i do it 1-2 times a day).
2- with a terminal command [piano_proxy] i change the pianobar configuration with the 1st proxie in the list(removing it from the list). So if this doesn't work i call it again until i have no proxies to change.
Just putting it out there for people that had the same problem i did.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.