Winamp stops playing after more than 24 hours of running

[Rafcio]

This seems like a resource leak problem and it's been there always (3.x.x? first version I tried). Here is the detailed description.

Host: Windows 7 x64 SP1
Guest: Windows XP Pro SP3

Winamp (latest version 5.621, much older version 5.24 tried with the same result) is configured for mp3 streaming (however with streaming turned off the same problem exists) using Icecast2 (v2.3.2) and Edcast (3.1.21). The mp3 files that Winamp plays are shared through VBox shared folder from the host. The audio is muted (it's meant for network streaming) and without a network traffic (streaming turned off for testing) the same problem happens. The problem is that after some time (AT LEAST 24 hours of continuous playing, but usually less than 48 hours) Winamp stops playing. It seems to respond to shut down (window closes), but it reamins in the task list and has to be killed. Restarting Winamp doesn't fix the problem. Winamp starts up, but it won't play anything at all. The VM (guest) has to be rebooted to clear the problem.

It seems to be a problem with a resource leak of some sort or some other limit reached (shared folder reaching transmission limit ;) ). It doesn't seem to be a problem with audio resources (because sound it is muted by Winamp) or a network resource limit (with or without network traffic same problem). Actually on the same host there is another XP guest running P2P client, transmitting copious amount of data daily and there is no problem whatsoever with that one. So networking issue can be safely excluded.

A physical box with almost identical configuration (with more stuff installed on the physical box) has no problem. Winamp streams mp3 music for weeks at at time without being touched at all. This proves that the configuration I have is sound (I've been streaming music for many years already) and the problem (whatever it is) is on the VBox side. Winamp is not to be blamed here.

[Rafcio]

Log file from the VM with a problem

[vasily Levchenko]

Do you see the same effect if you loop the single track stored in vm image?

[Rafcio]

I haven't tried that, but I can just about any test, because I can't put this system in "production". I will report on the test outcome, meanwhile it is not the shared folder issue I think. When Winamp stops playing I can still copy mp3 files from the shared folder into "local" folder using Windows Explorer.

[vasily Levchenko]

Replying to Rafcio:

I haven't tried that, but I can just about any test, because I can't put this system in "production". I will report on the test outcome, meanwhile it is not the shared folder issue I think. When Winamp stops playing I can still copy mp3 files from the shared folder into "local" folder using Windows Explorer.

It would be better to remove any dependencies (e.g. shred folders), to simplify the picture. Just single file looped in winamp.

[Rafcio]

A limited testing with single local looping file shows so far that it makes no difference. However, this testing reminded me about one very important piece of information that I forgot to mention at the beginning.
Winamp does not suddenly stops playing. It gradually progresses from good to unusable. On the server side there is one important phase before it stops playing. Still, it usually needs more than 24 hours to get to this phase, but its behavior may shed some light on what the problem may be.
During that phase before it fails Winamp plays files at about 4x the normal speed, therefore indicating it loses its timings, whatever those timings are. This phase lasts several hours at least.
On the server side this is about all I observed, but on the client side (with streaming enabled) there are more phases, so I will list them, but I'm not sure if this information will be helpful.
Client phase 1. Everything normal.
Client phase 2. Re-buffering occurs at the beginning of each song.
Client phase 3. Occasional breaks in the middle of the songs, but the playback continues.
Client phase 4. Playback is short (1-2 minutes or less) and then it stops. Has to be manually restarted and the cycle continues, cannot be sustained. This phase corresponds to the sped up playback on the server.
Client phase 5. Client is unable to connect to the stream. This corresponds to the phase where Winamp stops playing obviously.

[Rafcio]

The results of the testing with a single local track being looped indicate that Winamp continues to play beyond the usual time it died (usually less than 48 hours), which possibly indicates the problem is with the shared folder. However, I was still able to copy songs from the shared folder into local folder using Explorer after Winamp refused to play them. So, the issue is more obscure than I initially thought.

[vasily Levchenko]

Thanks for reporting, I've tried similar test (locally looped soundtrack in Winamp) but on Mac host and have got result you posted initially no sound on the guest after (~24h), but it looks like differ from observation you've made when the guest play music on Windows host. Have you stopped your last test (locally looped), and could you check that sound won't affected after yet another 24 h?

[Rafcio]

A test with looping a local track (a long one, about 70 minutes) is still going. I did upgrade the host to the version 4.1.4 in the meantime, but I doubt that this has a fix for the problem. I'm testing the local looping with streaming now. A previous test where Winamp was playing shared songs, but was subsequently switched to local track while it was still good (less than 24 hrs after starting playback) showed that the playback died within its usual time. That's why I said that limited testing with local track didn't make any difference. However, when local track is looped after rebooting the VM the playback still continues and it's been more than 3 days already. I'm not sure what you asked me to test this time? Stop the playback for 24 hours and resume after that time to see if it will be playing? Also, should I resume with the local track or shared tracks? I'm not clear about the test to perform, so could you explain your request?

[vasily Levchenko]

Replying to Rafcio: the reason of the local looped test is to identify location of the problem is it in our audio device emulation or in shared folders. As I understand in your case locally looped sample plays fine more then 48hrs, when on shared folder sources it dies in ~24h, right?

[Rafcio]

Correct. If the local song is played exclusively in Winamp it will play possibly indefinitely. It's been about 4 days and the local song is still playing. However, if first shared songs are played and then switched to local song while Winamp is still OK, it will play initially fine, but it will stop playing within 48 hours. Strange. I believe that the audio device emulation should have nothing to do with the problem, because the sound is muted for the entire time.

[Frank Mehnert]

Does anything change if you use the PIIX3 chipset (not the ICH9 one)?

[Rafcio]

Nope, the same result. I did some more testing comparing apples to apples this time. With one (long) track being looped it doesn't matter if the track is local or shared through VirtualBox folder. It will play indefinitely, which would indicate a problem inside the VM and not the shared folder. Previously I never tested looping one track from shared folder, so it was assumed that it is the same as playing many tracks. It turns out not to be the case. So, it takes more than one track to have Winamp fail after about of day of playing. Why is that different than playing one track continuously? I don't know. I also tested multiple tracks shared though Windows shared folder (as opposed to VirtualBox shared folder) and the outcome was the same - Winamp stops playing. So this proves that it doesn't matter what the source is, after a little more than a day of playing multiple tracks Winamp will fail to play until the VM is rebooted. I think the important thing to pay attention to is the fact that before Winamp completely stops playing, it plays for couple of hours at vastly (about 4x) increased speed, which would indicate it has trouble with timing. At that time it still can read the music from the source (whatever it is), but cannot play correctly. For me that symptom would be something to troubleshoot.

[Rafcio]

Any progress on this issue? Any additional tests that I can do? Actually, you have far more experience and tools at your disposal to nail this bug if you recreated the problem in your environment, but I'd still like to help to speed up the resolution of this issue. The latest release of VirtualBox isn't any better, in fact there may be some regression as it seems to me that the clients start to experience issues described previously as phase 2 and 3 sooner after the VM is rebooted than previously. This isn't a hard fact, rather a loose observation, but I'd like to report it anyway.

[Frank Mehnert]

I have no update but in the meantime there were some VirtualBox releases. Could you try if you still can reproduce this problem with the latest release (4.1.22 or 4.2.0)?