Any Good IT Guys Out There?

Does anyone know if it’s possible to create a separate cache for SiSi so I don’t keep getting this?


2498 :x: Errors :x: in an hour seems a bit high…

retrying traceback log, got an error in LogException
Traceback (most recent call last):
File "C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\packages\bluepy_init
.py", line 36, in CallWrapper
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\packages\uthread2\bluepyimpl.py”, line 31, in inner
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\packages\xmpp\xmppConnection.py”, line 504, in _reconnectToXmppServer
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\packages\xmpp\xmppConnection.py”, line 498, in _connectToXmppServer
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\packages\xmppchatclient\xmppchatsvc.py”, line 245, in GetAuthenticationToken
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\carbon\common\script\net\ServiceCallGPCS.py”, line 752, in callable
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\carbon\common\script\net\machobase.py”, line 134, in ThrottledCall
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\carbon\common\script\net\ServiceCallGPCS.py”, line 743, in doCall
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\carbon\common\script\net\ServiceCallGPCS.py”, line 289, in RemoteServiceCallWithoutTheStars
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\carbon\common\script\net\ObjectCallGPCS.py”, line 230, in CallDown
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\carbon\common\script\net\ExceptionMappingGPCS.py”, line 80, in CallDown
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\carbon\common\script\net\ExceptionMappingGPCS.py”, line 57, in _ProcessCall
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\carbon\common\script\net\ExceptionWrapperGPCS.py”, line 118, in CallDown
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\carbon\common\script\net\machoNet.py”, line 4082, in _BlockingCall
File “”, line 2, in _GetTransports
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\packages\ccpProfile\blueTaskletImplementation.py”, line 40, in Wrapper
File “C:\BuildAgent\work\d20533721e48eb3d\eve\staging\2019-INCUBUS\carbon\common\script\net\machoNet.py”, line 4240, in _GetTransports
destAddress = Address::Any(service=“chatAuthenticationService”,callID=“None”)
self =
srcTransport = None
UserError: User error, msg=GPSTransportClosed, dict={‘what’: ‘The transport has not yet been connected, or authentication was not successful.’}

Yes, I file a bug report.

In before lock.

Thank you Captain Obvious. I have and they basically said that it doesn’t really look like a problem to them. That’s why I’m here. Help if you are willing and able or STFU! :boom:

1 Like

It clearly says “User Error”, which means it must be your fault.

:3

Seriously though it does not actually look like there’s an issue with your cache. I don’t even see how you believe that having a seperate cache directory (it already is seperate from the main one) is going to help. All of that text is just a traceback eventually leading to the cause:

destAddress = Address::Any(service=“chatAuthenticationService”,callID=“None”)

Could you explain how you come to that conclusion? The error message rather indicates a connection problem. MachoNet is something something related to gathering data from the server, though in this case it looks like a problem with the chatserver?

What I’m really wondering about, though, is why this bothers you.

Anyhow, you have to give more information,
otherwise there’s just no way of helping you.

2 Likes

Well, when I only have TQ running without a shared cache I get zero errors.

There may have been a temporary “connection issue” but that’s not the norm.

The errors would be there whether they bothered me or not. When would you get concerned? Waiting for my client to crash seems a bit late.

It won’t crash if it isn’t already crashing. If the game is running fine then the python exception is caught and apparently dealt with appropriately. For some reason you’re mistaking this as a problem, which seems a tad paranoid to me.

Here’s why you don’t need to worry about it and how I get to that conclusion:

  • The game is running
  • CCP says it’s not a problem (found you saying that in another post somewhere)
  • The python exception is being caught and apparently appropriately dealt with

They’re telling you it’s fine, the game is running and when a python exception occurs and it doesn’t crash then that means it’s being dealt with appropritely to make sure everything continues smoothly.

You need to get some distance, to gain a better view, mate.

Calling a remote service without stars? What a preposterous idea!

2 Likes

LOL. The errors are increasing and that’s not good. Don’t be one of those people that settle for “just getting by”. Expect more, pay less. :stuck_out_tongue_winking_eye:

I’ve actually really tried looking into this.

I even found an EVE ONLINE Emulation Server on github, dating back to 2013, by googling for MachoNet in the hopes I can find out more. MachoNet is network related and appears to be some Wrapper for gathering information about local services in a system.

The error message indicates a problem with the chat server. All I can do is guessing, basically. For trouble shooting purposes, make a copy of the TQ folder, rename the Sisi folder, name the copy to “sisi” and see what happens.

Alternatively I’d just rename the folder to see what happens after that. Basically, I’d try all kinds of non-destructive things to find a way to influence the behaviour. I’m saying this, because that’s what I would do just to figure out what happens. It wouldn’t break anything.

I’d also look into IOError 22, “Invalid Argument”. Is the launcher being run with an argument? The “executable” part is cut off, so I can’t tell.

I’d probably also try recreating the directory structure and files mentioned in the error message, even if they were just empty files, just to see what happens.

I’m sorry I can’t help you any more than that. Usually I’m just trying to be as non-destructively creative as possible to figure out more about what’s going on … which reminds me of a former friend (the former is unrelated to this incident) of mine who gave me admin access to his webserver declaring that I can’t possible break anything and he has backups anyway.

It took him three whole days to fix what I’ve caused, but he really asked for it.

*snickers* xD

1 Like

I really appreciate your time and I will go down the list and try your solutions. I’ve seen this off and on for years. The shared cache permissions always gives me a headache. Also, what I perceive to be lag on the server might be my client trying to work out issues. Thanks!

1 Like

QFT :laughing:

1 Like

First thing: why EVE is referring to this patch: C:\BuildAgent? I don’t have this folder even with game running.
If you can find it (can be hidden) and show it content?

Second: Run game with log lite on for some time and save log to file and also upload it. Since what you shown so far don’t give much informations.

I can give you my discord name or whatever if you want more private way to exchange files/informations.

1 Like

The correct name is “discarded” so the issue of a child thread does not crash the whole system.

This means that the program ignores the issue instead of addressing it, mainly because the devs did not consider this issue could happen, or that they can’t do anything in that case.
So since the error is still there, it will happen again. The program warns you there is an issue it can’t deal with.

This can lead to, and hide, later issues, some of them being potentially more dangerous than crashing the program (eg data corruption which won’t be fixed later when the issue is fixed and may be invisible to the user and the devs).

So no, just because it’s caught, and logged, does not necessarily mean it’s handled correctly. In his case data corruption should not be too much of an issue, since it should be store on the eve servers and thus could be fetched later.

what is shown is that the connection to the server to export your achievement fails as it does not know how to set the “buff” prameter in the object “LogChannelStream”, which likely means there is an issue from the program (eg version difference between saved and new one).
I recommend clearing the sisi cache, and if it still fails, deleting all local files related to sisi, so that you are sure to fetch the most recent programs.

1 Like

Awesome! Can you just send me an email in game? Thanks!

↑ This was my concern. Do you think removing ALL eve files and starting from scratch is necessary? I don’t mind re-downloading it if you think it’ll fix the problem. Thanks for your help!

I’m afraid I can’t tell what exactly leads to this error.
It seems to me like a incompatibility between some of your libs and/or data, if this is the case it looks like a mismatch in some of you cached network libs and the settings they are used with. I don’t know if clearing the cache would have any effect, but it should be worth trying a fresh install just to check if this is related to your environment, or to eg remains of old settings. Maybe you downloaded and used sisi at a time where the achievement lib was not finalized, therefore leaving unknown settings in your config files.

This may be totally not it though. I had this kind of issues with serialization of data whose format was modified, but here the “buff” attribute looks more like a parameter to use on the network layer (the buffer to transmit, could have been renamed)

1 Like

Please have in mind that this file can be +7GB large.

What does “\SharedCache” imply on a fresh install? I had assumed up to this point that it was shared between servers.

It’s a folder with all client assets.

It is in main EVE folder. You can find it (or paste it to) “C:\EVE” if you instaled launcher in default path/location on your hard drive.