HTTPS access hangs Firefox plug-in manager

[Foyaxe]

I have the same problem on firefox.
The flash plugin generates 100% CPU load while loading the stream. When the file loading is completed, the player runs fine.
I could test that with Firefox 3.5. Since firefox 3.6, the plugin container is built in. So, all firefox versions >= 3.6 kill the plugin container after 45 seconds.
I cant explain why flash is actually generating 100% load and eats up huge memory.
The same flash version is running fine in opera and chromium.
It must be something that happens only in firefox. And only with subsonic and ssl, i couldnt find sb with this problem using jwplayer except here in the subsonic forums.
And it also seems not to be due to the plugin contianer of firefox. The problem also exists with firefox 3.5, but there flash is not killed and can complete loading.

So, is there anyone out there who has found a solution or at least the actual reason for these crashes?
Disabling SSL is not a good option cause im streaming over the internet and dont want plain text pws to be transmitted.
Not using firefox is possible, as i am using chromium anyway, but some friends of mine dont appreciate that.

Foyaxe

[supra92]

BTW, and in full recognition of the idea that 80 and 443 are discouraged as a "path of least resistance" as people have run into conflicts and avoiding the those ports altogether is a straightforward way to resolve.....

... using the WAR version of Subsonic in the Tomcat servlet container lets you run as many apps on a port as you'd like. I switched to https (443) a couple of years ago simply because I wasn't fond of the idea of TimeWarner being able to sniff packets and see that I was streaming music out into the world --- when i ran it in Jetty i was stuck because I had other apps (including my MySQL DB'd album catalogue app) that I also wanted to run on 443. The solution was simply to run everything on Tomcat ---- this way, subsonic is located at https://subsonic.supra92sdomain.com, my databased album catalogue at https://musiclib.supra92sdomain.com, plus a few others like a sad homebrew blog I semi-maintain at https://homebrew.supra92sdomain.com. Tomcat has been a perfect solution in that regard.

Definitely not meant to run counter to previous advice on this thread, but intended purely for those who truly do want to run multiple things on the same https/443 port on their home server and were concerned there wasn't a way. DNS "A" records let you point to each app in clean fashion, and virtual hosts in apache can let you use multiple domains on the same linux server in your house. In fact, I do just that, as I run the .COM, .NET. and .ORG domains of "supra92sdomain" all on the same Scientific Linux box. Jetty is definitely out, though, for anyone wanting to run multiple things on the same domain/port -- no real way around that.

Supra92

[mattyo1]

I just want to add that I have been having this problem recently (6+ months), too. I think it coincided with upgrading my server machine to Fedora 16, and also going to subsonic 4.6 at the same time. Also, I'm sure Firefox and Flash got updated around then, too... so I can't really pinpoint the issue. But it only happens for me when all of these are true:


1. Firefox
2. https (I use port 8443)
3. downsampling
4. from certain places on the internet and not others

HTTPS works fine everywhere, if I play the original mp3 file (i.e no bandwdth limit set on the player). But once I set the player to downsample, then the plugin-container hang occurs. Regular non-ssl HTTP works great with or without transcoding. I have tried from several locations, and the problem seems to happen more often when there is also a firewall/proxy involved. So maybe it's a network issue, or a JW player or a Flash issue. I have no idea. But it used to work fine (last year or so). I've done some packet captures, and not found much of interest.. Anyway with HTTPS, you can't see what's going on inside the packets. I know this is all vague info, but it's just too hard to organize all the testing when there are so many variables. And I 've tinkered with it a lot over the last 6 months or so.

At this point, I'm kind of just hoping that the next wave of updates to Fedora/Subsonic/Flash/etc. will fix it magically, just as it broke magically.

[GJ51]

Has anyone test this on a known "good" server to try and see if it's a sever or a browser issue?

Send me a PM if you want to test on one of my servers as I currently have instances of 4.6 and 4.7 b1 that I can make available for testing.

EDIT:

http://xw8600.subsonic.org/share/NWfUY

I'll leave the link active for one week.

[srobison13]

I just tried your server with the Ed Sullivan clips. None of them caused FF's plugin-container to run away and crash. Did you use any special transcode settings? Probably unrelated, but most clips I tried would play for a few seconds then restart, then play fine (some restarted a little later). I tried streaming video from my server and the problem is still definitely there.
While I was at it, I did try streaming with a non-down-sampled player and it worked fine as mattyo1 mentioned. Not that doing this is a very good option either, but interesting nonetheless.

Has anyone test this on a known "good" server to try and see if it's a sever or a browser issue?

Send me a PM if you want to test on one of my servers as I currently have instances of 4.6 and 4.7 b1 that I can make available for testing.

EDIT:

http://xw8600.subsonic.org/share/NWfUY

I'll leave the link active for one week.

[GJ51]

One of the biggest discoveries I have made regarding video performace behavior is that not all ffmpeg versions are created equal. I'm no expert in the compilation process that goes into producing any particular ffmpeg.exe file, but I do know that they seem to each have their own quirks.

I'm using Win x64 platforms for the most part and use a version of ffmpeg that I've found to work well on my servers.

https://skydrive.live.com/redir?resid=A ... 0A32A0!203

Here's a link to that file. It's named Videoffmpeg.exe so I just drop it into the transcode directory and substitute it in the video transcode string.

Videoffmpeg -ss %o -i %s -async 1 -b %bk -s %wx%h -ar 44100 -ac 2 -v 0 -f flv -vcodec libx264 -preset superfast -threads 0 -

I find this to be a handy way to test different versions of ffmpeg. (Idea courtesy of Glenn Sullivan, Bushman4)

I also suggest testing current ffmpeg builds from the ffmpeg site that are specific for your OS.

[mattyo1]

GJ51's shared TV clips (nice, BTW!) worked fine for me, as well. But I don't know how similar a situation those videos are, compared to my MP3 downsampling issues.

I did get subsonic 4.7-beta1 from svn, and am having my same problem with the firefox plugin-containter consuming the CPU when downsampling and HTTPS are used. Interestingly, subsonic 4.6 used lame to downsample, while 4.7beta1 is using ffmpeg. That probably rules out lame oddities, which I'd wondered about.

I'm guessing it has to be some obscure network-related issue with HTTPS, which in turn triggers some bug in Flash/JW player/Firefox. But don't quote me on that!

[GJ51]

It gets a bit hard to keep track of all the individual issues I read on the forum, but you're all wlecome to PM me for guest access if you need to compare behavior on my server.

[mattyo1]

Update: I think it's a java-related problem... for me, anyway.

My subsonic server has always run the latest 64-bit Fedora linux. I've always used Sun/Oracle JRE. Just now, I reinstalled a bunch of previous Sun java releases, and then ran the Subsonic daemon with each of them. My findings:

sun jre1.6.0_27 - no problem
sun jre1.6.0_29 - problem
sun jre1.6.0_30 - problem
sun jre1.6.0_31 - problem
java-1.6.0-openjdk.x86_64 - problem
java-1.7.0-openjdk.x86_64 - problem


I guess I'll keep jre1.6.0_27 around for a while!!!

[Foyaxe]

Good News here!

As there is no sun-java 1.6.0-27 in Gentoo any longer, I tried oracle Java 1.7.0-4 and that fixed the problem for me.

Hope that helps you and that you can confirm that this problem is due to the java version.

Foyaxe

[srobison13]

With the new Firefox release, I updated everything hoping for a miracle but, alas, the problem still remains on Firefox 13.0, Flash 11.3.300.257 Java 1.7.0_04-b22.

[srobison13]

SOLVED: Foyaxe was right. I had tried updating Java on my client machine to no avail. I updated the version on the box my server is running on to 1.7.0-4 and voila! I still find it odd that things seemed fine on my server and yet it was able to crash my client. Oh well. Goodbye Chrome...for now?

[srobison13]

For now indeed. After updating both my server and client java versions to 1.7.0_07-b10 the same problem is back. I guess it's Chrome again until the next Java release. Lame!

[dr3van]

I have this same problem, Firefox plugin-container eating up memory and then crashing, but it only seems to hang on FLAC files. I have not experimented with turning HTTPS off because I definitely do not want to do that as I access my server over the internet. I am running my server on Ubuntu server 12.04 running the latest beta of subsonic. I have tried many things to correct this including contacting sindre... I have had no luck getting this issue solved. I have completely uninstalled everything and re-installed including my server os and all flash and Firefox...

[srobison13]

Re-solved. Apparently it was some combination of updating Java across all my clients and server. I think the real issue was not rebooting my server (Win7 x64) after updating. Until next time....