Will Winamp ever be ready for prime time?

[Aminifu]

Please note again that the problem is most likely caused by the WA installer trashing third party plugins.

Hi pbelkner,

You're upset. I can understand. DrO (a very good dev, who has helped keep WA going for several years) said he knows of only 2 other cases like yours.

The problem with 3rd party plug-ins (mostly old and unsupported ones) is much larger than installer issues. I think it's up to active 3rd party devs to keep up with documented WA plug-in API changes. If that change and others are not documented and posted in the appropriate place, then I think you have a legit 'beef'. Also I think he said the problem is more on Windows side.

But I'm just a WA user, so what do I know.

[pbelkner]

I can understand. DrO (a very good dev, who has helped keep WA going for several years) said he knows of only 2 other cases like yours.

It' not only mine, it is the problem of the OP who told us that he's gonna leaving WA because exactly of that problem.

The OP described the problem exactly as that WA is broken after an (update) installation. It's not plausible in any way that this is due to any plugin, because no plugin disturbed WA before the installation. To me it is obvious that the problem is due to the installation. That was confirmed by DrO.

The OP talked about the big elephant in the room.

The problem with 3rd party plug-ins (mostly old and unsupported ones) is much larger than installer issues. I think it's up to 3rd party devs to keep up with documented WA plug-in API changes. If that change and others are not documented and posted in the appropriate place, then I think you have a legit 'beef'. Also I think he said the problem is more on Windows side.

As far as I understand the issue it is caused by the WA installer using a broken M$ Windows function. That's why I blamed M$ at first.

On the other hand I'm asking why the WA installer is using a broken function. As DrO was confirming, it is known to WA devs that they are using a broken function.

The easiest solution would be to alter the default setting for that questionable "optimization". Obviously that "optimization" should be switched off by default. If somebody switches that "optimization" on and has a problem afterwards, he definitely will know that it is due to that "optimization".

To clarify again, I'm not going to blame DrO. He's the only one giving qualified answers.

[Aminifu]

Hi pbelkner,

But it's not all 3rd party plug-ins that cause or have a WA based problem, even old unsupported ones. Clearly those the OP was trying to use (which he never identified) and yours cause or have problems.

But I use a number of 3rd party plug-ins and routinely installed new versions of WA over them with no WA (installer or otherwise) based problems, with them or WA.

A few are rather old. For one I was able to contact the dev to have him update it to comply with Win 7's restriction on where configuration .ini files should be placed. But even before this, I could install new versions of WA over it. I just had to run WA in administrator mode if I wanted to save configuration changes for that plug-in. I have 2 other old unsupported plug-ins that I still have to do that for. Although I now know them so well that sometimes I just copy their configuration files to an unrestricted folder, edit in the changes, and copy them back to the WA plugins folder.

One, that I'm no longer using, insisted on placing it's configuration file in the Windows folder (which Win 7 really doesn't like). But the point is that it still worked even when installing new WA versions over older ones.

What you say about the installer "optimization", I'm not qualified to speak on.

[pbelkner]

But it's not all 3rd party plug-ins that cause or have a WA based problem, even old unsupported ones. Clearly those the OP was trying to use (which he never identified) and yours cause or have problems.

But I use a number of 3rd party plug-ins and routinely installed new versions of WA over them with no WA (installer or otherwise) based problems, with them or WA.

Now knowing the reason (thanks to DrO) it's hopefully not a big issue to make the plugin resistent against the third party plugin trashing installer. Maybe I only have to link the plugin DLL using the M$ linker instead of the MINGW linker.

But that's not the point. The point is feeling dragged into M$ only world when trying to develop a WA plugin. The installer which (potentially) trashes third party plugins being developed using non M$ tools is the second observation making me feel this way. The first such observation was that the traditional WA API (just good old plain C) has been sometimes extended to become partly C++:

• Having a plain C API allows the plugin developer to choose the compiler he prefers because each C compiler is binary compatible to each other. That's e.g. the reason why the API for developing browser plugins (http://en.wikipedia.org/wiki/NPAPI) is plain C by intention.
• On the other hand you can't expect two C++ compilers to be binary compatible. In case of a C++ API the plugin developer has been locked into the compiler used for the hosting software, in case of WA it is M$ C++ (as long as the plugin needs to access some part of the API being C++).

Because the FFSoX plugin allows playing videos and WA's video API is C++ there's no way to avoid M$ C++. In case of WA's video API I have at least to compile one module mapping the C++ API to plain C using M$ C++.

[MrSinatra]

I know you are passionate about your proposal. I realize that some don't have time, or take time, to read what they've missed in a long thread. But I hope you're not asking me to, or expecting me to, wait in line when I have something to say.

DrO posted 5 minutes after my post (I think you're referring to), which was a good 4.5 hours after yours. I don't think my post distracted or interfered with DrO responding to you in any way. I think he decided to respond to a user's technical problem, which I was 'off base' on (which lead to him and the user getting upset), rather than continue in a 'what could be, should be' discussion.

I'm not upset. I just don't think I should let that comment pass without a response. My time is valuable to me too. If I have a response to something I see and don't make it when I see it, I may not come back to it. Or I fear my later response would be too far away from what I'm responding too. Not that I think my comments are all that important, just throwing in my 2 cents.

it has nothing to do with my passion, but my comment was directed at DrO, and what i mildly objected to was you basically speaking for DrO by confronting my post by regurgitating what you saw as his orig objections to my idea. i did not benefit for that, and imo, it did not speak to what i was now asking him to respond to. to put it another way, it was his response to my latest post i was interested in, not someones take on one of his earlier posts, which i had already seen and understood.

i'm not trying to silence you in any way, i am merely suggesting that was not the time for you to post that reply, nor did DrO need an assist. its one thing to seek clarification, its another to argue against to a post which is not directed at you. if he were to post his reply to me, and you expounded, agreed, whatever, afterwards, i'd have no objection. its just that restating what you see as his views does imo, end up making his reply to me afterwards, less focused. (and i'd feel that way even if DrO were to come on here now and say it didn't impact his post in any way, call it the Heisenberg principle)

and i only politely asked that you don't do it, if you insist on doing so, then thats your choice.

[Aminifu]

i'm not trying to silence you in any way, i am merely suggesting that was not the time for you to post that reply, nor did DrO need an assist. its one thing to seek clarification, its another to argue against to a post which is not directed at you. if he were to post his reply to me, and you expounded, agreed, whatever, afterwards, i'd have no objection. its just that restating what you see as his views does imo, end up making his reply to me afterwards, less focused. (and i'd feel that way even if DrO were to come on here now and say it didn't impact his post in any way, call it the Heisenberg principle)

and i only politely asked that you don't do it, if you insist on doing so, then thats your choice.

I am, and was, not arguing against your idea. Then again, in that post maybe I was. I did say I thought my idea was better.

We all response to posts that are not explicitly directed to us. Although in this case, I think I understand what you're saying.

The first 2 lines of that post, summarizing what you said and what DrO said was not intended as me speaking for him. Sorry you took it that way. That part of your revised idea had already been objected to and I was making note of it directly rather than referring back to DrO's post in which he did. I did not need to include those 2 lines at all, in order to make the comments I made in the rest of that post. And yes, I could have waited to make them, just didn't see a reason to.

When we get in these kind of discussions, it's not easy to determine what is 'appropriate' to reference and what isn't and when is a 'good' time to pitch in. After all, arguments in real live tend to be rather free flowing. But, it's not the same as trouble-shooting a technical issue and some rules of etiquette need to be followed.

[pbelkner]

The WA installer destroys DLLs

In order to verify that the ERROR reported by the OP and which I observe for some time with the FFSoX player plugin is DUE TO THE WA INSTALLER and not due to the plugin I did the following :

1. There's was a working WA installation including the FFSoX player plugin.
2. I've downloaded and run "winamp5623_full_emusic-7plus_en-us.exe".
3. Each time I was starting the newly installed WA I was bothered with the following message at start-up time:
   
4. I was re-installing the FFSoX player plugin. WA was working smoothly again.
5. I was listing all FFSoX player plugin related DLLs:
   $ ls -l in_ffsox.dll in_ffsox/*.dll
   -rwxr-xr-x 1 peter Administratoren 170563 May 13 08:47 in_ffsox.dll
   -rwxr-xr-x 1 peter Administratoren 7144448 May 13 08:47 in_ffsox/avcodec-54.dll
   -rwxr-xr-x 1 peter Administratoren 1079808 May 13 08:47 in_ffsox/avformat-54.dll
   -rwxr-xr-x 1 peter Administratoren 139776 May 13 08:47 in_ffsox/avutil-51.dll
   -rwxr-xr-x 1 peter Administratoren 130013 May 13 08:47 in_ffsox/liba52.dll
   -rwxr-xr-x 1 peter Administratoren 225944 May 13 08:47 in_ffsox/libmad.dll
   -rwxr-xr-x 1 peter Administratoren 4967668 May 13 08:47 in_ffsox/libsox.dll
   -rwxr-xr-x 1 peter Administratoren 36172 May 13 08:47 in_ffsox/setdlgitemurl.dll
   -rwxr-xr-x 1 peter Administratoren 306176 May 13 08:47 in_ffsox/swscale-2.dll
6. I was re-installing WA again. After re-installation I was bothered again with the above message each time I was starting WA.
7. I was listing all FFSoX player plugin related DLLs again:
   $ ls -l in_ffsox.dll in_ffsox/*.dll
   -rwxr-xr-x 1 peter Administratoren 170563 May 13 08:49 in_ffsox.dll
   -rwxr-xr-x 1 peter Administratoren 7144448 May 13 08:49 in_ffsox/avcodec-54.dll
   -rwxr-xr-x 1 peter Administratoren 1079808 May 13 08:49 in_ffsox/avformat-54.dll
   -rwxr-xr-x 1 peter Administratoren 139776 May 13 08:49 in_ffsox/avutil-51.dll
   -rwxr-xr-x 1 peter Administratoren 130013 May 13 08:49 in_ffsox/liba52.dll
   -rwxr-xr-x 1 peter Administratoren 225944 May 13 08:49 in_ffsox/libmad.dll
   -rwxr-xr-x 1 peter Administratoren 4967668 May 13 08:49 in_ffsox/libsox.dll
   -rwxr-xr-x 1 peter Administratoren 36684 May 13 08:49 in_ffsox/setdlgitemurl.dll
   -rwxr-xr-x 1 peter Administratoren 306176 May 13 08:49 in_ffsox/swscale-2.dll
   
8. I made the following observations:
   
   • Each of the DLLs are touched by the WA installer which is proven by the altered time stamp reflecting WA installation time.
   • To make the point clear: Not only the plugin DLL "in_ffsox.dll" is touched but also all DLLs from the sub-folder "in_ffsox" which are NOT loaded by WA but by the plugin DLL "in_ffsox.dll".
   • In one case even the file size of a DLL from the sub-folder has changed.

[DJ Egg]

@pbelkner

I'm going to exclude all of those DLLs you listed from the Bind/Optimizing stage for the next release.

Does anyone else know what other 3rd-party plugins are affected so I can also add them to the exclusion list?

(note, I need the actual dll filenames)

[pbelkner]

@pbelkner

I'm going to exclude all of those DLLs you listed from the Bind/Optimizing stage for the next release.

Does anyone else know what other 3rd-party plugins are affected so I can also add them to the exclusion list?

(note, I need the actual dll filenames)

Thanks a lot.

Is it possible to remove all DLLs from sub-folders regardless of their name from the optimization stage? For the FFSoX player theses DLLs are subject to change. During the last year there where e.g. several version bumps for the FFmpeg DLLs.

[Koopa]

We are already aware about it, also you can put some additional files from ffmpeg to the in_ffsox folder, iicr.

The problem is, that a simple rename does not allow wildcards.

I'm trying to find a solution for that and will provide the code change to the devs then.

[DJ Egg]

Ahh crap, right...

Well, I had a simple solution.... until now.
I'll have to think of some other method to maybe backup and replace the whole in_ffsox folder instead (see Koopa's post).

Can't you just always name the files avcodec.dll, avformat.dll, etc? Or does the version # also have to be in the filename?

Also, am I correct in assuming that any extra FFmpeg files placed manually into the in_ffsox folder should be ok,
because they won't have been compiled with MINGW?

[EDIT]

RE: reply below

Ok, fair enough.... bear with us...

[pbelkner]

Ahh crap, right...

Well, I had a simple solution.... until now.
I'll have to think of some other method to maybe backup and replace the whole in_ffsox folder instead (see Koopa's post).

Can't you just always name the files avcodec.dll, avformat.dll, etc? Or does the version # also have to be in the filename?

Also, am I correct in assuming that any extra FFmpeg files placed manually into the in_ffsox folder should be ok,
because they won't have been compiled with MINGW?

One of the core ideas of the FFSoX plugin is that users can substitute the FFmpeg DLLs from Zeranoe's frequent builds (http://ffmpeg.zeranoe.com/builds/). That allows the user to always use the most up to date FFmpeg version without the need of rebuilding the whole plugin. The DLLs from Zeranoe's builds contain the version number in the filename.

AFAIK Zeranoe cross compiles from some Linux using MINGW.

The version number in the filename is also important because it distinguishes binary incompatible versions.

[pbelkner]

We are already aware about it, also you can put some additional files from ffmpeg to the in_ffsox folder, iicr.

The problem is, that a simple rename does not allow wildcards.

I'm trying to find a solution for that and will provide the code change to the devs then.

That sounds promising, thanks a lot

[DJ Egg]

Done

in_ffsox.dll and the Plugins\in_ffsox folder will not be touched by the BindImageEx Optimizer as from the next release onwards :-)

I just need to know the filenames of any other incompatible plugins now....

[pbelkner]

Done

in_ffsox.dll and the Plugins\in_ffsox folder will not be touched by the BindImageEx Optimizer as from the next release onwards :-)

I just need to know the filenames of any other incompatible plugins now....

That's very good news! Thanks a lot, DJ Egg