[mp3togo] amarok playlist grabbing

[sim]

On 5/17/06, Justus Pendleton <justus at ryoohki.net> wrote:
> Here's a quick first pass to add support for grabbing the current
> playlist from Amarok. It might make sense to introduce a new command
> line option along the lines of --from-player=amarok.

Thanks Justus,
Applying your patch was easier than getting amarok to work (My on
board sound card got in a fight once with a beefy transistor amp from
the seventies, the sound card lost.)

I like the ability to store the library data in a postgres database.
I'll have to spend some more time looking at that, it could be useful.
Amarok did cheerfully erase one of the test playlists when I really
only wanted it to forget it. Oh well, that's why I backup, and why my
media files are owned by a different user.

I changed your code slightly to make the temporary playlist file in
the directory specified by opts['tempdir']. The user can still direct
it to their $HOME if they wish. I want to make sure that all the paths
mp3togo uses are configurable.

I also added a check for opts.bin['dcop'] in FileList.addAmarok(). I
had to change the constructor of FileList to accept an Options
instance and put it in self._opts. I used it for addXMMS() as well to
check if the module exists.

The value for opts.bin['dcop'] (if not False) is the location in the
users PATH where the binary was found. I like to use this value to
invoke the command as it saves searching again later and allows
redirection to another command from conf.Options() if necessary for
some reason.

I added some tests around the function calls in main.py. Error
messages are okay, but printing tracebacks is not cool. I fixed the
xmms call as well.

Your '--from-player=' option is not a bad idea, but I think you have
done the right thing here. If we use --import-<player name> for these
options we won't pollute the option namespace too badly and we leave
open the ability to pass extra arguments, like a session number for
xmms for instance.

> I also fixed two bugs with logging when modules (such as ID3) aren't found.

I got a patch for this bug from fab as well. His solution was to
bypass the log call altogether and just print an error.

I used a different solution to fix this bug. I used the same strategy
as the test for executables and moved the actual test to the base
class and just set up a dict of modules to check for in the Options
class derived in conf.py.

This is the way I should have coded it in the first place.

This seems to me to be the most general solution (I expect to reuse
'options.py' elsewhere) and it allows me to make the call to log() in
a place where I know verbosity has a value. This is important, because
a verbosity setting of 0 must suppress all program output, including
warnings about missing modules.

The modules bug is fixed in 0.3.2, I've started the 0.4.0 branch and
merged in the amarok patch.

Out of three bug fixes I've received, two have been reported by
multiple people. I can see I'm going to have to get the source code
into some kind of online SCM system pretty soon. I'll try to get
another feature or two into 0.4.0 and get it released, and then I
guess I'm researching SCMs.

Thanks again for the patch Justus, I wouldn't have even installed
Amarok without it.

-- 
sim