Re: cvs cd problem

Kristian G. Kvilekval wrote:
> I've applied your patch by hand.  I left out the 
> the ".so" changes for the moment as I think this will
> also impact win32 and we should let Tim get on with his
> work before trying some new stuff.

not being able to install zinf into the filesystem alters how zinf 
functions.  So anyone testing the cvs head is getting startup behavior 
that is not standard to how zinf loads up normally.

i'm not completely familiar with the way the makefile works at this 
moment, but why not just have make install  do what it normally does, 
but instead of installing from the tree as it traverses it, it builds if 
it needs to then when it reaches the end it executes an altered 
ln-plugins which mv's instead of ln's and just installs the altered 
files in there.  We don't need the .la's so they shouldn't be installed 
with the program.  Just have install, install everything as if it was a 
simple binary.

I'd actually prefer altering the makefile/configure system to install 
zinf in the way described above over editing the source files. But the 
makefile uses a lot of automated builtin commands for doing what it does 
during install and it's not clear where we'd put customized commands in 
in order to alter this behavior.  On the other hand, editing the source 
to adapt to the makefile is easy and results in files that make sense 
for every port except 1 and that's trivial to fix.

one or the other needs to be done soon because it's holding things up. I 
mean the unix ports are hardly in a state where we can all take a break, 
we haven't had a decent release since freeamp and we still have quite a 
lot to fix before we're solid.

if we cant get a makefile patch now then we should use the source patch 
with little ifdef's in the common files for win32 until we do get the 
makefile patch.

common files,  player.cpp, playlist.cpp, foreignTheme.cpp, 
downloadmanager.cpp

> 
> On Fri, 2003-03-21 at 13:25, Ed Sweetman wrote:
> 
>>Ed Sweetman wrote:
>>
>>>Kristian G. Kvilekval wrote:
>>>
>>>
>>>>On Thu, 2003-03-20 at 18:06, Ed Sweetman wrote:
>>>>
>>>>
>>>>>Our default is set to soundcard-pmo.so which is not built apparently. 
>>>>>ALSA is built. so for people who dont have soundcard-pmo.so our 
>>>>>player defaults to the first pmo in the list, which happens to be the 
>>>>>cd pmo for most people.  The player does not make any intelligent 
>>>>>decisions on which pmo to use at this point.  So it uses the cd pmo 
>>>>>to try and play any file.
>>>>
>>>>
>>>>
>>>>How about changing the preference to a list of pmo to try in order
>>>>instead of just skipping over the ones.   i.e. try alsa, soundcard,
>>>>esound, arts...
>>>
>>>
>>>did you look at the patch?  It tries the first non-cd and non-waveout 
>>>one. There is no need to try and get soundcard/alsa/esound/arts in a 
>>>particular order when the one that's selected in the preference file 
>>>isn't found.  The method i'm using works the way zinf is supposed to 
>>>work in this situation.   The way it was prior was bad.
>>
>>In case you're missing it.
>>
>>
>>
>>+	   if(!item){
>>+		cerr << "Requested pmo " << defaultPMO.c_str() << " not found\n";
>>+		int32_t xx = 1;
>>+		item = m_pmoRegistry->GetItem(0);
>>+		while(!strcmp(item->Name(), "cd-pmo.so") ||
>>+		      !strcmp(item->Name(), "wavout-pmo.so")){
>>+		    item = m_pmoRegistry->GetItem(xx);
>>+		    xx++;
>>+		}
>>+		cerr << "using pmo "<< item->Name() << " instead. Update pref\n";
>>+	    }
>>
>>
>>
>>what this says is if we dont have a output plugin because the default 
>>wasn't found in the list of plugins we have available to use as output 
>>plugins then we output that the requested plugin wasn't found. We 
>>initialize our counter to one and preload item to the 0 position of the 
>>registry we compare this to "cd-pmo.so" and "waveout-pmo.so" because we 
>>dont want to use them as backup audio output plugins ever. If it's 
>>either one of those we set item to the next item in the registry and 
>>incriment our counter and try again.  It exits this loop when we find a 
>>plugin that is not the cd-pmo plugin and  not the waveout plugin. We 
>>output which plugin we're using and tell them to update their 
>>preferences and continue on our merry way.  If none is found zinf will 
>>exit with an error like you'd expect it to if you had no pmo plugins.
>>
>>The way it worked before was that it used the 0 position plugin and went 
>>on it's merry way and that's it.  It didn't care if it was the cd plugin 
>>or the waveout plugin or what.  This is bad and lazy.
>>
>>The fix above is a perfect solution with the exception that it doesn't 
>>attempt to decide if you have the audio drivers loaded for the 
>>particular output plugin it's attempting to use. But that is well beyond 
>>the scope of zinf.  There is no better way to decide which plugin to use 
>>in the absense of the one we want.
>>



-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en