View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002633 | MMW v4 | Player | public | 2006-09-06 16:12 | 2007-09-03 14:30 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 3.0 | ||||
| Summary | 0002633: Validate: MM crashes when listening to an OGG stream and there's a network problem | ||||
| Description | User reported a crash when listening for a couple of hours to: http://www.digitaldancefloor.com/x/ (choose 'High Voltage' in Winamp/OGG format). I was able to reproduce this as well. Sent debug log via e-mail. | ||||
| Additional Information | User also indicated: New problem - something is happening to hold up the UI thread, and locking up the application when it has some problem either connecting or disconnecting from a stream... I am sure that the web operations are implemented asynchronously, however there is still some problem where the UI thread is doing something that causes it to freeze, perhaps waiting for resource. I was playing the DI.fm site's stream, and am having some sort of network problem where the stream is interrupted. I'm not sure what is happening at the network level at the moment. The stream was playing, it stopped, I reactivated MM from the systray icon with a double click. the bar was bouncing back and forth as if it were trying to reconnect to the site, so i pressed the X button to stop it. Within about 10 seconds, the UI froze and I have to kill the app using process explorer. I think it may be reproducible if you use a firewall to cut off or greatly delay the network traffic flow while attempting to connect to or disconnect from an internet radio station. there looks to be something in the ui thread that gets blocked when a network error occurs. this seems to happen on a very frequent basis for me. i think if you just unplugged the network cable that it might not exhibit the same behavior. perhaps the tcp session has been established but then cut off? then its sent a request and is waiting for a reply that is long delayed or may never arrive - something like that perhaps. ---------------------- Update: I am using the Microsoft ISA firewall client, don't know if that is significant - probably not because the app doesn't know anything about it. however, the ISA firewall server array sometimes gets overloaded and stops sending data for a few seconds (30-60 sometimes) and this seems to cause the issue. if you can make your connection flakey or really slow, that could do it. I did get another crash yesterday, but I wasn't running the debug version. first one in a week or so I think. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1066 | ||||
|
|
I tested with this and also another stream, but wasn't able to reproduce the problem by disconnecting from Internet. Waiting for more details... |
|
|
I was able to replicate the problem. Same thing is happening with MP3 Streams. Even I use large output buffers in MM and ZoneAlarm Security Suite I was able to simulate internet Lock, and UI locks 20 Seconds after internet lock is engaged due to output buffer length. Thats why Player got locked after 20 secnods and soon after so the UI. It seams that input plugin tries to connect to stream (endlessly) even there is no stream and connection to stream is down. Solution should be that input plugin close play in case that Output plugin request filling of buffer. In case I use http://otachan.com/in_!mpg123.html it skips to next song in playlist after some time. Updated: If there is no problems with Internet Stream while OUtput plugin buffer is played everything is working without problems, tested on 4 hour basics. |
|
|
I still can't reproduce. Peke, could you try to debug the plug-in? |
|
|
Peke confirmed the bug but can't solve it. Re-assigning to Ludek. |
|
|
The only (hopefully similar) way I was able to reproduce: While I was programming podcast managing and one of a podcast's episode was playing as a stream, my brother interrupted internet connection for some reason -> MM freezed at that moment for almost 3 minutes. I started up debug view and caught a debug lines after refreshing MM activity. The lines are: 00000000 0.00000000 [3852] Winamp sim - WM_USER message 603 00000001 0.00017293 [3852] Winamp sim - WM_USER message 603 00000002 0.00194382 [3852] Winamp sim - WM_USER message 603 00000003 0.00204244 [3852] Going to play file: http://podcast.wfmu.org/CG/cg061017.mp3 00000004 0.00215251 [3852] Plugin c:\MediaMonkey\Plugins\in_wmp3.dll can play http://podcast.wfmu.org/CG/cg061017.mp3 00000005 0.00334288 [3852] Winamp sim - WM_USER message 603 00000006 0.00341384 [3852] Going to start playback. 00000007 0.00502131 [3852] Winamp sim - message left to the default processing 00000008 0.00512104 [3852] Winamp sim - message left to the default processing 00000009 0.00595439 [3852] Winamp sim - WM_USER message 603 00000010 0.00617145 [3852] Winamp sim - WM_USER message 603 So it looks like that the problem occurs before entering an input plugin, Peke please could you confirm this or post a debug logs to our FTP? |
|
|
Yes I can Confirm that that was same error. |
|
|
I have posted a new debug log to the FTP where MM freezed for 2630 seconds, see the log named "stream freezing 25th sec.LOG" and see the 25th second. It freezes after the line 'Going to stop playback in dll: c:\MediaMonkey\Plugins\in_wmp3.dll'. Another thing is that MM also freezed after line 'Player: There is a problem in playing this file, try the next one' in another log, but this doesn't seem to be reproducable. The former is reproducable (log named "stream freezing 493th sec.LOG", "stream freezing 2099th sec.LOG"), but only on my notebook when I'm connected by a wireless connection which is quite unstable, unfortunately I cannot debug in_wmp3.dll cause I'm missing <wmsdk.h> to compile the plugin. |
|
|
I have been trying to debug the in_wmp3.dll plugin. Only that I have been able to found out is that this freezing causes the WaitForSingleObject() procedure. Strictly speaking: WaitForSingleObject(m_EvClosed, MAXWAITTIME); // in HRESULT Close() is cause of the freezing. Also (WaitForSingleObject(thread_handle, INFINITE) == WAIT_TIMEOUT) // in void Stop() causes freezing , but only for 20 seconds. |
|
|
Jiri, do you think that decreasing of MAXWAITTIME will be enough or do you have any other ideas? |
|
|
WaitForSingleObject(m_EvClosed, MAXWAITTIME); shouldn't cause freeze, because it has a maximal limit of execution 10 seconds. Also, I thought that the issue was originally about some AV, not freezing? In any case, if MM stays on this line longer than necessary (i.e. MAXWAITTIME), we should find out _why_ does it happen, what can we do about it. |
|
|
Yes, I see that you are right , i.e. MAXWAITTIME is set to 10 seconds. But I must correct myself, because the debug line was the one line above i.e. before if (SUCCEEDED(m_Reader->Close())) WaitForSingleObject(m_EvClosed, MAXWAITTIME); So it is probably that m_Reader->Close() causes the freezing, but it seems to be an internal method of WMSDK, I'm going to re-test this. |
|
|
After re-testing I can confirm that m_Reader->Close() causes the freezing. But I found out that also _endthread(); causes freezing after the successful executing of previous line PostMessage(mod->hMainWindow, WM_WA_MPEG_EOF, 0, 0); Note: Both this freezings seem to be infinite. Reproducibility: The former is casued by performing the sequence of actions Play, Stop on a mp3 stream. The latter is caused by performing another sequence of actions: Play, Pause. But as I wrote I used a wireless connection which is very unstable otherwise it doesn't seem to be reproducible. |
|
|
Ok, if it freezes here, I wonder what it does meanwhile in the other thread, the one that reads HTTP stream from file - ReadThread() and Read() functions in HttpStream.cpp. Does there happen any kind of dead-lock? |
|
|
I cannot reproduce it at all now. Probably it has been already fixed by fixing another issues (there has been some changes made). Marked as resolved until someone is able to reprocude it. |
|
|
Can't replicate any crashes (though I can replicate endlessly repeating audio for OGG streams--documenting this in another bug). |
