# Behavior of MTime after it gets reset due to continuous changes or running a long session
**URL:** https://discourse.vtk.org/t/behavior-of-mtime-after-it-gets-reset-due-to-continuous-changes-or-running-a-long-session/847
**Category:** Support
**Created:** [April 26, 2019, 12:44pm UTC](https://discourse.vtk.org/t/behavior-of-mtime-after-it-gets-reset-due-to-continuous-changes-or-running-a-long-session/847 "2019-04-26T12:44:33Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@scbiradar](https://discourse.vtk.org/u/scbiradar)
#### Post date: [April 26, 2019, 12:44pm UTC](https://discourse.vtk.org/t/behavior-of-mtime-after-it-gets-reset-due-to-continuous-changes-or-running-a-long-session/847/1 "2019-04-26T12:44:33Z")
I am using a vtkCutter with a vtkPlane as the Cut function to visualize a dataset.
I am running a loop where I continuously modify the cut plane’s origin/normal. Everything works fine till the Modified Time of the cut plane reaches close to the limit (VTK\_UNSIGNED\_INT\_MAX)
Now, I reach a scenario where the MTime has reached close to the VTK\_UNSIGNED\_INT\_MAX.
If I change the cut function (say, changing the origin/normal of the vtkPlane), the cutter output does not update. It seems like as the MTime reaches its maximum, it gets reset from zero.
I observed that (after the reset) the MTime of the cutter is ahead of the MTime of the cut plane (and hence, the cutter actor does not redraw ?). Basically, once I reach this stage of the maximum MTime, my pipeline gets broken and I can not use the same cutter and cut plane any more even after their MTime individually have been reset.
Can there be a scenario where the Modified Time of the Cut plane , Cutter and the Actor are not in the same cycle of the MTime - say two of them are close to the limit and the third one is reset to a small integer value \> zero ?
Will be very helpful if I could get any pointers on this.
Thanks,
Santosh
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [April 26, 2019, 1:10pm UTC](https://discourse.vtk.org/t/behavior-of-mtime-after-it-gets-reset-due-to-continuous-changes-or-running-a-long-session/847/2 "2019-04-26T13:10:41Z")
VTK has been supporting 64-bit counter for MTime for years (see `vtkType.h`). Double-check what vtkMTimeType you have configured for your VTK build.
---
### Author:  [@scbiradar](https://discourse.vtk.org/u/scbiradar)
#### Post date: [April 29, 2019, 10:15am UTC](https://discourse.vtk.org/t/behavior-of-mtime-after-it-gets-reset-due-to-continuous-changes-or-running-a-long-session/847/3 "2019-04-29T10:15:52Z")
I should have mentioned that I am using VTK-6.3.0 on windows.
I suspect that the 64-bit counter for MTime is not available for this version of VTK
Is upgrading to a newer VTK the only option to avoid the MTime behavior ?
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [April 29, 2019, 1:38pm UTC](https://discourse.vtk.org/t/behavior-of-mtime-after-it-gets-reset-due-to-continuous-changes-or-running-a-long-session/847/4 "2019-04-29T13:38:03Z")
You can backport the MTime change into VTK6, but of course it is much better if you can upgrade from this ancient VTK version to a recent one because there have been many other significant fixes and improvements.
---
### Author:  [@scbiradar](https://discourse.vtk.org/u/scbiradar)
#### Post date: [April 30, 2019, 5:38am UTC](https://discourse.vtk.org/t/behavior-of-mtime-after-it-gets-reset-due-to-continuous-changes-or-running-a-long-session/847/5 "2019-04-30T05:38:06Z")
Sure Andras. I understand that VTK-6.3.0 is fairly old.
I have a doubt regarding the increase in MTime. Does the MTime increase by the number of cells I am displaying? Because, each time i call Render the MTime jumps by tens of thousands or even lakhs. I just want to know if there is something wrong in my pipeline. I have a cutter acting on an unstructured grid. My pipeline is like vtu -\> vtkThreshold (one or more of these thresholds) -\> vtkCutter -\> Mapper -\> Actor
Thanks,
Santosh
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [April 30, 2019, 1:39pm UTC](https://discourse.vtk.org/t/behavior-of-mtime-after-it-gets-reset-due-to-continuous-changes-or-running-a-long-session/847/6 "2019-04-30T13:39:20Z")
Modified time is generated by a global counter that is incremented each time [vtkTimeStamp::Modified()](https://github.com/Kitware/VTK/blob/master/Common/Core/vtkTimeStamp.cxx#L40) is called. If you see jumps by tens of thousands then probably you have a quasi-infinite loop in your application (probably via event observations or GUI updates). Running your application using a profiler should pinpoint the hot loop.
---
### Author:  [@scbiradar](https://discourse.vtk.org/u/scbiradar)
#### Post date: [April 30, 2019, 2:19pm UTC](https://discourse.vtk.org/t/behavior-of-mtime-after-it-gets-reset-due-to-continuous-changes-or-running-a-long-session/847/7 "2019-04-30T14:19:39Z")
Thanks … I will check if there are any such loops in my application.
---
### Author:  [@scbiradar](https://discourse.vtk.org/u/scbiradar)
#### Post date: [May 14, 2019, 2:09pm UTC](https://discourse.vtk.org/t/behavior-of-mtime-after-it-gets-reset-due-to-continuous-changes-or-running-a-long-session/847/8 "2019-05-14T14:09:04Z")
I backported the vtkTimeStamp changes to VTK-6.3 to achieve the 64 bit counter for ModifiedTime and the problem of the MTime overflow is solved. Thanks Andras for the suggestion.
Regarding the jump in MTime, I can see that a simple pipeline like
vktUnstructuredGrid -\> vtkCutter does result in a jump in MTime of the cutter by approx. 3 times the number of the cells in the unstructured grid on each render. I tried this in a simple script without any GUI events.
---
### Author:  [@lassoan](https://discourse.vtk.org/u/lassoan)
#### Post date: [May 14, 2019, 3:33pm UTC](https://discourse.vtk.org/t/behavior-of-mtime-after-it-gets-reset-due-to-continuous-changes-or-running-a-long-session/847/9 "2019-05-14T15:33:10Z")
> [@scbiradar](#):
>
> simple pipeline like
> vktUnstructuredGrid → vtkCutter does result in a jump in MTime of the cutter by approx. 3 times the number of the cells in the unstructured grid on each render
There may be a bug in vtkCutter that unnecessarily calls Modified() too many times. There is a good chance that this was fixed since VTK-6.3 was released.