Firefox3 Final - DO NOT USE
Why not IceCat?
I just use IceCat.... when I want to connect to ZM.
Confirming to have same trouble with FF 3.x. Systemload goes up to 20+, extensive memory usage - system is swaping to death. If closing all FF windows from other (client) machine after some time load goes down to normal. So FF3 is indeed not usable with ZM.
Because reading your FF2 / IE suggest here, I started thinking about other ways. FirefoxPortable 2.0.16 came into my mind. Tried using FirefoxPortable 2.0.16 in WINE. Sadly this does not work fully here under Kubuntu Hardy because there seems to be some trouble between WINE and JRE (even xpiinstall.exe works fine). FF 2.0.16 portable starts showing ZM console. Streaming from cams does work anyhow, but around the streams black screen is filling all other screen areas. Anyone made this work?
Other: possibly using Crossover from Codeweavers. This maybe does work with IE, too (even though it would be somehow sick solution). Did not try this, yet.
Because reading your FF2 / IE suggest here, I started thinking about other ways. FirefoxPortable 2.0.16 came into my mind. Tried using FirefoxPortable 2.0.16 in WINE. Sadly this does not work fully here under Kubuntu Hardy because there seems to be some trouble between WINE and JRE (even xpiinstall.exe works fine). FF 2.0.16 portable starts showing ZM console. Streaming from cams does work anyhow, but around the streams black screen is filling all other screen areas. Anyone made this work?
Other: possibly using Crossover from Codeweavers. This maybe does work with IE, too (even though it would be somehow sick solution). Did not try this, yet.
Seamonkey is mentioned in an earlier post.
http://www.seamonkey-project.org/
I found it to be a good solution to a problem with the josm ywms plugin (mapping software) that broke with firefox3 as well.
Until the firefox crew get's around to fixing some serious regressions I'll be keeping a copy of seamonkey around.
http://www.seamonkey-project.org/
It is cross platform and can be installed without conflicting with firefox 3.The SeaMonkey project is a community effort to develop the SeaMonkey all-in-one internet application suite (see below). Such a software suite was previously made popular by Netscape and Mozilla, and the SeaMonkey project continues to develop and deliver high-quality updates to this concept.
I found it to be a good solution to a problem with the josm ywms plugin (mapping software) that broke with firefox3 as well.
Until the firefox crew get's around to fixing some serious regressions I'll be keeping a copy of seamonkey around.
This is kind of a crude hack but... I wrote a firefox extension that I think sort of fixes this. It simply toggles offline mode from initially on to off and back to on when you close a window. That closes the streams. It could potentially close streams you don't want closed I suppose. If anyone wants to test it I'll clean it up and put it online.
FF3 bug report page
FWIW, here's the Mozilla bug report which seems to identify the problem we're having.
I too have been bitten by this, and no one seems in a hurry to fix it any time soon.
(EDITED - fixed the Mozilla link)
I too have been bitten by this, and no one seems in a hurry to fix it any time soon.
(EDITED - fixed the Mozilla link)
Last edited by overly on Wed Oct 29, 2008 7:18 pm, edited 1 time in total.
Bluecherry PV-149 4-port capture card
Topica TP-936WIR-30C camera
Cheap Harbor Freight camera
HP Athlon 64 X2 w/ 2GB
Slackware 13 - 2.6.29.6-smp kernel
Topica TP-936WIR-30C camera
Cheap Harbor Freight camera
HP Athlon 64 X2 w/ 2GB
Slackware 13 - 2.6.29.6-smp kernel
Hi every one
I just read this post searching a solve to this (I just find the problem 2 hours ago).
One more thing U aren't mentioned .... ever time U do a "refresh" on a live stream the bandwidth rise a complete unit. I mean if U are using 64 kbps for 1 monitor, You will get a 128 K after the refresh, and 192 for the next one until you get 1 MB/s....
It get worts if you using a HiSpeed configuration...
The only way (you already know) is shut down FF or restart apache.-
My question is... Is there a little possibility to the ZM developers to handle this and make some "socket reset"?
Thanks!!!!
Sorry 4 my bad English if any
I just read this post searching a solve to this (I just find the problem 2 hours ago).
One more thing U aren't mentioned .... ever time U do a "refresh" on a live stream the bandwidth rise a complete unit. I mean if U are using 64 kbps for 1 monitor, You will get a 128 K after the refresh, and 192 for the next one until you get 1 MB/s....
It get worts if you using a HiSpeed configuration...
The only way (you already know) is shut down FF or restart apache.-
My question is... Is there a little possibility to the ZM developers to handle this and make some "socket reset"?
Thanks!!!!
Sorry 4 my bad English if any
Another method mentioned previously is to momentarily set FF3 to offline mode and then back. This forces FF3 to close the streams. Click on "Work Offline" in the File menu.CarLost wrote:Hi every one
The only way (you already know) is shut down FF or restart apache.-
Bluecherry PV-149 4-port capture card
Topica TP-936WIR-30C camera
Cheap Harbor Freight camera
HP Athlon 64 X2 w/ 2GB
Slackware 13 - 2.6.29.6-smp kernel
Topica TP-936WIR-30C camera
Cheap Harbor Freight camera
HP Athlon 64 X2 w/ 2GB
Slackware 13 - 2.6.29.6-smp kernel
Wouldn't help when you visit ip cams direct even if it was possible.CarLost wrote: My question is... Is there a little possibility to the ZM developers to handle this and make some "socket reset"?
In a couple of months it will have been a year since I reported this issue to the developers. I'm amazed it's still outstanding, and I've started being refused access to websites for running too old a browser. :/
The problem is the miss behaving browser not closing the socket. The only way this could be handled in ZM is to create a timeout. The problem with this is the rest who use a browser without this problem, will also have it reset and to be effective since someone might go through monitors or use cycle view, to be effective the timeout would have to be very short, thus interrupting any view on another browser.CarLost wrote: My question is... Is there a little possibility to the ZM developers to handle this and make some "socket reset"?
There really is no proper way to compensate for Firefox 3 short comings. It's rather a pain as it crashes one of my web servers all the time.
They really need to fix Firefox, If you have java on your machine, you can force cambozola by setting ZM_CAN_STREAM to "no" and by pass firefox 3 short coming by using the java app.
FF 2
Is Firefox 2 on linux (ubuntu, for instance) causing this same problem? I have 2 and 3 installed side by side, using 3 for my ZM stuff, and that seems to work fine, especially if you run them as different users.
I found if I left a FF3 window open with any kind of ZM console open in it, I'd wander off for coffee or lunch, and find all my FF processes dead. 2 doesn't seem to exhibit this behavior, as I leave a ff2 process running on one of my panes all day with a tab connected to each of my ZM servers (one of them on the machine I'm using now).
I found if I left a FF3 window open with any kind of ZM console open in it, I'd wander off for coffee or lunch, and find all my FF processes dead. 2 doesn't seem to exhibit this behavior, as I leave a ff2 process running on one of my panes all day with a tab connected to each of my ZM servers (one of them on the machine I'm using now).
