Skip to main content

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

CO7 wont start on MacOS (SOLVED)

Comments

9 comments

  • NN13758
    Solved the problem - guess letting out some steam helps.


    Sorry to say guys, this is just poor coding on your part. The issue was my firewall. I can certainly understand why you want your software to be registered and all that - it's your bread on the table.
    But, if a Firewall blocks the application it should never hang in the system, with no error message whatsoever and no indication on where to go.

    Even the logs were empty and useless, except for this little tidbit:
    "(ERROR) Could not create external processor" which yielded one result on google.... some guy had problems on 4.5.2. and his firewall.

    So I checked my firewall, and yes - outgoing requests from C1 and ImgCoreProcess were being blocked.... after adding those to my whitelist, I was able to start the program.
    (though, I was not able to register the software - unless I totally disabled my firewall! That should not be necessary!).

    You guys really need to log some more and provide feedback to the enduser- this has cost me far too many hours for such a small and needless issue.... really. ☹️
    0
  • Paul Steunebrink
    Can you share with us what firewall you were using? It is the first time I see this on Mac, I have seen this issue more often on windows.

    Capture One only needs TCP port 80 (same as HTTP browsing) to activate and check activation. In addition it uses port 2525 for crash reporter (but only if it crashes). If your firewall prevents these kind of connections, Capture One will run without problems.

    The issue might be that your firewall prevents Capture One to connect to a local port or the local loop address (the computer itself through the network stack). The is not bad programming on Phase One's side, but on the firewall's side, IMHO, but that's open for debate. 😉

    Thanks for sharing and I am happy you're back on track again.
    0
  • Paul Steunebrink
    Found the link you were referring to:
    viewtopic.php?p=25998#p25998

    Indeed the local loop address (IP 127.0.0.1) issue.
    0
  • NN13758
    Hi Paul,


    The firewall is blocking all outbound requests, except those I manually whitelist. Firewall is TCPBlock btw.

    The "bad programming" part was not the fact that it interfered with the firewall (or, as it may be, the other way around) - that's ok, that is the purpose of the firewall 😉
    The "bad programming" was in regards to the fact that there was no error or log messages from C1 - it simply stopped responding with no indication of what was wrong. A simple timeout and a popup saying "Can't contact C1 registration server" and a "quit" button to exit gracefully, should take roughly 4 minutes to implement and is really standard coding practice 😉
    0
  • Paul Steunebrink
    The error handling in CO 7 could be more smooth, indeed. 😁
    0
  • H. Cremers
    If you've ever worked with enterprise grade software (think SAP etc.), you may find that CO7 isn't that bad at all. It could be (quite a bit) better though, i agree.
    0
  • NN13758
    I develop enterprise grade software for a living - and I am still unhappy with CO7 😉
    0
  • H. Cremers
    Well, i don't actually develop it, but i'm architecting solutions in the ERP area. I figure you're developing better error handling and messages then 😉

    I know i have spent many hour trying to figure out what the dang error could be if we just received a non-descriptive error code/text, or just nothing at all.

    That was what i was pertaining to in regards to CO7.

    I concur with the others here that error handling and notification should be much better, but it so seems software vendors focus on the functionality first. And they don't seem to consider good user information functionality.
    0
  • SFA
    [quote="HCS" wrote:
    Well, i don't actually develop it, but i'm architecting solutions in the ERP area. I figure you're developing better error handling and messages then 😉

    I know i have spent many hour trying to figure out what the dang error could be if we just received a non-descriptive error code/text, or just nothing at all.

    That was what i was pertaining to in regards to CO7.

    I concur with the others here that error handling and notification should be much better, but it so seems software vendors focus on the functionality first. And they don't seem to consider good user information functionality.


    I would guess that developers cannot always guess what things might go wrong well enough to provide specific errors rather than generic or, for some type of error, any message at all. Even predicting that an error might occur could be a challenge.

    Moreover I suspect that, in most cases, only people who make a living from dealing with software development would care about an error message. Others would just be upset that the system they were using "crashed" (for whatever reason) and error messages would be of little interest to them except as a further example of how useless the software must be if it can report an error in detail rather than prevent it happening .... 😉

    Grant Perkins
    0

Post is closed for comments.