#10129 closed bug (fixed)
MediaPlayer takes a long time to quit after playing a playlist a few minutes
| Reported by: | Kev | Owned by: | stippi |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Applications/MediaPlayer | Version: | R1/Development |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | x86 |
Description
on hrev46198 :
1) start MP 2) quit MP 3) main window goes away, but Deskbar entry remains. clicking it, it says "no windows" indefinitely, until you kill it.
Change History (12)
comment:1 by , 11 years ago
| Summary: | MediaPlayer zombies when quitting → MediaPlayer zombies when quitting if playlist items are on non-boot volume |
|---|
comment:2 by , 11 years ago
OK, this is really weird, I can't get it to do it anymore, but it had been doing it every time for a few days, and had never shut down properly on this hrev.
I was trying to narrow it down, so I cleared the playlist and added just one file from the non-boot vol. Worked. Added a second. Worked. Added half the album. Worked. Added the rest of the album. Worked! Cleared again, and added the folder by dragging and dropping, which is how I'd been doing it before. Worked! Unmounted and remounted the nonboot volume as read-only. Still worked! But for the longest time, read-only or not, clearing and remaking the playlist or not, it would zombie on shutdown. Hmm...
comment:3 by , 11 years ago
Okay, I got it to happen again, only after listening to music for a few minutes.
Also, I noticed this particular time that clicking the deskbar entry and then Quit from there actually worked (after brief delay, maybe 1 s), whereas I don't believe it did before the odd time I tried.
comment:4 by , 11 years ago
Ah, just did it again--it seems to be only after one song has finished playing and it has switched to the next. This time, deskbar's Quit Application did not work even after a few seconds.
comment:5 by , 11 years ago
Tried again with files copied onto boot volume, no trouble quitting.
comment:6 by , 11 years ago
Maybe I was impatient: this time it quit upon the Deskbar request (after a normal quit by clicking the upperleft square in the window, and the window disappearing) about 9 seconds after the request. This was playing a playlist off the boot volume for a few minutes, through about 6 tracks.
comment:7 by , 11 years ago
| Summary: | MediaPlayer zombies when quitting if playlist items are on non-boot volume → MediaPlayer takes a long time to quit after playing a playlist a few minutes |
|---|
This time it took about 15 seconds to shut down, after a few minutes of playing off the boot volume.
comment:8 by , 10 years ago
Just tried on hrev46295. Played a whole album. When it finished, clicked the yellow square on MP's tab. Took 19 seconds for the Deskbar entry to disappear. It almost seems to be proportional (if not directly) to how long MP has been playing.
comment:9 by , 10 years ago
Seems to have to do with actual playing time, too...I just launched MP, let it sit there for 30 minutes, and closed it, and it left the Deskbar immediately.
comment:10 by , 9 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Got the MediaPlayer to play some albums in loop for the whole night and it just closed as well. Fixed as of hrev49662.
comment:11 by , 9 years ago
I think this ticket may have been closed prematurely. I doubt that the problem was reproduceable on any installation. More likely some specific problems were triggered and the long closing time was a symptom (likely about time-outs when disconnecting nodes). Maybe it has to do with certain files in the playlist folders, maybe certain sound notifications had to run in addition to the playback, maybe it happened with certain file formats... it was never properly investigated.
In any case, I think it should be obvious that this problem didn't always manifest, since otherwise it would have been fixed already, no? Maybe this can be said about more MediaPlayer tickets that have been closed recently.
When code has been changed, I would hope that potential problems with the old code have been understood, and when reading tickets, there should be an understanding how these problems could have caused the ticket symptoms. One should be sure that it is now fixed with the new code. Just trying if one can reproduce the ticket is unlikely to be enough evidence about a fix.
comment:12 by , 9 years ago
I agree with all but I'm not going on a casual basis. I've had this issue months ago happening from time to time but it looks fixed now, at least during the latest weeks it seems solved on my system. I'm also trying to use a little different approach relying on user's feedback on tickets which have high probability to be fixed. I think if there's the eventuality that an issue isn't really fixed this way we can have more chances to get the current status on this system as things may have changed a bit. For example i doubt that some bug like "SetHeader" is still around, where i'm not sure about the "DataExchange" ones as they are related probably to the driver or multi_audio node. Additionally, i'm testing also on two different computers with the help of a friend. Some of them have been tested on VirtualBox too. But if you think it's premature to close it, I'm of course OK if you reopen it.
The above was with a single album folder in the playlist. The folder happened to live on a read/write-mounted, non-boot volume. The problem goes away if I copy that folder to the boot Desktop and play from there instead.