What steps will reproduce the problem? 1. Get a change log which includes many many changes of files in a directory named foo and bar. The changes to foo need to happen in the middle of a time span which changes to bar have been done, but there are still many more changes to bar to come later. 2. Set the --file-filter to exclude directory foo. 3. Make sure that the auto-skip feature is turned on and set to a timeperiod that would make this issue noticeable, half a second should be good.

What is the expected output? What do you see instead? The rendered animations should only include bar's timeline and there might be a second (or half second, based on my recomendation above) where nothing happens in the middle of bar's timeline where foo was updated, but did NOT show.

What I see is bar's timeline and then a long gap of nothing appearing on the animation during which many changes has happened to foo's timeline.

What version of the product are you using? On what operating system? f1e6c66e9248d388cc946925236ac31252b3456e commit on git repo. Linux x86-64.

Please provide any additional information below. It seems like even though the file filter causes any changes related not to draw it still processes the lines information and updates the state to the rest of the rendering engine making it think there are changes which makes autoskip break. The file filter should make the log line completely ignored and not parsed at all except for the matching that should fix this issue and any other unintended side affects.

The log format I'm using in this instance is cvs2cl, but I cannot share it because it contains logs for a private product.

Hi.

What is the volume of 'commits' (ie groups of files in the cvs2cl log rather than individual files) that you have filtered? I think that may be the issue.

Gource process only one commit per tick eg approx 60 commits a second (arguably it shouldn't have that limitation ... but that is there currently).

I don't think the ignored files are messing with auto-skip-seconds directly as they are discarded before they are distributed to Users (they still get parsed, there's no way around that though - unless you used grep before hand :) ).

Skipping is triggered by the users being idle for more than the specified amount of time.

Cheers

Andrew

The volume is largish.

I added a snippet of the cvs2pl custom log file which will show this issue. Run it with C:\gource>gource -800x400 -a 1 -s .25 --time-scale 4 --camera-mode track --file-filter bugged --hide filenames,mouse,bloom cvs2pl.xml.scrubbed You'll see the issue fairly quickly at date April 13, 2011. You will see everything seeming to stop with the time ticking by very slowly. If you remove the --file-filter option this area will still run slow but show the updates to the bugged directory.

I wrote a program to remove(hopefully) all identifying information. That's why it took me so long to respond. Here's the link in case it might be useful to someone else submitting bugs. https://github.com/beeblebrox/cvs2plscrubber

Hi.

Thanks for log, was able to see the issue. Lots of commits was indeed the problem!

I think I have now fixed this:

https://github.com/acaudwell/Gource/commit/a0455010773738dc170d78578f66f86e788d969a

(On the coredump branch, which will probably be in the next release)

Cheers

Andrew