How Irritatiing is THIS?

Questions about MultiCharts and user contributed studies.
denizen2
Posts: 125
Joined: 17 Jul 2005
Has thanked: 8 times
Been thanked: 1 time

How Irritatiing is THIS?

Postby denizen2 » 11 Mar 2007

:roll: OK, I will try to calmly express myself...... I have just changed the 'style' of a symbol's plot from one size dot to a smallest size 'dot'. Nothing else was changed, AND nothing was ever changed that might have even a remote association with the data itself. So what happens next :shock: ? Well, the software 'thinks' it is time to download and reload the whole data series, AND of course, it just happens that I am looking at the clear chart with only status line showing that it is trying to 'connect'! It has stayed in this condition for over an hour.... on Saturday when the markets are closed.... BUT there is NO need for any 'new' data.... I just changed one display parameter, namely the size of the dots for the close price.

PLEASE,..... this is a 'bug' that has been with us for a very long time...
Does anybody else see the same kind of problem(s):
(a) Unnecessary request for new data to be download, and
(b) this request for 'new' data occuring when it is NOT even appropriate or needed?

denizen2
Posts: 125
Joined: 17 Jul 2005
Has thanked: 8 times
Been thanked: 1 time

Postby denizen2 » 11 Mar 2007

Here's some follow-up info on this issue, as of Sunday morning AND the rebooting of computer overnight. The 'problem' does not seem to occur now.... it only occurs when I am trying to 'get some work done' :twisted: ? :? .

Maybe it has something to do with how long the computer was running, e.g., all week long last week, and then into the weekend where the markets have changed from being 'online' to being 'off line'. Is it possible that such change from 'real-time' status to 'history-only' servers being available can cause the MC software to be 'extra sensitive' about what constitutes a 'change'?

Is it possible that merely changing the display attributes of the price-series under these conditions can trigger a data-reloading? The other seemingly significant aspect of this behavior is that even after this 'reload' is requested, the reload is never accomplished....mmmm So it looks like it is requesting to reload 'Real-time' data, NOT History data? On Saturday night, the markets are closed, so there is no real-time data, and that would explain why it get up-hung up, right?

So we have a 'cascade' of three bugs/issues?
(1) An inappropriate request for reloading data, triggered by just changing a display attribute, and
(2) such request for reloads are requesting Real-time data, when there is none available, and
(3) A non-responsive data-request is allowed to CONTINUE-indefinitely, without any chance for user to intervene/cancel.

I would suggest that at a minimum, the user should be given more status info about anything that 'triggers' a reload, and what is being requested for reloading, AND then the user can 'OK' or 'Cancel' such request.

This whole series of data-loading or re-loading issues amplifies the questions raised by many on these forums of what role the data cache plays, and exactly when/how is that data cache actually used, rather than requesting 'more' data be downloaded. It seems to be the case that the data cache is NEVER really used, because the system seems to always be downloading the whole data series (and this takes very long time). So can someone please explain what we should be expecting from the data-cache function?

:?:

User avatar
Kate
Posts: 758
Joined: 08 Dec 2006

Postby Kate » 14 Mar 2007

Denizen2,

Thank you for this information, we really appreciate your feedback. We confirm this problem and our developers are analyzing it now. As soon as they get a solution, I'll post it here.

denizen2
Posts: 125
Joined: 17 Jul 2005
Has thanked: 8 times
Been thanked: 1 time

Postby denizen2 » 14 Mar 2007

Denizen2,

Thank you for this information, we really appreciate your feedback. We confirm this problem and our developers are analyzing it now. As soon as they get a solution, I'll post it here.
Thank you Kate for acknowledging 'this problem'.

I presume you are referring specifically to the issue of 'changing a display-attribute sometimes causes data-reload'. Is this how you would briefly 'label' the 'bug'? It is very helpful to me (as a beta-tester) to get some (even very brief) feedback about how the 'bug' is being characterized, so that it can be better 'tracked' and/or 'supported' by any further inputs later on. :idea:

Here, for example, is some MORE INFO on 'this bug':
I just repeated this same 'bug' (again) this morning. .... BUT then it could ONLY be repeated ONCE (i.r., that is ONCE PER DAY?). In other words, the workspace has to be 'old enough', perhaps 24 hours, or just more than how long it takes to 'cross' to another day? in any case, this new 'evidence' should be some help in tracking it down.

So I think it would be accurate to say now that the 'bug' should be labeled to include the above condition of how 'old' is the workspace. This would 'explain' why it has been so 'elusive' :roll: , right? :idea:

User avatar
Kate
Posts: 758
Joined: 08 Dec 2006

Postby Kate » 15 Mar 2007

Denizen2,

I'd rather call this bug "leaving a workspace overnight causes data-reload" because when MultiCharts is working overnight if the next day you open FormatSymbol window and simply click Ok (without changing anything), MultiCharts will reload the data. This fix will be included in the next release.

denizen2
Posts: 125
Joined: 17 Jul 2005
Has thanked: 8 times
Been thanked: 1 time

Postby denizen2 » 15 Mar 2007

Denizen2,

I'd rather call this bug "leaving a workspace overnight causes data-reload" because when MultiCharts is working overnight if the next day you open FormatSymbol window and simply click Ok (without changing anything), MultiCharts will reload the data. This fix will be included in the next release.
Kate, thanks VERY much for the feedback and acknowledgment that you can also re-create this 'bug'.

BTW: :) I just 're-created' the same bug this morning (for the third day in a row). I never tried what you just mentioned, but I do notice that in my tests something that might be important to know. Namely, how many times this bug is 'triggered' in ONE chart. IF there are several data-series (in my case there have been two), THEN the bug can be triggered ONCE, for EACH and EVERY data-series. AFTER any one data-series has been 'used' to trigger the re-load, then that sensitivity to be a trigger is gone! That tells me that the trigger is associated with EACH specific data-series, AND NOT just the whole chart or workspace, right?

Guest

Postby Guest » 15 Mar 2007

thanks denizen2. This is has been bothering me too. I thought I did something wrong, it drove me crazy trying to figure out what. A few times I change the bar attribute because I need to go to a finer resolution to see the detail in order to make a decision to enter/exit a trade. And of course the damn thing spent 2 hours to download the perfectly complete data again.
thanks again !

denizen2
Posts: 125
Joined: 17 Jul 2005
Has thanked: 8 times
Been thanked: 1 time

Postby denizen2 » 16 Mar 2007

Kate and TSSupport,

At the beggining of this topic I noted that there seems to be three 'bugs' needing some attention. In this topic's discussion, so far, we have only focused on the first one of the three. You recently acknowledged the first mentioned 'bug' as being repeatable, and you gave it a 'label'. Now can we address the other two issues as well?

To refresh your memory I list the three again:
So we have a 'cascade' of three bugs/issues?
(1) An inappropriate request for reloading data, triggered by just changing a display attribute, and
(2) such request for reloads are requesting Real-time data, when there is none available, and
(3) A non-responsive data-request is allowed to CONTINUE-indefinitely, without any chance for user to intervene/cancel.
The second and third 'bugs' in this list (above) were issues that probably don't have a direct connection with the inappropriately triggered download issue. However, in my experience the other two issues were what made the mistakenly-triggered-downloads so VERY 'irratating', namely the triggered download would just hang-up the system.... and then it required a long and waisted time period of closing and re-opening the whole application.

So after this display-attribute-changed->triggering-a-download bug is 'fixed'
I suspect that we will still have to deal with some other kind of 'trigger' of downloads that are going to lead to the same outcome of waiting for data the will 'never' arrive (relatively speaking, of coarse). I say this because there have been other instances of having to wait and wait .... for data the never arrives :twisted: :? . I cannot point to a specific case right now, but I am sure this has occurred, and most likely it has occurred on the weekend when the market(s) are closed.

So consider a situation where the user does ANYTHING to initiate a download on the weekend. Regardless of whether it is the first 'bug' we've been discussing, or any other reason for a download or reload of data. So here is my question for that situation:

How does MC and/or QuoteManager make 'sure' that the kind of data being requested, say on a weekend, can only (maybe) be available from a 'history' server? So if real-time data service is being requested, then the software is 'smart enough' to 'gracefully' convert the request to whatever is really available (if any), and otherwise it must 'gracefully' end the request rather than hang-up the system. Since different data vendors do not all have both history and real-time data-servers, AND even when they do they may NOT be functioning (because of scheduled or non-scheduled reasons).

I'm sure you people have already given very much study and design effort to these issues, but somehow, sometimes, the software still gets into one of those very 'ungracefull' hang-ups waiting for data that will probably not be forthcoming until maybe the next day, or whatever :wink: .

So, all of this is to make my point: Please remind the developers that we need a 'better way' to process request for downloads so that we are assured of a 'graceful' handling of those cases where the data being requested is not available. Any comments on whether this is an 'active' action item already, or it is 'waiting' for more 'repeatable' cases?

Cheers,
denizen2

Guest

Postby Guest » 16 Mar 2007

it is time to introduce a ticket system where each problem is logged, dated and prioritized. This is the only way where the progress can be tracked and measured.

right now you are acting like a bunch of amatures, acknowledging problems only when you feel like it.

The customers are forced to act like whining kids. The more the kid (customer) nags, the more attention he gets.

you don't know what frustration means.
if I had known this product was only in beta, I would not have bought it.

ybfjax
Posts: 89
Joined: 05 Nov 2006
Contact:

Postby ybfjax » 23 Mar 2007

if I had known this product was only in beta, I would not have bought it.
It is clearly posted as being in a beta format.


Anyway, I did notice this problem as well. I thought it was just me.

User avatar
Andrew Kirillov
Posts: 1589
Joined: 28 Jul 2005
Has thanked: 2 times
Been thanked: 31 times
Contact:

Postby Andrew Kirillov » 28 Mar 2007

To denizen2:
So we have a 'cascade' of three bugs/issues?
(1) An inappropriate request for reloading data, triggered by just changing a display attribute, and
(2) such request for reloads are requesting Real-time data, when there is none available, and
(3) A non-responsive data-request is allowed to CONTINUE-indefinitely, without any chance for user to intervene/cancel.
(1)This fix will be included in the next release as Kate said previously.
As soon as (1) is fixed then (2)&(3) will not recur.
Anyway we'll put some additional efforts during weekends to test it to be sure (2)&(3) have been solved.

Nick
Posts: 496
Joined: 04 Aug 2006
Has thanked: 4 times
Been thanked: 24 times

Postby Nick » 28 Mar 2007

I feel your pain. For me the most irritating thing is that a kown bug list is/was not published. Frankly that wastes every testers time. It was something that was promised 6-9 months ago.

Josh, I thought with version 2.0 MC had moved to release status? I mak be mistaken. To be honest support is good withot a trouble ticket system however I would strongly vote for one being used. Not to track the status of queries but to prevent bugs being 'brushed under the carptet'. There are many minor bugs that have been there since day 1 and to be honest I am not sure of there status - I know I have reported some 2 or 3 times.

Cheers.
Nick.

User avatar
Andrew Kirillov
Posts: 1589
Joined: 28 Jul 2005
Has thanked: 2 times
Been thanked: 31 times
Contact:

Postby Andrew Kirillov » 04 Apr 2007

it is time to introduce a ticket system where each problem is logged, dated and prioritized. This is the only way where the progress can be tracked and measured.

right now you are acting like a bunch of amatures, acknowledging problems only when you feel like it.

The customers are forced to act like whining kids. The more the kid (customer) nags, the more attention he gets.
You do mix up "ticket system" and "bug tracking" system. Ticket system is used for support teams with
a considerably big number of support persons. Since we have just a few people in our support team
using ticket system would be irrelevant. It will simply slow down the support process. So when you
get a ticket ID assigned to your support request by some company it doesn't guarantee receiving a
fast/good support merely because of your having a ticket ID.
As for bug tracking, all I can tell is that it is impossible to develop any project comparable to
MultiCharts' level (in the sense of complexity and number of developers involved) without a powerful
bug tracking system. We use industry-standard bug tracking. All the issues reported by users are
always entered into the system, prioritized and tracked.
The problem is most likely to be not with the system but with the reporters who can only say that
"the software is not working" without specifying any particular issue.

For me the most irritating thing is that a kown bug list is/was not published. Frankly that wastes every testers time.
Nick,

With each new version released you can find the "What's new" file where you can see the list of bugs resolved.

denizen2
Posts: 125
Joined: 17 Jul 2005
Has thanked: 8 times
Been thanked: 1 time

Postby denizen2 » 04 Apr 2007

With each new version released you can find the "What's new" file where you can see the list of bugs resolved.
A reminder: That list of 'resolved bugs' AFTER a new version release does not inform those who are *currently* wondering if the 'problem' they are *currently* experiencing has *already* been 'acknowledged' as an 'issue' for investigation, i.e., a 'bug' :>)).

I think the customer-service 'ticket' idea proposed by Nick and others was meant to suggest that we need some way to be informed of what is already in the 'bug' category (yet to be resolved). If an issue has been 'identified' and some kind of brief but symptom-based 'label' or 'description' has been included in a 'bug' report, then we THEN know it is now in 'good hands'!

If there was this kind of 'two-way' communication between TSSupport and the beta-testers there would be more happy beta-testers :roll: , right? It also looks very 'impressive' to see the 'list of bugs' get 'squashed', one-by-one :evil: , right?

We fully appreciate the limited resources of a small company like TSSupport, but your most significant 'advantage' of being a 'small but responsive' company is somewhat lost when there is limited 'feedback' about what is already being worked on for the next or future release.

It may be appropriate to think of a three-level list of bugs:

(1)An 'Issue' about something in somewhat vague terms, but not (yet) at the stage of consistently reproducible enough to focus on as a 'bug' for the developers to focus on. This would serve to solicit any additional users-inputs (that might contribute to identifying the issue for level-2 status, below).

(2)An issue has been reproduced internally, and is being investigated. Some symptoms are given that helps identify the issue to others external to TSSupport.

(3)The 'issue' has been 'resolved' (and will be ,or has been, 'released' ).

Is this kind of bug-reporting scheme possible to implement at TSSupport?


Return to “MultiCharts”