Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Dariusz Piatkowski

Pages: [1] 2 3 ... 13
1
Storage / How to discover the newly assigned USB drive letter?
« on: May 14, 2025, 05:50:11 am »
I'm using a little nifty REXX script to download pics off of my DSLR's memory card:

- issue the LVM rediscover attached media with '@LVM.EXE /RediscoverPRM'
- if no errors encountered start doing the copy

My problem is that when I created that script I never attempted to figure out what that removable media assigned drive letter is...it was simpler to just use a static name (used to be drive 'W:' and assigned to the disk with LVM) and run with it.

Well, recently I added a few NAS shares to my NetDrive and happened to map this to the drive letter which was previously assigned to the USB storage media card. Now my script doesn't work b/c that old drive letter is no longer usable and the USB stuff is assigned 'D:' instead.

OK, seems simple, but where the heck do I even start with querrying this in REXX?

I took a stab at this by reading through Alex Taylor's "RxLVM Library Reference - Version 0.5.1 - March 18, 2007", but that's really about all sorts of disk functions, so not what I'm looking for.

Any other references I could look up for this functionality?

Thanks!

2
Setup & Installation / Troubleshooting process trap/dump...how?
« on: May 05, 2025, 05:51:12 am »
So I've got a weird problem that just seemingly has shown up about a couple of weeks ago: I've seen three separate RSYNC jobs die part-way through a LOCAL backup, and as best as I can tell my OS/2 box reboots at the same time.

Now the strange part is that I can't find anything listed in places like POPUPLOG.OS2 or as TRP files...so it's rather tough to figure out whether this is a hardware or a software issue. At the moment I am leaning towards this being a hardware thing.

Having said that, I know that this is not a CPU cooling problem as I am running a pretty capable setup here and that's something I've been through multiple times so I know there is spare room there...but it could be something else, such as memory, or even CPU/core problems.

Sooo...I went back to my CONFIG.SYS and re-enabled the system LOG stuff I had previously enabled:

Code: [Select]
...
DEVICE=G:\OS2\LOG.SYS /OFF
RUN=G:\OS2\SYSTEM\LOGDAEM.EXE /E:g:\tmp\trp
DUMPPROCESS=G:\tmp\trp /F=10240
RUN=G:\OS2\EPWDDR3.EXE
DEVICE=G:\OS2\EPWDD.SYS
...

Not sure though if there is anything else I should be looking at to try to maximize the data capture should RSYNC cause either that hardware or perhaps software fault again.

What have you used in your previous attempts to narrow this kind of a problem down?

Thanks!

3
Setup & Installation / PYTHON - v2 vs v3 and dependencies...
« on: April 27, 2025, 04:02:26 pm »
So I noticed that libxml2 RPM package got updated to 2.12.4 whereas currently I'm at 2.9.10.

OK, cool, I figured seeing as it was in '-REL' status I'd pull the trigger and get it updated on my machine as well.

However, doing so resulted in an error (during install and not in the pre-check stage ABAICT) and produced the attached error. Basically it turns out my python2-libxml2 has a dependency on the libxml2 RPM.

Hmm...OK, so let me sort this out. Off I went looking thinking that I had already installed Python3 anyways, so why did I still have Python2 on this box, and did it still even make sense to do so.

Take a look at my list of Python stuff that's currently installed here...so yeah, it's a bit of a mix of things.

Now I recall thinking/reading in the past that our RPM/YUM solution required Python2, but checking the RPM/YUM Netlabs page (https://trac.netlabs.org/rpm) I'm not finding anything there calling this out.

So my question is: is Python2 needed for anything RPM/YUM related? I do not use Python for anything but this and maybe one or two little utilities.

It feels like I should perhaps just try to move to Python3...???

Thanks!

4
Setup & Installation / libtiff and libtiff tools - MIA in 4.6.x but...
« on: April 15, 2025, 03:05:08 pm »
Folks,

Just a quick FYI, although those who need this functionality have probably already instituted this.

The latest drop of libtiff & tools (4.6) is missing the vast majority of tiff tools. This is a known issue (as has been pointed out on our forum here already) and has been remedied with the 4.7 release (https://libtiff.gitlab.io/libtiff/releases/v4.7.0.html), which we do not have available to us yet.

Sooo...in case you are like me and need to use those tiff tools here is what you can do:

1) before upgrading your <4.6 libtiff stuff
- copy the tiff tools you need from \usr\bin to \usr\local\bin
- optionally copy the tiff libs from \usr\lib to \usr\local\lib (this is not really needed b/c the 4.6 update will force install libtiff-legacy-5 package and that has all the DLLs you need (two actually)
- copy the tiff MAN pages from \usr\share\man\man1 to \usr\local\share\man\man1

2) upgrade your <4.6 release of libtiff & tools

3) remove the doubled up EXE and MAN pages from the \usr\local\... locations

This approach has allowed me to continue using the available 4.0.9 libtool EXEs which apps like PDFMergeNX require.

BTW: The stipulation here is of course that \usr\local\... is present in your CONFIG.SYS in the appropriate LIBPATH & SET PATH lines.

5
Networking / inetcfg.ini - window size, but why this result?
« on: March 03, 2025, 05:13:19 am »
So a couple of days ago the AOS testers list was asked with giving some new SEND & RECEIVE window sizes a try.

Ever since I went to a 1Gig fibre line I had tweaked my inetcfg.ini to use the max allowable value for both TCP & UDP windows.

However this request prompted me to test and surprisingly enough I found that the smaller window size actually caused a repeatable 20-25% improvement when doing a speedtest run.

OK, nice...so I permanently updated my inetcfg.ini with these values, and carried along.

Today I needed to reboot my machine, all was good. The box re-started fine, I brought up my regular apps: PMMail, Thunderbird, RDP, Firefox...but whoa...hang on...why isn't Firefox taking me anywhere????

Yeah, it just sat there, spinning, "connecting..." but it would never go anywhere.

So I check the other apps: PMMail is good, but TB...nope, same story as FF.

I whip up the speedtest CLI...nope, not going anywhere either.

After numerous trials I determined that the window sizing was impacting certain apps. Further on, I found that on my machine anything smaller than 131,072 (so 128K) would cause the above described "stall", while anything bigger consistenty 'just works'!!! ugh???

Can anyone explain this please?

Here are the contents of my inetcfg.ini:

Code: [Select]
#Inetcfg:       CURRENT DEFAULT MINIMUM MAXIMUM

keepalive       60      7800    0       7800    KeepAlive (sec)
tcpswinsize     131072  32768   1024    246723  TCP SendWindow Size
tcprwinsize     131072  32768   1024    246723  TCP RecvWindow Size
udpswinsize     131072  9216    1024    246723  UDP SendWindow Size
udprwinsize     131072  41600   1024    246723  UDP RecvWindow Size
lingertime      120     120     0       65535   Linger Time (sec)
probecnt        8       8       1       8       Number Of KeepAlive Probes
ipforward       0       0       0       1       IP Forwarding flag ON/OFF
mtudiscover     1       1       0       1       TCP Path MTU Discovery ON/OFF
arpkillc        1200    1200    180     15300   ARP Complete TimeOut (sec)
arpkilli        180     180     60      1200    ARP InComplete TimeOut (sec)
lipcstswinsize  10240   10240   1024    246723  LIPC Stream SendWindow Size
lipcstrwinsize  10240   10240   1024    246723  LIPC Stream RecvWindow Size
lipcdgswinsize  2048    2048    1024    246723  LIPC Dgram SendWindow Size
lipcdgrwinsize  4096    4096    1024    246723  LIPC Dgram RecvWindow Size
synattack       0       0       0       1       SYN Attack Flag ON/OFF
syncookie       0       0       0       1       SYN Cookie Flag ON/OFF
firewall        0       0       0       1       FIREWALL ON/OFF
multidefrt      1       1       0       1       Multiple Default Routes ON/OFF
winscale        1       1       0       1       TCP Window Scale ON/OFF
timestmp        1       0       0       1       TCP TimeStamps ON/OFF
realslow        20      20      1       100     TCP TW Q Slow Timeout ticks
perfhttp        1       1       0       1       Fast Path HTTP ON/OFF
tcpttl          64      64      1       255     TCP  TTL (hops)
udpttl          64      64      1       255     UDP  TTL (hops)
icmpttl         64      64      1       255     ICMP TTL (hops)
fragttl         60      60      1       255     Fragment TTL (sec)
reusetw         1       1       0       1       Reuse Time Wait ON/OFF
msl             30      30      1       16384   TCP MaxSegLifeTime (sec)
cc              0       0       0       1       TTCP function ON/OFF
sack            1       0       0       1       Selective ACK ON/OFF

6
Programming / app high-mem capability, how to tell if it's there?
« on: December 31, 2024, 09:27:43 pm »
...basically, when looking at either an EXE or a DLL, how can I tell whether the application was written/compiled with highmem support?

I am aware of 'highmem', and stuff like 'exehdr', but even in the case of 'exehdr' I do not see how to interpret the results (i.e. is there anything in the output I am missing that already shows me that "yup, highmem capable" flag?).

Yes, I agree that leaving things "as-is" (meaning: the way the software was supplied) is a good recommendation, but if changes were made (we've all marked DLLs to load-high I'm sure) how the heck do I figure out what the intended DEFAULT mode is???

7
Programming / DISKIO - preferred TIMER to use
« on: December 26, 2024, 11:24:45 pm »
DISKIO uses a TIMER in order to track the duration of various data xfer events.

More specifically, provisions were made in the old code to account for an incorrectly working high-resolution timer on SMP machines.

Subsequently right at the start of DISKIO a call is made to determine which TIMER should be used by examining the CPU core count, and if >1 than we force the use of "standard MS counter":

Original Code
Code: [Select]
// init flHiresTmr flag
// note: DosTmrQueryTime() API not works on OS/2 SMP as designed (thanks scott),
// so on SMP systems we must use other timer - standart MS counter.
void init_timer (void)
{
    int nCPUs = 0;

    if (DosQuerySysInfo (QSV_NUMPROCESSORS,
                         QSV_NUMPROCESSORS,
                         &nCPUs,
                         sizeof(nCPUs)) == NO_ERROR)
    {
        if (nCPUs > 1) flHiresTmr = 0;
    }
}

My udpated code
Code: [Select]
// init flHiresTmr flag
// note: DosTmrQueryTime() API does not work on OS/2 SMP as designed (thanks scott),
// so on SMP systems we must use other timer - standart MS counter.
void init_timer (void)
{
   //int iCPUs = 0; //moved this to a GLOBAL variable in diskio.h, v1.26

   if (DosQuerySysInfo (QSV_NUMPROCESSORS,    /* ordinal of first system variable */
                        QSV_NUMPROCESSORS, /* ordinal of the last system variable */
                        &iCPUs,              /* address of output data buffer */ 
                        sizeof(iCPUs))          /* size of output data buffer */
       == NO_ERROR)
   {
      if (iCPUs > 1)
         flHiresTmr = 1;
   }
         
   #ifdef DEBUG
      printf("\n DEBUG => CPU cores detected is: %d\n", iCPUs);
      printf(" DEBUG => flHiresTmr is: %d\n", flHiresTmr);
   #endif /* DEBUG */

} // end of init_timer

...where I basically ignore that original comment and force flHiresTmr = 1, which also means that throughout DISKIO's execution I will always use the hi-res TIMER, that being through DosTmrQueryTime API.

OK, so when I had initially encountered this I thought to myself: umm, I recall we had some troubles in the past with the hi-res stuff being spotty. Firefox had encountered some of this, heck we even made use of the 'SET NSPR_OS2_NO_HIRES_TIMER=1' flag. But digging into this further, by all accounts today that no longer appears to be the case. My FF install no longer uses this, I have several other apps that use the hi-res TIMER, and I believe some work was done in the ACPI codebase to manage this better, although some opinions remainder for a while as to whether these changes were working or not.

Needless to say, my testing here appears to be showing correct results as the results match what the original DISKO logic was showing.

Here is a more specific example of code (API comments have been added by me, as well as some variable name changes) that relies on previous determination of what TIMER should be used:

Code: [Select]
// use MS counter timer for SMP systems and HiRes Timer for any other
int start_timer (TIMER *tStart)
{
   if (flHiresTmr)
   {
      if (DosTmrQueryTime (tStart) != NO_ERROR)
      {
         printf("Timer error.\n");
         return (-1);
      }
   }
   else
   {
      tStart->ulHi = 0;
      if (DosQuerySysInfo (QSV_MS_COUNT,   /* ordinal of first system variable */
                           QSV_MS_COUNT,/* ordinal of the last system variable */
                           tStart,           /* address of output data buffer */
                           sizeof(tStart))      /* size of output data buffer */
          != NO_ERROR)
      {
         printf("Timer error.\n");
         return (-1);
      }
   }

   return (0);

} // end of start_timer

My question to you all is: should we be still concerned about this?

I feel like simplifying the codebase is a good pursuit and if the hi-res TIMER works (which I understand to be the more precise one given that at the standard frequency the PIT chip runs at (roughly) 1.193182 MHz, so that gives us a microsecond precision as opposed to the ms stuff that DosQuerySysInfo is capable of), we should use it.

8
Programming / DISKIO - storage device detection logic
« on: December 22, 2024, 05:18:41 am »
Alright...the one well known DISKIO problem/challenge stems due to the fact that any removable storage devices, these being primarily connected through USB, cause DISKIO to error when no actual media is mounted.

AFAIU at the start of execution DISKIO simply asks DosPhysicalDisk API for a number of partitionable disks using this API call:
Code: [Select]
DosPhysicalDisk (INFO_COUNT_PARTITIONABLE_DISKS, &nDisks, sizeof(nDisks), 0, 0)

Sure enough, ALL devices defined as storage media, whether these are currently mounted and accessible, show up in that list.

Further on, DosPhysicalDisk is called again but this time in order to obtain the device handle for DosDevIOCtl32 calls later on:
Code: [Select]
DosPhysicalDisk (INFO_GETIOCTLHANDLE, &usPhysical, sizeof(usPhysical)

OK, so far so good, only one caveat here: "...The handle returned for the specified partitionable disk can only be used with the DosDevIOCtl function for the Category 09h Physical Disk Control IOCtl Commands...".

Now DISKIO proceeds to query the device parameters by calling DosDevIOCtl32:
Code: [Select]
DosDevIOCtl32 (&dpb, sizeof(dpb), &bCmd, sizeof(bCmd), DSK_GETDEVICEPARAMS, hfHandle)

Here is the thing: I think it ONLY gets the parameters but doesn't actually do any checking to see if the media can actually be accessed. It assumes that since the storage device was found it can therefore be tested.

What I am not sure about however is how to interpret the meaning of the logic that decides whether to retrieve the DEVICEPARAMETERBLOCK or BIOSPARAMETERBLOCK record structures.

In other words, the IF statement check "if (hfHandle & PHYSICAL)" below, where we have the following defines:

#define PHYSICAL     0x1000
#define CDROM        0x2000

...does that mean that hfHandle will be BIT anded with PHYSICAL and if they MATCH the device we are querying must therefore be a mounted storage media?

I see we distinguish between PHYSICAL & CDROM, perhaps USB attached should have a different define as well?

Code: [Select]
   // now check if we have a valid physical file handle
  if (hfHandle & PHYSICAL)
   {
      // get the info for DEVICEPARAMETERBLOCK
      if (DosDevIOCtl32 (&dpb, sizeof(dpb), &bCmd, sizeof(bCmd), DSK_GETDEVICEPARAMS, hfHandle))
      {
         DosPhysicalDisk (INFO_FREEIOCTLHANDLE, NULL, 0, &usPhysical, sizeof(usPhysical));
         return (-1);
      }

      *lSectors = dpb.cSectorsPerTrack;
      *lTracks  = dpb.cCylinders;
      *lSides   = dpb.cHeads;
      *lSector  = DSK_DEFAULT_SECTOR_SIZE;

      #ifdef DEBUG
         printf("\n DEBUG => found the disk and storing in DEVICEPARAMETERBLOCK...\n");
      #endif /* DEBUG */
   }
   else
   {
      // get the info for BIOSPARAMETERBLOCK
      if (DosDevIOCtl32 (&bpb, sizeof(bpb), &bCmd, sizeof(bCmd), DSK_GETDEVICEPARAMS, hfHandle))
      {
         DosClose (hfHandle);
         return (-1);
      }

      *lSectors = bpb.usSectorsPerTrack;
      *lTracks  = bpb.cCylinders;
      *lSides   = bpb.cHeads;
      *lSector  = bpb.usBytesPerSector;

      #ifdef DEBUG
         printf("\n DEBUG => found the disk and storing in BIOSPARAMETERBLOCK...\n");
      #endif /* DEBUG */
   }

Anyways...a LOT of detail there, and so I'm going to run some debug sessions to understand this a tad better. In the meantime, any hints would of course be greatly appreciated!!!

9
Programming / DISKIO - Dhrystone benchmark calc
« on: December 21, 2024, 06:23:55 am »
OK, so DISKIO, the continuing mission to boldly go where I haven't gone before! LOL

Working through what seems like funny results, outcomes that change based on duration of the test, which to me implies an overflow.

In the case of the Dhrystone benchmark for the CPU, here is the pertinent section of the code:

Code: [Select]
...
void run_dhrystone (void)
{
   long lDhryTime = dhry_stone ();

   /* originally, time is measured in ms */
   lDhryTime = (lDhryTime + 5) / 10;
   /* now it is in units of 10 ms */

   if (lDhryTime == 0)
      lDhryTime = 1; /* if less than 10 ms, then assume at least 10 ms */

   /* now calculate runs per second */
   ulDhryStones = Number_Of_Runs * 100 / lDhryTime;
   /* by the time we cross 20 million dhrystones per second with a CPU,
      we will hopefully have only 64-bit machines to run this on ... */

   #ifdef DEBUG
      printf("\n DEBUG => lDhryTime      is: %ld", lDhryTime);
      printf("\n DEBUG => Number_Of_runs is: %lu", Number_Of_Runs);
      printf("\n DEBUG => ulDhryStones   is: %lld", ulDhryStones);

      printf("\n\n DEBUG => ULONG size     is: %d\n", sizeof(ULONG));
      printf(" DEBUG => ULONG bit size is: %d\n", sizeof(ULONG) * CHAR_BIT);

      printf("\n DEBUG => LONG LONG size     is: %d\n", sizeof(long long));
      printf(" DEBUG => LONG LONG bit size is: %d\n", sizeof(long long) * CHAR_BIT);
   #endif /* DEBUG */
   
} // end of run_dhrystone
...

...and what I'm seeing is the following weird situation:

1) t=5 secs
Code: [Select]
Dhrystone benchmark for this CPU:
 DEBUG => lDhryTime      is: 502
 DEBUG => Number_Of_runs is: 31084783
 DEBUG => ulDhryStones   is: 6192187    6192187 runs/sec

 DEBUG => ULONG size     is: 4
 DEBUG => ULONG bit size is: 32

 DEBUG => LONG LONG size     is: 8
 DEBUG => LONG LONG bit size is: 64

2) t=7 secs
Code: [Select]
Dhrystone benchmark for this CPU:
 DEBUG => lDhryTime      is: 1003
 DEBUG => Number_Of_runs is: 65230248
 DEBUG => ulDhryStones   is: 2221393    2221393 runs/sec

 DEBUG => ULONG size     is: 4
 DEBUG => ULONG bit size is: 32

 DEBUG => LONG LONG size     is: 8
 DEBUG => LONG LONG bit size is: 64

Clearly, the result for t=7 secs is wrong.

ulDhryStones is defined as 'long long', was originally 'ULONG' but it looked like it was overflowing so I changed it to 'long long', but that's still not big enough.

So this is the weird part (to me anyways), long long is a substantial –9,223,372,036,854,775,807 to 9,223,372,036,854,775,807, so why am I seeing this? Is my printf use of '%lld' incorrect?

10
Programming / CPUMON - source code location?
« on: December 01, 2024, 01:47:49 am »
I have Trevor Hemsley's CPUMON here and I love the overall arrangment / functionality that little util has...BUT...there are a few things I'd like to change: the graph legend as getting past the 2-4 core CPUs these days produces a bit of a mess, colour sync between the lines and CPUx on the legend, provide for a user-controllable refresh rate, etc.

Needless to say, I looked everywhere and haven't found the sources...any ideas where I might though?

Thanks!

11
Programming / DosSetThreadAffinity - process or thread only?
« on: October 19, 2024, 02:52:52 pm »
Trying to learn a bit about SMP capabilities on our platform and I would like to understand the functionality of the DosSetThreadAffinity API.

The Toolkit 'Programming Guide and Reference Addendum' states "...DosSetThreadAffinity allows the calling thread to change the processor affinity mask for the current thread...", so this very much feels like THREAD only control for the current thread I am in, as in: executing right now.

In the meantime, I am curious if this can be applied to a process, and by default all of it's threads?

Further on, could I develop a system driver which would enforce the execution of specific programs (i.e. processes) on a specific CPU/core of a SMP system?

The example code shown in the addendum is:

Code: [Select]
#define INCL_DOS
#define INCL_32
#define INCL_DOSERRORS
#define INCL_NOPMAPI
#include <os2.h>
#include <stdio.h>

int main(void)
{
APIRET rc;
MPAFFINITY affinity;

rc = DosSetThreadAffinity(affinity);
printf("Set thread's affinity rc = %08.8xh\n", rc);
printf("Set thread's affinity affinity[0] = %08.8xh, affinity[1] = %08.8xh\n",
        affinity.mask[0], affinity.mask[1]);
return rc;
}

Given what is shown above, and the fact that no 'target THREAD' parameter is provided, I conclude that indeed this API will only control the current thread.

Any ideas where else I could dig up some info on this and the DosQueryThreadAffinity APIs?

Thanks, as always!

12
Internet / HTTPS server?
« on: October 02, 2024, 03:05:54 am »
I'm using Peter Moylan's excellent WebServe 2.4 at the moment to host a few of my thigns, but given the whole move from http to https, I started to think it would be nice to look into this further (have heard some complaints from people that they can't get to my stuff).

Sooo...what are our choices besides the Apache stuff?

13
Question for the masses: I'm at libtiff-tools 4.0.9 level here, and the 4.6.x release has been sitting out there in EXP state, so I thought I'd take a stab at it with the pre-req of course being the baseline libtiff itself.

The libtiff-tools however drops just about all the "tiff2..." EXE files...so tools themselves, and I see not legacy version out there that still provides these.

Specifically I am after the tiff2pdf.exe one, as PDFmergeNX uses that...

Sooo...I went back to the previous version b/c the latest & greatest doesn't quite seem to be just that.

Is there something else out there that has this? Doing a 'yum provides */tiff2pdf.exe' just lists the previous releases and shows nothing at the 4.6.x level.

EDIT
====

Just spotted libtiff-legacy-tools, but that's at 3.9.5-2 level, and wouldn't that be an older version of libtiff-tools-4.0.9-1? (which is what I had before I executed the upgrade)

14
Multimedia / mplayer - just stopped working...sort of...
« on: March 30, 2024, 07:23:15 pm »
I've been using mplayer for years...only recently (yesterday in fact) noticed that when attempting to play a MP4 file it looks like no actual video is created, although the app itself starts.

So looking into this I found the following in the LOG:

Quote
MPlayer SVN-r38083-9.1.0 (C) 2000-2021 MPlayer Team
Setting process priority: realtime

Playing G:\tmp\AUTO\20210128_201140.mp4.
Cache fill:  0.00% (0 bytes)

libavformat version 58.65.101 (internal)
libavformat file format detected.
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x307b00]Protocol name not provided, cannot determine
 if input is local or a network protocol, buffers and access patterns cannot be
configured optimally without knowing the protocol
[lavf] stream 0: video (h264), -vid 0
VIDEO:  [H264]  1920x1080  24bpp  30.000 fps  34089.8 kbps (4161.4 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 58.118.100 (internal)
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
Clip info:
 major_brand: mp42
 minor_version: 0
 compatible_brands: isommp42
 creation_time: 2021-01-29T01:14:08.000000Z
 location: +42.2680-083.0048/
 location-eng: +42.2680-083.0048/
 com.android.version: 10
 com.android.capture.fps: 30.000000
Load subtitles in G:\tmp\AUTO\
Audio: no sound
Starting playback...
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [kva] 1920x1080 => 1920x1080 Planar YV12
KVA: Setup failed!!!
...

...indeed, the "KVA: Setup failed!!!" is reporting out a problem initiating the video outout.

OK, so I went back to my startup CMD, which is:

Code: [Select]
@mode 80,60
G:\apps\multimedia\mplayer\mplayer.exe -xy %1 %2 %3 %4 %5 %6

And here is what my mplayer.ini file looks like:

Quote
# Write your default config options here!
# VIDEO
vo=kva:snap

# 'geometry' settings, where '+0+0' is the top left
# 'x:y' will put the display at this specific location
# 'x%;y%' will put the display at this percentage of the overall screen location (50%:50% would be center of screen)

# slightly moved from LEFT and TOP sides, good for 720 playback
#geometry=10%

# full-screen-width for 1080 playback (fits on HEAD-0 window)
geometry=0%

#aspect=16:9
double=yes              # double buffering(recommended for subtitles)
autoq=100               # AUTO control the video quality
#vf=pp=de,hqdn3d        # additional post-processing options
#vf=pp                  # additional post-processing options
#framedrop="1"          # For slow machines
#hardframedrop="0"      # Make sure hard frame drop is off but can turn on easily now

# AUDIO
ao=kai:dart
#ao=kai:uniaud
#srate=48000
softvol-max=300

#font=g:\psfonts\verdana.ttf
#subfont=g:\psfonts\verdana.ttf

codecpath=g:\apps\multimedia\mplayer\codecs

# OTHER CONTROLS
msglevel:all=5          # set the DEBUG level (5 = DEFAULT)
cache=20480             # set the TOTAL cache size
cache-min=50            # fill xx% of TOTAL cache before playback start
autosync=30             # sync up video/audio by adjusting the algorithm
#mc=1.0                 # up to how many seconds/frame to adjust
priority=realtime       # set the priority of mplayer (idle,belownormal,normal,abovenormal,high,realtime)

# Video Overlay Options and VIO Message Window Options
#really-quiet=yes       # limit what the VIO window shows
#fixed-vo=yes           # keep display output window open between different feeds
colorkey=0x000001       # change the background to off-black, instead of bright green

# Setting for Browser User Agent response
user-agent=NSPlayer/4.1.0.3856

Is anything jumping out at anyone here? Like I said above, this is the config I've been running for somet time now, heck, my last update of anything is about 2022 timeframe.

Going to try with DIVE next to see if that results in something different...

As always: thanks everyone!

15
Utilities / LinearMemoryMap.cmd => new version produces an error...why?
« on: December 23, 2023, 05:06:46 pm »
So Steven Levine published an updated version of this awesome util, but I'm now seeing an error, which I can't quite decipher:

Code: [Select]
[G:\util\theseus]linearmemorymap
Writing results to G:\util\theseus\linearmemorymap-20231223-1059.lst

[G:\util\theseus]G:\OS2\CMD.EXE /c G:\UTIL\MISC\LinearMemoryMap.cmd -  1>G:\util\theseus\linearmemorymap-20231223-1059.lst
Running from G:\util\theseus
NOVALUE signaled at G:\UTIL\MISC\LinearMemoryMap.cmd line 190.
REXX reason = DIR.
Source ="if dir \== '' then".
   545 *-*         Call lineout 'STDERR', 'Exiting.';
Exiting.
       +++   Interactive trace. "Trace Off" to end debug, ENTER to Continue.

   546 *-*         Nop;

   547 *-*         If symbol('RC') \== 'VAR';

   547 *-*         Then;
   548 *-*           rc = 255;

   549 *-*         Exit rc;

ERROR signaled at G:\UTIL\MISC\LinearMemoryMap.cmd line 114.
REXX reason = G:\OS2\CMD.EXE /c G:\UTIL\MISC\LinearMemoryMap.cmd - >G:\util\theseus\linearmemorymap-20231223-1059.lst.
RC = 255.
Source ="cmd".
   545 *-*         Call lineout 'STDERR', 'Exiting.';
Exiting.
       +++   Interactive trace. "Trace Off" to end debug, ENTER to Continue.

   546 *-*         Nop;

   547 *-*         If symbol('RC') \== 'VAR';

   549 *-*         Exit rc;


I'm running this from the Theseus directory, the linearmemorymap-20231223-1059.lst is created, and appears to be fine.

Any ideas?

Pages: [1] 2 3 ... 13