[vlc-devel] Re: Multiple instances of vlc have incorrect instance references (vlc on windows unstable?)

[Tony Anecito]

Hi Filippo,
   
  I got past the peer issues finally for at least the use case where you select a child that was not initially selected then you select and bring to front the selected child.
   
  Two more things I noticed and had to fix:
   
  1. When getting the jvlc instance in the in the button action code after getting the file always re-get the jvlc instance from the JVLCCanvas by doing a getJVLC() against the JVLCCanvas. Seems even though I did what I thought was a reinitialization against the JVLC for the canvas I had a panel with where in some action code for a button where I was loading the jvlc playlist object and it had the old reference which would cause the jre to crash.
   
  2. After addNotify for the canvas the canvas size was reset to o length and width.
   
  I added the code for creating a new JVLC instance in the addModify method. The example of what I have so far is:
   
  public void addNotify() {
  super.addNotify();
  
  // if jvlc was destroyed from prior
  // removeNotify then replace it and reset boolean
  if (jvlc.beingDestroyed) {
  jvlc = new JVLC(options);
  jvlc.video.setActualCanvas(this);
  try {
  reparent();
  } catch (Exception ex) {
  System.out.println("JVLCCanvas.addNotify() exception:" + ex);
  }
  // remove after adding new code to save original dimensions
  setSize(200, 200);
  bRemovedPeer = false;
  }
  // remove after adding new code to save original dimensions
  setSize(200, 200);
  }
   
  I have a bit of more codeing before I can use it in my app but it is 3:00AM here and I need to go to work tomorrow.
   
  Hope it helps,
  -Tony
  

Tony Anecito <adanecito at yahoo.com> wrote:
    Hi Filippo,
   
  I figured out what causes the crash and why you might want to think about the change in destroy() method for JVLC.java.
  Seems whenever destroy is called a second time on the libvlc it causes the jvm to crash from what I could tell in the thread dumps. It will always be called a second time because of the finalize method for the jvlc class.
  So in the finalize class you might want to consider detecting if destroy was already called. If not then call the destroy method.
   
  So for the finalize() method I did this:
   
  /*
  * (non-Javadoc)
  * 
  * @see java.lang.Object#finalize()
  */
  protected void finalize() throws Throwable {
  if(!beingDestroyed) {
  destroy();
  }
  super.finalize();
  }
   
  Seems to work well.
   
  Regards,
  -Tony



Filippo Carone <filippo at carone.org> wrote:
  Tony Anecito ha scritto:
> Hi Filippo,
> 
> Are you going to verify the destroy method logic? I had someone
> verify the method was correct for the 8.6 but somehow the logic since
> then has been changed such that destroy will not work.

There was an error actually, which should now be fixed (_destroy was 
never called in destroy...).

> There are still issues to be resolved like streaming for
> instance. Have you fixed that yet? I was hoping you would have that
> resolved by now so others can use steaming via the api. I am getting
> more emails from people that want to use the jvlc api but there are a
> few important issues left to resolve like streaming.

If for streaming you mean VLM, I mailed the vlc developer who started 
the rework of VLM to check what is the current status of the job. Just 
be patient for a few days still.

Cheers,
Filippo

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html


    
---------------------------------
  Be a better Heartthrob. Get better relationship answers from someone who knows.
Yahoo! Answers - Check it out. 

       
---------------------------------
Ready for the edge of your seat? Check out tonight's top picks on Yahoo! TV. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20070514/baf97de3/attachment.html>