Streamerp2p Forum

I am running a fully licensed SAM3 v3.4.3 and I am now at a complete standstill and unable to broadcast at all.

I had run into this problem earlier in the day but it just "went away". Unfortunately the problem has returned and is showing now signs of going away.

Here's the error report first for my dial up server, then the broadband server:

Streamer p2p radio 1.42 has Crashed!
Build: Mar 5 2006 02:13:42
c0000005 00000000 pc 000a0d3e 0001003f
00000001 0000001c 00000103 00000000
00db7e90 00000000 0012ff34 0012fec8
000a0d3e 0000001b 00000023 00010202
00401000-004316b0
mem 20 20 20 20 20 20 20 20
gui

For help with this error, email the file 'error.txt' to me at
bugs@streamerp2p.com

Streamer p2p radio 1.42 has Crashed!
Build: Mar 5 2006 02:13:42
c0000005 00000000 pc 000a0d3e 0001003f
00000001 0000001c 00000103 00000000
00db7e90 00000000 0012ff34 0012fec8
000a0d3e 0000001b 00000023 00010202
00401000-004316b0
mem 20 20 20 20 20 20 20 20
gui

For help with this error, email the file 'error.txt' to me at
bugs@streamerp2p.com

In addition to the above, in my Encoders window is the following message:

$IndyThreadSock.Execute: Connection Closed Gracefully (200)

And, finally, even when the servers WERE up and running, nobody but me (with a 3rd installation of 1.42) could connect. The station is showing in the list but using the listen link (URL.txt) or the link on the Streamer home page or double clicking to listen would work for 3 different people.

Everything has been tested with the firewall off and it doesn't seem to make a difference.

Just a follow up on this.

I reinstalled 1.42 and set up my server. I selected 256k for my bandwidth test and statred broadcasting. Everything seems fine now other than tuned hosts not showing in the ping column as reported in another thread.

The first time I set up I selected a custom number for the bandwidth test and that is when I started having all kinds of problems culminating in not being able to broadcast.

I'm not sure if using a custom bandwidth setting has anything to do with it but I thought I'd mention it.

That shouldn't have affected it Bear. SOmething else went whacko there I think. Could be worth keeping in mind though. THanks for the info!

I just had the same crash as reported in my first post including the message in my encoder box on SAM.

I couldn't get the encoder to connect so I shut down Streamer, restarted it, same result.

I closed everything and rebooted, fired up Streamer and SAM, same result.

Don't ask me why but I started clicking around on other people's stations then clicked the stop button on Streamer, started the encoder on SAM, and viola...it worked...lol.

I've also noticed a very disturbing trend with this version of Streamer. After broadcasting for a couple of hours the bitrate creeps up and up and up. I broadcast (to broadband users) at 80kbps. It's climbed as high as 166kbps all by itself.

I've tried mp3 and mp3PRO encoders at different kHz values but I'm getting the same problem.

This had the effect of shutting down 3 listeners who installed v1.42 and tuned in. When you install Streamer it seems to automatically test bandwidth at 128k which is fine but with the bitrate creeping up and over that...well...it's not very good.

Any ideas as to why it does this? I mean, I noticed some variance in bitrate with 1.40 but nothing to this extreme.

There are a few other little things but the Streamer team has enough on it's plate at this time.

I'm only getting a few "brave listeners" to install 1.42 and I've set up a forum for them at my site. I will report any and all weirdness here.

I can assure you that when the next version comes out, providing I still have listeners...lol...we will Beta Test for you. I was tempted to gather a few of my listeners and help you out this time around but real life conspired against me.

I still believe in, and back Streamer 100%...

...I'm just sorry I didn't have the foresight of bringing a few of my listeners over and help with the Beta.

Has anybody else seen their bitrate creeping up like this?

I'm running quality -0.6 OGG and I stay at about 50-54K consistently. FYI, I'm simultaneously running a 160k MP3 to a steamcast server and it is fine.

Not that I know what I'm talking about, but isn't that more of an encoder thing?

Kevin

It might have been an annomoly.

Streamer has been up for over 8 1/2 hours now using mp3 80kbps/32kHz and it's steady with 2 tuned hosts.

I'm getting this bitrate spiking problem again. Everything was fine for about 26 hours or so and now twice in the past hour the bitrate has climbed up to 156 knocking off two listeners.

What could possibly be causing this?

Nothing has changed on my end certainly not over the past 30 hours or so.

Hi,
SAM 3 will eat up CPU and ram like candy if you use there encoders within SAM 3.What you can do is use oddcast V3 stand alone version like i do and have oddcast v3 do all of your encoding for you and you will be all set.All you need to do is copy the aac plus dll file from winamps plugins folder and then copy that into oddcasts folder.

That is the set up im using right now and my cpu usage is between 10 to 15% usage which is perfectly fine and has not crashed on me at all.

I have been running the set up with out a crash for 2 weeks 24/7.

Also try and turning off the 5 band processor in SAM 3 becuase it will eat up all of your resources and ram as well as cpu.If you need some presets for the AGC in SAM 3 i will give them to you.
So again don't use SAM 3 encoders.

If you have anymore questions on setting up sam 3 just ask and i will help you get set up and running correctly with sam 3.

I understand SAM3 is a hog. It always has been but I didn't have this problem with 1.40. Or, at least, it wasn't as severe as this since turning to 1.42.

This aslo doesn't explain why everything can be hunky dory for over 24hrs and then the problem occurs not once, not twice, but 3 times in the past 4 hours. Nothing has changed on the system and there are no additional resources being used.

It also doesn't explain why I can run a SHOUTcast server via SAM and the bitrate stays smooth as silk all the time.

I may be daft but wouldn't that mean there's something in the way Streamer is handling incoming encoders, not how SAM is handling them?

During the time I've been typing this I watched the bitrate climb to 99k and it's slowly working back down...it's now at 87k.

I say again. This wasn't as big a deal, nor did it happen nearly as often with 1.40.

Ok i see your point,with SAm 3 mine does the samething with streamer the bitrate goes up and down and never stays at a constant bitrate.When i use a shoutcast server it stays at the bitrate i put in the encoder.

From what i was told that in streamer the bitrate goes up and down to adjust to the listeners bandwidth.And yes it is streamer that is handling the enocders bitrate adjusting them contantly it is not SAM 3.There is nothing you can do about that at all no matter what you do within streamer.

What happens is when you first start your encoders in SAM 3 and then streamer the bitrate jumps up high and then gradulely the bitrate drops down again to near what you set in the SAM encoder.It is to the fact that you are using streamer and it is P2P.

My advise to you is to uninstall streamer make sure the folder is deleted also then restart your PC and then try it again.

Next thing is does SAM 3 crash does SAM 3 give you any errors in the event logs if so what are they? or is it streamer that crashes only and not SAM 3?

I think since 1.42 has been released I've uninstalled and reinstalled it 3 or 4 times (clean). SAM3 is running fine with no issues. The only error message I get in SAM's event log is the one stated in the first post on a Streamer crash.

The bitrate doesn't go high on an encoder start. As a matter of fact it's quite stable for long periods of time. Again, there was always a little fluctuation in the bitrate with 1.40 but nothing to this extent. When I was broadcasting at 80k on 1.40 I never saw the bitrate go over 90. That's why these numbers of over 150 and 160 are so disturbing with 1.42.

I've backed down the bitrate to 64k and I've also started anotehr copy of Streamer to serve dial up at 18k and they've both been running fine with no fluctuation more than a few kbps for almost 3hrs now.

P.S. - I still love Streamer and have NO intention of going *elsewhere* because, frankly, *elsewhere* sucks compared to Streamer.

I"m stumpped. No clue here but keep shippin' the reports. THe more info the better.

Yes in My initial set up which was IDENTICAL to my 1.40 set up using WINAMP oddcast Q +0.80,
My bitrate was UNCONTROLLABLE,

I have Since toned it down to a Q setting of 0,8 and is very stable now, encoder runs at 61-65 and stream runs at 60-67 tops, I have also tried Q setting 0,6 and that to is stable, Shame to cuz I had finally found what I thought was the BEst sound my stream had had at +0.80 and without the LIMIT feature in the bitrate config NOW this is unusable to me...

OH well, Lower rate it is...

ALSO NOTE to KMEAT, the CRASHING while de-tuning an ACP stream is still existant in my player setup.

so I for one wont be tuning in any acp streams it kills my whole winamp.

thanks guys for all your hard work...

OUT!

STRIKE MY PREVIOUS POST

Today after streaming succesfully for over 24 hours, Upon a reboot and a fresh start I cannot control my bitrate, I HAVE CHANGED NO SETTINGS and am playing the EXACT same playlist as yesterday
MY Bitrate is NOW uncontrollable, as high as 117K froma 61K stream , This is happening as I type this has been applied back down to as low as 50K three times now and is right back over 80K allready.

I sure miss the LIMIT feature in the old version.
if anyone has any suggestions , aside from lowering my Q setting yet again, which I am not to fond of as this is the LOWEST setting I have ever streamed at now. I would appreciate it.

thank you in advance...