The Cavern Links Checker

By yah Last update Jan 19, 2012 — Installed 2,002,386 times.

Browser lagging out

in
Subscribe to Browser lagging out 15 posts, 3 voices



Couchpotato User

Hi again Yah,

I should probably have mentioned this sooner, but there are days when this script kills my browser

...not a crash, just an inability to move past the pages that are loaded, doesn't matter whether in single or multiple tabs. So if I click on anything (eg a link, or a submit button), nothing happens.

The only way for me to sort this out when it happens is to turn off Greasemonkey (just to be clear, yours is the only script I'm running) and then restart the browser.

When I first got the script I couldn't really use it for a couple of weeks. I updated the browser, uninstalled and reinstalled everything, tried a whole bunch of things to no avail. Then a few days after I'd given up, it started working.

I persevere with this problem because I love the script, but I figured since nobody else has notified you of the problem, I should do so.

My suspicion is that this occurs when MU links aren't able to be checked properly. I could be wrong about this though.

cheers, and thanks for all your great work so far,

CP

 
yah Script's Author

CP,

This is good info. I have seen this happen once or twice myself. During normal browsing with the script turned on, I almost never have an issue. However, doing a Link Check, I have seen the script wander off into never-never land. It starts eating memory at an accelerated rate.
..
I too suspect that one of the hosts it checks is causing the issue. MU is a different bird than the other hosts as it stores your authentication in a special cookie. We have recommended that Link Checking be done in a portable Firefox version reserved only for Link Checks. No passwords/authentications are to be stored in this version. It seemed to help an is not an altogether bad idea. However, I enjoy the script being there full-time so I've put up with the quirks here and there.
..
I'd really like to nail this bug down and move ahead with some other improvements. If you can pass along any information, it will be tremendously helpful. If you have a runaway script, document as much as you can. Open tab qty, how long has FF had been running, was there a particularly link ridden page you were accessing, did you notice any more MU indicators, specific pages that cause problems would be most excellent. Also let me know what version of FF you are running. Anything will help.
..
Thanks for the info,
yah.

 
Couchpotato User

LOL I know this isn't quite right to say, but I am glad to know it's just not me! ;) Since nobody else had reported it I had definitely wondered about that.

Okay, I will document as much as possible. First, to give you some basics:

- I am using Firefox 3.0.6

- Windows XP Pro 2002 SP 3

- Pentium 4 CPU 3Ghz / 1GB RAM

- Internet is running over cable network, download speed 2Mbps / upload 256kbps
...I'm about to get an upgrade to double that in the next week or two so I can also let you know if that makes a difference. I have a friend who is on the same network with the same provider on that double speed and she doesn't have the same issues, despite using the script for the same purpose. Mind you, she also has a more state-of-the-art machine, so I'm not sure whether that factors in.

My experience so far...

- I tend to have multiple tabs open most of the time - usually anything from two to six tabs. The problem can occur when I am only using one though.

- I have found that the problem is more likely to occur when the page has a large number of links to check.

- It is also more likely to occur when it is peak time for my ISP. At these times I tend to turn off the script. So bandwidth might be an issue.

- If I have multiple tabs open with long lists of links the problem is almost certain to occur.

- I have noticed that when it does occur, the Megaupload links tend not to have any results reported yet (thus my suspicion).

- The browser doesn't have to have been open for long - if it's a bad day then it could occur on the first page I open in the first tab.

So these are some general thoughts from memory. Next time it happens I will try to document some more specific information. I'll look at memory and CPU usage at the time too; this is not something I'd thought to check on.

It would be terrific if we could sort this one out, because like you, I prefer to have the script running all of the time.

I'm not sure how to do that separate iteration of the browser, although it sounds useful for testing purposes. Would you like me to try it? If so, I would need some instructions.

cheers, and thanks for looking into this Yah.

CP

 
yah Script's Author

CP,

I have two 100% guaranteed ways to work around this for you. One Bad, one Good.
..1. Remove your megaupload cookie from FF. (Bad option)
..2. Turn off Direct Downloads in Megaupload Account. (Good option)
..
It seems that the initial megaupload request causes a URL Redirect command to be issued to the actual location of the file. It's not typical of file hosting sites. There may be a way to work around this and leave the megaupload cookie on your machine. Greasemonkey does not pick up on the server-side redirection and, instead, starts streaming all of the linked files down on a page -- ouch. I used HTTP Analyzer to validate our suspicions. Greasemonkey can't handle this with a simple @exclude. Grrrrrrrrrr. It'd be a miracle if I could come up with a script soliution for this. I'll just live with turning off the Direct Downloads.
..
Thanks for the quick response. Hope this helps. Let me know if it works for you.
yah.

 
Couchpotato User

Eep.

I just went to Megaupload settings and actually, direct downloads were already deactivated... not really keen on removing the cookie, as I use it for filefetching, logging in automatically etc. It's kind of convenient having it.

Any other suggestions?

 
yah Script's Author

CP,

Do you have any other FF Add-Ons installed? Another possibility is Download Accelerators like "Internet Download Manager" that integrates itself into FF and installs it's own Add-On into the browser. These might be affecting the way the script is functioning for you.

Let me know,
yah.

 
Couchpotato User

Add-ons in my FF are minimal, as follows:
- Greasemonkey (TCLC is the only script running)
- Norton IPS
And as of yesterday, ZoneAlarm Spy blocker has been added.
...
Separate to the browser I have FlashGet but it's not integrated except to watch for links copied to the clipboard.
...

Hopefully over the next few days I will be able to do a bit of proper testing and keep some notes for you. This past few days I had a lot to get done so I couldn't turn on the script and risk any slow down.

 
yah Script's Author

CP,

I uploaded the test version of the 2.0 script as a new script here:
http://userscripts.org/scripts/show/43375

It give you the ability to disable checking of each individual host site. You can disable just Megaupload if you want. It adds a TCLC Prefs button at the bottom of each page that opens up a preferences window. If you'd like to try this, uninstall the current script and install this one.

This is a safer way for me to install/maintain test versions of the script.

Hope it can help you,
yah.

 
lordfrikk Scriptwright

I checked your test version, yay, and since I saw the commented upcoming Preferences stuff, I wanted to ask if you intend to allow us to display the Prefs window thru User Script Command as AIO does it or keep it the way it's now (adding element to page, which is horrible btw :))?

 
yah Script's Author

Lukáš,

For testing purposes, I left the prefs button on the page. For now, that's where it'll stay. It's a lot quicker than navigating through the menu 100 times an hour during testing. There are several different ways to accomplish a professional looking menu. I won't say AIO's choice is the best but it is an option.

yah.

 
Couchpotato User

Hi Yah,

Well this makes a world of a difference and is very much appreciated. Turning off MU has fixed everything.

I discovered over the past few days (via a great deal of determined digging), that there was a pretty major problem going on. For a while I thought I had a virus, but now that I've used the test script and disabled access to MU, I realise it was the script causing the issues. You may want to consider blocking MU until it is resolved, because this is pretty serious stuff. As it turns out, when I checked in with various other users of TCLC on forums I am a part of, they are experiencing similar problems but have had no idea what was going on.

Basically, the script was opening up connections to several different hosts on MU, all beginning with one of three IP prefixes: 209.222.128.xxx / 174.140.128.xxx / 66.117.43.xxx (it took me a while to narrow these down to MU but eventually I got there).

Once these connections were opened, very large downloads of unknown data were coming through to an unknown location on my machine. These downloads wouldn't stop until I killed the browser, which would break the connections within a minute or two. Once my bandwidth was upgraded, these downloads simply got faster.

I spied on my connection and kept notes over a few days to narrow all of this down. Here's an example of what I was experiencing:

---

Connections:
174.140.128.21 x2
174.140.128.31 x2
209.222.128.140
209.222.128.199
66.117.43.59 x2

All downloading at about 85Kbps each

total download: over 1.1GB downloaded (from 7:16am to 7:56am Mon 2 Mar (40 mins))

---

Now that I have switched off access to MU using your preferences button, the script is behaving properly and the weird downloads are not occurring anymore.

My browser is happy and the world has become a sunny place. :D

You have no idea how relieved I am. Until I was able to turn MU off in the test script, I was beginning to think I had a new virus (Norton/AVG and several other scanners refused to find anything) and that I would need to rebuild my machine all over again to clear it up. I had also been forced to browse using IE, which I have to say was simply heartbreaking. ;)

For now, I will just use the test script with MU switched off. If you want me to do any further testing, please feel free to ask.

 
Couchpotato User

FYI, in case you didn't know, the Preferences button sometimes appears at the top of the screen. Seems to depend on which site I am viewing. It's no big hassle of course, but I thought you might like to know.

cheers,

~v

 
yah Script's Author

CP,

Your effort and replies are much appreciated. The behind-the-scenes downloads that you too have verified are not malicious, as far as I have been able to determine. They are however, a sign of MU's odd behavior.
..
Normal link checking at other sites involves just a request for the file pointed to by a link. Normally, a small HTML page, is returned. If you are a free user, the page displays the option to download, usually at a slower pace, or register/subscribe and get blazingly fast downloads. This is the key to the script functioning as desired as I'll explain in a bit.
..
However, a fully subscribed user at MU with a recent cookie enabled, will not get an HTML page as a response to the initial request. They will initiate a full download of any linked files on the original page where the script ran. If there was one link, one file download kicks off. If there were 100 MU links, 100 downloads will initiate. This has been a known issue since we started with this script at The Cavern Forum. Since the script was designed to aid us in link checking, we just removed the MU cookie for the duration.
..
The frustrating part is that there is no apparent GM script that can affect MU's behavior. The automatic download starts on the server side where GM/javascript cannot go. The downloads just get pushed into the temporary internet files. They are there but may be stored as temp files or named oddly.
..
Unfortunately, I have not found a way around this problem. Other scripts, AIO, for example, get around this by querying another website and depending upon its responses, not directly to the Host sites. This is OK in theory, but large numbers of users quickly bring a single server to its knees with requests during large scale link checking.
..
TCLC script was designed to be distributed, every person using it is an island. They send requests directly to the Host sites. They do not have to worry about one central server going down and killing all link checking for all host sites.
..
Again I'd like to say thanks for the info. But I agree that we'll just close this topic for now. I have hopes that there may be a way around it involving reading/disabling cookies but right now that's a sore subject with GM security folks.
..
yah.

 
Couchpotato User

Thanks Yah,

This is just as I had suspected - that perhaps each MU link on the page was attempting to be downloaded. That's pretty scary when I think of some of the pages I view!
...

Does this mean that if I was logged out of MU in megamanager and in the browser, TCLC should be able to safely check the MU links?

thanks for hanging in there with me on this one.

 
yah Script's Author

@CP,
I think just removing your MU cookie should put you in the clear. I'm an MU subscriber myself and I use "Internet Download Manager" to do the actual downloading. I'm normally logged out of Megaupload. I let the script do the checking for me and I just login to megaupload when there's one or more links I want to grab.
..
Not elegant, but it works for the limited MU links I grab. MU is the only host site I've seen that handles links this way. I've subscribed to several other sites but they've always behaved in a normal manner.
..
Cheers,
yah.

Cross
Presentational HTML allowed.
Use <code> for inline code and <pre> for code blocks. Use &lt; and &gt; for literal < and >.
We help break paragraphs and link your links.
or cancel