After switching over to SVF2 await aggregated.waitForLoadDone() sometimes blocks indefinitely. Unfortunately I can't reproduce the issue deterministically. It can happen right after starting my app, after loading/unloading models or not at all.
I did not observe this behavior previously, but I wasn't able to (ab)use the viewer like this until now (eg. rapidly switching between very large models, some half-broken). Kudos for SVF2, performance is mind-boggling.
My current workaround is to Promise.race the waitForLoadDone() and reject after 10 seconds. This is working ok and keeps my app in a consistent state.
I have a suspicion that the problem might be network related.
Edit: I narrowed it down to the property model.getData().loadDone which sometimes remains false forever.
Edit2: This is getting worse with every release. I'm now on 7.60 and the viewer constantly breaks. Some objects never load, websockets get stuck and don't transfer any data, users need to manually clean their browser cache. How can this possibly pass any QA?
I'm afraid that this could be - as you pointed out - a network issue. You may have noticed that the SVF2 format uses WebSockets to transfer the granular asset data to the browser, but if that persistent connection breaks, it's possible that the viewer wouldn't be able to recover.
Next time you see this happen, please check the console logs (and share them here if possible) and the network tab, to see if the WebSocket connection is still active. If it is, and the model still isn't loaded successfully, please submit a report to forge (dot) help (at) autodesk (dot) com with as much info as possible so that we can debug it on our side.
Related
I have a question about performance of Forge Viewer, and i think its big problem when the end users approach this technology. In Debug enviroment its so smoothly, i dont have any problems, model doesnt reload all the times. However, when i deploy application, its a different story. Take a look link below you can see how it lag, like the model reload all the times when ever i do something.
I use Firebase for my frontend and Azure for my backend. What is the problem or i must config something?
https://youtu.be/c4QbAknZNRY
Appreciate any comments.
Paxton.
I've been writing an extension that allows the user to issue voice commands to control their browser, and things were going great until I hit a catastrophic problem. It goes like this:
The speech recognition object is in continuous mode, and whenever the onerror: 'no-speech' or onend events fire, it restarts. This way, the extension is constantly waiting to accept input and reacts whenever a command is issued, even after 5 minutes of silence.
After a few days of of development, today I reached the point where I was testing it in practical use, and I found that after a little while (and with no change to anything on my part), my onend event started firing constantly. As in, looking at the console, I would see 18,000 requests being made in the space of three seconds, all being instantly denied, thus triggering onend and restarting the request.
I'm aware that it would be optimal to wait for sound before sending a request, or to have local speech recognition capabilities without the need for a remote server, but the present API does not allow that.
Are my suspicions correct? Am I getting request limited?
Are my suspicions correct? Am I getting request limited?
Yes
I'm aware that it would be optimal to wait for sound before sending a request, or to have local speech recognition capabilities without the need for a remote server, but the present API does not allow that.
To hide the IP source of your request you can use anonymizer networks like Tor, though it will not be fast.
It's naive to assume Google will spend resources to process all audio being recorded on your system. In your application development it is better to rely on API which provides at least some guarantees. It could be either commercial API or open source implementation like CMUSphinx.
With CMUSphinx, you can also properly implement command keyword detection and increase accuracy by specifying the grammar of the commands.
You could also use a Voice Activity Detection (VAD) algorithm to detect when a user is talking. This can be done by either setting a volume threshold or a frequency threshold (Human speech is usually less than 400hz for example). This way, you won't send useless requests to Google unless those conditions are meant. I would not recommend using Tor as this would significantly increase latency. CMUSphinx is probably the best local system option, but if still want to use a web-based service, I would recommend either using a Voice Activity Detection algorithm or finding a different web-based software.
I've developed a Chrome Extension that cycles through approximately 1500-2000 pages to collect information from a website and push it onto my own server. I use a Chrome extension, as given the requirements it's much easier to configure than making and parsing from the server side.
The extension is used only for internal purposes and we trigger this job using the chrome.alarm API to run at 3:00 am every day. This alarm when triggers pops open a new tab and runs through the 1500-2000 pages. The problem is when we check in the morning we see the SNAP dialogue after the extension has cycled through about 1500 pages (approx 3/4). I'm presuming this is due to the memory demand placed on Chrome to maintain such an unusually large history?
My question is, what would be the best way to mitigate this? Presumably killing the tab and reopening (after x number of pages) would work but that would slow down the feed and require quite a bit of code re-factoring. Is there any way you can force Chrome to dump the history and would doing so free memory in the immediate session?
Just to add some context, I am running this on a extra small VM with only 1 GB of memory. I appreciate I could upgrade the VM but that really just defers the problem.
It's hard to make a solid recommendation without seeing your code, but here's something a bit more general:
The problem is likely the information that is being collected. It continues to build up in memory until you run out. You might consider saving the results to local storage using Chrome's unlimited storage capability. In manifest file:
"permissions": [
"unlimitedStorage"
],
What I would probably do is save to local storage after every page, or something similar, and then reset the array (or whatever you're using).
UPDATE
If indeed history is the problem, you could consider deleting it on the fly. This function will delete entries for a specific URL:
https://developer.chrome.com/extensions/history.html#method-deleteUrl
My browser extension is crashing occasionally. The problem is, I cannot find a good, comprehensive list of things that can cause an extension to crash, and thus am having a hard time creating a checklist of things to work with.
My assumption is that anything that causes a standard Chrome tab to crash would cause the extension to crash when run in the Background.html file.
Off the top of my head, I'm assuming the following could cause problems...
Infinite loops or other instances of a script becoming unresponsive
Uncaught exceptions (eg, a JSON.parse with no try/catch)
Database storage errors
Excessive resource usage (??)
That's really all I can think of. I'm having a heck of a time trying to debug my extension and would really appreciate any help creating a checklist...
I'm coming back to this question about 3 months after asking it because a 2nd extension of mine was also crashing. In this case, though, the extension was far simpler -- only about 40 lines of code in the background.js script.
2 operations seemed to be possible culprits: writing to localStorage and using console.log
I have previously observed that it is possible to crash a normal chrome tab by using console.log repeatedly with large objects in a website if you leave the page open for an extended period. Because background.js is always open, it seems like a likely culprit here.
tl;dr
Don't use console.log in production. Ever.
I have an HTML5/jquery mobile web app at http://app.bluedot.mobi. It is used for long distance races to track competitors via SPOT satellite tracking. The issue I have not yet resolved is that when loading the app when no data connection exists, the browser throws a "no data connection" alert popup as it is attempting to fetch the manifest during the checking event. Even when a data connection is present, loading the app can take a very long time. There are ~ 500 files to check. The fastest way to load the app (from a phone) is to be in airplane mode and dismiss the browser's alert - not so elegant.
Rather than force an update on users who tend to be in the backcountry with a spotty connection, I want to use applicationCache.update() programmatically, giving the user control over the process and speeding up app load whether on or offline.
Is this currently possible with the HTML5 spec and respective browser implementations?
Sounds like you need the abort() method. Unfortunately it is very new, and it will probably be a while before it is implemented by the majority of mobile browsers.
There are ~ 500 files to check.
It sounds like you're implying that the browser checks each file to see if there's any of them which has changed. This is not correct. The browser only checks the manifest file if that has changed, and that is a simple byte check. If the manifest file has not changed, the browser believes nothing has changed.
So if your application is slow to start, it might be your because your application is complex and there's alot of HTML and Javascript to parse. I would advise you to take a look at the application and see if there's anything you can optimize. In that case, you might want to take a look at Yahoo's Best Practices for Speeding Up Your Web Site page.
For example, I noticed you have a lot of Javascript code in the HEAD section. The beforementioned article advices us to move all Javascript (To the extent of what's possible) to the bottom of the page, so that the browser can start rendering the page as soon as possible. And there's a lot of other sound advice in the article. So take a look, I'm sure you'll find it useful. :-)