ZoneMinder Forums

IETab is a quick solution. I'm thinking they'll fix this soon!

I just use IceCat.... when I want to connect to ZM.

freak wrote:IETab is a quick solution. I'm thinking they'll fix this soon!

Doesn't work on Linux.
Breaks rendering and other tools.
They seem to feel no urgency, so I am looking at other options. Anyone recommend a good cross platform lightweight browser?

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.

Seamonkey is mentioned in an earlier post.
http://www.seamonkey-project.org/

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.

It is cross platform and can be installed without conflicting with firefox 3.
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.

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 am starting to think they have become too big to give a damn. Time to find some competition...

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

CarLost wrote:Hi every one

The only way (you already know) is shut down FF or restart apache.-

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: My question is... Is there a little possibility to the ZM developers to handle this and make some "socket reset"?

Wouldn't help when you visit ip cams direct even if it was possible.

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. :/

CarLost wrote: My question is... Is there a little possibility to the ZM developers to handle this and make some "socket reset"?

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.

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.

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).

3 is the broken one. 2 works fine in ZM, and is what I generally use.

Lee Sharp wrote:I am starting to think they have become too big to give a damn. Time to find some competition...

Agree. What other browser is recommended under Windows, to fully enjoy ZM's MJPEG stream capability?