Discussion for Troubleshooting Guide wiki page

Rosie Perera said:

Can't find in my Library such-and-such resource that I know I should have (some possible solutions: restart Logos if you just downloaded it, check Hidden Resources in case you accidentally hid it, do "update resources", try scan [explain details], failing all else: contact Customer Service to have them unlock it for you)

... or arrange for you to download the file.  I had one resource that was showing up on one computer but not another.  The missing file would not download with the "update resources" command.  The solution was for the tech to find the required file on their own computer, arrange for me to download it, and then do a "scan".  I still keep a copy of that file so I can reinstall it on newer computers that need to have LOGOS installed.  I think the resource was the "Oxford Bible Commentary"  but it has been long enough now, that it might be something else.

Rosie Perera said:

Can't find in my Library such-and-such resource that I know I should have (some possible solutions: restart Logos if you just downloaded it, check Hidden Resources in case you accidentally hid it, do "update resources", try scan [explain details], failing all else: contact Customer Service to have them unlock it for you)
Logos won't start at all
Different number of resources on one machine from another
Sync doesn't work (are they offline?) or creates multiple note flags (known bug; there's a workaround)
Logos is really slow
No search results at all (finish indexing? could be something else -- there's a recent thread trying to help someone with this where they've definitely finished indexing)
Etc. Other ideas?

Just to be obvious

• Logos crashes on a search/other specific action
• Indexer crashes

steve clark said:

This thread is for MVP's to discuss the possibility of creating a new wiki page for a Troubleshooting Guide. This was requested by Mark Barnes (see this post).

Thanks, Steve. Also, I'm glad Floyd has contributed, too. I'm sure we're all happy for any forum user who's experienced in Logos 4 Windows trouble-shooting to join in, not just MVPs.

It's nearly midnight here, so I don't have much to contribute at the moment, other than to say I had also envisiaged that the guide might include some standard solutions to hard-to-diagnose errors (e.g. .NET crashes, etc.). Even though 'ordinary' users might not be able to diagnose the errors from the Logos logs or Event logs, at least it would provide us with a page where we could find all such solutions, instead of trying to find the last forum post we mentioned it on Google. Here's one recent example: http://community.logos.com/forums/p/30141/223127.aspx#223127

Thanks for that start, Mark. Hopefully I'll have more time to help out with it when I get back from a trip (I'm going to be away and not checking in on the forum much at all from March 3-15).

The following page of error codes is old (from 4.0b) and hasn't been updated in a while, but it might be helpful info to include these in the troubleshooting guide (or pages that it links to) under the section "I have the Logos crash log and I know the specific error code"

http://wiki.logos.com/Logos_4.0b_Crashes

Even though many of these errors haven't been seen in a while, they are generic enough that the solutions for them ought to work if the condition ever arises again (e.g., Error ID 2297 = corrupt index --> rebuild index).

I think we ought to scour the forums for crash reports with error codes in them and try to build up a more complete list of what all the common error codes are (with help from Logos devs if they'd be willing to help out with some internal documentation), under what conditions they might arise, and what to do to work around them (while also reporting them to Logos since a fix is probably needed in their code; users really never should see these crashes).

Mark Barnes said:

outside the beta forum, there were surprisingly few crashes

Shouldn't we try to make this complete enough to help beta users troubleshoot things too? As long as they promise to not just find a workaround and then sweep the bug under the carpet. They still need to report a reproducible (if possible) case to Logos so they can fix it. But in the meantime, so they can continue to get some work done, a workaround might be helpful.

OK, I agree with you as to point (a), up to a point. But here are some reasons why I think we should include the errors beta users run across (perhaps separated out into a different section, though point 2 below will show why I think that might be a difficult task):

1) It would take a bit of the load off of us if a known error were documented here once it has been encountered; then further people encountering it could look up the error message here instead of posting a question to the forum

2) Yes most beta users are probably tech-savvy enough to Google the forums for answers, but many of them are lazy enough that they'd rather post a question and make us do the Googling work for them.

3) It's not immediately clear from an error code that it is something that could only happen in a beta release. The stable releases are certainly far more stable and thus it's far more unlikely that anyone would encounter one of these. But all the more reason for having a place where people can look them up in the rare (an unlikely) situation that they ever do come up. Suppose the bug where the index could end up being corrupted got fixed long ago, but the error message still exists in the code, and Logos will crash and put out that error code if, God forbid, the index should ever become corrupted again. There might be some subtle hard-to-reproduce bug that gets introduced (and ships) in Logos 4.3c where someone doesn't stumble upon it until after the stable release has been out for a while. Having that error message documented would be useful in such a case.

4) As for your concern that having all these codes documented in one place might give the impression that Logos is very buggy, many other software companies do this on their websites. Microsoft has tons of such lists, for many of their different software products (e.g., http://support.microsoft.com/kb/310123; http://support.microsoft.com/kb/193625; http://support.microsoft.com/kb/904336; etc.). We can get some ideas on how to organize this troubleshooting page from there. For example, they number all the articles in their Knowledge Base. We might not have enough to warrant doing that, but it might be a useful idea. We could probably get away with 3 digits rather than the 6 that Microsoft uses. See, for example, the References section of http://support.microsoft.com/kb/229683. It gives a nice brief summary of what each error is, and a link to the Knowledge Base article which deals with how to work around that problem.

5) As for your concern that this page might confuse non-beta users if it had too many error codes listed in it, chances are that most non-beta users will probably post to the forums first anyway. What this error list / knowledge base would do would be to give us a very quick way to look up an error code and the solution that has been found for it, and post a link to that solution page on the forum. So the non-beta user probably wouldn't even be seeing the long list of possible error codes.

Anyway, I'd rather have Logos be perceived as buggy with solutions than be perceived as buggy with no (easy) solutions to those bugs. The only people who will encounter this list at all anyway are going to be people who have already run into a bug so they already probably think of Logos as buggy.

The only reason you didn't list which I would say we shouldn't list the beta-only bugs, is it would take more of our time to do that list, and the small payoff might not be worth it.

MJ. Smith said:

Rosie Perera said:

Shouldn't we try to make this complete enough to help beta users troubleshoot things too?

Betas change so rapidly that I would be concerned about the maintenance involved - old information can be worse than no information.

The point is, the error messages are generic things usually. They mean stuff like "your index is corrupted" and in many cases there is a known workaround that will fix it for now (e.g., "rebuild index"). It doesn't matter how you got the error message to come up. It might be a bug that is here now, gone tomorrow (as betas are in flux). The error shouldn't have come up at all, but given that it did, and Logos might take a while to fix the problem that caused it in this particular instance, it is helpful to be able to look up a workaround.

I would agree that we should not put in documentation for error messages that seem so specific to a particular release that they wouldn't be relevant ever in the future. But as a programmer, I know that many internal error messages can be triggered by multiple different paths in the code, when something gets broken that shouldn't have.

Dave Hooton said:

I removed the empty sections on Logos 4 is missing some resources (could be documented separately as common to Mac and Windows) and Logos 4 is very slow (documented on main page).

Shouldn't we remove the Troubleshooting section from the front page, merge all that stuff into the troubleshooting guide, and replace that section on the home page with a link to the guide? Otherwise there's likely to end up being more redundancy again and confusion among users about where to look for things.

steve clark said:

Dave Hooton said:

Removed Troubleshooting + unnecessary/duplicate links from VTOC (corrected links from TOC).

i disagree with the change on the VTOC. Its goal was to contain all links to all wiki pages (with few exceptions). You have removed a whole table of links.

EDIT: now those links are orphaned with no easy way to find them.

The good thing about wiki history is you can easily get back what was deleted. I suggest putting it back to the way it was.

The bad thing about redundancy in pages like that is that people (like me) who forget the VTOC exists will forget to add links to it when we create new pages. I disagree that there needs to be one single page that has links to pretty much every page on the wiki. It becomes unwieldy and a maintenance hassle.