Problem Trying To Access Examples, from within xTIMEcomposer

[dahoma]

I perform a fresh reinstall but nothing. Still without connect to xmos and ask about my login

Although I have found out something interesting.

If I run xtime composer from C:\Program Files (x86)\XMOS\xTIMEcomposer\Community_14.3.3\xtimecomposer_bin, before starting the xtime environment appear the following message. Later, the interface is open and the program asks me now about my login.


https://imgur.com/a/8ZSKrJp

[dahoma]

It is a normal raw Linux, where the network connection is just as normal, especially given that the first connection attempt succeeds immediately. I guess it has nothing to do with the network. Tested under Java 7 and Java 8. Also, I had never problems with other applications, networking, etc. on this system. So it is not "some rare bug on some Windows versions", unless my Ubuntu is some vicious Windows in disguise :)

As he said it does not seem a bug on windows versions. I try in MAC and the same problem

[markp]

dahoma, uth:

Can your web browser access both the following locations which appeared in your debug output?

https://www.xmos.com/api/get_all_softwa ... e_version=
https://www.xmos.com/api/get_all_board_ ... l?&xde_ver

(Note these URLs seem suspicious - perhaps they were truncated when the debug was uploaded. Perhaps you could upload the entire debug output file. Nonetheless, I put them directly into my browser and valid data was returned)

I wonder if some users have a local firewall blocking issue, a security certificate issue or a proxy issue.
In xTIMEcomposer, under Preferences->General->Network Connections there are fields to provide Proxy server information and to bypass.
However it is not totally clear when these are used/processed by Eclipse because I put some "invalid" entries in here and I could still download new examples.

On the net there seems to be various issues in this area, for example:
https://stackoverflow.com/questions/545 ... onnections

Now I'm not sure why a fresh Linux install solves uth's problem (temporarily). I can only test with Windows at the moment.
I notice on Windows we get a preferences directory with some state recorded in *.prefs after we quit xTIMEcomposer:

c:\Users\%USERNAME%\.eclipse\com.xmos.cdt.ui.product_1.0.0_1295910307_win32_win32_x86\configuration\.settings\*.prefs

Perhaps the equivalent directory on Linux lives under the XMOS dir, given removal of this and re-installation seems to solve the problem. Can you find such a directory under XMOS, rename it, and see if it cures the problem?

[Bootucal]

After the problem was solved for me on both of my computers (in university and at home) my tutor installed Xtimecomposer on his laptop. Setup is the same like my university-computer: Windows 10, Java 8 update 191, same Network. But on his laptop we get the issue again. The debug.log looks like the one of dahoma. Both links in the log are reachable via normal browser. Increasing the connection timeout by x10 doesn´t help. We also tried to connect the laptop to my computers LAN-Port. So they had absolutely the same Network-conditions. Doesn´t work.
Our workaround was:
- open Xtimecomposer preferences on the working pc
- go to xtimecomposer and klick "download all content from..."
- copy C:\Users\username\.xmos\cache to the not connecting laptop.
The laptop is still unable to connect to xmos but the examples and libraries are available.

[Bisonhwk]

Just wanted to chip in and say that I am facing the same problem on Mac. So, it's not limited to Windows.

[bear118]

someone takes it seriously?

[dahoma]

Hello markp, thanks for your answer

Can your web browser access both the following locations which appeared in your debug output?

https://www.xmos.com/api/get_all_softwa ... e_version=
https://www.xmos.com/api/get_all_board_ ... l?&xde_ver

Yes, Both links in the log are reachable via normal browser

I wonder if some users have a local firewall blocking issue, a security certificate issue or a proxy issue.
In xTIMEcomposer, under Preferences->General->Network Connections there are fields to provide Proxy server information and to bypass.
However it is not totally clear when these are used/processed by Eclipse because I put some "invalid" entries in here and I could still download new examples.

On the net there seems to be various issues in this area, for example:
https://stackoverflow.com/questions/545 ... onnections

I am not behind any proxy server, so I think that I do not have to set those entries at network connection for xtimecompose preferences

Now I'm not sure why a fresh Linux install solves uth's problem (temporarily). I can only test with Windows at the moment.
I notice on Windows we get a preferences directory with some state recorded in *.prefs after we quit xTIMEcomposer:

c:\Users\%USERNAME%\.eclipse\com.xmos.cdt.ui.product_1.0.0_1295910307_win32_win32_x86\configuration\.settings\*.prefs

Perhaps the equivalent directory on Linux lives under the XMOS dir, given removal of this and re-installation seems to solve the problem. Can you find such a directory under XMOS, rename it, and see if it cures the problem?

I have removed this prefs files and then reinstalled, but nothing. Although with this step when I run xtimecomposser after reinstalled, it asks me about my login.


I wonder if these connections fail are due to the last release of xtimecomposser. Because everybody here that have this error is curiously joined this forum recently and we are running the program from different platform

[uth]

Now I'm not sure why a fresh Linux install solves uth's problem (temporarily).

It is not a fresh Linux install, but a fresh install of xTIMEcomposer. That said, it is run-of-the-mill Linux with, I suppose, a run-of-the-mill internet connection. After the fresh install, there is "connected", but it does not really works, so it might just be a message with no substance behind it. Then, it is always "connection failed".

What surprises me is that an HTTPS-based authentication is often used just to bypass firewalls and atypical internet connections, as it is one of the most common protocols, thus widely allowed. Yet, here we have "connection to https://... failed" and questions about possible atypical internet configurations.

[bear118]

So far，Is there a final official solution from XMOS?
Thanks.

[bear118]

This issue is usually caused when something is corrupted in the xTIMEcomposer cache.
The solution is to delete the contents of the cache and restart xTIMEcomposer.
The cache directory within Windows is located at
C:\Users\{username}\.xmos\cache\

This method is ineffective.