Re: [Bug-gnubg] Analysis changing the game record and producing garbage

[Neil Robins]

I had autosave enabled when I analysed this. I can't yet say whether 
disabling autosave will solve the problem because reanalysing with it on 
doesn't reproduce this error exactly. I suggest trying to reproduce this 
sort of thing by playing a match with lots of moves that are deliberately 
bad set to autosave as often as possible.
This sgf file comes from a match where the fourth move made was 8/2 6/2* not 
the 24/18 22/18 GNU has changed it to, and clearly the rest of the game only 
makes sense after what was actually played.

----- Original Message ----- 
From: "Christian Anthon" <address@hidden>
To: "Neil Robins" <address@hidden>
Cc: "Michael Petch" <address@hidden>; <address@hidden>
Sent: Tuesday, October 06, 2009 11:18 AM
Subject: Re: [Bug-gnubg] Analysis changing the game record and producing 
garbage


> Neil Robins wrote:
> > I don't feel these issues are related. I think I have seen this using
> > CMARK with earlier builds but was never that bothered by it because a
> > quick reanalysis put the correct move back in red. My problem, I am
> > guessing, is related to autosave kicking in, and GNU somehow losing
> > track of what the actual move made in the match was. Reanalysing the
> > match from the original mat file does not necessarily reproduce the 
> > error.
>
> It is possible. Have you enabled autosaving? Does the problem disappear
> if you disable it?
>
> Christian.

nonsense.sgf
Description: Binary data