You are technically correct, the best kind of correct.
If they didn’t expect discussion of related issues they wouldn’t have hooked up the support ticket mechanism to a public forum.
If support’s official forum reply is, “watch out for large numbers” then I think asking what “large” is is fair game.
If it is going to take three hours to cut that will be a large file, bigge will have issues. Also perhaps Chrome instead of Firefox if at all possible. Even a simple vector with a high lpi engrave can be large it the result is big.
They “hooked it up” so people could get help easily, and so other users could pitch in and help as well. They didn’t “hook it up” so other people could hijack the thread with other things and make it harder for the original poster’s issue to stay in focus.
1 Like
If it takes too long for their software to process then it will time out and not finish processing.
If it uses too much memory it may also stop processing.
It’s almost certainly not strictly the number of nodes but a combination of multiple factors, e.g., how nested are the SVG tags, how complex are the stylesheets, which specific commands are present in the file (a Bézier curve may take more time/space than a simple line segment), etc.
2 Likes
If someone says “i’m having X issue that wasn’t happening yesterday” seems fair to chime in and let the OP know they’re not the only one (and that it isn’t necessarily related to what support seems to point to). I’ll certainly open my own thread if its an issue that doesn’t seem intermittent, server related, and has 3 threads about it already publicly opened. I experienced this issue on and off yesterday with the same file (literally one vector shape with 8 nodes).
1 Like
Your issue is not necessarily caused by the same thing. Support can see that by looking at the metrics for the individual machines. We can’t. 
(But it isn’t necessary to open a ticket unless you actually want help. All we try to do is let new users know that if they want help from support, they need to open their own ticket. They don’t necessarily see add-ons to existing posts once they’ve commented on it.)
2 Likes
Its also not necessarily NOT caused by the same thing, my apologies for trying to help.
If it is caused by the same thing, opening another thread on it adds to the count that they have, which causes them to look into something global, instead of machine specific.
In either case, the most helpful thing to do is to open another thread on it. They do want to see what’s going on, and they do appreciate people being helpful.
2 Likes
I am sure it is complicated… and if they provided more information about file limits, and detailed error messages, we’d have fewer posts about such problems because we’d be better able to solve our own problems.
The print simply failing does not make for a great user experience. I will keep providing similar feedback in the hopes that it sends a message to the company and contributes to the improvement of the product that we all enjoy.
The current situation is akin to being on a road and seeing a sign that simply says SPEED LIMIT.
1 Like
I’m not sure what they’re using for bug tracking, but my assumption was that opening a new thread opens a new issue that gets assigned to the next available person that may or may not have seen the other 3-4 incidents, a new support ticket can’t just automatically “add to the count” unless they’ve got some super-smart AI thats reading all of the tickets and sorting them. So starting a new ticket seems less efficient (or helpful) to me than attaching comments to an open ticket letting them know that multiple people are experiencing the issue (which is what I would want if I was debugging).
Well, they don’t tell us what they are using, but they have asked us to do it this way. So whatever they are doing, that’s what they prefer to see.
4 Likes