MediaPlayer does not quit

[vidrep]

Played a video file in MediaPlayer After conclusion of the video, I quit MediaPlayer MediaPlayer continues running in taskbar I attached a debug report to the running app Had to kill MediaPlayer from Team Monitor to stop it.

[vidrep]

hrev49547 x86_gcc2

[vidrep]

Had it happen again today after playing an .AVI file, using hrev49591 x86_gcc2. I have attached a debug report, syslog, and some ProcessController screenshots in case they are of use in finding the problem.

[vidrep]

Had it happen again today. It doesn't matter the media file type. First attached debug report was with .MTS file Second with .AVI Third with .MP4

[Barrett]

What is your latest working rev? In particular it would be useful if you can check if it has been added in hrev49503.

[ttcoder]

@vidrep Screenshot2 (with the full CPU usage in pathmonitorloop) is a different matter, it's the other ticket that you filed, which I was following too; it happened to me once yesterday too: 100% CPU usage in that thread, though this time I had fully functional keyboard and mouse. In fact I didn't even notice it right away (I should take the habit of checking the ProcessController CPU gauges right after boot hmm). Anyway might be worth posting an update to that other ticket, to say the symptoms have evolved somewhat.

@Barrett Had never seen this bug before, but this started happening to me on the laptop, after I updated it yesterday to 49625 (from an old 48xxx). I have slightly different symptoms though; maybe it would help if I file a separate ticket ?

Overview:

• happens to SoundPlay, not MediaPlayer
• SoundPlay does disappear from deskbar
• when opened in Debugger, I see only 2 threads left: main thread, and _BMediaRoster_
• (edit) if I click "debug" on both running threads, I see that:
• the main thread is stuck in QuitRequested()
• the roster is blocked in acquire_sem()
• (edit) this occurs when quitting mid-song, didn't try quitting at the end of playback yet

[vidrep]

I was using yesterday's nightly build hrev49629 x86_gcc2.. In my previous ticket I had noted that one CPU was pegged during the time MediaPlayer was exhibiting this behaviour. I did not take note of whether it was happening or not yesterday.

[vidrep]

ttcoder, Can you add a comment to the 100% CPU ticket #11280, as I have seen this evolve as well. Thanks.

[ttcoder]

Can a commiter/admin add me to the Cc field of this ticket, I keep forgetting about it and almost filed a new one; this should also be in the beta1 milestone I believe, seeing how it's 100% reproducible for some (both on my desktop and laptop)

[Barrett]

Can you give me more informations about the bug? I mean how much time it take to happen. Actually for a 10/20 minutes video it doesn't happen here.

[ttcoder]

SoundPlay won't quit : stuck on roster and main thread

[vidrep]

All of the clips were short duration <5 minutes, which were allowed to play in their entirety. After closing the Media Player main interface, you can see that the app is still running in the desk bar. The only way to stop it is to kill it from Team Monitor. Media type in each case was combined video/audio, of various format types (mp4, mov, avi). I have not noted whether it also happens with audio only files (e.g. audio CD etc.). I can try that later today after work.

[ttcoder]

@vidrep I wouldn't want to 'mix up' my issue in your ticket if it's not the same as you; what you could do is provide a more detailed backtrace, like I did above: next time MediaPlayer is stuck, throw it in Debugger as you did in the very first message, but before invoking "create report" first select the BMediaRoster thread and click "Debug" to stop it from running.. And then you can create the report -- which will then include the roster backtrace for comparison purposes.

@Barrett Truth be told, MediaPlayer is not what I use to reproduce this -- only saw it remaining stuck a few times, and only on my desktop. SoundPlay however, remains stuck on both the desktop and laptop. Here's how I do it:

• launch SP
• quit it (it does not)
• throw in in Debugger, stop the two threads, and create a report.

[vidrep]

Replying to ttcoder:

@vidrep I wouldn't want to 'mix up' my issue in your ticket if it's not the same as you; what you could do is provide a more detailed backtrace, like I did above: next time MediaPlayer is stuck, throw it in Debugger as you did in the very first message, but before invoking "create report" first select the BMediaRoster thread and click "Debug" to stop it from running.. And then you can create the report -- which will then include the roster backtrace for comparison purposes.

I have been trying to figure out how to properly use Anevilyak's debugger from the guide he provided. Any tips are greatly appreciated. Thanks!

[vidrep]

Just in case Rene reads this thread, may I suggest creating a "Haiku Debugger Guide for Dummies" with some simple but useful tips for creating a useful report in these kind of situations.

[ttcoder]

hi vidrep, don't panic it's exactly the same report you did in comment:1, but with one extra button click, bolded below:

• reproduce the bug (MediaPlayer freeze)
• right-click the CPU gauge in deskbar, choose Threads/CPU-usage > MediaPlayer
• in the alert that pops up, click Debug This Team
• select the BMediaRoster thread, and click Debug
• invoke menu Tools > Save Debug Report

[vidrep]

"Panic" - hardly. Confused - somewhat :) ttcoder, it may be worthwhile to collaborate on some of these media kit related tickets "off the record" so as to not introduce extraneous comments (like this). Fire me a email: vidrep@…

[ttcoder]

Stuck MediaPlayer report (with backtraces)

[ttcoder]

Seems to happen (to MediaPlayer) more often here than first realized, so I can contribute a .report for MP, with backtraces for the interesting threads.

The MediaPlayer video in control thread is stuck inside BBufferGroup::ReclaimAllBuffers() and indeed the corresponding semaphore's count seems to be 3 or 4, but not sure how to interpret that (a semaphore can only be 'acquired' when == 0 ?).

The other threads are stuck in various flavors of Lock().

[Barrett]

Thanks a lot guys for being so supporting!

I've solved it but need some more time to test everything as i worked to fix also other problems with BMediaNodes reference count and lateness. I will commit it in the next days.

[ttcoder]

I think I've (accidentally) found an easy way to reproduce this in a deterministic way. This is likely similar to what you've found out, Dario, but here it is just in case: if one forgets to delete a BSoundPlayer before quitting the app, thus leaving it to resource tracking/deleting to take care of it, the system waits until sound playback completion.

In other words, write a simple app that does new BSoundPlayer(..) and new BMediaFile(..) on an mp3 song, do all the connecting between them and Start(), then send yourself B_QUIT_REQUESTED without cleanly stopping the mp3 and boom. The app disappears from the deskbar, but not from the team listing (and the song continues playing in the background). Not a show stopper though; to the contrary it reminds me to write clean code ;-)

[Barrett]

I guess it's a kind of a different problem which I am considering those days, BeOS required to have a BApplication object to use the BMediaRoster, in Haiku there's not apparently this limitation.

It would have been a good addition but here the problem, there are situations where the BApplication exit but the BMediaRoster doesn't receive the Quit() command because the linker do it only when the static vars of libmedia.so are unloaded, this will not happen if we have already some node running. Other than this, there may be more serious problems, if the node is using an app_server's BBitmap and the be_app is destroyed before the BMediaNode the result will be a crash due to a debugger call arguing that we don't have a valid app_server link happening when the node delete the objects.

So actually i am going to consider how to solve this problem definitely, we can't do this in the B_QUIT_REQUESTED mechanism because we should have a BApplication but it's not required to Run(), so probably the best place is the BApplication destructor. The best way is supposedly to notify the BMediaRoster with a B_QUIT_REQUESTED itself, but I am already in research phase.

[Barrett]

Fixed in hrev49662.