The VideoLAN Forums

Before I get flamed for not doing a search first - I have done a search and found many instances of people asking the same question... all with no clear answers.

So I'm repeating the question with the plea that someone please answer this clearly!

I'm running fedora core 1 (fc1) with a 2.4.19 kernel (which shouldn;t matter). I've downloaded, built and installed all the newest sources for ffmpeg, libmpeg2, libmad, libid3tag, wxwindows and vlc (0.8.2) - on 2 different boxes. I configured ffmpeg with --enable-gpl and --enable-pp. I configured vlc with --enable-wxwindows.

I always get the same result.

I do have a wxwindows plugin. I have moved all the correct startup files to ~/.vlc (as you'll see from the debug output). Vlc comes up with a beautiful OSX skin (I know because I also have a Mac at home and the skin is a perfect match), but I can;t get to ANY dialog boxes - preferences or file open.

What's going on?! Can somebody please provide a straight answer.

Here's the startup debug output:

VLC media player 0.8.2 Janus
[00000001] main vlc debug: opening config file /root/.vlc/vlcrc
[00000001] main vlc debug: checking builtin modules
[00000001] main vlc debug: checking plugin modules
[00000001] main vlc debug: loading plugins cache file /root/.vlc/cache/plugins-04041e.dat
[00000001] main vlc debug: recursively browsing `modules'
[00000001] main vlc debug: recursively browsing `/usr/local/lib/vlc'
[00000001] main vlc debug: recursively browsing `plugins'
[00000001] main vlc debug: module bank initialized, found 179 modules
[00000001] main vlc debug: opening config file /root/.vlc/vlcrc
[00000000] main root debug: VLC media player - version 0.8.2 Janus - (c) 1996-2005 VideoLAN
[00000000] main root debug: libvlc was configured with ./configure --enable-wxwindows
[00000001] main vlc debug: translation test: code is "C"
[00000001] main vlc debug: opening config file /root/.vlc/vlcrc
[00000001] main vlc debug: checking builtin modules
[00000001] main vlc debug: checking plugin modules
[00000001] main vlc debug: loading plugins cache file /root/.vlc/cache/plugins-04041e.dat
[00000001] main vlc debug: recursively browsing `modules'
[00000001] main vlc debug: recursively browsing `/usr/local/lib/vlc'
[00000001] main vlc debug: recursively browsing `plugins'
[00000001] main vlc debug: module bank initialized, found 179 modules
[00000001] main vlc debug: opening config file /root/.vlc/vlcrc
[00000001] main vlc debug: CPU has capabilities 486 586 MMX MMXEXT SSE SSE2 FPU
[00000001] main vlc debug: looking for memcpy module: 3 candidates
[00000010] main module debug: using memcpy module "memcpymmxext"
[00000223] main playlist debug: waiting for thread completion
[00000223] main playlist debug: thread 16386 (playlist) created at priority 0 (src/playlist/playlist.c:152)
[00000224] main private debug: waiting for thread completion
[00000224] main private debug: thread 32771 (preparser) created at priority 0 (src/playlist/playlist.c:174)
[00000225] main interface debug: looking for interface module: 1 candidate
[00000103] main module debug: using interface module "hotkeys"
[00000225] main interface debug: interface initialized
[00000225] main interface debug: thread 49156 (interface) created at priority 0 (src/interface/interface.c:211)
[00000227] main interface debug: looking for interface module: 2 candidates
[00000227] skins2 interface debug: Using character encoding: ANSI_X3.4-1968
[00000230] main dialogs provider debug: looking for dialogs provider module: 0 candidates
[00000230] main dialogs provider error: no dialogs provider module matched "any"
[00000227] skins2 interface error: No suitable dialogs provider found
[00000227] skins2 interface debug: found skin /root/.vlc/skins2/default.vlt
[00000227] skins2 interface debug: Cannot open directory share/skins2
[00000227] skins2 interface debug: found skin /usr/local/share/vlc/skins2/default.vlt
[00000142] main module debug: using interface module "skins2"
[00000227] main interface debug: interface initialized
[00000227] main interface debug: thread 65541 (manager) created at priority 0 (src/interface/interface.c:196)
[00000227] skins2 interface debug: Using skin file: /tmp/vltlBz24o/theme.xml
[00000231] main private debug: looking for xml module: 1 candidate
[00000157] main module debug: using xml module "xtag"
[00000227] skins2 interface debug: Using catalog /root/.vlc/skins2/skin.catalog
[00000231] xtag private debug: catalog support not implemented
[00000227] skins2 interface debug: Using DTD /root/.vlc/skins2/skin.dtd
[00000227] main interface debug: creating access '' path='/tmp/vltlBz24o/theme.xml'
[00000233] main access debug: looking for access2 module: 4 candidates
[00000233] vcd access debug: trying .cue file: /tmp/vltlBz24o/theme.cue
[00000233] access_file access debug: opening file `/tmp/vltlBz24o/theme.xml'
[00000021] main module debug: using access2 module "access_file"
[00000238] main private debug: pre buffering
[00000238] main private debug: received first data for our buffer
[00000227] skins2 interface: skin: VLC OSX Interface author: BigBen
[00000227] skins2 interface debug: Loading font /root/.vlc/skins2/fonts/FreeSans.ttf
[00000239] main decoder debug: looking for decoder module: 18 candidates
[00000097] main module debug: using decoder module "png"
[00000241] main private debug: looking for video filter2 module: 2 candidates
[00000241] ffmpeg private debug: input: 424x152 RV24 -> 424x152 RV32
[00000241] ffmpeg private debug: libavcodec initialized (interface 4718 )
[00000016] main module debug: using video filter2 module "ffmpeg"
[00000227] skins2 interface debug: Loading font /tmp/vltlBz24o/FreeSansBold.ttf
[00000227] skins2 interface debug: Loading font /tmp/vltlBz24o/FreeSansBold.ttf
[00000097] main module debug: unlocking module "png"
[00000016] main module debug: unlocking module "ffmpeg"
[00000157] main module debug: unlocking module "xtag"
[00000021] main module debug: unlocking module "access_file"
[00000227] skins2 interface debug: Loading theme configuration
[00000227] skins2 interface debug: Saving theme configuration
[00000001] main vlc debug: removing all interfaces
[00000227] main interface debug: thread 65541 joined (src/interface/interface.c:238)
[00000142] main module debug: unlocking module "skins2"
[00000225] main interface debug: thread 49156 joined (src/interface/interface.c:238)
[00000103] main module debug: unlocking module "hotkeys"
[00000001] main vlc debug: removing all playlists
[00000224] main private debug: thread 32771 joined (src/playlist/playlist.c:206)
[00000223] main playlist debug: thread 16386 joined (src/playlist/playlist.c:207)
[00000001] main vlc debug: removing all video outputs
[00000001] main vlc debug: removing all audio outputs
[00000001] main vlc debug: removing announce handler
[00000010] main module debug: unlocking module "memcpymmxext"
[00000001] main vlc debug: opening config file /root/.vlc/vlcrc
[00000001] main vlc debug: saving plugins cache file /root/.vlc/cache/plugins-04041e.dat

According to vlc you do not have the wxwindows module installed:
To make sure, if you start with vlc -I wx, do you get the wxwindows interface instead of the skins interface? You should.
That is a VERY meager configure line for VLC. Please read the configure and compilation guide for linux. http://developers.videolan.org/vlc/nix-compile.html

thanks for replying so quickly. much appreciated.

i understand that vlc doesn't think i have wxwindows installed but i don't know why. vlc -I wx doesn't work, btw.

and yes, i also understand that my config line was meagre, but configure was happy and double-checking my config.h showed that the defaults for everything else sufficed for an initial minimally functional build (minimal at least insofar as the defaults are concerned).

i've been scouring through the forums looking for answers to this and finally got so discouraged that i simply went in to /usr/local/lib/vlc/gui and swapped the 2 plugin modules... and voila! up came wxwindows under the guise of skins2... so i know wxwindows is working, and i know that the plugin module was built and installed correctly.

so why can't i tell/configure vlc to use it?

just an addendum:

now i can't switch it back to skins2 (unless i swap the plugins again).

bizarre...

i'll take a look in the source code when i get a chance - maybe tomorrow. there must be something there that's either building the module name wrong or something...

another addendum:

interestingly, swapping the 2 gui modules and forcing vlc to use wxwindows just one time, created an entry in vlcrc for wxwindows that wasn't there before (i know, i looked):

[wxwindows] # wxWindows interface module

# Embed video in interface (boolean)
#wxwin-embed=1
# Show bookmarks dialog (boolean)
#wxwin-bookmarks=0
# Show taskbar entry (boolean)
#wxwin-taskbar=1
# Minimal interface (boolean)
#wxwin-minimal=0
# Size to video (boolean)
#wxwin-autosize=1
# Show systray icon (boolean)
#wxwin-systray=0
# last config (string)
wxwin-config-last=(-1,0,0,1024,768)(0,149,215,404,81)


i swapped the modules back to their original file names and now the -I switch works perfectly - i can now go back and forth between skins2 and wxwindows!

go figure.

anyway, maybe posting the wxwindows entry from my vlcrc file will help somebody else. i honestly can't say if that was the trick or not, but its appearance after getting the wxwindows interface to come up once certainly is interesting. maybe, all one has to do is add the [wxwindows] line to the rc file...?

btw, now when i run vlc -vvv, it's loading 180 modules instead of 179.

and i now see both wxwindows modules in my --list output:

wxwindows wxWindows interface module
wxwindows wxWindows dialogs provider


thanks for the link. i know i do need to rebuild vlc to support some other things, like .png files, etc., so i'll be checking out the document for what i need. that'll be helpful.

If you want to make sure whether the added section in the config really changed something, just try to remove it. If the problems happens again, then this was important... and it would mean that there is a bug in the code!

Seems like an out of date vlc plugin cache file actually. Vlc was installed without wxwindows. the plugin cache is created, vlc is recompiled, the plugin cache doesn't see the difference with the new version (same version id's etc) and therefore isn't updated. posing the plugin as another name, forced it to load (which incidently also forced a rebuild of the cache because vlc detected that the skins2 module had changed considerably) and that did the trick.

yes. partly. except that vlc was never installed without wxwindows. the fc1 distro didn't have vlc, i never tried to install it from an rpm and built/installed wxwindows in response to what configure told me it needed... so vlc was never run before before wxwindows was built and installed.

but i definitely agre that the problem is the cache file and that by posing the plugin it forced the cache file to be rebuilt.

i went thru the same process at home last night on my laptop and got the same result.

that last one was me. apparently i wasn't logged in.

anyway, i guess my concern here is the sheer number of people who seem to be having the exact same problem. this isn't a one-of issue, it seems to be pandemic with this release. my search of the forum on this topic brought up 15 pages of postings and each page listed 30 or 40 related issues - and i'm sure i didn't find all of them. it was frustrating enough for me and i'm a seasoned systems developer. i can only imagine how impossible this might seem to someone with no background in development and/or who struggles at best when it comes to building and installing linux source packages.

perhaps the problem isn't in the method by which vlc is being built and installed, but in the way the cache is initially being built by vlc. it seems to me that skins2's dependency on wxwindows is not being recognized, and because skins2 is the default startup interface, the initial cache is bad/wrong.

perhaps the answer is to do what the windows version does which is to make the wxwindows interface the default interface, instead of skins2. if the initial start does not use skins2 and the onus is on the user to switch over to skins from the plainer wxwindows interface, that would force-initialize the cache to recognize the wxwindows dialogs provider from the start.

otherwise, i'd say that there appears to be a bug in the way the cache is created when skins2 is used as the default startup interface...?

it might be interesting to take a look at the code that creates the initial/new cache and see what it does when skins2 is the current interface at the time. i can guess that what it does is that it investigates the current loaded gui plugin and caches what it finds. since the skins2 gui plugin does not provide a dialogs provider, none is found and therefore no dialogs provider is cached... but i didn't develop it, so i can't say for sure until i look at it personally, or hear it from someone who knows the code. i could be wrong and it could be that there's some kind of conflict somewhere that prevents vlc from properly analyzing its plugins and their dependencies under certain conditions. i will take a look at the code over the next few days and i'll let you know what i find - there's something not quite right in there somewhere.

...and i'm talking about what happens with a fresh install here, not an overwrite of an existent install. fresh linux distro + downloads/builds/installs of required libraries + new build of vlc - a brand new, virgin, never-been-run-before build and install.

Looking at the code, the skins2 interface has a priority of 30.
The wxwindows one has a priority of 150 if the DISPLAY environment variable is set, otherwise its priority is 15.
Conclusion: the skins2 interface is not necessarily the default one, it depends on your environment. Could you tell us if in your case the DISPLAY variable is defined?

Of course, the code of the plugins cache may be buggy. But what i don't understand is why it didn't work at your very first try. Since you installed VLC on a system where it was not present, you didn't have any plugins cache, and for the first run the loading of the modules must have been effective. Even if the skins2 interface was the default one, the wxwindows module would have been loaded, and therefore there would have been a dialog provider... which was apparently not the case
How to solve this contradiction?

yes, DISPLAY is set which would give wxwindows a priority of 150 - which, i assume, is why i got the skins2 interface by default...?

apparently, the wxwindows module did not get loaded on first run - or subsequent runs for that matter - until i forced it to do so by fooling it into loading what it thought was the skins2 interface. it didn't even load it when i told it to load it (vlc -I wx). after a cache entry was created for wxwindows (by fooling/forcing it), it worked perfectly from then on out.

so apparently the issue is somewhere in the code that does the initial cache creation.

i may have some time on and off over the next couple of days to dig in and take a look - unless you find it before i get a chance to.

i'd probably want to look at how the code establishes module dependencies. even if skins2 has been selected as the interface module, how is its dependency on wxwindows determined? how does it know to also load the wxwindows module? why would it not have loaded wxwindows? or, at least have known that it needed a dialogs provider module?

taking a broader look at the issue, perhaps dialogs provision and interface provision should be physically separate modules and not just logically separate functions. i understand why you'd probably want these two functionalities to be separate from on another, but maybe this is the crux of the problem...? maybe the software needs to look not only for an interface provider, but also for a dialogs provider - if the interface provider doesn't provide dialogs.

i dunno. i haven't looked at the source code, so i'm speculating as i'm heading out the door on my way home for the day. i'd think though, that there must be some logic in there that would have to determine whether or not certain important features have been loaded - but, maybe there's not and maybe it was intended to be that way.

anyway, gotta go. i'll check back later.

Just in case :

Are you sure that both wxGTK and VLC were compiled with the same version of gcc/g++ ? I have a similar problem because of the C++ ABI change in gcc 3.4

positive. the only version of gcc/g++ i have installed is 3.3.2.

yes, DISPLAY is set which would give wxwindows a priority of 150 - which, i assume, is why i got the skins2 interface by default...?

No, the default interface is the one with the highest priority, so it is wxwindows in your case.

so apparently the issue is somewhere in the code that does the initial cache creation.

Maybe there is a problem in the cache creation, but then it's not the only one, because in the first run the plugins cache could not interfere...

taking a broader look at the issue, perhaps dialogs provision and interface provision should be physically separate modules and not just logically separate functions. i understand why you'd probably want these two functionalities to be separate from on another, but maybe this is the crux of the problem...? maybe the software needs to look not only for an interface provider, but also for a dialogs provider - if the interface provider doesn't provide dialogs.

I don't know exactly how the plugins cache works. But here are some precisions about the modules.
There is a predefined list of modules types. For example: audio output, audio filter, video output, video filter, interface, interface provider, access, muxer, demuxer, visualisation, ... For example, the skins2 module is of type interface.
You can declare several modules (generally called submodules) in the same .so. For example, the wxwindows .so contains a module of type interface and another one of type interface provider.

When VLC starts, all the modules are loaded (we suppose there is no plugins cache, since it was your first installation of vlc). One of the threads will contain the interface, so the core looks in the loaded modules which ones have the interface type, and among them which one has the highest priority. In your case, both wxwindows and skins2 should have been loaded, so the wxwindows interface should have been launched. Conclusion: your wxwindows module was not loaded at all, for some reason.

Since wxwindows was not loaded, the interface module with the highest priority was the skins2 one. This one needs a dialog provider to work correctly (because we didn't want to duplicate code for the dialogs), so it asks one to the core. Currently, the only module of type interface provider is the second module defined in the wxwindows .so. As it was not loaded either (the contrary would have been surprising...), the skins2 module complained about the missing interface provider.

So far, the plugins cache is not responsible of anything. If you have a way to uninstall/reinstall vlc and reproduce the problem, it would be interesting to see why the wxwindows module is not loaded (you can probably see it running 'vlc -vvv'). It might be due to the version of g++, as Rémi suggested above.

besides, there doesn;t seem to be a problem with the module. once i forced the entry into the cache by fooling it into thinking wxwindows was skins2, then even after i undid the spoof, vlc was able to load and use wxwindows perfectly well. i can now switch back and forth between them as i should have been able to do from the start.

(reply to ipkiss)

i hear you re your explanation of modules vs. sub-modules and the various module types. it seems to me though, that dialogs provider might be better defined as a module type rather than a sub-module type since it provides such an important task in terms of how vlc functions. no matter the interface, without dialogs, the program is practically useless (i say practically since it is possible that someone might not want/need dialogs if it's only used/called via the command line). but, i can also see that it makes sense to potentially associate a specific dialogs provider with its matching interface provider which i assume must have been the logic behind the way it was done.

thank you for your responses though. if i get into the code to look for this, your insights will be useful to direct me to the source files i'd have to look at.

Sorry, i wrote "interface provider" everywhere instead of "dialogs provider" in my previous post. But dialogs providers are actually a module type, the only instance being the wxwindows module (in a submodule, but there is no real difference between a module and a submodule afaik).

right.

i assume though, that if one wanted to, one could develop a skins2 dialogs provider, even though at this point in time there is only a wxwindows dialogs provider... which is why (again, supposition) the dialogs provider was designed to be an optional sub-module - so that one doesn't have have to develop a dialogs provider to match the interface provider.

anyway, i think we need to rid ourselves of all the suppositions and assumptions. it looks like i'll have less time today and tomorrow than i thought i would, but i do have a long weekend coming up and this has piqued my curiosity, so i'll dig in when i can and take a look at the module interfaces, how they're analyzed and how the subsequent analysis is then used when building the initial cache. i'll try deleting the cache file first to see if that's enough to get me back to where i started.

there must be something implicitly skewed in the logic that builds the initial cache file - and those kinds of errors are hard to find. it's not a bug, per se, but something needs to be tweaked to properly load a missing dialogs provider when none is available from the selected interface provider- essentially, if there's an interface provider, there must be a dialogs provider somewhere, even if it's in another module, or an error condition should exist. there has to be some sort of implicitly recursive logic to handle that condition... whatever that piece of code is, it seems to be broken under certain conditions, like initial startup. there isn't a problem once the dialogs provider module is located and its location is cached.

in other words, the logic that locates and loads the dialogs provider seems to work perfectly well when working from the cache, but has a problem when building the cache from scratch when multiple interface providers are available, but only one of them has a dialogs provider.

anyway, i think i understand the process, but have no vision, yet, of the details. so, to the code i must go...

i assume though, that if one wanted to, one could develop a skins2 dialogs provider, even though at this point in time there is only a wxwindows dialogs provider... which is why (again, supposition) the dialogs provider was designed to be an optional sub-module - so that one doesn't have have to develop a dialogs provider to match the interface provider.

"dialogs provider" modules are not more optional than other modules. If the wxwindows dialogs provider module is declared in the same .so as the wxwindows interface module, it is only because they share code and it would have been stupid to duplicate that code between 2 .so. But you can very well imagine a stand-alone module, of type dialogs provider, and implemented using Qt for example. If this module had a higher priority than the wxwindows one, it would be used by the skins2 interface instead of the wxwindows one.
So the last part of your sentence quoted above doesn't mean anything

in other words, the logic that locates and loads the dialogs provider seems to work perfectly well when working from the cache, but has a problem when building the cache from scratch when multiple interface providers are available, but only one of them has a dialogs provider.

Well, i'm not yet convinced of that, but until you find a way to reproduce the bug we won't really know...

anyway, i think i understand the process, but have no vision, yet, of the details. so, to the code i must go...

I will list some particularly interesting files in a subsequent post, later today.

Here is a short list of relevant files to get you started:
- src/misc/modules.c: modules and cache handling, in the core
- modules/gui/wxwindows/wxwindows.cpp: declaration of the wxwindows interface and wxwindows dialogs provider. The most important macro is probably set_capability().
- modules/gui/skins2/src/skin_main.cpp: declaration of the skins2 interface (and of the skins2 loader demux, btw).
- modules/gui/skins2/src/dialogs.cpp: search of a dialogs provider (via a call to module_Need()). This code is called indirectly in skin_main.cpp:202.

thanks for the direction. i did take a quick look inside this afternoon after i read your posting and can see at least how the modules are created. i want to take a closer look at the higher level initialization process, although now i can't reproduce the issue. i haven't gone to the extreme of actually uninstalling the software yet, but everything up to that point doesn't seem to do it... which is interesting in and of itself - might suggest something that's not software-related.

i do have one other virgin linux box at home i may have to try it on if i can't reproduce the issue any other way, although i'd be perfectly happy to back out of everything i installed to try to make it happen. it's easy enough to rebuild/reinstall.

later.

I got the same pb. with FC4 and Package videolan-client.i386 0:0.8.2-3.2.fc4.rf from Dries,

I switched to vlc-0.8.2-0.lvn.3.4 from http://rpm.livna.org and all works fine

To make it work I had to install:

• libcdio-0.75-3.fc4.i386.rpm
  libdvbpsi-0.1.5-0.lvn.1.4.i386.rpm
  vcdimager-0.7.23-2.2.fc4.rf.i386.rpm
  vlc-0.8.2-0.lvn.3.4.i386.rpm
  wxGTK2-2.4.2-12.i386.rpm
  wxGTK-common-2.4.2-12.i386.rpm

I hope this helps

-fk

Could you explain me the procedure to do this ....I'm not so sure to understand you right and I don't like to do a mistake . Thank you in advance .

Well, download the files (you should be able to find them through Google quite easily) and run "sudo rpm -i" on each file. You might need to install some before the other because they depend on each other, but the command-line will tell you that.