Opened 15 years ago
Closed 14 years ago
#6216 closed bug (invalid)
mediaplayer close all windows does not work
Reported by: | samui | Owned by: | stippi |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Applications/MediaPlayer | Version: | R1/alpha2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
tested on hrev37184. 256mb of mem, intel i5 2.6ghz
open a few videos and try to close them all from tracker - medplayer - close all. none of the videos will close. Closing mediaplayer wont work either.
closing the windows manually will leave mediaplayer in zombie mode that wont close unless you force it to.
killing mediaplayer from process controller crashes media add on server (bt attached).
Attachments (1)
Change History (3)
by , 15 years ago
Attachment: | closeMedPlayerCrash.png added |
---|
comment:1 by , 14 years ago
Description: | modified (diff) |
---|
comment:2 by , 14 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Note:
See TracTickets
for help on using tickets.
The ticket "as is" is not valid. I can open many videos and use the "Close all windows" feature from Deskbar. MediaPlayer will close just fine. This ticket is more likely a duplicate of another ticket, which is concerned with locking up the AudioProducer node, which when it happens prevents MediaPlayer from quitting properly. In some instances, MediaPlayer will quite after quite a bit of time passed, in some instances media_addon_server will crash. The root cause of the problem is that some codecs return a keyframe which is very far away from the frame that MediaPlayer wants to play, and the long seek operation causes the AudioProducer to run out of buffers (which hints at a second problem). This in turn can sometimes crash the audio mixer which is running in the media_addon_server team and that would be a third problem. The bt attached shows it has actually not crashed, but dropped purposefully into the debugger. Unfortunately the debugger message is not seen in the picture, but I guess it will not be hard to find out. Since I am pretty sure that the actual issue is tracked in another ticket, I am closing this one, since it is based on the wrong conclusion.