SMPlayer 0.6.8 beta 3 Released
Christian Hennecke
eComStation. SMPlayer is a Qt 4 based GUI front-end for MPlayer, a command-
line movie player that is available for many systems and supports a wide
range of formats and codecs, either natively or via Win32 DLL codecs. For
instance, you can watch VideoCD, SVCD, DVD, 3ivx, DivX 3/4/5, WMV, and
even H.264 movies. SMPlayer intends to be a complete front-end for
MPlayer, from basic features like playing videos, DVDs, and VCDs to more
advanced features like support for MPlayer filters and more. This release
is based on the GA version of Qt 4.5.1 and contains a number of fixes for
both the Qt 4 library and the application itself.
Changes in this version:
* updated to Qt 4.5.1 source
* enabled colorkey
The third beta is available at:
ftp://ftp.netlabs.org/pub/smplayer/smplayer-0.6.8-beta3.zip
Qt is a cross-platform application development framework, which is widely
used as a widget toolkit for developing GUI programs. Availability for
OS/2 and eComStation both means that developers can easily port existing
Qt applications and create new ones more easily. The GA of Qt 4.5.1 has
been released, however, funding is still needed. The future road map
includes updating the framework to version 4.6.1 if enough funding can be
collected.
For more information, see:
http://qt.netlabs.org/en/site/index.xml
Since the project relies on funds made by the OS/2 and eComStation
community, please consider making a donation:
Al Savage
<christian...@os2voice.org> wrote:
> Changes in this version:
>
> * updated to Qt 4.5.1 source
> * enabled colorkey
After installing the GCC442 support library, and the QT4.5.1 WPI, I
installed this beta3.
Unfortunately, it takes down my system hard if playing in fullscreen
mode and using the keyboard to rewind, pause, etc. C-A-D does not work,
neither can the <CapLock> be toggled. Power OFF time. Repeated three
times.
Also, the problem with <Ctrl+F>, where four system error dialogues are
presented for every drive that does not have media loaded, is still
present. It even complains about not finding drives A: & B: when there
are no such drives on the system. So, twelve responses to dialogues (24
keypresses) are required to get to the file picker screen (or load any
file not previously loaded).
--
Regards,
Al S.
ivan
wrote:
Al,
I think that is a problem with QT because the same thing happens for
me with Scribus.
regards
ivan
--
Dmitry Kuminov
> I think that is a problem with QT because the same thing happens for
> me with Scribus.
Do you guys have AUTOFAIL=YES in CONFIG.SYS? If no, could you please add it and
see if that fixes the problem for you?
--
dmik
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Ruediger Ihle
> Do you guys have AUTOFAIL=YES in CONFIG.SYS? If no, could you please add it and
> see if that fixes the problem for you?
Didn't we have the same issue with with Qt3 before ?
--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Rich Walsh
> ivan wrote:
> >
> >> Also, the problem with <Ctrl+F>, where four system error dialogues are
> >> presented for every drive that does not have media loaded, is still
> >> present. It even complains about not finding drives A: & B: when there
> >> are no such drives on the system. So, twelve responses to dialogues (24
> >> keypresses) are required to get to the file picker screen (or load any
> >> file not previously loaded).
> >>
> > I think that is a problem with QT because the same thing happens for
> > me with Scribus.
>
> Do you guys have AUTOFAIL=YES in CONFIG.SYS? If no, could you please add it and
> see if that fixes the problem for you?
Why aren't you using DosError(FERR_DISABLEHARDERR) ?
--
== == almost usable email address: Rich AT E-vertise.Com == ==
___________________________________________________________________
|
| DragText v3.9 with NLS support
Rich Walsh | A Distinctly Different Desktop Enhancement
Ft Myers, FL | http://e-vertise.com/dragtext/
___________________________________________________________________
Dmitry Kuminov
>>> I think that is a problem with QT because the same thing happens for
>>> me with Scribus.
>> Do you guys have AUTOFAIL=YES in CONFIG.SYS? If no, could you please add it and
>> see if that fixes the problem for you?
>
> Why aren't you using DosError(FERR_DISABLEHARDERR) ?
In fact, I was using it in early Qt3 builds back then, but then I came to a
conclusion that it is wrong:
1. This setting is actually global by its nature. The user either wants these
annoying system error dialogs for all applications, or doesn't want them at all.
Disprove me if I'm wrong (with a real world example, please).
2. Assuming that the DosError() call in the Qt DLL will turn error notifications
off, there will be no way to turn it on for a Qt application even if the user
wants it.
For these reasons, I removed this code to let the system-wide defined action
take place.
Al Savage
> Do you guys have AUTOFAIL=YES in CONFIG.SYS? If no, could you please add it and
> see if that fixes the problem for you?
I just checked, and I don't have an AUTOFAIL statement in my CONFIG.SYS
I am out of town until the 15th, and cannot add that statement and test
this until after that date.
--
Regards,
Al S.
Ruediger Ihle
> The user either wants these annoying system error dialogs for all
> applications, or doesn't want them at all.
I cannot speak for "the users", but IMHO not many people set this option by
purpose. They just leave it alone. It just happens to be that AUTOFAIL=NO
is the default for Warp4 and AUTOFAIL=YES for the newer versions of eCS.
Since normal PM file open boxes don't produce these messages, I would
expect a Qt application to behave the same. No matter if run on eCS or
Warp4. And as a Warp4 user, I find it unacceptable beeing forced to
change CONFIG.SYS just in order to run Qt applications. Maybe I even
have some really old command line tool that copies data to floppies
where it might be good to have these popups allowing me to change or
insert a diskette. Setting AUTOFAIL=NO for the whole system would break
this.
> 2. Assuming that the DosError() call in the Qt DLL will turn error notifications
> off, there will be no way to turn it on for a Qt application even if the user
> wants it.
Why would a user want to do that ? Especially since Qt applications are
usually ported from other platforms. On these platforms the error popups
don't exist either and thus those applications don't expect them to appear.
I.e. the kind of "old command line tool" described above will most likely
not be written using Qt.
So after all I would say setting DosError(FERR_DISABLEHARDERR) within Qt
has more benefits than shortcomings.
Dmitry Kuminov
> Since normal PM file open boxes don't produce these messages, I would
> expect a Qt application to behave the same. No matter if run on eCS or
> Warp4. And as a Warp4 user, I find it unacceptable beeing forced to
> change CONFIG.SYS just in order to run Qt applications. Maybe I even
> have some really old command line tool that copies data to floppies
> where it might be good to have these popups allowing me to change or
> insert a diskette. Setting AUTOFAIL=NO for the whole system would break
> this.
Okay, I see your point but actually putting AUTOFAIL=YES to CONFIG.SYS was the
first thing I did after installing a fresh Warp back then -- every single
application would spit these annoying notifications to me otherwise. Strange,
that neither you nor the original author of this topic suffer from this issue in
non-Qt applications with having AUTOFAIL=NO on your systems. Maybe they have
patched the standard PM file open dialog since then...
Anyway, I will consider doing DosError(FERR_DISABLEHARDERR) if CONFIG.SYS
doesn't contain an explicit AUTOFAIL setting in the next Qt4 release -- this
will satisfy all parties including those who wants these ugly popups in Qt
applications for some mysterious reason (you know, people are different).
Until then, please put AUTOFAIL=YES to CONFIG.SYS, this is never bad.
Soren Birkelund Hansen
>from ConfigTool 1.3.0
=YES or NO (default)
In the default setting, when an error occurs, OS/2 will only display a window
informing you of the problem. If you wish to see the actual error code
information, set AUTOFAIL to Yes.
<<=NOTE=>> This command can't be run from an OS/2 prompt.
<<=TIP=>> Paul Kurr writes: "I set this value to YES on my machine so that
I'm not interrupted with those pesky drive not ready popups and such.
AUTOFAIL=YES takes the "first" option in those windows presented (usually
return error code to program).
"This can be seen most easily when running WIN-OS2 with a CDROM installed -
either empty or with a music CD in the drive. With AUTOFAIL=NO (default) OS/2
pop's up the window stating that my
drive "E" is not ready. With AUTOFAIL=YES, the first "selection" from that
error is executed -- returning the failed drive status to WINOS2, which just
keeps running fine."
*******************************************************
* Soren Birkelund Hansen < sor...@privat.dk >
* DK-4000 Roskilde
* N 55.64427 E 12.09586 CET
*******************************************************
Steven Levine
<dmik.against-s...@hugaida.com> wrote:
HI,
> 2. Assuming that the DosError() call in the Qt DLL will turn error notifications
> off, there will be no way to turn it on for a Qt application even if the user
> wants it.
While IMO it would be better if DosError was process local, this is
not going to change anytime soon. What I do is use, the somewhat
undocumented
// 27 - Get process DosError setting
ULONG SavedDosError = 1;
DosSysCtl((ULONG)27, (ULONG)&SavedDosError);
to retrieve the current setting and implement a close approximation of
process local behavior.
Steven
--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
Dariusz Piatkowski
I have been experiencing the same issue as what Al reported...making the change
to CONFIG.SYS here resolves it. I do find that the FILE dialog-box is slow
populating...not sure if this has anything to do with the program having to
process the 'drive fail' messages first before it actually shows a listing of
all playable files.
As a side note, can anyone explain how the Video=>Output Drive setting relates
to what the 'raw' mplayer config file states? By default KVA (fast) is set, I am
using Warp Overlay here and have the following option in my myplayer config
file: "vo=kva:wo". I have replaced the default smPlayer option with the
UserDefined choice and set it to "kva:wo"...not quite sure if it has any
effect...although the playback stability seems to be better.
I also had to enable "Repaint the background of the video Window" option to make
sure the screen is properly re-drawn after a window re-size and/or flip to a
full-screen...otherwise artifact would remain on the screen.
On the whole, great job on the QT port and the app port..so far it seems like a
real nice, fully featured video player! Thanks to all....
Dmitry Kuminov
> I do find that the FILE dialog-box is slow
> populating...not sure if this has anything to do with the program having to
> process the 'drive fail' messages first before it actually shows a listing of
> all playable files.
Can you check if you get a high CPU load when you open the file dialog with no
drives? If so, it would explain the delay: the current Qt4 file system watcher
implementation on OS/2 uses the polling method (a file/directory is checked for
changes every 50 ms) so that if it doesn't get enough time slices from the
scheduler (due to the high CPU load) it will report changes with delays.
In future Qt4 releases, we will use the file system change notification
facilities provided by XWorkplace (when it's insatlled) which are event-based.
Dariusz Piatkowski
Well, here is the interesting part: when the 'Open-File' is invoked (CTRL-F) the
dialog box pops up and takes some time to populate. The CPU does NOT spike,
however in my process watch application (TOP) I can see that momentarily the
smplayer.exe process shows a CPU hit, for a very brief moment. It then takes
some time (2-3 secs) for stuff to show up in the dialog.
However...if I continue to use the file dialog and change between several
directories, the speed at which those subsequent directories populate is
normal...meaning, that entries come up pretty quick, as expected.
So, it appears that only the first invocating of the File dialog is what is
slow...jumping between the various directories is not on the other hand.
Thanks for the great app. BTW, your efforts are appreciated!
Dmitry Kuminov
> While IMO it would be better if DosError was process local, this is
> not going to change anytime soon. What I do is use, the somewhat
> undocumented
>
> // 27 - Get process DosError setting
> ULONG SavedDosError = 1;
> DosSysCtl((ULONG)27, (ULONG)&SavedDosError);
>
> to retrieve the current setting and implement a close approximation of
> process local behavior.
Okay, yet another undocumented call :) Thank you for the information, I will use it.