Strange behaviour

edited November -1 in General Discussion

I have two PCs sitting next to each other.  Both are running windows xp sp3 and both have "suffered" from having a lot of software loaded and unloaded over the years (my day job as a test engineer means this is an on-going process).  Both have had openLP v1.2.x installed for "production", and both v.1.9.3, and more recently v1.9.4 for testing.  V.1.2.8 is rock solid on both (good thing as they get used in Church as fall back machines).  The laptop has only had 1.9.3 on for a short time (the firewall griping and the need to be on site with it forced its early removal), and 1.9.4 only an hour or so; this PC appears to be "behaving OK".

However the desktop is really being a very naughty boy, in that it appears to have some data "hangining around", despite unistalling v.1.9.4 three times today, with repboots, registry purges and disk cleaning in between it continues to want to look for a non-existant user directory.  This PC was the one on which I found this problem some moths ago - at the time this only affected the import of .csv Bibles, but now its just about everything.

The questions are-  Where should I look to find the errant data?  Once found how do I get rid of it? (I'm guessing that the latter will be easier than the former...)

As one can imagine this is rather frustrating.....


  • edited January 2011

    This "errant" user directory is not an error, it was the directory the Windows build was built in. You won't find it on your computer, and it has nothing to do with the error at hand.

  • edited January 2011

    I realise that the directory isn't on my PC, but what I'm asking is how to sort the PC so that when I do an import something doesn't point to the non-existant directory.

    Thus far - three removals using the normal windows uninstaller, each followed by a reboot just to make sure.  Second and third followed by registry trawls to remove all occurances of openLP v1.9.x, again followed by reboots.  The last one was followed by an extended session of disc cleaning to reomve all the obvious files.  again folowed by a reboot before re-installation.

    Its frustrating to have a PC that just won't forget a path that it should forget...

  • edited January 2011


    Please remember that 1.9.4 is still an "Alpha" release. This means it is unstable and unfinished. We still have Beta and Release Candidate releases to go before a Final, hopefully stable release.

    Whilst we appreciate you testing this release and bringing problems to our attention, we also hope you understand that you should be expecting problems, and we're not suddenly going to stop in our tracks and succumb to your demands! Also because it is an alpha release, then it may cause you problems, and you need to expect that files may not be where you expect etc.

    If you want a stable release you need to stick to the 1.2 series.

    However back to the topic, as Raoul has said the software has never looked for or added a "raoul" folder to YOUR computer. This folder only ever existed on the machine that created the exe file. Because of the platform we are using, and to avoid the need for the end user to have to install lots of different software, we have to package up openlp in a certain way. As part of this process it has to assume a certain folder path, and so uses that of the process creating the exe.

    If you see this path mentioned, just ignore it.


  • edited January 2011

    A couple of things.

    First is I know I'm working with alpha software, so expect problems, I would expect to be asked questions about the exact sequence of operations, and so on.

    I know that the folder only ever existed on Raoul's machine, and that's where the problem lies, for some strange reason installations on this particular PC are stuck with THINKING that the folder should be there.  Just so you can see what the problem is, here are the first few lines from one of yesterday's trace reports:

    **OpenLP Bug Report**
    Version: 1.9.4

    --- Exception Traceback ---
    Traceback (most recent call last):
    File "C:\Documents and Settings\raoul\My Documents\My Projects\openlp\trunk\build\pyi.win32\OpenLP\outPYZ1.pyz/openlp.plugins.bibles.forms.bibleimportform", line 285, in onCurrentIdChanged
    File "C:\Documents and Settings\raoul\My Documents\My Projects\openlp\trunk\build\pyi.win32\OpenLP\outPYZ1.pyz/openlp.plugins.bibles.forms.bibleimportform", line 514, in performImport
    File "C:\Documents and Settings\raoul\My Documents\My Projects\openlp\trunk\build\pyi.win32\OpenLP\outPYZ1.pyz/openlp.plugins.bibles.lib.manager", line 197, in import_bible


    I was attempting to import a bible, one that I'd confirmed would import into V1.2.8 so was fairly certain I was working with a working test data set.  I selected the "books" and "verses" files, entered the version and copywrite data and "instantly" on starting the import got the error message.

    I reported a similar error some time ago against v1.9.3.  I believe there something "hanging" on my PC from that bug, and if so, where should I look to clean it out so testing of 1.9.4 can continue.

    I should add, that once this path has appeared the import stops, so it is quite probable that this problem (which is peculiar to one of my PCs) is actually hidding another bug by prevetning the correct error logging taking place.

  • JTJT
    edited January 2011

    Hi Bob,

    Firstly, as has been said above this is expected and not incorrect behaviour.

    Secondly it is not looking for items in an incorrect directory - you would get file not found errors if it was.  There is nothing to clean, nothing to try and purge.  The stack traces you've posted to the bug tracker are correct in terms of their output to help debug issues.

    Thanks for reporting the errors and please continue to do so but this path listing on windows is not an issue so just ignore it.



  • edited January 2011

    I get it now, the path is where to look in the source on raoul's PC, whcih of course is not the same for my pc, or indeed anyone else's pc.

Sign In or Register to comment.