search

OpenELEC / OpenELEC.tv

OpenELEC - The living room PC for everyone
http://openelec.tv
1.61k stars 883 forks source link

Official XBMC Addon Repository empty #726

Closed alexricher closed 11 years ago

alexricher commented 12 years ago

Good day OpenElec Team,

First and shortly, I'd like to say you are doing an amazing job at this nice piece of code! :) I love XBMC, and I love the fact that it runs on ION based system. Now onto the issue.

Since 1.95.1, I cannot access the official XBMC Addon repository. I've created a thread on the forum regarding this at some point in the hope of someone having the same issue, but no luck: http://openelec.tv/forum/72-xbmc/32158-xbmc-official-repository-empty

Anyhow, I feel it should be accessible. As the thread explains, I've tried:

19:55:45 T:140298596382464 NOTICE: Previous line repeats 1 times. 19:55:45 T:140298596382464 WARNING: FillBuffer: curl failed with code 28 19:55:45 T:140298596382464 ERROR: CFileCurl::CReadState::Open, didn't get any data from stream. 19:55:50 T:140298596382464 ERROR: Open - failed to open source http://mirrors.xbmc.org/addons/eden/addons.xml.md5 19:56:00 T:140298596382464 WARNING: FillBuffer: curl failed with code 28 19:56:00 T:140298596382464 ERROR: CFileCurl::CReadState::Open, didn't get any data from stream. 19:56:05 T:140298596382464 ERROR: Open - failed to open source http://mirrors.xbmc.org/addons/eden/addons.xml|Encoding=gzip

19:56:05 T:140298596382464 ERROR: Repository XBMC.org Add-ons returned no add-ons, listing may have failed

I've seen similar tickets opened, but always got closed after some inactivity. On my end, every time there was a new beta, I always updated my system with it to see if it would solve it, but I'm out of luck.

Please, let me know if I can be of any help because I truly believe OpenElec is a very nice piece of software that I'm planning on using for quite a while. :D Thanks!

alexricher commented 12 years ago

Enabled debugging for some more completed logs...

Here's what I get when I "Check for updates":

20:07:37 T:140185842050880 DEBUG: Checking repositories for updates (triggered by XBMC.org Add-ons) 20:07:37 T:140184771356416 DEBUG: CFileCache::Open - opening <addons/eden/addons.xml.md5> using cache 20:07:37 T:140184771356416 DEBUG: FileCurl::Open(0x7f7f40004760) http://mirrors.xbmc.org/addons/eden/addons.xml.md5 20:07:37 T:140184771356416 INFO: easy_aquire - Created session to http://mirrors.xbmc.org 20:07:42 T:140185842050880 DEBUG: ------ Window Init (Pointer.xml) ------ 20:07:43 T:140184762963712 DEBUG: Received request to serve unknown md5 'DeviceDescription.xml' 20:07:47 T:140184771356416 WARNING: FillBuffer: curl failed with code 28 20:07:47 T:140184771356416 ERROR: CFileCurl::CReadState::Open, didn't get any data from stream. 20:07:48 T:140185842050880 DEBUG: ------ Window Deinit (Pointer.xml) ------ 20:07:49 T:140184746178304 DEBUG: Received request to serve unknown md5 'DeviceDescription.xml' 20:07:52 T:140184771356416 ERROR: Open - failed to open source http://mirrors.xbmc.org/addons/eden/addons.xml.md5 20:07:52 T:140184771356416 DEBUG: CFileCache::Open - opening <addons/eden/addons.xml> using cache 20:07:52 T:140184771356416 DEBUG: FileCurl::Open(0x7f7f4000ed80) http://mirrors.xbmc.org/addons/eden/addons.xml

20:08:02 T:140184771356416 ERROR: CFileCurl::CReadState::Open, didn't get any data from stream. 20:08:03 T:140185842050880 DEBUG: SECTION:UnloadDelayed(DLL: special://xbmcbin/system/ImageLib-x86_64-linux.so) 20:08:03 T:140185842050880 DEBUG: Unloading: ImageLib-x86_64-linux.so 20:08:07 T:140185249511168 DEBUG: Thread Jobworker 140185249511168 terminating (autodelete) 20:08:07 T:140185350985472 DEBUG: Thread Jobworker 140185350985472 terminating (autodelete) 20:08:07 T:140184771356416 ERROR: Open - failed to open source http://mirrors.xbmc.org/addons/eden/addons.xml|Encoding=gzip 20:08:07 T:140184771356416 ERROR: Repository XBMC.org Add-ons returned no add-ons, listing may have failed 20:08:07 T:140184771356416 DEBUG: CFileCache::Open - opening <2.1/ION/x86_64/addons.xml.md5> using cache 20:08:07 T:140184771356416 DEBUG: FileCurl::Open(0x7f7f40007550) http://addons.openelec.tv/2.1/ION/x86_64/addons.xml.md5 20:08:07 T:140184771356416 INFO: easy_aquire - Created session to http://addons.openelec.tv 20:08:07 T:140185383728896 NOTICE: Thread CFileCache start, auto delete: false 20:08:07 T:140185383728896 DEBUG: Process, request seek on source to 0 20:08:07 T:140185383728896 INFO: easy_aquire - Created session to http://addons.openelec.tv 20:08:08 T:140185383728896 DEBUG: Thread CFileCache 140185383728896 terminating 20:08:08 T:140184771356416 INFO: ADDON: cpluff: 'Could not read plug-in directory /usr/lib/xbmc/addons: No such file or directory' 20:08:08 T:140184771356416 DEBUG: ADDON: cpluff: 'Not all directories were successfully scanned.' 20:08:08 T:140185842050880 DEBUG: CGUIMediaWindow::GetDirectory (addons://repos/) 20:08:08 T:140185842050880 DEBUG: ParentPath = [addons://repos/] 20:08:08 T:140185383728896 NOTICE: Thread Background Loader start, auto delete: false 20:08:08 T:140185842050880 DEBUG: SECTION:LoadDLL(special://xbmcbin/system/ImageLib-x86_64-linux.so) 20:08:08 T:140185842050880 DEBUG: Loading: /usr/lib/xbmc/system/ImageLib-x86_64-linux.so 20:08:08 T:140185383728896 DEBUG: Thread Background Loader 140185383728896 terminating 20:08:37 T:140185842050880 INFO: CheckIdle - Closing session to http://mirrors.xbmc.org (easy=0x7f7f40013c40, multi=0x7f7f400346f0) 20:08:38 T:140185842050880 INFO: CheckIdle - Closing session to http://addons.openelec.tv (easy=0x7f7f4003fea0, multi=0x7f7f40031270) 20:08:38 T:140185842050880 INFO: CheckIdle - Closing session to http://addons.openelec.tv (easy=0x7f7f6c01bb90, multi=0x7f7f6c251980) 20:08:38 T:140184771356416 DEBUG: Thread Jobworker 140184771356416 terminating (autodelete) 20:08:38 T:140185842050880 DEBUG: SECTION:UnloadDelayed(DLL: special://xbmcbin/system/ImageLib-x86_64-linux.so) 20:08:38 T:140185842050880 DEBUG: Unloading: ImageLib-x86_64-linux.so

alexricher commented 12 years ago

Here's with a "Force Refresh":

20:12:46 T:139926896097024 WARNING: FillBuffer: curl failed with code 28 20:12:46 T:139926896097024 ERROR: CFileCurl::CReadState::Open, didn't get any data from stream. 20:12:51 T:139926896097024 ERROR: Open - failed to open source http://mirrors.xbmc.org/addons/eden/addons.xml.md5 20:12:51 T:139926896097024 DEBUG: CFileCache::Open - opening <addons/eden/addons.xml> using cache 20:12:51 T:139926896097024 DEBUG: FileCurl::Open(0x7f4328017a40) http://mirrors.xbmc.org/addons/eden/addons.xml 20:13:01 T:139926896097024 WARNING: FillBuffer: curl failed with code 28 20:13:01 T:139926896097024 ERROR: CFileCurl::CReadState::Open, didn't get any data from stream. 20:13:02 T:139928005654336 DEBUG: SECTION:UnloadDelayed(DLL: special://xbmcbin/system/ImageLib-x86_64-linux.so) 20:13:02 T:139928005654336 DEBUG: Unloading: ImageLib-x86_64-linux.so 20:13:06 T:139926947493632 DEBUG: Thread Jobworker 139926947493632 terminating (autodelete) 20:13:06 T:139927643727616 DEBUG: Thread Jobworker 139927643727616 terminating (autodelete) 20:13:06 T:139927652120320 DEBUG: Thread Jobworker 139927652120320 terminating (autodelete) 20:13:06 T:139926896097024 ERROR: Open - failed to open source http://mirrors.xbmc.org/addons/eden/addons.xml|Encoding=gzip 20:13:06 T:139926896097024 ERROR: Repository XBMC.org Add-ons returned no add-ons, listing may have failed 20:13:06 T:139926896097024 DEBUG: CFileCache::Open - opening <2.1/ION/x86_64/addons.xml.md5> using cache 20:13:06 T:139926896097024 DEBUG: FileCurl::Open(0x7f43280185b0) http://addons.openelec.tv/2.1/ION/x86_64/addons.xml.md5 20:13:06 T:139926896097024 INFO: easy_aquire - Created session to http://addons.openelec.tv 20:13:06 T:139927668905728 NOTICE: Thread CFileCache start, auto delete: false 20:13:06 T:139927668905728 DEBUG: Thread CFileCache 139927668905728 terminating 20:13:07 T:139926896097024 INFO: ADDON: cpluff: 'Could not read plug-in directory /usr/lib/xbmc/addons: No such file or directory' 20:13:07 T:139926896097024 DEBUG: ADDON: cpluff: 'Not all directories were successfully scanned.' 20:13:07 T:139928005654336 DEBUG: CGUIMediaWindow::GetDirectory (addons://repos/) 20:13:07 T:139928005654336 DEBUG: ParentPath = [addons://repos/] 20:13:07 T:139927668905728 NOTICE: Thread Background Loader start, auto delete: false 20:13:07 T:139928005654336 DEBUG: SECTION:LoadDLL(special://xbmcbin/system/ImageLib-x86_64-linux.so) 20:13:07 T:139928005654336 DEBUG: Loading: /usr/lib/xbmc/system/ImageLib-x86_64-linux.so 20:13:07 T:139927668905728 DEBUG: Thread Background Loader 139927668905728 terminating 20:13:36 T:139928005654336 INFO: CheckIdle - Closing session to http://mirrors.xbmc.org (easy=0x7f4329926350, multi=0x7f4328017cf0) 20:13:37 T:139928005654336 INFO: CheckIdle - Closing session to http://addons.openelec.tv (easy=0x7f432802b330, multi=0x7f4328018950) 20:13:37 T:139926896097024 DEBUG: Thread Jobworker 139926896097024 terminating (autodelete) 20:13:37 T:139928005654336 DEBUG: SECTION:UnloadDelayed(DLL: special://xbmcbin/system/ImageLib-x86_64-linux.so) 20:13:37 T:139928005654336 DEBUG: Unloading: ImageLib-x86_64-linux.so

sraue commented 12 years ago

you still have this issue?

alexricher commented 12 years ago

Sadly, yes, I still do. :( I've tried several thing even after opening this ticket, but no go. I'm not sure why it does this though. I mean, it never happened with before 1.95.x (before the 2.0 betas) Even through several reinstall, the issue is still present. I can access any other repository (OpenElec and other unofficial ones).

It's not a major blocking, but because of this, every time I need a special XBMC addon from the official repository, I need to go online, grab the .zip file and install it manually while I could do this in a few clicks normally through the official repo.

Let me know if I can be of any help. :) Thanks for this great piece of software sraue (and OpenElec team! :D)

hulmeman commented 12 years ago

Same problem here, any ideas yet?

alexricher commented 12 years ago

I see beta 5 was released, but this ticket is still opened. I guess it won't be fixed within this release? Has anyone had a chance to look into it?

I have been holding out on customizing XBMC with skins and other cool addons since everything needs to be done manually but I gotta admit I'd really enjoy being able to download from the official repo soon. :)

Thanks a bunch! :D

kiranos commented 12 years ago

error code 28 for curl is:

CURLE_OPERATION_TIMEDOUT (28)

Operation timeout. The specified time-out period was reached according to the conditions.

so have you tried:

wget http://mirrors.xbmc.org/addons/eden/addons.xml.md5 wget http://mirrors.xbmc.org/addons/eden/addons.xml curl http://mirrors.xbmc.org/addons/eden/addons.xml curl http://mirrors.xbmc.org/addons/eden/addons.xml.md5

manually after logging in through ssh? if it gets timeout then aswell?

alexricher commented 12 years ago

Thanks a lot for the come back on the error code. :) I'll try that just now and report back how it goes.

alexricher commented 12 years ago

I've just tried the given command through SSH.

Both wget commands ran successfully:

root ~ # wget http://mirrors.xbmc.org/addons/eden/addons.xml.md5 Connecting to mirrors.xbmc.org (212.110.166.220:80) addons.xml.md5 100% |_| 33 0:00:00 ETA root ~ # wget http://mirrors.xbmc.org/addons/eden/addons.xml Connecting to mirrors.xbmc.org (212.110.166.220:80) addons.xml 100% |_| 442k 0:00:00 ETA

Same for the curl commands, although the output contains a bit too much XML to copy paste it here... but here's a small part:

XML START

XBMC MPRIS D-Bus interface XBMC MPRIS D-Bus Schnittstelle Control XBMC using the MPRIS D-Bus interface (with Ubuntu sound-menu integration). XBMC über die MPRIS D-Bus Schnittstelle steuern (mit Ubuntu Sound-Menü Integration). linux true Qlock Service Script to display current time in words, needs skin support. so far only Transparency! is supporting this in SVN all truetrue D-Bus notification service Connects to the D-Bus notification interface and publishes the currently playing media information. linux true Performs Rom Collection Browser startup tasks Some features in Rom Collection Browser require actions on XBMC startup: starting RCB after launching emulators in solo mode and scraping games on XBMC startup. GPL 2.0 all true Gesture Remote Control for touch based webkit browser. wTouch give you to remote XBMC with your touch based webkit browser, like iOS and Android devices. It use your gestures by swiping fingers on your devices, so you will keep focus on your TV/Display rather than going back and forward between your TV/Display and your devices to find the exact buttons to be pressed/touch. With Gyroscope enabled devices and supported by it's browser, you can tap and hold then conduct the XBMC with your device. all true # # XML END What I do not understand in this is if I request it through the addons interface, I'll get those CURLE_OPERATION_TIMEDOUT (28), but by doing them manually, it works fine. Just to be 100% safe, I've redone it through the interface by forcing the refresh of the XBMC.org Add-ons, but still no go; hence why I'm starting to believe there might be something within the request for this specific add-on since the OpenElec repository works for me. Thanks for your help and have a good day! :)
alexricher commented 12 years ago

Oups, the XML got interpreted by the web site instead of just showing raw XML. Sorry about that...

lgladdy commented 12 years ago

I've got this same issue. It started after I deleted my .xbmc folder by SSH in order to start fresh with a new install.

I'm running the latest beta (7) and I was able to fix it by copying over the AddOns15.db folder from my known working XBMC on mac.

alexricher commented 12 years ago

Thanks for the update. I also had OpenElec 1.95.1 back then and I did a copy of my xbmc folder so I could move my installation from a USB key to a SSD. Everything seemed to have worked fine except the repository. Since then, I've never been able to get it to work.

I wish I could try what you're suggesting but I don't have any other installation.

Unless I'm mistaking, deleting the db file should rebuild it and it seems this is where the issue happens. So, could it be that because your db is valid, it doesn't need to reconstruct it; therefore, doesn't need to fetch the xml data from the server?

As I've stated before to the OpenElec team, I'm willing to try and troubleshoot the issue further, but fistly, I would need someone to help me out. I totally understand there are higher priorities in the currently opened issue, but if we never tackle this one, it'll never get solved. ;-)

Thanks for an update OE-team! :)

tijnemans79 commented 12 years ago

are you by any chance using PXE ?

alexricher commented 12 years ago

Not as far as I know, currently using OpenElec 2.0 beta 7 on ION 2.

DiMag commented 12 years ago

I have had the same problem (empty xbmc.org repository) even before the 1.95.x builds. It seems to be not a bug but a feature --the devs intentionally disable access to the xbmc repository. It is a policy which is impossible to rationalize: what is the purpose of beta-testing a functionally crippled system? Notice that OpenELEC's brother OpenELEC/Pulse-Eight is offered without this cripple. Which, of course, makes the decision course taken by OpenELEC all the more incomprehensible. PLEASE join in shouting to the devs se they should come to their minds.

alexricher commented 12 years ago

Thanks for the info. I actually didn't know it was related to access and it could technically make sense since the request seems to get there (I had tried it manually and it worked) but it will never fetch anything in the end; thus ending with an empty repository.

The only thing I find a bit weird is we're only a few to report this. I can't believe people are able to get it working and we're only a few that cannot. I must admit it'd be nice that someone takes a look into this issue, even though it isn't a high priority problem. It's just slightly annoying and like I said, I'm willing to help debug the issue, as long as someone gives me info on what to look for. Right now, this ticket seems to be bouncing between versions... And being a dev myself (not on OpenElec, nor XBMC but a video game programmer), I would hate being yelled at by angry users. :P hehehe

DiMag commented 12 years ago

You are right about it being weird that so few people have noticed, and made an issue of, the empty xbmc.org repository problem. But guess what, Hans Christian Andersen has long ago described a similar situation in his wonderful sordid satire (masquerading as a children fairy tale) 'The Emperor's Clothes'.

You are also right about the 'yell at the devs' request, I retract it. But guess what, it is really their fault. They should have stated at the beginning that for a number of reasons they have removed access to the official repository which limitation shall be lifted at a subsequent point. I can still hypothesize no plausible reason for this decision, and the fact that Pulse Eight offers a version of OpenELEC with free access to the official repository damages their (hypothetical) defense. Sorry for speaking so, I am a lawyer by profession.

alexricher commented 12 years ago

Lawyer, huh? :) Any magic you could do regarding this issue? ;) heheh I kid... I kid.

So if it's an issue of being blocked by the server, I guess there might be a work-around possible, like spoofing the ID of XBMC to make it think it's actually the XBMCbuntu; that way, we get access to the repository! :D

If any dev knows where the identification is stored, I could maybe give it a try... ;)

DiMag commented 12 years ago

The proper place to look for a fix/bypass would be Pulse-Eight, a company which offers a PVR-enhanced (as they claim) flavor of OpenELEC for free. Their OpenELEC has open access to the main (XBMC.org) repository, so one could theoretically run the relevant code through a diff tool, pick up the cripple, remove it, and build a new squashfs image sans cripple. Whether this would be worth the trouble is another matter; a new beta-version of either OpenELEC or OpenELEC_PulseOS pops up every month. What puzzles, and irritates, me is that one developer team has crippled the product in such a way while the other hasn't (neither, for that matter, have the developers of the XBMC monthlies, dailies and nightlies restricted access to the central repository), and no-one has bothered to explain why. I have been led to believe that having a central repository is a good thing in terms of centralization, control of code quality and security. If so, OpenELEC's vote of distrust to the value of the repository opens an issue of central import to all users of XBMC.

taoizt commented 11 years ago

Ah finally some more guys who have the same problem. I've also been struggling with since there are plenty of addons like the youtube or subtitles plugin that are in the XBMC repo. Thanks for mentioning it, and now let's hope there comes a sensible solution because i'm on the verge of switching over to XBMCBuntu to see if i have less problems with it.

DiMag commented 11 years ago

@taoizt: No need to switch over to XBMCbuntu. Try OpenELEC/Pulse Eight, which is (according to my experience) as good as OpenELEC pure except it consumes slightly more memory (due to its adding this company'w PVR code to the builds). Most significantly, OpenELEC/Pulse Eight grants full read/copy/download access to the official repository, and this despite the fact that it, too, is a beta-testing build like OpenELEC pure. An additional option is to keep OpenELEC pure but hand-copy to /storage/.xbmc/addons each and every addon yoy need (decompressed) plus all pertinent customizations to userdata/addon_data. You achieve the same result as if you installed per repository, except that sometimes execution fails because of unmet dependencies. This problem can be addressed by hand-copying the dependencies, too, but this is obviously a messy process and at any rate you don't get the benefit of automatic updates which comes with access to the official repository. OpenELEC's decision to restrict access to the official repository defies a simple user's logic.

DiMag commented 11 years ago

[EMPTY REPOSITORY PROBLEM SOLVED]

The reason XBMC.org repository (and, incidentally, many other repositories) is empty is not due to a willful restriction on the part of the devs --my sincere apologies for holding that view (which, however, has been put forward in the openelec forum without the moderators bothering to correct it). Rather, it has to do with a bug in OpenELEC's DNS service. Apparently OpenELEC cannot access the official repository (and many (all?) other repositories as well) unless it is configured with 1) a static IP 2) a static DNS addresses. This has been pointed out in the forum, and after a check I have verified it to be a correct solution to the problem. Again, apologies.

Without retracting anything from my apology, I should note that a screwed DNS service is a far more serious problem than non-access to a repository, and, moreover, more damaging to the reputation of a Linux-based system than a screwed DVB-T driver or a glitch in the video resolution or whatever else. Consequently its fixing should be assigned top priority, which apparently has not been the case. (The deficiency persists in the recently released OpenELEC 2.0-final.)

It should be also noted that OpenELEC-PulseEight (http://packages.pulse-eight.net/) is free of this bug. Perhaps a user with deeper knowledge of Linux than myself could identify the bin or conf file responsible for the deficiency so that we could either modify the installation package, or replace the relevant files with those lifted from OpenELEC-PulseEight.

tijnemans79 commented 11 years ago

This is fairly strange, as I'm using a mixture of static and dhcp addresses here and all seem to work properly in all situations. So I am convinced that this still points to certain installations/combination/situations only.... Have you tried a blanco installation of OE 2.0?

alexricher commented 11 years ago

Good day gentlemen,

Just to keep you in the loop, I've just upgraded to OpenElec 2.0 Final version and the problem is still there.

On my end, I'm having the default network configuration by OpenElec, which is DHCP with a gateway of my router address and its primary DNS as 127.0.0.1. Works fine accessing the OpenElec repository (or any other for that matter with the plugin that you install to add any repository) but the XMBC official one is still unaccessible. Tried the usual tricks by forcing a refresh but it's still empty.

I'm a bit sad the OpenElec released their final version without even checking into this issue. To me, this isn't a final release if we can't even access the official repository. I will nonetheless give a try to what DiMag suggested by using static DNS and see if it works. Even if it does though, it means there is an issue with OpenElec's implementation regarding their network setup as it should be able to resolve XBMC's repository as it can for any other repo.

I'll keep you posted if it works with a DNS upgrade (or not)

tijnemans79 commented 11 years ago

we probably would have received tons of reports if this was a real issue on 2.0 so still think this happens on rare and specific occasions. the 127.0.0.1 is correct. This is due to connman. Don't look there. connman functions as dnsproxy, hence the 127.0.0.1

what are the settings of your dhcp server? Can you post those here?

or check in the file /var/lib/connman/ethernet_xxxx/settings which settings that it received. (replace xxxxxxx with yours)

lgladdy commented 11 years ago

I feel a need to point out again that the fix for me was something to do with the addons15.db file. After I deleted my .xbmc folder, OpenELEC's xbmc recreated it, and it didn't work. Copying over addons15.db from my mac fixed it.

Does that .db file contain anything relating to DNS?

alpar-t commented 11 years ago

Just build from git, same issue, curl works from cmd line, fails from xbmc, both with dhcp and static

alexricher commented 11 years ago

Good day guys!

Alright, I did play around yesterday with my network config. Turns out from the OpenElec config tools, I was setup as static and not DHCP (and that was probably the case since the first time I've installed OpenElec): IP: 192.168.2.15 Subnet mask: 255.255.255.0 (prefix 24) Gateway: 192.168.2.1 Primary DNS: 127.0.0.1

But with this, it seems for an unknown reason, it wouldn't work accessing the repo, but I could get rss feeds, access the OpenElec repository and scrape content from the web (weird!)

So, I've set my network config as DHCP by pressing "DEL" on all of the field I would see in the OpenElec config tool. Even then, I'd still have data configured because if I went directly into this file: /storage/.xbmc/userdata/addon_data/os.openelec.settings/settings.xml, I'd still see a gateway, prefixlen, dns1 configured there. So, with nano, I've deleted all of the content of those fields and then rebooted.

Once rebooted, I've checked my network status in XBMC and at first, "Internet: Busy", then "Internet: Not connected" or sometimes, "Internet: Connected, but no DNS" and suddenly, it would change to "Internet: Connected".

I'll be honest, I'm not too sure what happening with the network config, seems like it kept changing. But at last, it said "Connected" so I didn't bother anymore.

While I was doing something else, I found another thread where someone mentioned he had to play with the advancedsettings.xml for another issue (http://openelec.tv/forum/69-network/44573-internet-problem-dell-d830#45411) and it's funny because I always had somehow the feeling that when accessing the XBMC Official repository, it would attempt to download and would somehow time out (see threads at the top of this issue where I've output debug info.) So, I'm basically thinking I should give this a try. So, I've modified my advancedsettings.xml by adding this:

`

30 5 5242880 ` I then forced refreshed my XBMC Official Repository and guess what, it worked! The thing I'm not 100% sure (and some people could test it if necessary) is was the issue related to my network config or hte new timeout I've just added in my advancedsettings.xml (or a combination of both?) You guys are free to give it a try and report back. :) Maybe some dev could also shed some lights on this issue?
tijnemans79 commented 11 years ago

You cannot resolve properly to DNS if you use a static IP address, and use Primary DNS: 127.0.0.1 This should have been set to your provider's DNS.

At the moment you configure statically 127.0.0.1 as DNS server, you point to the openelec box itself, which obiously isn't a DNS server. It has to get its queries from a public one. The public DNS'es are updated to connman which functions as DNS proxy. So basically, the system tries to resolve to 127.0.0.1 (hardcoded in /etc/resolv.conf), connman then forwards this request (on behalf of) to the public configured DNS.

At a first glance this issue still smells like one regarding networking (DNS, wireing, bad router, bad NIC, maybe a NIC driver issue etc etc).

alpar-t commented 11 years ago

I have a similar issue. Repo list was not populating. Weather and Rss worked, curl from cmdline worked, so this wasn't a no connectivity issue. I left he pi running and went to bed, the second day in the afternoon ( without doing anything ) the list was there, but downloads of add-ons was failing.

I can't try it out right now, but having red alexrichers post above, I suspect that this is a configuration issue, the timeouts are to aggressive, and I need to set more tolerant ones. My providers DNS is really, really slow, so I am guessing that there is a timeout waiting for it. Either in conman or xbmc. I plan to test with opendns and poke around a bit to confirm this.

alpar-t commented 11 years ago

I changed my dns to opendns, which is much faster than my ISPs DNS, and everything started working. I didn't have this issue with other distros, so it could be that conman times out too soon when talking to upstream dns.

DiMag commented 11 years ago

Today I put to test the thesis that the empty repository problem is due to special hardware/software configurations (incl a faulty NIC driver) and that a clean install of OpenELEC 2.0.0 should fix it, versus the alternative hypothesis that it has to do with dynamic (DHCP-conferred) DNS, versus the second alternative hypothesis that it is all a problem of configuring curl timeouts with deference to the needs of the XBMC repository.

[A] I did a clean install on a spare SD, and the empty repository problem was there as expected. Specifically, it was, as ever, the official XBMC.org repository that is empty. The OpenELEC repository is, and has always been, accessible.

[B] I changed this virgin system from DHCP to DHCP plus a static DNS server. More specifically, I put Google's 8.8.8.8 as (static) DNS2, keeping my ISP's server as (static) DNS1. Now all went OK: not only was the repository not empty, it opened instantly.

[C] All the time I had the empty repository problem, my network was configured to get DHCP from the router, its DNS server address configured (a) either as the ISP's default, or (b) pointing to OpenDNS, or (c) pointing to Google. The problem only disappeared when Google's 8.8.8.8. was configured as static DNS. I did not try to substitute OpenDNS for Google in this setup, but atorok who did had the same success as I did.

[D] I then reverted to pure DHCP (router distributes IP, DNS server, etc) and tried alexricher's suggestion to tweak curl timings per advancedsettings.xml. I used exactly the code he exerpted in his comment, and guess what, the XBMC.org repository was again accessible.

In conclusion, and as far as I am concerned --location: Athens, Greece--, but also corroborated by the experience of the other participants in this thread,---

1) The willful restriction hypothesis is falsified and must be buried. Please delete all pertinent threads in the forum.

2) Nor can the faulty NIC driver hypothesis and the faulty DNS hypothesis stand. Were either of them right, all participants of this discussion would have experienced massive connectivity problems. But this is not the case. The only problem we experienced was an empty repository.

3) All forensic evidence points to the culprit being a failure to address the XBMC.org repository's specific connectivity needs. Whether this also implies a faulty DNS implementation I am in no position to tell, but it is a question worth asking.

4) There is clear evidence that the fix is:

(a) Either static DNS pointing to Google or OpenDNS. (Whether to local ISP, no-one has so far tried, and it would indeed produce results not comparable across several countries.) It is only the static DNS that matters. Whether the IP itself is also static or DHCP-conferred appears to be immaterial.

(b) Or tweaking the curl timings per advancedsettings.xml using the code in alexricher's comment. In the comment there is a warning about this tweak adversely affecting memory usage, so does this suggest that fix (a) is preferable?

4) There is also clear evidence that the empty repository problem does not exist in Pulse-Eight's OpenELEC build. Why this is so, no-one seems to know. (For that matter, no-one seems to have measured which of the two builds performs faster/more reliably.)

Another of the many things I do not understand in this context is why the reason of this problem does not show in the debug log.

tijnemans79 commented 11 years ago

First of all, thanks for writing it all down but tell me: What are the settings of the dhcp server of your router? Besides, to exactly roll out any of the issues you should have done a few more steps:

If it already works on the first step, then we should take some more steps:

I don''t say that this could be some connman or python or whatever related issue. I have been installing a lot of virgin boxes, and with all of them they instantly started to download all updated addons from the xbmc repo at first boot (hence getting a dhcp address).

It''s quite hard to start digging on something that we''re not experiencing on most test systems and which has been just reported by just ~5 people.

DiMag commented 11 years ago

@cowbalt:

1. I have configured Google DNS (A) first both on the OE statically and as specific tweak on the router, (B) then only on the OE box (static IP, static DNS=Google. In both cases I had a working repository. (C) Then I tried the IP from the router/static DNS=Google on the OE box configuration. It too worked. Before that, and for a long long time, I had my router set to query OpenDNS, and later Google, for DNS service. This didn/t work, never did. On this factual basis I concluded that the fix is a static DNS=Google on the box and that a static IP is not required. To be honest it is a situation with which I can live. I don't see any problem in my media boxes asking Google for DNS services while the rest of the network asks the router (which in turn asks Google or OpenDNS or whatever). What I could not live with is having an OE box (or, more problematically, several of them) mess up with the central administration of IPs and other services (such as NBT, etc).

2. My network is configured on the router as 192.168.100/26, the router's IP is 1, and the scope for reserved IPs is up to 15 (it is a network with more infrastructure devices than hosts). There is no doubt the OE box is correctly assigned its IP address, otherwise I could not winscp into it, and it would not connect to the Internet either.

3. As to whether it really gets its DNS server information from the router correctly, you must help me. How can I debug this piece of information? Not knowing what to do I winscp'ed into the OE box, opened winscp's console, typed 'nslookup www.xbmc.org', and I got a fast response. But when I typed 'nslookup www.google.com', and then 'nslookup www.google.gr', everything broke down! The console closed, then the connection terminated. It did not just take long time to complete then timed out, it completely broke down! Then again, 'traceroute www.google.com' returned nothing unexpected. Please advise.

alexricher commented 11 years ago

Thanks for the update DiMag. :+1: I'm glad we're getting closer to fix this issue. It's true only a handful of people had the issue, although I'm sure a lot of the users were not as persistent as some of us in this thread and simply gave up. If I wouldn't use OpenElec on a daily basis, I'd probably just would have give up as anybody else. But being a bit techy and wanting to give back to the OpenElec team for their massive great work on this piece of software, I didn't want to give up. I guess it's somehow really paying off! :)

DiMag commented 11 years ago

In this post I have time and again stated that OpenELEC-PulseOS doesn't suffer from the empty repository(ies) problem afflicting OpenELEC pure. Well guess what, it does. The other day I set up OpenELEC-PulseOS v1.99.12 on a spare SD card and there I had it again: A virgin distribution pointing to two repositories, OpenELEC accessible and XBMC.org empty, the fix being to set static DNS (in my case pointing to Google). I have not tried the alternative fix of tweaking curl timeouts per advancedsettings.xml, but alexricher has reported that it too does works and there is no reason to doubt him.

The more I reflect on the empty repositories problem the more I come to the conclusion that it has to do with inappropriate timeouts. This hypothesis is supported by my experience (so far discarded as mere oddity, now viewed in a new light) of sporadic failures of video plugins and/or the communications server to start, and of erratic behavior of video streaming plugins in the sense that even though they seem to work sometimes they fail to open streams or just time out.

It may be that different addons require different timeout settings, a uniform work-for-all timeouts being a bad idea. Perhaps we need a buil-in network debugger to track down different tiemout requirements? But, can timeouts be set on a per-addon basis?

The problem may be quite serious, and it may afflict all branches of XBMC not just OpenELEC.

DiMag commented 11 years ago

Last weekend I installed PulseEight's edition of OpenELEC (OpenELEC_PulseOS), which by now has reached version 2.0.0 (final), on a 2GB SD card. Immediately after boot it started auto-updating the addons from the XBMC.org repository; a manual check revealed the repository to be accessible (as it should be, since it managed to auto-update addons).

So it appears the empty repository problem is, as far as OpenELEC_PulseOS is concerned, at last cured. How did the PulseEight guys pull it off?

Well, they have pre-set their final build to static DNS2 to 8.8.4.4 = Google's public DNS server. (The IP is dynamic/DHCP rendered, and so is default gateway. Just DNS2 is sratic)

I am inclined to declare the issue closed - but not archived.

jenkins101 commented 11 years ago

could be related to #1770

sraue commented 11 years ago

closing for now, if the issue still exist please open a new report, thanks