Hulu, Netflix and Pandora geo-location bypass – watch/listen to content freely

For many reasons, which I will not elaborate on inside this post, Hulu, Netflix and Pandora (like many other services) block access to their content by making use of geo-location user filtering. So regardless if you already have an account or not, if you’re accessing the websites through an ISP that is not a US internet provider we’re out of luck…OR ARE WE? ūüôā

Not to keep you on your toes, but a small Garage48 startup called Media Hint is providing a FREE means by which users outside the continental US can use Hulu, Netflix and Pandora radio can bypass geo-location restrictions and enjoy their favorite shows and listen to their music.

head over to Media Hint main website

The way in which it all works, is that Media Hint has provided users with a Chrome Browser extension (click link to go to the Chrome Web Store MediaHint website extension page), that users simply have to install and enjoy the awesomeness. (Firefox add-on also available Рcheck MediaHint website as well.)

This is how the Hulu geo-location error page looks like prior to installing the browser extension:

This is what it looks like when Hulu geoblocks you

And this is after installing (re-enabling if disabled) the Media Hint browser extension:

Playing content on Hulu without any geo-location restrictions

For the sake or argument (and if you fear the browser extension requirements) it would be advisable to take a look at the Media Hint Privacy Policy and Term of Use¬†– however after browsing through them for a little bit, it doesn’t look like anything to worry about.

The Chrome Browser Extension permissions are:¬†This extension can access:¬†Your data on all websites –¬†and you can read more about what this means on the Google Chrome Support page, or for¬†convenience¬†I’ve copy/pasted the info below:

This item can read every page that you visit — your bank, your web email, your Facebook page, and so on. Often, this kind of item needs to see all pages so that it can perform a limited task such as looking for RSS feeds that you might want to subscribe to.

Caution: Besides seeing all your pages, this item could use your credentials (cookies) to request or modify your data from websites.

In terms of how exactly it works, the secret sauce is actually a server side javascript that automatically sets a proxy for the Hulu, Pandora and Netflix urls. The proxy itself is hosted on a Linode (US based) server. The proxy settings are only applied for the previous mentioned srvices and do not affect your “other” browsing experiences, as you’ll easily be able to notice in the source code below:

function FindProxyForURL(url, host) {
       var basic_files = [/.*\.gif/, /.*\.png/, /.*\.jpg/, /.*\.mp3/, /.*\.js/, /.*\.css/, /.*\.mp4/, /.*\.flv/, /.*\.swf/, /hulu\.com\/mozart\//, /.*\.json/, /crossdomain\.xml/];
       for(var i=0;i
                     return 'DIRECT';
       var usa = ['', '', ''];
       var direct = ['', '', '', '', '', '', '', '', '', '', '', ''];
       for(var i=0;i -1){
                     return 'DIRECT';
       if(host.match(/audio.*\.pandora\.com/) || host.match(/const.*\.pandora\.com/) || host.match(/mediaserver.*\.pandora\.com/) || host.match(/cont.*\.pandora\.com/)){
              return 'DIRECT';
       for(var i=0;i -1){
                     return 'PROXY';
       return 'DIRECT';

As far as the streaming quality, things are¬†pretty¬†awesome at the time of writing this post, with no lags while watching TV shows or listening to online radio. Of course given that this is powered by¬†free of charge proxy server services, an increase in popularity may result, over time, in a degradation of quality leading to a less than ideal viewing or listening experience…but until then¬†“I’m gonna go watch something”¬†:).

WordPress (nginx-varnish) Jetpack xml_rpc 32700 glitch fix

My wordpress setup is hosted on a micro instance VPS on Amazon EC2 cloud running Ubuntu 12.10 64-bit, mysql, php-fpm, nginx web server and varnish cache http accelerator and after I install and try to activate jetpack I’ve experienced the following error:

Your Jetpack has a glitch. Something went wrong that√Ę‚ā¨‚ĄĘs never supposed to happen. Guess you√Ę‚ā¨‚ĄĘre just lucky: xml_rpc-32700. Try connecting again.

Error Details: The Jetpack server could not communicate with your site’s XML-RPC URL. Please check to make sure is working properly. It should show ‘XML√Ę‚ā¨‚ÄėRPC server accepts POST requests only.’ on a line by itself when viewed in a browser and should not have any blank links or extra output anywhere.

The URL request that’s being made and fails is:********** where ********** represents an alphanumerical code cooked up by Jetpack (like: bf67aebc88)

As many others before me I’ve also run into the jetpack problem mentioned above, however it seemed that none of the solutions I’ve found out there fixed the issue for me, mostly due to the specifics of the server setup, therefore I’ll illustrate below how I’ve fixed the problem for myself, and I’ll also provide some links to additional resources that have worked for others (for users who are mostly having to do with shared hosting environments).

Additional note: this fix also works for the situation in which you’re trying to use the WordPress for Android mobile app and your’re trying to add your self hosted blog to the android app – which fails without the steps below. Just as in the case of the Jetpack fix, this only has to be done once, so you might consider activating Jetpack and adding your self hosted blog to the android app at the same time as to not have to repeat the steps below.

WordPress for Android error message: org.xmlpull.v1.XmlPullParserException: unexpected type (position:END_DOCUMENT [email protected]:1 in

Solution (nginx – varnish):

If you are unfamiliar with LEMP (Linux server using Varnish, Nginx, W3 Total Cache, and WordPress), have a look at this post to get started.
In the this setup combination the culprit is actually Varnish which seems that although is passing through the request to the nginx backend (a.k.a no cache), some of the .js scripts required by Jetpack are not loaded/executed but rather served from the Varnish cache, leaving the jetpack plugin with incomplete data while attempting the request.
To fix this we could go ahead and blow our brains out trying to tweak the varnish configuration .vcl file to properly handle the request, but given that this Jetpack activation is a one time thing we’ll just go ninja, do it faster and with very little downtime.

Step 1:

Open the nginx configuration file specific for your site:

 nano /etc/nginx/conf.d/yoursite.conf 

edit and change the listening port to port 80. Typically nginx would be listening on a specific port (like 8080) for requests from varnish (which would be listening on 80).

listen 80; 

save and exit the file:

Ctrl+x > y > Enter

Step 2:

Now that we’ve changes nginx listening port to 80, before we can reload the configuration for the changes to take effect, we must stop the Varnish webserver, and we do that by issuing the following command:

 service varnish stop 

Step 3:

With the Varnish server stopped it is not time to reload the nginx configuration for the webserver and we do that by issuing the following command:

service nginx reload 

Step 4:

What’s happening now is that all wordpress requests are handled by nginx directly and are no longer passing through the Varnish caching layer.
Now go back in you wordpress blog, and click on the Jetpack tab > Connect to > Authorize Jetpack and voila…Jetpack has been authorized and enabled for your blog.

Note: as mentioned above, now would be a good time to also add your self hosted blog to the WordPress for Android mobile app to avoid having to redo these steps.

Step 5:

It is now time to undo what we did above with nginx and varnish in order to re-enable the varnish caching layer (don’t worry, only the activation had issue, everything else works well with varnish cache in front of it).

Open the nginx configuration file specific for your site:

 nano /etc/nginx/conf.d/yousite.conf 

Edit and change the listening port back to it’s original value (from 80 to 8080)

 listen 8080; 

Save and exit the file:

Ctrl+x > y > Enter

Reload the nginx web server configuration for changes to take effect

 service nginx reload 

Finally, it’s time to restart varnish cache:

 service varnish start 

Now it’s time to go back to your blog and play around with Jetpack as much as you want. You’ll find that pretty much everything works and you can enable and disable the various available modules, and you can even disconnect from if you want to, with no problem√Ę‚ā¨¬¶.however should you want the re-enable it, you’ll need to perform the above steps all over again.

Conclusion: the fix is rather simple actually, and if you read through the guide before actually doing it, it will take you less than a minute to complete, and with basically no downtime since you’re disabling varnish, but immediately enabling nginx as the fallback. This way, I think, is better than adding rules to the varnish configuration, since it’s something you only have to do it once, and just as the guide above it would still require you to stop and restart varnish.


Look at the common issues as depicted on the site:

Look at the plugin compatibility know issues on the site:

Try the “XML-RPC De-whitespacer” plugin in order to remove any white spaces / empty lines from your themes and plugins.

If you’re running lighttpd instead of nginx/varnish, you should check out this post on how to fix jetpack connection issue.

If none of the solution above resolve your xml_rpc 32700 glitch, you can contact the guys using this link:, but before you do it would help you and the jetpack guys if you:

1) Download the jetpack compatibility plugin from
2) Upload the plugin to your site via Dashboard -> Plugins -> Add New.
3) Activate the plugin and go to Plugins -> Jetpack Compatibility Test.
4) Click the “Select All” button.
5) Send the results of the test back in a reply.