New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add geolock and language filters in the add-on browser #829
Conversation
Nice work spiff I can hear the out cry now "XBMC is tracking my location" :) even though weather already does it |
Alternate is setting properties for the bits you want to filter in the FillItem stuff then filtering on the property in the browser? |
This is related to PR #830. It seems location is starting to play a bigger role in XBMC. We should probably consider pulling our scattered location methods (wunderground, freegeoip, wifi, maybe android/iphone gps in the future) into an addon. |
this allows listing the countries the content is locked to for add-ons providing geo-locked content
rebased to use an add-on to grab region. |
FYI: freegeoip.net has a request limit of 1000/h (which is ~1.1 request every 4 seconds). If this limit is reached property won't be set and never retried. |
allows specifying the language(s) of the content the add-on provides
…owser. English add-ons are always included. Setting defaults to false
and filtering moved to window. |
If we're going to do geoip lookups, we need to provide them ourselves rather than relying on some 3rd party site to stay up and fulfill the requests AND not get pissed at us in the process. This has bitten us more than once before. |
As it wasn't apparent in my tone above.. We should be able to handle this easily enough. Addon downloads already do geoip lookups in order to forward to the closest mirror, we'd just need to add a quick function to expose that functionality externally. |
If we're going to use our servers, then we can potentially get away with doing it without the add-on - not that it really matters - either is fine in my opinion (the add-on could be used easily by other scripts and we don't need to bother exposing it, though that would be trivial). Rest of the code looks fine from a quick scan. @garbear your thoughts on the add-on thing? |
script.library.geoip suffices. Content providers block by IP, so it doesn't make sense for us to use any other locationing mechanism besides geo-ip for geolock. This duplicates functionality from the wunderground add-on, so I think we should setting on a single URL for ip lookups. |
garbear getting off topic but your image is |
fixed (maybe) |
yep fixed and nice but its an addon not an addon category right ? |
ya. it was just a thumb i drafted a year or two ago |
got our own setup: http://geoip.xbmc.org/json/ I think that's all that's needed? |
For this, country is probably enough. For weather, we'd probably want nearest city if possible? |
Ok, added. But the results are pretty poor. Compare the free results: https://www.maxmind.com/app/lookup_city?type=geolite |
both came with same results for me |
Same for me - both are equally inaccurate (it thinks I'm 600km away). |
for me the location returned by our server is more accurate but still 70km away |
makes my geo-wifi patch look better and better ;) |
I know this one is on hold atm, but what are the plans? Trying to bring focus to our oldest PRs so they don't get forgotton. |
@tamland maybe you can pick this up if you are interested |
This PR adds
i'm not entirely happy about the filtering happening in the directory class, but the alternative is fuglier (namely reconstruction addon-id's from the just-returned list of fileitems inside the browser). it should not hurt though, just a purist thing really.
is this something we want? i think a lot of users will appreciate both of these..