[MPlayer-cygwin] Basic help needed...

[Lostgallifreyan]

compn <tempn at mi.rr.com> wrote:
(12/05/2015 02:53)

>
>On Mon, 11 May 2015 16:49:29 +0100
>Lostgallifreyan <z.crow at btinternet.com> wrote:
>
>
>> Remember in a config file, the last volume setting.
>
>not with mplayer, but frontends like smplayer do this i think.
>http://smplayer.sourceforge.net/
>
>smplayer will also remember what part of the file you were playing and
>resume later.
>

I may look into front ends for Mplayer, though for now I want to see what can be done as it is. If I find it hard now, I doubt I'll find it any easier with another layer on top of it all.. Rememberign some low volume is good enough, I just needd a way to prevent unusually loud audio damaging some studio monitors before I had time to respond to it.

>> Use CTRL or ALT keys to extend the
>> available keys to bind to commands.
>
>see mplayer/etc/input.conf , DOCS/tech/slave.txt and
>mplayer/input/input.c
>

I'd have to compile my own if I changed the C file. :) Not sure I'm up for that because my main purpose for compiling C is a phasemod synth that will never got built if I don't reserve that kind of work for it. I now know of syntax CTRL-, but still not seen it work.

>i know its possible to use CTRL at least. might work in -vo gl or -vo
>directx, its tricky some vos work some dont. wont work in terminal i
>dont think.
>

Strange, I guess it's using the characters that CTRL-Key sends, rather than testing directly for VK_CONTROL and such? That could explain a lot... If Windows compiles tested for the modifier keys held down, things might be far easier, that should work at all times, and also allow some key to use its normal code in most cases. I imagine the main problem if any, is that it may not be compatible with builds for anythign other than Windows. Terminals certainly use specific control codes that may not originate from the keys intended, between OS's. That may be the problem, using those instead of their native char values and modifier key states.

>> Load a file for playback, but
>> always pause it immediately until I am ready to start it.
>
>-idle and maybe -slave
>dont remember if theres autopause. maybe in a frontend like smplayer.
>

I was given that one earlier. :) Didn't work though, it paused ok, but denied me the conmtrol of the Mplayer window via keys. I'd have had to do everything via the console.. I entered the word 'exit', which fortunately worled as I wanted. :) I decided to leave that idea at that point.

A nice simple pause-on-load option in the main config would be ideal.

> 
>> in fifteen YEARS, there is a definite problem here! By metaphor: I
>
>yes, help is appreciated. coding, documentation, anything you can do.
>send patches to mplayer-dev-eng list. thanks
>

Point taken, but a newcomer asking for help in a moment of brain-blind frustration is the LAST person you want contributing code. My suggestions and thoughts are worth MUCH more, if those who are coding can pick anything looking useful from them. The biggest problem, by far, is that many coders no longer see things as they would if they weren't already deep into it. Insights from a newcomer with half a brain are far more useful to you than any code I try to write for a totally unfamiliar problem!

>> Is there a guaranteed way to prevent the occasional green-screen
>
>it does this on windows ? with what vo ? are you building yourself or
>using a binary package? what ver mplayer? it shouldnt do this.
>
>upgrading or building mplayer yourself fixes 99% of problems imo.
>

I mentioned Gianluigi Tiesi and SubJunk, and only the second source has recent builds that run on W98. I'm using the latest one. The problem of the seizure-on-close has always existed, it's just less likely with newer builds, when I tried Mplayer a few years ago it happened so often that it was a long time before I tried again. Upgrading does not fix problems. Fixing problems fixes problems.