Winamp Crashing, But M3W Works

[vahost]

The good news is that I finally got my new radio station up-and-running, if not actually broadcasting anything of value. I can even get it to stay up long enough for YP to include it.

But that only happens when I use M3W instead of Winamp.

The bad news is if I try to use Winamp with the DSP plug-in instead of M3W, it crashes at various points in time.

It crashes sometimes when I try to change the input source to Winamp (Recommended) from the microphone.

It crashes sometimes when I play a song, at the end of the song.

It crashes sometimes when a playlist ends.

I set up logging, and here is what I got:

2012-09-19 14:47:47 Logging starting
2012-09-19 14:47:55 Logging stopping
2012-09-19 14:48:00 Logging starting
2012-09-19 14:48:00 Not Connected
2012-09-19 14:48:03 Logging stopping
2012-09-19 14:48:51 Logging starting
2012-09-19 14:48:51 Not Connected
2012-09-19 14:52:46 Connecting
2012-09-19 14:52:46 Sending Cipher request
2012-09-19 14:52:46 Cipher Response received
2012-09-19 14:52:46 Cipher Response received. Try enabling 'SHOUTcast v1 mode'.
2012-09-19 14:52:46 Receiving Authorization Response
2012-09-19 14:52:47 Sending Content Type
2012-09-19 14:52:47 Response received
2012-09-19 14:52:47 Sending Bitrate
2012-09-19 14:52:47 Response received
2012-09-19 14:52:47 Sending max Payload size
2012-09-19 14:52:47 Response received
2012-09-19 14:52:47 Sending Flush
2012-09-19 14:52:48 Response received
2012-09-19 14:56:30 Logging starting
2012-09-19 14:56:32 Not Connected

The entries that seems weird to me in this list are the Cipher request and response. The server I installed is the latest version of Shoutcast DNAS, SC_SERV v2 Build 29. So I don't understand why it would try to connect as if connecting to a v1 server.

Very frustrating. Any ideas why this is happening?

[DrO]

what version of the Source DSP and Winamp have you installed? as v2.3.0 and v5.63 (respectively) are the current versions at the time of this reply (and that log doesn't look like a v2.3.0 Source DSP output). and crashing when changing from Winamp to soundcard mode is a known issue with all of the 2.2.x builds of the Source DSP.

and the message is not saying it's trying to connect in v1 mode but that something is preventing it from connecting in v2 mode. without proper details of what you're using, i'm not going to guess what might be going on.

-daz

[vahost]

It says I've got 2.2.3 of Source DSP and 5.63 of Winamp.

Wow! I just downloaded that from the Shoutcast Broadcast Now page just a few days back. Did 2.3.0 just come out?

Oh well.

Okay, I just upgraded Source DSP to v2.3.0 and tried again.

Once again when I waited for the song to end, the program crashed.

Here's the full log. I have it set to not rewrite on restart.

2012-09-19 14:47:47 Logging starting
2012-09-19 14:47:55 Logging stopping
2012-09-19 14:48:00 Logging starting
2012-09-19 14:48:00 Not Connected
2012-09-19 14:48:03 Logging stopping
2012-09-19 14:48:51 Logging starting
2012-09-19 14:48:51 Not Connected
2012-09-19 14:52:46 Connecting
2012-09-19 14:52:46 Sending Cipher request
2012-09-19 14:52:46 Cipher Response received
2012-09-19 14:52:46 Cipher Response received. Try enabling 'SHOUTcast v1 mode'.
2012-09-19 14:52:46 Receiving Authorization Response
2012-09-19 14:52:47 Sending Content Type
2012-09-19 14:52:47 Response received
2012-09-19 14:52:47 Sending Bitrate
2012-09-19 14:52:47 Response received
2012-09-19 14:52:47 Sending max Payload size
2012-09-19 14:52:47 Response received
2012-09-19 14:52:47 Sending Flush
2012-09-19 14:52:48 Response received
2012-09-19 14:56:30 Logging starting
2012-09-19 14:56:32 Not Connected
2012-09-19 15:05:56 Connecting
2012-09-19 15:05:56 Sending Cipher request
2012-09-19 15:05:56 Cipher Response received
2012-09-19 15:05:56 Cipher Response received. Try enabling 'SHOUTcast v1 mode'.
2012-09-19 15:05:56 Receiving Authorization Response
2012-09-19 15:05:56 Sending Content Type
2012-09-19 15:05:57 Response received
2012-09-19 15:05:57 Sending Buffer size
2012-09-19 15:05:57 Response received
2012-09-19 15:05:57 Sending max Payload size
2012-09-19 15:05:57 Response received
2012-09-19 15:05:57 Sending YP Information
2012-09-19 15:05:57 Sending Flush
2012-09-19 15:05:57 Sending Standby
2012-09-19 15:07:31 Logging starting
2012-09-19 15:07:33 Not Connected
2012-09-19 15:07:56 Connecting
2012-09-19 15:07:56 Sending Cipher request
2012-09-19 15:07:56 Sending Authorization
2012-09-19 15:07:56 Receiving Authorization Response
2012-09-19 15:07:56 Sending YP Information
2012-09-19 15:08:31 Logging starting
2012-09-19 15:08:34 Not Connected
2012-09-19 15:09:31 Connecting
2012-09-19 15:09:31 Cipher Response received
2012-09-19 15:09:31 Cipher Response received. Try enabling 'SHOUTcast v1 mode'.
2012-09-19 15:09:31 Sending Authorization
2012-09-19 15:09:31 Receiving Authorization Response
2012-09-19 15:09:31 Response received
2012-09-19 15:09:32 Sending Bitrate
2012-09-19 15:09:32 Response received
2012-09-19 15:09:32 Sending max Payload size
2012-09-19 15:09:32 Response received
2012-09-19 15:09:32 Sending YP Information
2012-09-19 15:09:32 Response received
2012-09-19 15:09:47 Logging starting
2012-09-19 15:09:49 Not Connected
2012-09-19 15:11:07 Connecting
2012-09-19 15:11:07 Sending Cipher request
2012-09-19 15:11:07 Cipher Response received
2012-09-19 15:11:07 Cipher Response received. Try enabling 'SHOUTcast v1 mode'.
2012-09-19 15:11:08 Sending Authorization
2012-09-19 15:11:08 Receiving Authorization Response
2012-09-19 15:11:08 Sending Content Type
2012-09-19 15:11:08 Response received
2012-09-19 15:11:08 Sending Bitrate
2012-09-19 15:11:08 Response received
2012-09-19 15:11:08 Sending max Payload size
2012-09-19 15:11:08 Response received
2012-09-19 15:11:09 Sending Flush
2012-09-19 15:11:09 Response received
2012-09-19 15:14:24 Logging starting
2012-09-19 15:14:26 Not Connected
2012-09-19 15:14:51 Connecting
2012-09-19 15:14:51 Sending Cipher request
2012-09-19 15:14:51 Cipher Response received
2012-09-19 15:14:51 Cipher Response received. Try enabling 'SHOUTcast v1 mode'.
2012-09-19 15:14:51 Receiving Authorization Response
2012-09-19 15:14:51 Sending Content Type
2012-09-19 15:14:51 Response received
2012-09-19 15:14:52 Sending Buffer size
2012-09-19 15:14:52 Response received
2012-09-19 15:14:52 Sending max Payload size
2012-09-19 15:14:52 Response received
2012-09-19 15:14:52 Sending Flush
2012-09-19 15:14:52 Sending Standby
2012-09-19 15:29:33 Logging starting
2012-09-19 15:29:35 Not Connected
2012-09-19 15:32:44 Logging stopping
2012-09-19 15:33:14 Logging starting
2012-09-19 15:33:14 Not Connected
2012-09-19 15:34:10 Connecting to... Server: 50.23.131.82; Port: 8000; Mode: v2; Stream ID: 1; DJ / User ID: n/a
2012-09-19 15:34:11 Cipher Response Received
2012-09-19 15:34:11 Cipher Response Received. Try enabling 'SHOUTcast v1 mode'.
2012-09-19 15:34:11 Sending Authorization
2012-09-19 15:34:11 Receiving Authorization Response
2012-09-19 15:34:11 Sending Content Type
2012-09-19 15:34:11 Response Received
2012-09-19 15:34:11 Sending Buffer Size
2012-09-19 15:34:11 Response Received
2012-09-19 15:34:12 Sending YP Information
2012-09-19 15:34:12 Sending Flush
2012-09-19 15:34:12 Sending Standby
2012-09-19 15:44:31 Not Connected
2012-09-19 15:44:37 Connecting to... Server: 50.23.131.82; Port: 8000; Mode: v2; Stream ID: 1; DJ / User ID: n/a
2012-09-19 15:44:37 Sending Cipher Request
2012-09-19 15:44:37 Cipher Response Received
2012-09-19 15:44:37 Cipher Response Received. Try enabling 'SHOUTcast v1 mode'.
2012-09-19 15:44:37 Sending Authorization
2012-09-19 15:44:37 Receiving Authorization Response
2012-09-19 15:44:37 Sending Content Type
2012-09-19 15:44:37 Response Received
2012-09-19 15:44:37 Sending Bitrate
2012-09-19 15:44:38 Response Received
2012-09-19 15:44:38 Sending Maximum Payload Size
2012-09-19 15:44:38 Response Received
2012-09-19 15:44:38 Sending Flush
2012-09-19 15:44:38 Response Received
2012-09-19 15:51:36 Logging starting
2012-09-19 15:51:36 Not Connected

Any ideas?

[DrO]

v2.3.0 came out last week (as noted in the sticky thread for the current tools in this sub-forum and in the discussion forum) but only went on the main page today.

firstly, have you changed / set uvoxcipherkey in your DNAS config - if so then remove that line. that can lead to cipher errors (and the docs do mention not to change it unless you know what and why to change it)


secondly, have you set requirestreamconfigs=1 in the DNAS config but don't have a streamid=1 or streamid_1=1 - if yes then add streamid=1 to your config file. that can also cause this issue but the DSP doesn't get a real reason for it happening with the build of the v2 DNAS you're using (the next one plays better by sending back more helpful responses to the source to be able to reflect such things).


otherwise, making sure you've got the correct password for the stream is all i can suggest to re-check i.e. if you've got a streampassword_1 or just streampassword line then that is the password to use, otherwise it should just be what is set for 'password'.

-daz

[vahost]

Originally Posted by DrO

v2.3.0 came out last week (as noted in the sticky thread for the current tools in this sub-forum and in the discussion forum) but only went on the main page today.

firstly, have you changed / set uvoxcipherkey in your DNAS config - if so then remove that line. that can lead to cipher errors (and the docs do mention not to change it unless you know what and why to change it)


secondly, have you set requirestreamconfigs=1 in the DNAS config but don't have a streamid=1 or streamid_1=1 - if yes then add streamid=1 to your config file. that can also cause this issue but the DSP doesn't get a real reason for it happening with the build of the v2 DNAS you're using (the next one plays better by sending back more helpful responses to the source to be able to reflect such things).


otherwise, making sure you've got the correct password for the stream is all i can suggest to re-check i.e. if you've got a streampassword_1 or just streampassword line then that is the password to use, otherwise it should just be what is set for 'password'.

-daz

Thanks for the ideas to check.

Unfortunately, none of those settings are configured in the DNAS. I'm using very basic settings in the DNAS.



I have to admit that I don't understand why the above settings would cause Winamp to crash. Which only shows how little I understand this particular technology, I suppose.

[DrO]

when you say crash, do you actually mean the Winamp process completely stops or do you mean that the DSP just doesn't connect?

if Winamp is crashing then a plug-ins list (http://forums.winamp.com/showthread....161361#plugins) is really needed as none of what you are describing should be happening.

also might be an idea to pm me your configuration file and in the morning (assuming the DNAS is still running), i'll have a look / try to connect to the DNAS to see what i can find.

-daz

[vahost]

Originally Posted by DrO

when you say crash, do you actually mean the Winamp process completely stops or do you mean that the DSP just doesn't connect?

if Winamp is crashing then a plug-ins list (http://forums.winamp.com/showthread....161361#plugins) is really needed as none of what you are describing should be happening.

also might be an idea to pm me your configuration file and in the morning (assuming the DNAS is still running), i'll have a look / try to connect to the DNAS to see what i can find.

-daz

Yes, the Winamp process completely stops.

I've been using two different configuration files, both with the same result. I'll pm both of them to you.

I'm trying to do some of the things that were crashing Winamp, so I can check the Windows logs for any useful information.

My first attempt, I let the song run out with Repeat set to Playlist. It didn't result in a crash this time.

My second attempt, I tried to change the input from Winamp to the Mic, and that did it. Here's what I found in the App log:

Faulting application Winamp.exe, version 5.6.3.3235, time stamp 0x4fec7b3e, faulting module lame_enc.dll, version 0.0.0.0, time stamp 0x4f4d4fa7, exception code 0xc0000005, fault offset 0x00003deb, process id 0x1658, application start time 0x01cd96bd9e036a4d.

And next in the log:

Fault bucket 3163491309, type 1
Event Name: APPCRASH
Response: None
Cab Id: 2010878763

Problem signature:
P1: Winamp.exe
P2: 5.6.3.3235
P3: 4fec7b3e
P4: lame_enc.dll
P5: 0.0.0.0
P6: 4f4d4fa7
P7: c0000005
P8: 00003deb
P9:
P10:

Attached files:
C:\Users\Walt\AppData\Local\Temp\WER5DCF.tmp.version.txt
C:\Users\Walt\AppData\Local\Temp\WER6DB8.tmp.appcompat.txt
C:\Users\Walt\AppData\Local\Temp\WER73F0.tmp.mdmp

These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Report13f2b6a8

My third attempt, I tried letting the song run out with Repeat: set to none. It behaved properly this time.

So I tried changing the Input from Winamp to the Mic again. This time, it worked properly.

So I tried changing the Input back to Winamp, and that worked to.

Then I tried once more to change the Input back to Mic, and it crashed. Same errors codes as above.

Interestingly, in contrast to previous crashes, this time Winamp wouldn't go away after I received the failure message. It simply failed to respond. I had to force the program to close.

I don't understand why the song running out isn't causing Winamp to crash anymore, but I guess maybe that's a good thing. I can't help but wonder if something was cached from before the DSP upgrade that might have caused the earlier symptom.

So if we can get rid of the crashing when the Input is changed, that would be a good thing.

[DrO]

that crash is in the lame encoder which is outside of what i can try to fix (especially as i've not been able to replicate crashes when toggling the input mode over the last few months of testing). as i cannot replicate it, i don't know what can be done to resolve that issue especially as i reverted the code changes which had seemed to lead to the input changing crash.

i've replied to the pm regarding the connection stability issue.

-daz

[vahost]

I've replied to your pm regarding the stability issue and followed your suggestion in that pm. Hopefully, stabilizing the DNAS will also end up solving the lame encoder issue as a side benefit.



Hey, it doesn't hurt to be optimistic!