May 8, 200917 yr Hi Joe L., I've just installed the new script to run from go with -w option. After bootup I reveive the following message in syslog: May 8 21:34:00 Tower atd[2346]: Exec failed for mail command: No such file or directory ... and don't see the "usual" messages in the log, what I see if I run cache_dirs -w from the console after an already booted up unraid. However cache_dirs seem to run, as I see it in /var/lock. Could you please assist me, if I made something wrong? Thank you in advance! EDIT: No, it's not started. However I can start if after bootup.
May 8, 200917 yr OK... based on feedback, attached is version 1.3 of cache_dirs. The changes are as follows: Added -w option, to wait till array comes online before starting scan of /mnt/disk* share folders. Changed default min-seconds delay between scans to 1 instead of 0. Moved test of include/exclude directories to after array is on-line Added logging of mis-spelled/missing include/exclude dirs to syslog Added ability to have shell wildcard expansion in include/exclude names Modified slightly the logic used to adjust loop delay to not adjust unless difference is > .1 seconds. Great work again! Wildcard works perfectly! Haven't rebooted yet, to fully test the -w option, but it's a great idea. I've revised the wiki page (Keep directory entries cached section) to keep up with the changes, hard to keep up at the current pace of changes! Unfortunately ... :'( The whole idea of this script and this thread is to keep all uninvolved drives spun down, and although each major improvement has shown progress with my setup, it is still only keeping half my drives down. There must be some other dynamic involved, that we are not yet aware of. I have 8 drives, 7 data drives, and I almost daily move 5 to 15 gigabytes of TV recordings from desktops to the server, or vice-versa. Lately I have been copying about 10 gigs to Disk 5 every day, and I expect Disk 5 and the Parity drive to spin up, and ONLY those 2. I run SageTV, and it scans all media folders it is aware of every 5 minutes. All 7 data drives have one to three video folders, and some sub-folders. Before I added any drive caching, a large video transfer would cause all 8 drives to spin up, that's 6 drives that I don't want spun up. When I added the '''ls-r''' script, Disk 7 would stay down, Disk 6 would hesitate for awhile, but finally join the rest in spinning up. When I changed to '''cache_dirs v1.2''', then Disk 7, Disk 6, and Disk 3 stayed down, which is progress(!), but Disks 1, 2, and 4 still spun up, completely unnecessarily. With v1.2 and params of "-d 4 -M 6", my scan speed was .02 of a second and sleep period between scans varied between 4 and 5. I upgraded it to v1.3, changed params to "-w -d 5 -M 5", and scan speed remained at .02sec and sleep period changed to 2 seconds between scans, with an occasional brief dip to 1 second, quite aggressive I think, with no improvement in the drives staying down. It seemed to take a little longer, but then Disks 1, 2, and 4 spun up! It's hard to imagine how a scan speed of .02 seconds and a scan period of 2 seconds can be improved significantly. So why are my directory entries getting dumped so fast? What are we missing? The script is definitely working, because for the first time, Disks 3, 6, and 7 are staying spun down. I have 1 GB of RAM, total folders cached is about 20, total files cached about 2200.
May 8, 200917 yr Hi Joe L., I've just installed the new script to run from go with -w option. After bootup I reveive the following message in syslog: May 8 21:34:00 Tower atd[2346]: Exec failed for mail command: No such file or directory ... and don't see the "usual" messages in the log, what I see if I run cache_dirs -w from the console after an already booted up unraid. However cache_dirs seem to run, as I see it in /var/lock. Could you please assist me, if I made something wrong? Thank you in advance! EDIT: No, it's not started. However I can start if after bootup. Nah... it wasn't you. It was me. The reason it does not work is that when I queued up the task in the "at" scheduler, I did not use a full path name to the program. When it executes, it first "cd's" to "/" and then tries to execute the cache_dirs program. Since it is not at "/" and not in the execution path, it is not found, and not executed. It's not even enough to first "cd" to /boot in the go script because the current directory is not in the execute path, so it will not be found. The solution is very easy... Please add one line in the go script, just above the one that invokes cache_dirs to set the PATH variable so it finds the cache_dirs command: If you put cache_dirs in /boot use this: PATH=$PATH:/boot cache_dirs -w If you put cache_dirs in /boot/custom/bin use this: PATH=$PATH:/boot/custom/bin cache_dirs -w It will then know where to find the cache_dirs program when the "at" command goes to execute it. I'll fix this in the next version of cache_dirs Thanks for the feedback.... Joe L.
May 8, 200917 yr The whole idea of this script and this thread is to keep all uninvolved drives spun down, and although each major improvement has shown progress with my setup, it is still only keeping half my drives down. There must be some other dynamic involved, that we are not yet aware of. I am having the same problem too... I started with trying my own ls -r trick (which i set up to be really aggressive, a few weeks ago now), i've tried the cache_drives program. I could not get any to work with my set-up. I am using vista media center with the media browser plugin, without any mods, if I try and browse my list, it will spin up the drive that the highlighted folder is on... as i scroll down my list and highlight(not select, just highlight) each option, if the drive that that folder resides on is spun down, I get a delay while it spins up the drive and then I can proceed to scroll through the list. With any of the tricks installed, the drives will stay spun down as I scroll or enter a directory(for the most part but not 100% of the time), but as soon as I back out of that folder (without selecting anything to play) and back to the root menu (listing all the folders in a share) when I start scrolling again the unraid server inevitably spins up one or more drives, along with the associated stuttering/pausing of the program, when I get to a certain point. I have even tried it on just a single share (using the -i option) with no luck. (ps, if the drives are all spun up, I don't have any problems, browsing the folders never causes a pause in the program) This seems odd to me. As far as I can tell, I have not done anything with the server to push the directory cache out. I was simply browsing up/down through the tree, and it didn't keep the drives down. any ideas? Matt
May 8, 200917 yr OK... based on feedback, attached is version 1.3 of cache_dirs. The changes are as follows: Added -w option, to wait till array comes online before starting scan of /mnt/disk* share folders. Changed default min-seconds delay between scans to 1 instead of 0. Moved test of include/exclude directories to after array is on-line Added logging of mis-spelled/missing include/exclude dirs to syslog Added ability to have shell wildcard expansion in include/exclude names Modified slightly the logic used to adjust loop delay to not adjust unless difference is > .1 seconds. Great work again! Wildcard works perfectly! Haven't rebooted yet, to fully test the -w option, but it's a great idea. I've revised the wiki page (Keep directory entries cached section) to keep up with the changes, hard to keep up at the current pace of changes! Unfortunately ... :'( The whole idea of this script and this thread is to keep all uninvolved drives spun down, and although each major improvement has shown progress with my setup, it is still only keeping half my drives down. There must be some other dynamic involved, that we are not yet aware of. I have 8 drives, 7 data drives, and I almost daily move 5 to 15 gigabytes of TV recordings from desktops to the server, or vice-versa. Lately I have been copying about 10 gigs to Disk 5 every day, and I expect Disk 5 and the Parity drive to spin up, and ONLY those 2. I run SageTV, and it scans all media folders it is aware of every 5 minutes. All 7 data drives have one to three video folders, and some sub-folders. Before I added any drive caching, a large video transfer would cause all 8 drives to spin up, that's 6 drives that I don't want spun up. When I added the '''ls-r''' script, Disk 7 would stay down, Disk 6 would hesitate for awhile, but finally join the rest in spinning up. When I changed to '''cache_dirs v1.2''', then Disk 7, Disk 6, and Disk 3 stayed down, which is progress(!), but Disks 1, 2, and 4 still spun up, completely unnecessarily. With v1.2 and params of "-d 4 -M 6", my scan speed was .02 of a second and sleep period between scans varied between 4 and 5. I upgraded it to v1.3, changed params to "-w -d 5 -M 5", and scan speed remained at .02sec and sleep period changed to 2 seconds between scans, with an occasional brief dip to 1 second, quite aggressive I think, with no improvement in the drives staying down. It seemed to take a little longer, but then Disks 1, 2, and 4 spun up! It's hard to imagine how a scan speed of .02 seconds and a scan period of 2 seconds can be improved significantly. So why are my directory entries getting dumped so fast? What are we missing? The script is definitely working, because for the first time, Disks 3, 6, and 7 are staying spun down. I have 1 GB of RAM, total folders cached is about 20, total files cached about 2200. The biggest difference between the ls -R and the "find" is that you are specifying a maxdepth to scan. Now, I don't know your data, but perhaps try it without any "-d" option... (or make the depth much deeper) The other difference, and it might be the cause, is that it could be the directory nodes in the /mnt/user file system are being displaced. We theorized it was already in memory, so it would not be necessary to scan /mnt/user, but perhaps we were wrong... I'll add in a option to scan it too so we can experiment. You are correct, there is nothing that can be displacing the buffer cache that fast that is uses up all the blocks in a few tenths of a second. The fact that is is scanning so fast indicates everything it is scanning is already in cache. For the other disk to spin up, it must be something we do not have in cache that is being accessed. (does it perhaps constantly access a file on those disks... It could be reading it, and its blocks are not in memory) Joe L.
May 9, 200917 yr If using the include switch does it ignore all other directories or do you still have to use the exclude switch. Thanks, Scott
May 9, 200917 yr Also I have the newest script in the root of my flash drive and this in my go script: PATH=$PATH:/boot cache_dirs -w -i Movies I just want my Movies share cached. This is what I am getting in my syslog after reboot: May 8 20:34:00 Tower cache_dirs: ---------------------------------------------- May 8 20:34:01 Tower cache_dirs: cache_dirs process ID 3378 started, To terminate it, type: cache_dirs -q May 8 20:34:01 Tower atd[3328]: Exec failed for mail command: No such file or directory May 8 20:34:02 Tower ntpd[2108]: synchronized to 216.184.20.83, stratum 2 May 8 20:34:02 Tower ntpd[2108]: time reset -0.519639 s May 8 20:39:18 Tower ntpd[2108]: synchronized to 216.184.20.83, stratum 2 Did I do something wrong??
May 9, 200917 yr If using the include switch does it ignore all other directories or do you still have to use the exclude switch. Thanks, Scott If using the "include" feature, only those directories included are scanned. There is no need to use an exclude as well, unless you use a wild-card for the include directory and the "include" wild-card matches more than you want cached. For example, let's say you have folders like this: Movies-Comedy-Bad Movies-Comedy-Good Movies-Chick-Flicks-Good Movies-Chick-Flicks-Bad Movies-Adventure-Good Movies-Adventure-Bad Movies-Drama-Good Movies-Drama-Bad Movies-Kids-Good Movies-Kids-Bad Movies-Junk-Good Movies-Junk-Bad Data1 Data2 Data3 ... You could use an include rule like this -i "Movies*" and an exclude rule like this in combination with it -e "*Bad" You would cache only those directories that start with "Movies" and do not have "Bad" at the end of their name. If you added one more exclude like this: -e "*Junk*" You would not scan either of the folders with Junk in their name. Joe L.
May 9, 200917 yr Also I have the newest script in the root of my flash drive and this in my go script: PATH=$PATH:/boot cache_dirs -w -i Movies I just want my Movies share cached. This is what I am getting in my syslog after reboot: May 8 20:34:00 Tower cache_dirs: ---------------------------------------------- May 8 20:34:01 Tower cache_dirs: cache_dirs process ID 3378 started, To terminate it, type: cache_dirs -q May 8 20:34:01 Tower atd[3328]: Exec failed for mail command: No such file or directory May 8 20:34:02 Tower ntpd[2108]: synchronized to 216.184.20.83, stratum 2 May 8 20:34:02 Tower ntpd[2108]: time reset -0.519639 s May 8 20:39:18 Tower ntpd[2108]: synchronized to 216.184.20.83, stratum 2 Did I do something wrong?? Nope, you did nothing wrong. It looks to me like it is running. It is process ID 3378. To see it in the process list, type: ps -f -p 3378 The error message " Exec failed for mail command: No such file or directory" occurs because "at" is trying to send mail to the "root" user, telling that it had executed the job. Unfortunately, unRAID does not have a "mail" command, so it fails. It has no effect on the job itself. Joe L.
May 9, 200917 yr Joe, I'm running your newest version and am still not convinced the program is running right. I have well over 1 million files on my system all at a depth of less than 10, but when I run the program with a "./cache_dirs -F -v -d 12" it runs in a split second: Executed find -maxdepth 12 in 0.013269 seconds, avg=0.013269 seconds However when I run it without any depth at all (./cache_dirs -F -v), it took 40 minutes and filled up the buffers to the point where it could hold no more data and started emptying some to make room for more: top - 18:28:52 up 59 min, 2 users, load average: 0.02, 0.41, 0.68 Tasks: 90 total, 1 running, 89 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 6102020k total, 1148084k used, 4953936k free, 542084k buffers Swap: 0k total, 0k used, 0k free, 242324k cached I have 6 GB of ram in the system and at around 580,000k usage in buffers it started going back down again, which doesn't surprise me as 32-bit is limited in this manner with everything I have read. Supposedly 64-bit can cache at least 1.5 Gig. I have my disks set to spin down at 30 minutes and the first couple of disks had time to spin down before it finished running the first set of commands. By the time it got back to disk 1, it had to spin it up and re-cache everything. Since it had emptied some of the cache or hit the limit, then it will constantly spin up the drives and loop through them over and over. Obviously this will not work for systems with lots and lots of files without a 64-bit version Looking at the verbose output, it looks like you are running this command - "find -maxdepth 2 /mnt/disk4/Movies"; however when I issue this command at the command prompt, I get the following: find: paths must precede expression Usage: find [-H] [-L] [-P] [path...] [expression] When I put the -maxdepth at the end - "find /mnt/disk4/Movies -maxdepth 2" it runs fine and I see a bunch of files. Are you issuing the -maxdepth after the path or before? This would explain why it runs so fast when I use maxdepth of anything and essentially doesn't cache anything. I am running unRAID version 4.4.2, so this may have something to do with it?
May 9, 200917 yr Looking at the verbose output, it looks like you are running this command - "find -maxdepth 2 /mnt/disk4/Movies"; however when I issue this command at the command prompt, I get the following: find: paths must precede expression Usage: find [-H] [-L] [-P] [path...] [expression] When I put the -maxdepth at the end - "find /mnt/disk4/Movies -maxdepth 2" it runs fine and I see a bunch of files. Are you issuing the -maxdepth after the path or before? This would explain why it runs so fast when I use maxdepth of anything and essentially doesn't cache anything. I am running unRAID version 4.4.2, so this may have something to do with it? You nailed it... I'll post a corrected version shortly. Edit... the new version is posted... It has the correct order of the arguments to the "find" command so it actually works. The version of unRAID had nothing at all to do with this problem ftp222 found. It was a programming error that was affiliated with using the "-d" option. Thanks so much for finding this. Joe L.
May 9, 200917 yr The biggest difference between the ls -R and the "find" is that you are specifying a maxdepth to scan. Now, I don't know your data, but perhaps try it without any "-d" option... (or make the depth much deeper) We may have a winner! I removed the -d option, so no -maxdepth, and with a short test (only 1.3GB), it seems to have worked correctly, only the 2 drives spun up. This was not a conclusive test, that will be done tomorrow morning. My 20 folders are very shallow, so I really don't think it was a problem of depth. The other difference, and it might be the cause, is that it could be the directory nodes in the /mnt/user file system are being displaced. We theorized it was already in memory, so it would not be necessary to scan /mnt/user, but perhaps we were wrong... I'll add in a option to scan it too so we can experiment. You are correct, there is nothing that can be displacing the buffer cache that fast that is uses up all the blocks in a few tenths of a second. The fact that is is scanning so fast indicates everything it is scanning is already in cache. For the other disk to spin up, it must be something we do not have in cache that is being accessed. (does it perhaps constantly access a file on those disks... It could be reading it, and its blocks are not in memory) I don't use User Shares, so never have a /mnt/user folder, so I wouldn't waste much time on that. I think you are on the right track with the maxdepth thing. Edit: by the way, scan speed increased slightly to .022 seconds, instead of .020 seconds, scan period is staying around 2 seconds.
May 9, 200917 yr I don't use User Shares, so never have a /mnt/user folder, so I wouldn't waste much time on that. I think you are on the right track with the maxdepth thing. I do use user shares and I think you may be on to something with the caching of disk shares not helping user shares... I did a very crude attempt at trying to write my own quick and dirty script to test the theory and it seems like I did gain quite a bit from cache the user shares directly. Drives were still spun up, but it seemed to hold onto things longer and through deeper browsing. if you are still up to it, it would be nice to have it in the script to at least be able to test it side by side under the same script with the same settings. It can also be tken out if it proves to be useless. Cheers, and thank you for your continued efforts. Matt
May 9, 200917 yr The solution is very easy... Please add one line in the go script, just above the one that invokes cache_dirs to set the PATH variable so it finds the cache_dirs command: If you put cache_dirs in /boot use this: PATH=$PATH:/boot cache_dirs -w If you put cache_dirs in /boot/custom/bin use this: PATH=$PATH:/boot/custom/bin cache_dirs -w It will then know where to find the cache_dirs program when the "at" command goes to execute it. I'll fix this in the next version of cache_dirs Thanks for the feedback.... Joe L. Thank you Joe L. Anyway, me too seems to have issues with caching all drives and dirs with the new version. For me, it was OK with earliers versions with ls -R method. Would it be possible to bring it back as an option, while defaulted to 'find'? Or it is possible to track down the difficulties with the 'find' method? Thank you again for the efforts you put into this!
May 9, 200917 yr The solution is very easy... Please add one line in the go script, just above the one that invokes cache_dirs to set the PATH variable so it finds the cache_dirs command: If you put cache_dirs in /boot use this: PATH=$PATH:/boot cache_dirs -w If you put cache_dirs in /boot/custom/bin use this: PATH=$PATH:/boot/custom/bin cache_dirs -w It will then know where to find the cache_dirs program when the "at" command goes to execute it. I'll fix this in the next version of cache_dirs Thanks for the feedback.... Joe L. Thank you Joe L. Anyway, me too seems to have issues with caching all drives and dirs with the new version. For me, it was OK with earliers versions with ls -R method. Would it be possible to bring it back as an option, while defaulted to 'find'? Or it is possible to track down the difficulties with the 'find' method? Thank you again for the efforts you put into this! You can still have it, even now, just use -c "ls -R" iin addition to any -i and -e options. (because you could always use any "command" I did not have any issue about removing it.) Do not use any "--d" option, as it forces you back to "find -maxdepth" As I said in my earlier post, the last version is broken as the "find" command is being invoked with the wrong parameter order. I've been running the newer version for a few hours now, so I'll zip it up and attach it to a new post. Joe L.
May 9, 200917 yr OK, here's version 1.4.1 Fist and most important, I fixed the "find" command arguments so it is invoked correctly. Now it should actually descend into the sub-directories to the maxdepth specified. Next, I fixed the command submitted to "at" to use a full path. If you invoke this version in your "go" script you need to invoke it in one of three ways: 1. Add a line to set the PATH (only method that worked with older versions) PATH=$PATH:/boot cache_dirs -w or 2. Change directory to /boot before invoking cache_dir like this:cd /boot cache_dirs -w or 3. Use the full path when invoking cache_dirs, like this:/boot/cache_dirs -w Last, I added a new "-u" option to allow you to also scan and cache /mnt/user (the user-share hierarchy) just in case it helps. Sorry for any inconvenience... Thanks to everybody in help with this. It does take longer to scan the sub-directories, as you might expect, but then it also does have more work to do, now that it is actually invoking the "find" command correctly. Edit: fixed the comment at the top of the program. 1.4 is now 1.4.1 Edit: Newest version 1.5 is here: http://lime-technology.com/forum/index.php?topic=3666.msg33498#msg33498 Edit: Newest version is here: http://lime-technology.com/forum/index.php?topic=4500.0 Joe L.
May 9, 200917 yr -q is supposed to stop cache_dirs right cause on mine all it does is tell you the process id root@TOWER:~# /boot/scripts/cache_dirs -q cache_dirs is already running [12371]
May 9, 200917 yr -q is supposed to stop cache_dirs right cause on mine all it does is tell you the process id root@TOWER:~# /boot/scripts/cache_dirs -q cache_dirs is already running [12371] It was late... I had been testing the newer version for about 2 hours, I saw I had not yet put the version comments at the top of the script and added them just before zipping it up. At the top of the script, there is a "comment" describing the revision history. On line 28, I left off the leading "#" when I re-formatted a long line to not wrap around the screen. If you add it, you will again be able to kill the process easily. [pre] # Version 1.4 Fix bug with argument order passed to find when using -d option # Fixed command submitted to "at" to use full path. Should not need to # set PATH variable in "go" script. # Added ability to also cache scan /mnt/user with -u option [/pre] I've highlighted the missing "#" in the correct line in red above. My luck, "set" is a valid command... It kept the -q from being recognized. (actually, it kept any from being recognized). I'll zip up version 1.4.1 in a minute or two, as soon as I go make some coffee... :'( Edit: its's there now. as version 1.4.1 Edit: Version 1.5 attached here: http://lime-technology.com/forum/index.php?topic=3666.msg33498#msg33498 Edit: newest version is here: http://lime-technology.com/forum/index.php?topic=4500.0 Joe L.
May 9, 200917 yr I'll zip up version 1.5 in a minute or two, as soon as I go make some coffee... :'( OK... now I have a cup of coffee in front of me... Freshly ground... freshly brewed... I'm ready to be beaten up about my stupid (but syntactically correct ) error. Joe L.
May 9, 200917 yr Joe, I don't seem to be able to get this working properly. I edited the 'go' script using the PATH method and after a reboot I get the message "cache_dirs is already running" when trying to execute from the prompt. Sounds good, but the drives still spin up while browsing the shares. Using -F -v shows the same list every 5 seconds. Executing find /mnt/disk1/Audio Executing find /mnt/disk2/Audio Executing find /mnt/disk3/Audio Executing find /mnt/disk6/Backup Executing find /mnt/disk6/Game Executing find /mnt/disk6/Prog Executing find /mnt/disk1/Video Executing find /mnt/disk2/Video Executing find /mnt/disk3/Video Executing find /mnt/disk4/Video Executing find /mnt/disk5/Video Executing find /mnt/disk6/Video Executed find in 0.224566 seconds, avg=0.228831 seconds, now sleeping 5 seconds
May 9, 200917 yr Joe, I don't seem to be able to get this working properly. I edited the 'go' script using the PATH method and after a reboot I get the message "cache_dirs is already running" when trying to execute from the prompt. Then it sounds like it was started. You can type ps -ef | grep cache_dirs | grep -v grep to see if it is in the process list. but the drives still spin up while browsing the shares. Using -F -v shows the same list every 5 seconds. Executing find /mnt/disk1/Audio Executing find /mnt/disk2/Audio Executing find /mnt/disk3/Audio Executing find /mnt/disk6/Backup Executing find /mnt/disk6/Game Executing find /mnt/disk6/Prog Executing find /mnt/disk1/Video Executing find /mnt/disk2/Video Executing find /mnt/disk3/Video Executing find /mnt/disk4/Video Executing find /mnt/disk5/Video Executing find /mnt/disk6/Video Executed find in 0.224566 seconds, avg=0.228831 seconds, now sleeping 5 seconds Are you using the latest version? Previous version was broken.
May 9, 200917 yr I'm using version 1.4 and grep does show it in the process list. It does seem that some dirs are kept in cache, maybe the ones I was browsing before.
May 9, 200917 yr -q is supposed to stop cache_dirs right cause on mine all it does is tell you the process id root@TOWER:~# /boot/scripts/cache_dirs -q cache_dirs is already running [12371] It was late... I had been testing the newer version for about 2 hours, I saw I had not yet put the version comments at the top of the script and added them just before zipping it up. At the top of the script, there is a "comment" describing the revision history. On line 28, I left off the leading "#" when I re-formatted a long line to not wrap around the screen. If you add it, you will again be able to kill the process easily. [pre] # Version 1.4 Fix bug with argument order passed to find when using -d option # Fixed command submitted to "at" to use full path. Should not need to # set PATH variable in "go" script. # Added ability to also cache scan /mnt/user with -u option [/pre] I've highlighted the missing "#" in the correct line in red above. My luck, "set" is a valid command... It kept the -q from being recognized. (actually, it kept any from being recognized). I'll zip up version 1.4.1 in a minute or two, as soon as I go make some coffee... :'( Edit: its's there now. as version 1.4.1... attached to http://lime-technology.com/forum/index.php?topic=3666.msg32991#msg32991 Joe L. Thanks Joe new version working as expected. Nice work.
May 9, 200917 yr I'm using version 1.4 and grep does show it in the process list. It does seem that some dirs are kept in cache, maybe the ones I was browsing before. Yes, 1.4 is broken...as reported in the earlier post I made. try 1.4.1, or edit 1.4 yourself to fix the comment at the top. Joe L.
Archived
This topic is now archived and is closed to further replies.