[vlc-devel] contributing to jvlc development / bug: vlc destruction fails in jvlc
abethke at oamk.fi
Wed Aug 5 13:42:42 CEST 2009
we're using vlm via jvlc in a java server app and it's a nice approach
of doing things. Over the last half a year I got a bit more acquainted
in how the whole jvlc and jna thing works. However we're having some
basic problems with jvlc that we can't solve.
I have no idea where to post a bug report about that,
https://trac.videolan.org/jvlc seems to be dead, I get a 404 on that
one. Filippo are you still around somewhere? I appended a small bug
I would like to get more involved with jvlc, especially with the vlm
bindings. I still have a patch lying around here that implements
exception handling for the vlm that I would want to commit, but there
are still too many problems with the jvlc in master before that makes
sense to commit.
Recently I sent a still pending patch to fix the jvlc instantiation, as
the instantiation with DOPEN_GLOBAL option was only possible with a
patched jna and seemed to work good without that option. I would further
like to implement bindings for the new vlm events and get more
information flow between vlm and jvlc.
However, I will need some help regarding the more advanced jna stuff and
how some things are supposed to work, and I will not be able to maintain
the whole jvlc by myself. So please Fillippo, contact me so we can
discuss the future development of jvlc.
Best Regards, Alex
Here a small bug report:
There's a problem with vlc instance destruction in jvlc. Whenever
release() in JVLC is called, the vm crashes with
java: control/media_player.c:411: libvlc_media_player_release: Assertion
When one comments out mediaListPlayer.release() from the release method,
most of the time the destruction works, but randomly some destructions
still fail with that message, even though mediaListPlayer.release()
wasn't called in jvlc, libvlc_media_player_release must be called
somewhere natively. The assertion error does not appear when
instantiating vlc natively via the vlc executable.
We have a hunch, that the this commit could have something to do with
The problem already randomly occurred earlier revisions of vlc (since
May), but since recently (June/July) it appears on every destruction.
To reproduce: Run VLMTest as a unit test, the vm will crash with the
error after every test method.
More information about the vlc-devel