Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - problem with MediaPlayer in 6.3.0: (4 Items)
   
problem with MediaPlayer in 6.3.0  
We have a customer who is complaining about a ConnectAttach call from MediaPlayer to devb-umass hanging.  Investigation 
has shown that the MediaPlayer thread has over 10000 channels open.  The kernel call scans the channels vector looking 
for a chance to re-use an existing channel before it locks, and this huge channels vector results in the call being 
continually preempted before it has a chance to complete.

Are there any known problems with MediaPlayer that can explain the large number of open channels?  Or is this normal 
behaviour?

Is this the right place to ask this question?

Thanks for any assistance.

Doug
Re: problem with MediaPlayer in 6.3.0  
For this project, this "Mediaplayer" is their own application using the old Multimedia TDK libraries (1.0.1)
RE: problem with MediaPlayer in 6.3.0  
Sorry, I didn't realize that.  That means the problem might be in their
own code, rather than in QNX code.  But, to be complete, does anybody
know of problems with files or side-channels being left open in the
Multimedia TDK libraries of that version? 

-----Original Message-----
From: Kevin Mar [mailto:community-noreply@qnx.com] 
Sent: Thursday, November 06, 2008 3:29 PM
To: general-multimedia
Subject: Re: problem with MediaPlayer in 6.3.0

For this project, this "Mediaplayer" is their own application using the
old Multimedia TDK libraries (1.0.1)

_______________________________________________
General
http://community.qnx.com/sf/go/post16138
Re: RE: problem with MediaPlayer in 6.3.0  
I saw something similar. libc.so doesn't include slogf. If you load an MMF DLL that calls slogf(), it gets its own copy 
of the code and creates opens an fd the first time it calls slogf(). If that dll then gets unloaded, the fd is leaked 
and remains open until the application terminates.

So if they are loading/unload DLLs on each track change, and those dlls call slogf() or any other slog call that is not 
in libc.so, they will leak an FD each one of those DLLs is unloaded.