Hi All,
I’m trying to integrate VLC player through VlcDotNet wrapper in a local copy of Xibo 1.8-beta project…
It seems work correctly for an undefined time (both with video and streaming contents) but, after a while, the application ends with “Application Hang B1” error…
I’m not expert unmanaged code integration and multithreading programming (but this could be a good opportunity to improve my poor skills ).
Do you thing that running VLC Wrapper in a dedicated Worker Thread could be a possible way to solve this issue?
Firstly i’d like to say that this is a very interesting enhancement!
It is very difficult to comment on your implementation without being able to see it - you could fork in github and upload your branch? I’d happily take a look at it.
Oh how such an enhacement would make a lot of people happy. I would certianly love to see such a feature if you are willing to share your work when finished.
You sign into your GitHub account and visit the xibosignage/xibo-dotnetclient repository and press “Fork” at the top. That will fork into your own GitHub account, which you can edit and push your changes to.
We can then create a Pull Request which will compare your fork with the main repo code, which we can review together.
Hi @dan, there are a lot of dll(s) of libvlc (unmanaged code) that are needed to run VLC. Have I to push them on GitHub?
Or maybe is better to use VLC standard installation, asking to user to specify installation path? If yes, should be done in the option form? Or at CMS level in ProfileMonitor?
The best thing to do would be to use a package manager to pull in those dependencies - which mean they only appear in the repo in packages.config, but for anyone building the project they would be downloaded and included in /bin at build time.
Perhaps there are NuGET packages for libvlc ?
It would also be better to use a package manager so that you could guarantee the version of the dlls which would be included - relying on a user install for this is not usually a good idea (because they could have all sorts of different versions)
A NuGET packages for libvlc doesn’t exist. NuGet packages exist for VlcDotNet wrapper and it has been already included through packages.config.
In my opinion, it should work as per Win Media Player: it should be installed. The only difference is that you should specify a location path if it is different from the default location…
So the vlcdotnet wrapper doesn’t include the DLL’s it wraps?! Did you have to manually install VLC to get the libvlc dlls?
Sorry for the questions, I just don’t think it is a good idea to reference “any version the user has installed” - I am sure that will break. If you say that the only way is to request an install location, then that is the way we would have to go I think.
The windows media player DLL’s are provided with the application (although only the linking ones I suppose). - see the wmpdll folder.
Xibo is compatible with the GPL, so I think it would be OK to redistribute. I would be more comfortable if we added a section to the licence dialog in the About form to mention that the software includes libVLC.
Exactly!!!
Maybe could be better try another wrapper… or an ActiveX solutions…
Anyway, if you agree I can push my bugged version (without DLL and a static for now reference to default VLC path) if you (or someone else) want to examine my code, let me know…
).
:
