VLC 1.1.13 problems anyone?

[Dariusz Piatkowski]

The latest version of the OS/2 VLC player just got released...I downloaded
1.1.13, was previously using 1.1.11.

Here is the strange situation I'm seeing, I have the VLC frame running in a
separate window then the video playback. With 1.1.13 the video window frame
shows up fine and plays back fine, however the actual VLC window frame (where
all program controls exist) is nowhere to be found. Indeed, strange enough, on
my 4 core AMD Phenom II machine the CPU monitor goes crazy and I see all cores
firing endlessly. This is the sort of behaviour I have seen with Firefox when
not using "SET NSPR_OS2_NO_HIRES_TIMER=1" setting to avoid problems with the
high-resolution timer.

In comparison to 1.1.11, the player behaved just fine, no issues found and the
CPU utilization was negligent...barely any spikes. My Phenom is running at 4
GHZ, all four cores...so that is plenty of processing power.

When installing 1.1.13 I completely wiped out the previous version, so no file
conflicts should exist. Once I encountered the problem I also rebooted to rule
this out.

Has anyone seen this as well?

[Peter Brown]

Hi Dariusz

Dariusz Piatkowski wrote:
> The latest version of the OS/2 VLC player just got released...I downloaded
> 1.1.13, was previously using 1.1.11.
>
> Here is the strange situation I'm seeing, I have the VLC frame running in a
> separate window then the video playback. With 1.1.13 the video window frame
> shows up fine and plays back fine, however the actual VLC window frame (where
> all program controls exist) is nowhere to be found. Indeed, strange enough, on
> my 4 core AMD Phenom II machine the CPU monitor goes crazy and I see all cores
> firing endlessly.

I'm seeing the above with vlc 1.1.13 on a 2core system.

This is the sort of behaviour I have seen with Firefox when
> not using "SET NSPR_OS2_NO_HIRES_TIMER=1" setting to avoid problems with the
> high-resolution timer.
>
> In comparison to 1.1.11, the player behaved just fine, no issues found and the
> CPU utilization was negligent...barely any spikes. My Phenom is running at 4
> GHZ, all four cores...so that is plenty of processing power.
>
> When installing 1.1.13 I completely wiped out the previous version, so no file
> conflicts should exist. Once I encountered the problem I also rebooted to rule
> this out.
>
> Has anyone seen this as well?
>

I suggest sending a bug report about the problems, I've just submitted mine.

Regards

Pete

[John Varela]

On Mon, 26 Dec 2011 00:05:38 UTC, "Dariusz Piatkowski"
<dariusz@_NO-SPAM_mnsi.net> wrote:

> The latest version of the OS/2 VLC player just got released...I downloaded
> 1.1.13, was previously using 1.1.11.

I just checked for updates and the download is 1.1.12. Maybe .13 was
withdrawn.

--
John Varela

[Dariusz Piatkowski]

Hi Peter!

On Mon, 26 Dec 2011 01:04:45 UTC, Peter Brown <losepeteS...@ntlworld.com>
wrote:

I sent Ko an email, but let me look into the tickets as well...I'll look for
what you logged...no sense duplicating.

Thanks!

[Peter Brown]

Sorry, by "bug report" I meant I had sent an email to KO - not sure if
there is a bug tracker for this app anywhere...

Regards

Pete

[KO Myung-Hun]

Hi/2.

Dariusz Piatkowski wrote:
> The latest version of the OS/2 VLC player just got released...I downloaded
> 1.1.13, was previously using 1.1.11.
>
> Here is the strange situation I'm seeing, I have the VLC frame running in a
> separate window then the video playback. With 1.1.13 the video window frame
> shows up fine and plays back fine, however the actual VLC window frame (where
> all program controls exist) is nowhere to be found.

Do you mean you didn't check 'Preferences/Interface/Look and fee/Embed
video in interface' ?

> Indeed, strange enough, on
> my 4 core AMD Phenom II machine the CPU monitor goes crazy and I see all cores
> firing endlessly. This is the sort of behaviour I have seen with Firefox when
> not using "SET NSPR_OS2_NO_HIRES_TIMER=1" setting to avoid problems with the
> high-resolution timer.
>

Hmm... Strange. VLC 1.1.x does not use high-resolution timer at all.

> In comparison to 1.1.11, the player behaved just fine, no issues found and the
> CPU utilization was negligent...barely any spikes. My Phenom is running at 4
> GHZ, all four cores...so that is plenty of processing power.
>
> When installing 1.1.13 I completely wiped out the previous version, so no file
> conflicts should exist. Once I encountered the problem I also rebooted to rule
> this out.
>
> Has anyone seen this as well?
>

I'm sorry I cannot reproduce this problem at all.

But I want to confirm that this is a problem of a multi-core system. How
about disabling other cores except 1 core ?

Finally, I read your e-mail. However for the others encountering this
problem, I reply to newsgroup.

--
KO Myung-Hun

Using Mozilla SeaMonkey 2.0.14
Under OS/2 Warp 4 for Korean with FixPak #15
On AMD ThunderBird 1GHz with 512 MB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr

[Peter Brown]

Hi Dariusz

Dariusz Piatkowski wrote:

Do you have gcc446.dll somewhere on your libpath?

I installed it as it is required for the latest odin build and found vlc
now has a qt gui again.

If you do not have this dll file get it here
http://ignum.dl.sourceforge.net/project/ecsports/GCC%20Runtime%20DLLs/gcc446.zip


Regards

Pete

[Dariusz Piatkowski]

Peter!

On Mon, 26 Dec 2011 12:28:25 UTC, Peter Brown <losepeteS...@ntlworld.com>

> Sorry, by "bug report" I meant I had sent an email to KO - not sure if
> there is a bug tracker for this app anywhere...

LOL...sure enough....I went looking through the regular Netlabs interface, no
matter how high/low I looked...didn't find VLC there...so I'll await the news
here or an email response...thanks for clarifying that!

[Dariusz Piatkowski]

Hi KO!

On Mon, 26 Dec 2011 13:14:32 UTC, KO Myung-Hun <ko...@chollian.net> wrote:

> Hi/2.
>
> Dariusz Piatkowski wrote:
> > The latest version of the OS/2 VLC player just got released...I downloaded
> > 1.1.13, was previously using 1.1.11.
> >
> > Here is the strange situation I'm seeing, I have the VLC frame running in a
> > separate window then the video playback. With 1.1.13 the video window frame
> > shows up fine and plays back fine, however the actual VLC window frame (where
> > all program controls exist) is nowhere to be found.
>
> Do you mean you didn't check 'Preferences/Interface/Look and fee/Embed
> video in interface' ?

Actually, with this release, it appears that the previous INI file was either
not-detected, or ignored. I had always set the 'Embed video in interface' to OFF
(meaning, no check mark there), so yes, the answer to your question is : YES, I
did not have it checked.

But...as Peter Brown posted in another response, including gcc446.dll all of a
sudden makes VLC work just fine. This is how I discovered that the INI file I
had previously used was no longer being honoured and that setting I mentioned
above was now actually CHECKED...

12-16-11 4:01a 131447 124 gcc446.dll

> I'm sorry I cannot reproduce this problem at all.
>
> But I want to confirm that this is a problem of a multi-core system. How
> about disabling other cores except 1 core ?

OK, shutting OFF the 3 of the 4 cores (using SETPROC utility) and renaming
gcc446.dll to something else (thus making it inaccessible to the process) causes
the remaining single core to MAX out, running at 100% utilization. The video
still plays, but if I chose to close the window the VLC program itself continues
to run, still maximizing the core at 100% utilization. I then kill the process,
which does end it.

Now, as I mentioned above, Peter suggested adding gcc446.dll, sure enough, that
allowed VLC to function correctly on my system again, with a single or multiple
cores enabled.

OK, so here is what I noticed: the HELP=>About screen shows the following :
'...Compiler: gcc version 4.4.6 (GCC)...', so it certainly appears to me that
gcc446.dll is a requirement to run 1.1.13 successfully, and as best as I could
tell this was not listed in the README...so maybe just a missing piece of info,
no biggie really.

But I'm curious now, why does the missing DLL (gcc446.dll) cause such a
behaviour? The VLC control window is not displayed...and that makes sense, but
the weird core utilization spike is just so extremely similar behaviour to the
Firefox high-res timer issue...to the point that I'm curious what the do have to
do with each other. Is there anything I can do to help debug this? Could we
pursue this even though this is not a real VLC problem?

Thanks KO for the great work, as always!

-Dariuss

[Dariusz Piatkowski]

Hi Pete!

On Mon, 26 Dec 2011 13:48:45 UTC, Peter Brown <losepeteS...@ntlworld.com>
wrote:

Yup, you were right on the money here...gcc446.dll was missing on my
system...installing it allowed VLC to function correctly.

I responded to KO's post, I'm very curious why the behaviour with the missing
DLL...seems so awefully similar to my Firefox experience.

[Dave Yeo]

Dariusz Piatkowski wrote:
> Yup, you were right on the money here...gcc446.dll was missing on my
> system...installing it allowed VLC to function correctly.

Why do so many developers not link in gcc*.dll statically? We've pretty
well always done that with Mozilla (I screwed up the recently uploaded
SeaMonkey 2.6). The license allows it (GPL with linking exception, Peter
got Knut to update the Innotek licensing).
Just need to set GCCOPT=-static-libgcc or as I have, set GCCOPT=-pipe
-static-libgcc.

>
> I responded to KO's post, I'm very curious why the behaviour with the missing
> DLL...seems so awefully similar to my Firefox experience.

Must only be using a small function in gcc446.dll as it does actually
start. IIRC there are only a couple of small functions in gcc*.dll.
For comparison I built a SeaMonkey with gcc 4.4.6 forgetting to link
statically and it wouldn't even start with out gcc446.dll
Dave

[Dariusz Piatkowski]

Hi Dave!

So any guesses as to why the CPU/core behaviour appears to exhibit the same
symptoms? Again, my only goal here is to identify the root cause of that
strangeness...from my software development experience (I admit, it pales in
comparison to what you guys do these days to keep this stuff compiling and
running on our platform) I would have expected the application to flat out die
if the required DLL itself is missing...no matter how tiny of an API is being
used...I am guessing it's the system's response to such a situation that's
exhibiting the CPU spiking.

[Steve Wendt]

On 12/27/11 06:16 am, Dariusz Piatkowski wrote:

> I would have expected the application to flat out die if the required
> DLL itself is missing...

I suspect this means that the main executable does not need the DLL, but
one of the plugins does.

[Mat Nieuwenhoven]

On Tue, 27 Dec 2011 19:41:14 -0800, Steve Wendt wrote:

When I started vlc.exe 1.1.13 from a cmd prompt, it complained about libc064
not being found. You don't see this if I just click on vlc.exe. I have
gcc446.dll in \ecs\dll, but didn't have that libc064. I downloaded it from
netlabs (ftp://ftp.netlabs.org/pub/gcc/libc-0.6.4-csd4.zip), but that
contains also other libc06x dlls. After just unzipping libc064.dll, vlc.exe
exits immediately, no error this time. When unzipping the other dlls too, it
still exits. Before the upgrade 1.1.11 started fine.
More to research, obviously.

Mat Nieuwenhoven

[Paul Ratcliffe]

Or it loads the DLL dynamically...

[Dariusz Piatkowski]

Hi Mat!

On Wed, 28 Dec 2011 15:28:22 UTC, "Mat Nieuwenhoven"

You need gcc446.dll as well, which Peter found out as he ran into this issue,
posted about it, I tried on my machine and it addressed the issue I was seeing,
here is what I tossed in:

12-16-11 4:01a 131447 124 gcc446.dll

-Dariusz

[Steve Wendt]

On 12/28/11 07:28 am, Mat Nieuwenhoven wrote:

> netlabs (ftp://ftp.netlabs.org/pub/gcc/libc-0.6.4-csd4.zip), but that
> contains also other libc06x dlls. After just unzipping libc064.dll

I doubt that is a good idea.

[Dave Yeo]

Why not? Libc064.dll seems to have been a bit rushed and personally I
haven't installed the forwarder DLLs either yet.
Dave

[Ruediger Ihle]

On Thu, 29 Dec 2011 07:10:12 UTC, Dave Yeo <dave....@gmail.com> wrote:

> Why not? Libc064.dll seems to have been a bit rushed and personally I
> haven't installed the forwarder DLLs either yet.

I would think it's really calling for trouble to have one
application using two different LIBCs at the same time
(VLC core - >0.6.4, Qt -> 0.6.3).




--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Please remove all characters left of the "R" in my email address

[Dave Yeo]

Ruediger Ihle wrote:
> On Thu, 29 Dec 2011 07:10:12 UTC, Dave Yeo<dave....@gmail.com> wrote:
>
>> Why not? Libc064.dll seems to have been a bit rushed and personally I
>> haven't installed the forwarder DLLs either yet.
>
> I would think it's really calling for trouble to have one
> application using two different LIBCs at the same time
> (VLC core ->0.6.4, Qt -> 0.6.3).
>

Good point. The problem I have is that I have to keep libc063 around for
building Mozilla as using libc064 breaks SSL and I'm not sure how to
trace the problem down.
VLC does seem to work fine with the mixed DLLs.
Dave

[Steve Wendt]

On 12/28/11 11:57 pm, Dave Yeo wrote:

> The problem I have is that I have to keep libc063 around for
> building Mozilla as using libc064 breaks SSL and I'm not sure how to
> trace the problem down.

That shouldn't affect anything for the runtime DLLs(?).

[Dave Yeo]

In this case it doesn't but it could depending on what is broken and it
took a while to be sure.
Still seems safer to use the same DLL as it was linked against
especially when things break even if it's not obvious what broke.
Dave

[KO Myung-Hun]

Hi/2.

Dariusz Piatkowski wrote:
> Hi KO!
>
> On Mon, 26 Dec 2011 13:14:32 UTC, KO Myung-Hun <ko...@chollian.net> wrote:
>
>> Hi/2.
>>
>> Dariusz Piatkowski wrote:
>>> The latest version of the OS/2 VLC player just got released...I downloaded
>>> 1.1.13, was previously using 1.1.11.
>>>
>>> Here is the strange situation I'm seeing, I have the VLC frame running in a
>>> separate window then the video playback. With 1.1.13 the video window frame
>>> shows up fine and plays back fine, however the actual VLC window frame (where
>>> all program controls exist) is nowhere to be found.
>>
>> Do you mean you didn't check 'Preferences/Interface/Look and fee/Embed
>> video in interface' ?
>
>
> Actually, with this release, it appears that the previous INI file was either
> not-detected, or ignored. I had always set the 'Embed video in interface' to OFF
> (meaning, no check mark there), so yes, the answer to your question is : YES, I
> did not have it checked.
>
> But...as Peter Brown posted in another response, including gcc446.dll all of a
> sudden makes VLC work just fine. This is how I discovered that the INI file I
> had previously used was no longer being honoured and that setting I mentioned
> above was now actually CHECKED...
>
> 12-16-11 4:01a 131447 124 gcc446.dll
>
>

Ok. I misunderstood your statement.

When I read your statement at first, I think you can see VLC gui window,
then it disappears after a play-back window is created.

But, now I can understand your statement correctly. You cannot see VLC
gui at all. If you tell me how to launch VLC, I could ask a more proper
question to you.

How did you launch VLC ? D&D on PM, on command line, or any other methods ?

>> I'm sorry I cannot reproduce this problem at all.
>>
>> But I want to confirm that this is a problem of a multi-core system. How
>> about disabling other cores except 1 core ?
>
> OK, shutting OFF the 3 of the 4 cores (using SETPROC utility) and renaming
> gcc446.dll to something else (thus making it inaccessible to the process) causes
> the remaining single core to MAX out, running at 100% utilization. The video
> still plays, but if I chose to close the window the VLC program itself continues
> to run, still maximizing the core at 100% utilization. I then kill the process,
> which does end it.
>
> Now, as I mentioned above, Peter suggested adding gcc446.dll, sure enough, that
> allowed VLC to function correctly on my system again, with a single or multiple
> cores enabled.
>
> OK, so here is what I noticed: the HELP=>About screen shows the following :
> '...Compiler: gcc version 4.4.6 (GCC)...', so it certainly appears to me that
> gcc446.dll is a requirement to run 1.1.13 successfully, and as best as I could
> tell this was not listed in the README...so maybe just a missing piece of info,
> no biggie really.
>

Yes, you are right. But gcc446.dll should not be a requirement. Because
I linked the executable of VLC and all the DLLs including plugins
against a static lib of gcc446.dll.

Nevertheless, a new gcc 4.4.6 always linked them against of gcc446.dll.

For the details, see a bug tracker of Paul Smedley.

http://mantis.smedley.info/view.php?id=503

> But I'm curious now, why does the missing DLL (gcc446.dll) cause such a
> behaviour? The VLC control window is not displayed...and that makes sense, but
> the weird core utilization spike is just so extremely similar behaviour to the
> Firefox high-res timer issue...to the point that I'm curious what the do have to
> do with each other. Is there anything I can do to help debug this? Could we
> pursue this even though this is not a real VLC problem?
>

Some DLLs are build by g++, that is, C++ compiler. As you can see the
above bug tracker, it always links against gcc446.dll. BTW, qt4 plugin
is built by g++, so it depends on gcc446.dll. As a result, without
gcc446.dll, qt4 plugin cannot be loaded.

In this case, VLC try to find another interface plugin. Maybe console
plugin based on lua. But this has not been optimized and investigated
for OS/2 by me. And I don't have a plan to support it. Because my
concern is qt4 interface not any other interfaces.

I think, the console interface, maybe based on lua, seems to use polling
method or incompatible way with OS/2. This is the cause of 99.9% cpu load.

Anyway, this is not a high-res timer issue.

And the cause of making CPU load to spike to 99.9% is vary. So only with
this, it is not possible to conclude that they are the same problem.

> Thanks KO for the great work, as always!
>

It's my pleasure. ^^

[KO Myung-Hun]

Hi/2.

Dariusz Piatkowski wrote:
> Hi KO!
>
> On Mon, 26 Dec 2011 13:14:32 UTC, KO Myung-Hun <ko...@chollian.net> wrote:
>
>> Hi/2.
>>
>> Dariusz Piatkowski wrote:
>>> The latest version of the OS/2 VLC player just got released...I downloaded
>>> 1.1.13, was previously using 1.1.11.
>>>
>>> Here is the strange situation I'm seeing, I have the VLC frame running in a
>>> separate window then the video playback. With 1.1.13 the video window frame
>>> shows up fine and plays back fine, however the actual VLC window frame (where
>>> all program controls exist) is nowhere to be found.
>>
>> Do you mean you didn't check 'Preferences/Interface/Look and fee/Embed
>> video in interface' ?
>
>
> Actually, with this release, it appears that the previous INI file was either
> not-detected, or ignored. I had always set the 'Embed video in interface' to OFF
> (meaning, no check mark there), so yes, the answer to your question is : YES, I
> did not have it checked.
>
> But...as Peter Brown posted in another response, including gcc446.dll all of a
> sudden makes VLC work just fine. This is how I discovered that the INI file I
> had previously used was no longer being honoured and that setting I mentioned
> above was now actually CHECKED...
>
> 12-16-11 4:01a 131447 124 gcc446.dll
>
>

Ok. I misunderstood your statement.

When I read your statement at first, I think you can see VLC gui window,
then it disappears after a play-back window is created.

But, now I can understand your statement correctly. You cannot see VLC
gui at all. If you tell me how to launch VLC, I could ask a more proper
question to you.

How did you launch VLC ? D&D on PM, on command line, or any other methods ?

>> I'm sorry I cannot reproduce this problem at all.
>>
>> But I want to confirm that this is a problem of a multi-core system. How
>> about disabling other cores except 1 core ?
>
> OK, shutting OFF the 3 of the 4 cores (using SETPROC utility) and renaming
> gcc446.dll to something else (thus making it inaccessible to the process) causes
> the remaining single core to MAX out, running at 100% utilization. The video
> still plays, but if I chose to close the window the VLC program itself continues
> to run, still maximizing the core at 100% utilization. I then kill the process,
> which does end it.
>
> Now, as I mentioned above, Peter suggested adding gcc446.dll, sure enough, that
> allowed VLC to function correctly on my system again, with a single or multiple
> cores enabled.
>
> OK, so here is what I noticed: the HELP=>About screen shows the following :
> '...Compiler: gcc version 4.4.6 (GCC)...', so it certainly appears to me that
> gcc446.dll is a requirement to run 1.1.13 successfully, and as best as I could
> tell this was not listed in the README...so maybe just a missing piece of info,
> no biggie really.
>

Yes, you are right. But gcc446.dll should not be a requirement. Because
I linked the executable of VLC and all the DLLs including plugins
against a static lib of gcc446.dll.

Nevertheless, a new gcc 4.4.6 always linked them against of gcc446.dll.

For the details, see a bug tracker of Paul Smedley.

http://mantis.smedley.info/view.php?id=503

> But I'm curious now, why does the missing DLL (gcc446.dll) cause such a
> behaviour? The VLC control window is not displayed...and that makes sense, but
> the weird core utilization spike is just so extremely similar behaviour to the
> Firefox high-res timer issue...to the point that I'm curious what the do have to
> do with each other. Is there anything I can do to help debug this? Could we
> pursue this even though this is not a real VLC problem?
>

Some DLLs are build by g++, that is, C++ compiler. As you can see the
above bug tracker, it always links against gcc446.dll. BTW, qt4 plugin
is built by g++, so it depends on gcc446.dll. As a result, without
gcc446.dll, qt4 plugin cannot be loaded.

In this case, VLC try to find another interface plugin. Maybe console
plugin based on lua. But this has not been optimized and investigated
for OS/2 by me. And I don't have a plan to support it. Because my
concern is qt4 interface not any other interfaces.

I think, the console interface, maybe based on lua, seems to use polling
method or incompatible way with OS/2. This is the cause of 99.9% cpu load.

Anyway, this is not a high-res timer issue.

And the cause of making CPU load to spike to 99.9% is vary. So only with
this, it is not possible to conclude that they are the same problem.

> Thanks KO for the great work, as always!
>

It's my pleasure. ^^

[KO Myung-Hun]

Hi/2.

You can see the popupos2.log on your boot drive.

And you can generate the logs as the following.

vlc.exe -vvv --extraintf=logger > vlc.log 2>&1

Of course, you should do it on command line.

Then, send vlc.log and vlc-log.txt to me.

I'll add this to README at the later release.

Finally, you should unzip all the libc06x.dll for its zip. Then I
recommend to replace the old ones with them.

[John Small]

On Sat, 31 Dec 2011 11:45:31 UTC, KO Myung-Hun <ko...@chollian.net>

FWIW, VLX 1.1.13 would not run for me until I installed gcc446.dll.

[KO Myung-Hun]

Hi/2.

What I meant is my intention was that gcc446.dll should not be a
requirement of VLC v1.1.13.

[Dariusz Piatkowski]

Hi KO!


On Sat, 31 Dec 2011 11:45:31 UTC, KO Myung-Hun <ko...@chollian.net> wrote:

...snip...

> When I read your statement at first, I think you can see VLC gui window,
> then it disappears after a play-back window is created.
>
> But, now I can understand your statement correctly. You cannot see VLC
> gui at all. If you tell me how to launch VLC, I could ask a more proper
> question to you.
>
> How did you launch VLC ? D&D on PM, on command line, or any other methods ?

Correct...the VLC control GUI did not show up at all, only the actual video
playback window would show and it was playing back the video itself just fine.
The problem was obviously having no control over that window...and I really
didn't try any keyboard based short-cuts.

I launch VLC by selecting it as one of the available programs in the RMB 'Open
as' selection. So, in order for this to work I have created a vlc.cmd script
located in the directory where VLC.EXE is located:

SET BEGINLIBPATH=G:\apps\multimedia\vlc\usr\local\lib;%BEGINLIBPATH%
G:\apps\multimedia\vlc\usr\local\bin\vlc.exe %1

> Yes, you are right. But gcc446.dll should not be a requirement. Because
> I linked the executable of VLC and all the DLLs including plugins
> against a static lib of gcc446.dll.
>
> Nevertheless, a new gcc 4.4.6 always linked them against of gcc446.dll.
>
> For the details, see a bug tracker of Paul Smedley.
>
> http://mantis.smedley.info/view.php?id=503

OK, I understand now...read through the Mantis bug entry as well.

Thanks for the committment to support this app...nice to have a good multimedia
player like this!