update on Re: MPlayer problems

[Paul Higgins (U of M)]

It's taken me a month or so to get back to the whole MPlayer issue.  As for  
the last piece of advice given on this list, all I can say is, no such luck:

$ cd /usr/bin
$ ./mplayer
MPlayer 1.0pre6-3.3.3 (C) 2000-2004 MPlayer Team
Illegal instruction

I did make sure that my yum.conf was pointing to the latest rpm repositories 
as per the how-to instructions on the YDL site.  I also have a couple 
alternate sites in yum.conf as well.  The MPlayer binary came from the YDL 
site.

I guess I'll be learning to compile from source and/or installing xine, which 
sounds like a much less problematic package.  (Oh, I might add, the latest 
binaries of MPlayer for OS X are also buggy, so this must not be a problem 
that is confined to Linux).

Thanks for everyone's help!

-PRH

On Friday 20 January 2006 07:06, Derick Centeno wrote:
> Hi Paul:
>
> I merely mentioned a potential problem with yum.  Which could range
> from it being directed to download from old or incomplete repositories
> to problems in it's own code.
> If it functioned and you said it reported no errors, maybe you should
> see in yum.conf for where it is going and update the information there
> so that it is going instead to the most recent and current
> repositories.  The more current repositories are posted somewhere;
> certainly someone on this list can help with that.  You can check
> against that.
>
> Meanwhile although I'm a fan of xine, I do understand your being
> focussed on a mplayer.  However, keep on slugging things out regarding
> mplayer and you may come up with something which satisfies you.
> Otherwise, if you want to get moving onto whatever you intend to do --
> you may discover xine to be more than flexible.
>
> This might be a no brainer, and obvious, but did you try doing:
>
> $ cd /usr/bin
> $ ./mplayer
>
> Just a thought, before you throw up your hands and go for xine.  I'm
> sure you realize that some programs need to be started with ./ from
> within the directory where they can be executed (in this case
> /usr/bin).  The details of why they are invoked differently requires a
> different kind of discussion, but you can look that up elsewhere.
>
> Best of luck...