[JHV 2.0] JPIP Cache settings odd behavior

Bug #470811 reported by Keith Hughitt
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
JHelioviewer
Fix Released
High
Juan Pablo

Bug Description

In the preferences section, "JPIP Cache" maximum size is set to 0.0Mb.. does this mean unlimited? or that caching is not allowed?

Tags: jhv2.0
Revision history for this message
Markus Langenberg (markus-langenberg) wrote :

I'm not even sure, if this option affects anything... We will have to check on that.

summary: - [JHV 1.0] JPIP Cache settings odd behavior
+ [JHV 2.0] JPIP Cache settings odd behavior
Changed in jhelioviewer:
status: New → Incomplete
tags: added: jhv2.0
removed: jhv1.0
Revision history for this message
Juan Pablo (jp-garcia-ortiz) wrote :

Yes, 0 bytes means unlimited. This affects to the JPIP caching mechanism, if this hasn´t been modified.

Revision history for this message
Keith Hughitt (keith-hughitt) wrote :

Okay. In that case, perhaps the best solution would simply be to add a note on the right side of the input box to the effect of "0.0 means unlimited space." Another options would be to use a slider with some useful values, and the right-most setting "unlimited".

Also, is the "Occupied size" listing work? Mine always shows up as zero, even after working with data for a while.

One final suggestion might be to swtich from "Occupied size" to "Currently used".

Revision history for this message
Juan Pablo (jp-garcia-ortiz) wrote :

Yes, that´s a good idea. Currently the mean of "0.0" as unlimited for the maximum cache size is not explained at all in the program, so it´d be really good to clarify it with what you propose.

The "Occupied size" should work. At least it worked, but maybe some changes in the code affected this feature. I´ll check it ASAP.

Changed in jhelioviewer:
status: Incomplete → Confirmed
importance: Undecided → High
milestone: none → 2.0.3
assignee: nobody → Juan Pablo (jp-garcia-ortiz)
Revision history for this message
Juan Pablo (jp-garcia-ortiz) wrote :

At least for me, the value of "Occupied size" is correct, different from zero, reflecting the total size of the cache files. Keith, could you check it again for the revision 41 (or later) of the trunk branch?

I´ve seen in the code that, by the time being, a line of the method "updateCacheDirectory", within the class "JHV_Kdu_cache" has been commented, so currently the value "Maximum size" specified in the preferences is not taken into account (it is always assumed to be zero), does anyone know why?

Revision history for this message
Markus Langenberg (markus-langenberg) wrote :

I did that. Since the seperation of the project into six different project, the class JHV_Kdu_cache doesn't know the class Settings any more. So it has to be implemented the other way round, that JHV_Kdu_cache has a method "setCacheSize", which is called from within the Settings class while updating. I haven't done that so far, but as you can see, there is TODO just above that line you mentioned, marked with my initials - So I will fix that some time. I thought this is not a problem for now, so at the moment, the cache should always be infinite. If it is important, I can fix it tomorrow.

Revision history for this message
Juan Pablo (jp-garcia-ortiz) wrote :

No, it´s not important at all. Anyway, I think that, since all the projects have been put together under only one parent project, the commented line would work again without needing any other modification.

Revision history for this message
Markus Langenberg (markus-langenberg) wrote :

"all the projects have been put together under only one parent project" - Really? If that's the case, that happened accidentally, they are supposed to be six different projects, with certain dependencies. So, for example the project "jhv" (containing the gui) depends on the project "viewmodel", so it's impossible to call something belonging to "jhv" from within "viewmodel".

Changed in jhelioviewer:
status: Confirmed → Fix Committed
Changed in jhelioviewer:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.