DSperber

Well, that did it!! But I think we need to pin this down more precisely, as I have three machines running Win7 with 850 Pro drives all of which have EXM04B6Q firmware. I need to enumerate what really is the "RAID" aspect of this, since I'm not actually running RAID on any of these machines. But I do have Intel RST installed on all three of these (which I thought would "improve" SATA performance even in a non-RAID situation). So it might have been installing Intel RST which was really responsible for the disappearance of drive temperature (i.e. SMART data), and not actually the firmware upgrade to EXM04B6Q. On the other hand, it could be something working together between EXM04B6Q and Intel RST, because I'm sure I was very careful to confirm that on my P70 still running with EXM03B6Q I still had drive temperature, and it was only after upgrading to EXM04B6Q that the drive temperature disappeared immediately. So this couldn't have had anything to do with Intel RST. Furthermore, on one of my machines (with the 128GB 850 Pro, which also has the "unique" Hardware ID that has complete 850 Pro and 128G character strings) Intel RST is also installed, and the two RAID SMART are NOT checked, and yet I DO get SMART data and drive temperature. But the other two machines running with the larger 512GB and 1TB models that have the "generic: Hardware ID that is missing the critical character strings (or at least I think they're critical), the SMART data and drive temperature vanished once EXM04B6Q was applied. And ALL of these drives have a Hardware ID that starts with SCSI. So, all three of these Win7 Pro machines are Skylake chipset motherboards, all have an 850 Pro with firmware EXM04B6Q, and all have Intel RST installed to "enhance SATA performance". All three machines show "Intel 100 Series/C230 Chipset Family SATA AHCI Controller" in Device Manager, but the version of Intel RST installed is different on all three machines (but supposedly most current for that machine, per the hardware vendor). (1) Lenovo P70 laptop, 512GB 850 Pro, Intel RST 15.7.0.1074: AIDA64 did not show drive temperature until the two RAID items were checked, and now it does. (2) ASUS Z170-Deluxe desktop, 1TB 850 Pro, Intel RST 15.7.1.1015: AIDA64 did not show drive temperature until the two RAID items were checked, and now it does. (3) Lenovo M800 SFF desktop, 128GB 850 Pro, Intel RST 14.5.0.1081; AIDA64 always showed drive temperature even though two RAID items are NOT checked!!! I am still of the opinion that there is more connection to the Device Manager disk drive name, and the "generic" Hardware ID value for the 512GB and 1TB models which adds yet one more variable to the mix. The fact that the M800 situation with the 128GB model where Intel RST is also installed but which has the "unique" Hardware ID and which also does NOT have the two RAID items checked and yet where AIDA64 actually DOES report drive temperature... how can this be, unless there is more significance to the "unique" device name character string shown in Device Manager and/or Hardware ID which is equally as useful in identifying the SMART-capability of the drive, even if those two RAID sensor checkboxes are left unchecked for AIDA64. In other words that must be some explanation for why the SMART data is still obtained for the 128GB model (with the "unique" Hardware ID) even though Intel RST is also installed as with the other stories, and even though the two RAID boxes are NOT checked. This 128GB model is the only one whose Hardware ID is "unique" and complete, with fully identifying info. And yet all three model's Hardware ID start with SCSI, so that can't be critical. Anyway, there is no question that your suggested solution DID WORK! I now have SMART data (and thus drive temperature) not only for the Samsung 850 Pro SSD, but also for the other SATA HDD devices in the machine, which also have SCSI at the start of their Hardware ID... which also had mysteriously disappeared, I think once I installed Intel RST that is when SCSI showed up, and perhaps was really the start of my AIDA64 disappearing drive SMART data problems. I believe it is really Intel RST which is what necessitates the two RAID boxes to be checked, in order to retrieve SMART data from ANY SATA DEVICE, SSD or HDD. But then there is that mystery of the 128GB 850 Pro which is getting SMART data and yet does NOT have the two RAID boxes checked!!! What's the answer there?

I have opened a support ticket on this problem weeks ago, but so far have received only initial acknowledgement and no status update beyond "works for us, must be something at your end". Well that's not much of a diagnostic interest in getting to the bottom of exactly what it really might be "at my end" which is responsible for the AIDA64 failure, and it is indeed failing... but only in Win7, as it works properly in Win10. I believe I have completely analyzed the situation and have a complete understanding of the circumstances and clues. All I ask is help from FinalWire, to fix the problem... which is unique to the Win7 execution of AIDA64. Background: I own four different size Samsung 850 Pro SSD drives, 128GB, 256G, 512GB and 1TB. With previous versions EXM02BQQ or EXM03B6Q of the drive firmware all four of them used to have a unique Hardware ID (as shown by Device Manager), that contained both (a) a character string identifying the drive as "Samsung SSD 850 Pro", and (b) a character string identifying the size of the drive, such as "128G", "256G", "512G" or "1TB". However now with the latest EXM04B6Q version of the drive firmware, the devices now have somewhat different Hardware ID's than they used to have. Thankfully for AIDA64, with EXM04B6Q firmware installed the 128GB and 256GB versions of the drive still do have unique Hardware ID's that identify both the drive and its size correctly, to Device Manager as well as to AIDA64. However the EXM04B6Q firmware "broke" the Hardware ID for the larger 512GB and 1TB versions of the drive. For these larger models the Hardware ID is non-unique (but in fact identical for both drive models), and also does NOT contain either of the expected character strings identifying the drive model and size. And it is THIS which has caused problems for AIDA64 running in the Win7 environment. By sheer luck, Win10 Device Manager is "smarter" than in Win7, and apparently is perhaps looking at the still-unique "world wide name" identity of each drive model, rather than just the Hardware ID. So AIDA64 running in Win10 doesn't have a problem knowing that this is a Samsung 850 Pro SSD drive of a certain size, and that SMART data is obtainable, and therefore drive temperature is available for reporting. However AIDA64 running in Win7 cannot determine that this is a Samsung 850 Pro SSD drive of a certain size, and thus NO SMART DATA IS RETRIEVED, and therefore no drive temperature is available for reporting. That's the problem. Note that even though the cause of the problem has really come from Samsung by screwing up the Hardware ID for the two 512GB and 1TB larger models of the product family, this causes no issue for the HWINFO64 or CrystalDiskInfo software products, which clearly are making use of the still-unique "world wide name" value to still correctly identify the drive make/model/size. It is only AIDA64 running in Win7, which fails to properly identify the 512GB and 1TB models of this drive with EXM04B6Q firmware installed (even though it sill correctly identifies the smaller 128GB and 256GB models as their Hardware ID is still "acceptably unique"). I would guess that, like me, any other Win7 AIDA64 users of the Samsung 850 Pro SSD in the 512GB or 1TB sizes should be experiencing the identical Win7 AIDA64 failure to present drive temperature (even though the identical machine and drive WILL see Win10 AIDA64 present drive temperature, simply because Win10 Device Manager works differently than Win7 Device Manager). It would be comforting to me if other Win7 AIDA64 users could confirm that they, too, see my symptom with this drive and EXM04B6Q firmware. Here are the specifics, as I know them right now, based on my research. Note that the 256GB model is from someone else, who didn't provide everything and so I cannot really vouch for the 100% accuracy of that drive's details. But I was able to gather info for myself for the other three drive sizes which I actually have installed in my own machines. (1) 512GB with EXM04B6Q (AIDA64 does Not retrieve SMART data in Win7, and does NOT present drive temperature; Win10 AIDA64 works fine) (a) Hardware ID: SCSI\DiskSamsung_SSD_____________EXM0 (b) Win7 Device Manager disk drive name: "Samsung SSD SCSI Disk Device" (c) Win10 Device Manager disk drive name: "Samsung SSD 850 Pro 512GB" (d) HWINFO64 drive name: "Samsung SSD 850 Pro 512GB", world wide name: 50025388400576F2 (e) CrystalDiskInfo: "Samsung SSD 850 Pro 512GB" (2) 1TB with EXM04B6Q (AIDA64 does Not retrieve SMART data in Win7, and does NOT present drive temperature; Win10 AIDA64 works fine) (a) Hardware ID: SCSI\DiskSamsung_SSD_____________EXM0 (b) Win7 Device Manager disk drive name: "Samsung SSD SCSI Disk Device" (c) Win10 Device Manager disk drive name: n/a (d) HWINFO64 drive name: "Samsung SSD 850 Pro 1TB", world wide name: 5002538C4043F52C (e) CrystalDiskInfo: "Samsung SSD 850 Pro 512GB" (3) 128GB with EXM04B6Q (AIDA64 retrieves SMART data in both Win7 and Win10, and does present drive temperature in both) (a) Hardware ID: SCSI\Disk_Samsun_SSD_850_Pro_128GEXM0 (b) Win7 Device Manager disk drive name: "Samsun SSD 850 Pro 128G SCSI Disk Device" (c) Win10 Device Manager disk drive name: n/a (d) HWINFO64 drive name: "Samsung SSD 850 Pro 128GB", world wide name: 50025388401AD82D (e) CrystalDiskInfo: "Samsung SSD 850 Pro 128GB" (4) 256GB with EXM04B6Q (AIDA64 retrieves SMART data in both Win7 and Win10, and does present drive temperature in both) (a) Hardware ID: SCSI\DiskSamsung_SSD_850_PRO_256GEXM0 (b) Win7 Device Manager disk drive name: "Samsung SSD 850 PRO 256GB" (c) Win10 Device Manager disk drive name: n/a (d) HWINFO64 drive name: n/a (e) CrystalDiskInfo: n/a

I just gave beta build 3124 a try, thinking perhaps some additional adjustments might have been made to the logging functionality without a matching update post here in this thread. Didn't happen. So after experimenting with the related Preferences options as well as the RMB menu start/stop items, I honestly feel that the current logging behavior is confusing and seemingly inconsistent, although it may performing be exactly as you programmed it to work. Which is why I'd like to again propose just a few small alterations and tweaks which (if others following this thread might "vote" agreement or disagreement) I feel would produce completely unambiguous and totally consistent and intuitive slightly altered new behavior. Here is a description of currently implemented logging behavior along with my comments as well as suggestions for what I feel would be very beneficial user-friendly tweaks and adjustments. (1) The primary "problem" as I see it is that the current single checkbox in Preferences which designates the type of logging output is actually behaving as a two-function option controlling and activating both options, which makes it ambigous and undesirable as currently implemented: a - choose the TYPE of logging output, either HTML or CSV and specify a path/filename prototype, and b - automatically START the logging function when the Aida64 program is launched But if the "log sensor readings" checkbox is UN-CHECKED while a non-blank path/filename prototype is still present, the logging function is NOT automatically started with Aida64 is launched. Instead, initiating the logging session is deferred following program launch until the "start" item from the RMB menu is selected at which time the logging session is begun and a pair of initial LOG/STAT files for that logging session opened with the designated path/filename prototype used along with a current date/time filename suffix appended. I think it would be clearer and more intuitive to the user if there actually were one more new logging checkbox option presented: "automatically start logging when Aida64 program is launched". Having this new checkbox option available would clearly imply that a logging session is either to be started automatically along with Aida64 program launch, or not automatically started but rather deferred until a manually requested "start" is issued. And that new second checkbox option would then clearly separate the other true preference option, which is to deisgnate the type of log file(s) format (HTML or CSV) and its path/filename prototype. (2) The second "problem" as I see it is that there is no "finished" line guaranteed to always be added at the very end of the LOG file (as a "footer" record) if the RMB menu "stop" item is selected to stop the current logging session. There is only guaranteed to be the "started" line at the top of the LOG file which got written when the current logging session began (either automatically at program launch of manually if the RMB menu "start" item was selected). The "finished" line only appears at the very end of the LOG file if the Aida64 program itself is terminated while the logging function is still active. It does not appear if the RMB menu "stop" item is selected earlier to stop the current logging session manually. This makes for an inconsistent and confusing to the user LOG file output structure, which may or may not have the "finished" last line depending on how the logging session being tracked by the LOG/STAT files was ended. In contrast, the "started" and "finished" lines ALWAYS appear at the top of the STAT file, even though the current logging session may actually still be active and in progress, and thus is not actually "finished" at all. And yet, there is ALWAYS a pair of "started" and "finished" lines with the "finished" English words actually suggesting something that is not true since the logging session is actually still "in progress and active". Furthermore, while the logging session is active the pair of LOG/STAT files is realtime updated (as a pair) at the logging update frequency specified in Preferences. And each new set of updated LOG/STAT files shows a newly updated "finished" item in the STAT file which reflects the always increasing new date/time of the most recent update, whereas there is never a "finished" item shown in the ongoing LOG file (which does seem reasonable, since ongoing new LOG lines will be continually added at the bottom until the logging session is ended). So looking at the STAT file while the current logging session is progressing, the "started" line remains fixed since the current logging session obviously started at some fixed time. However the "finished" line keeps changing, updated to the new current date/time at each logging update frequency interval. And simuiltaneously, looking at the LOG file while the current logging session is progressing, the "started" line also remains fixed and there is never a "finished" (footer) record but rather only continually appended new detail logging lines. (3) In my opinion if the logging session is still active so that the pair of LOG/STAT files is updated periodically at log update frequency, perhaps better and more appropriate English for that "finished" line in the ongoing updated STAT file (i.e. until the logging session is actually ended) might be something like "current last LOG entry" or similar. This would more accurately convey the status of things, i.e. that the ongoing logging session is actually still active and not stopped/closed. Only when the logging function is truly terminated (either temporarily with the RMB menu "stop" item or permanently by closing the Aida64 program) would a "finished" item be posted instead of the "current last LOG entry", thus conveying the implication that the logging session is truly ended and no longer active. And now the "started" item would reflect the true time that the logging session started, and the "finished" item would truly reflect the time that the logging session ended... for the logging session monitored by the pair of LOG/STAT files. (4) And for sure, when the current logging session is ended (either manually through RMB menu "stop" item or automatically by closing the Aida64 program) there should ALWAYS be a "finished" item added at the end of the LOG file (prior to issuing the CLOSE for the file) as a "footer" record, so that it always appears no matter how the logging session was ended. There's no reason the LOG file should not be wrapped up when logging ends with this "footer" record showing the time that the logging session was ended, no matter how the session was ended. Today, the "finished" item only appears if the method of logging termination is to close the Aida64 program while logging is still ongoing and active (which also forces logging to be automatically started when the Aida64 program is next launched!). If the RMB menu "stop" item had previously been used to end the logging function, A - there is no "finished" footer line posted to LOG file which has now been CLOSE'd, and B - closing the Aida64 program also does result in the "finished" footer added to the already closed LOG file. Inconsistent and confusing not to see a "finished" footer record always appear in the LOG file to identify when exactly the logging session being tracked was ended. (5) If logging is active because the "log sensor readings" checkbox was CHECKED, and the RMB menu "stop" item is used to end the current loggging session, and Preferences is examined, the "log sensor readings" checkbox will appear as UN-CHECKED. However this Preferences appearance is only in-memory and temporary. If the Aida64 program is closed at this moment the UN-CHECKED state of this option is NOT saved. So the next time the Aida64 program is re-launched, the original CHECKED state of the option will once again be in effect, and thus logging will automatically be activated at program launch, even though the last thing done in the prior program instance was to "stop" logging. Again, this is inconsistent and confusing and ambiguous to the user, because there essentially are TWO functions implied by the ONE checkbox option for logging... when there should really be TWO SEPARATE OPTIONS to control two separate user choices for controlling program behavior. In summary... There should be a distinct new option to control whether or not sensor logging is to automatically begin (or not) when the program is launched. If this option is not checked then the RMB menu "start" item must be used sometime after the program is launched to manually start a logging session. This new option is separate from the existing checkbox option which should be re-purposed to specifically designate the LOG/STAT file format (either HTML or CSV). And again, no matter whether the logging session is automatically begun when the program is launched or manually begun using the RMB menu "start" item, and no matter whether the logging session is automatically ended when the Aida64 program is ended or manually ended when the RMB menu "stop" item is selected, there should ALWAYS be a "finished" item (shown as footer record in LOG file) present in both the LOG and STAT files. It should not be sometimes missing. And for cosmetic and user-friendly reasons the "finished" line that always currently appears in the STAT file (updated at regular logging update frequency throughout the still active logging session) no matter that the current session is still active and ongoing, I'd suggest an English change to show "current last LOG entry" rather than "finished" to more accurately convey the meaning of this date/time value. Only at the end of the logging session might the English "finished" be used.

I see. Now that I've actually closed the program (with a logging session currently open) I can see your new generated last line in the LOG file. However now I'm actually a bit confused as to how logging is supposed to be activated or not. I had assumed it was a "dynamic" function, activated by selecting "start sensor logging" from the RMB context menu on the System Tray icon. I had assumed that my checking in Preferences of "log to HTML" was simply choosing the HTML output option over say CSV output, not that this check actually automatically enabled logging when the program is started. But now that I see what's happening (which is that when I RMB on the icon the choice presented immediately after launching the program is to "stop sensor logging", implying that it is already active... although I did not explicitly "start sensor logging" but instead only checked the HTML output choice in Preferences) I can see why I'm confused, and why the program behavior is other than I expected. I thought I had to manually start it from the RMB menu, but apparently not. Apparently is auto-starts at program launch because I had checked the "HTML output format" option box in Preferences. I would have thought the Preferences option simply describes the type of output desired, and not simultaneously forces auto-start of logging when the program launches. Perhaps there should be another checkbox on this same Logging tab, to actually request auto-start of logging when the program launches or not (if this new checkbox is not checked). In the absence of this new checkbox not being checked, logging would NOT auto-start when the program launches, but rather must be manually initiated through the RMB context menu and selecting "start sensor logging". In some circumstances, I suppose automatic launching of the logging function when the program starts might be desired, but I would think that most of the time this is NOT desired. And since I run Aida64 100% of the time, I really do want the ability to conveniently be able to start/stop a logging session without having to close/re-launch the program itself. That's what I thought the RMB context menu items were for... to manually "start logging" and "stop logging", and that the "start logging" actually opened a new file (rather than resumed writing to an existing file), and that the "stop logging" actulaly closed the currently opened file (rather than just suspending logging but keeping the file open so as to facilitate later resuming of logging). So, this is obviously my own confusion in understanding how this works. Certainly there IS a "finished" line now added to the STAT file simply when I select the "stop logging" item on the RMB context menu, so I feel justified in expecting that same line to have also been written to the LOG file as a direct result of this action. I feel justified in thinking this whole START/STOP process (using the RMB context menu items) to be like OPEN/CLOSE for a brand new pair of files, rather than RESUME/PAUSE for a one-and-only pair of files reflecting the program's instance. Personally, I guess it is that ambiguity which stems from my checking of "HTML output format" which also seems to automatically launch logging when the program starts (and which is NOT what I expected or want) that is at the heart of the confusion. Yes, I want HTML as opposed to CSV format output. But I want the logging to be manually started and stopped by me, when I want to. And each START/STOP pair produces a new pair of LOG/STAT files, with the proper STARTED/FINISHED lines showing in both LOG and STAT files... even with the program itself still remaining active and running across each of these event pairs that results in a distinct new pair of LOG/STAT files.

I don't understand the timing. What I've posted is what got produced when I clicked on the "stop sensor logging" item on the popup menu from RMB on the Aida64 icon in System Tray. That's when both files get closed and appear in the directory, and that's the date/time of the two file entries in the directory. Why isn't the new footer record in the LOG file not written to the LOG file prior to issuing the CLOSE, which creates the file from the session I just ended?? What does this have to do with closing the program or opening a new log file?? I want to see the identical two STARTED/FINISHED information lines in both LOG and STAT files from a given logging session that I started and let run for a while and then ended. I don't expect any additional information to be "deferred" until after the program itself is ended (which in my case is NEVER), or when opening a new log file (which may never happen if I choose to never start another logging session). What am I missing about your design in implementing what you've coded so far?

3120 doesn't seem to have made any change to the LOG file. No "footer" record.

One last pitch for the one missing line to be added to the end of the LOG file... using "visual aids" to try and persuade you to do this one final tweak. Here's what the STAT file looks like. Note the START and FINISH lines, providing all of the relevant information about the logging session. I recognize that the entire STAT file is produced all at once, when the logging session is terminated, hence why it's possible to put the FINISH line right after the START line. And in contrast here's what the LOG file looks like. Note the START line up at the beginning of the file which is physically there because that's produced at the beginning of the logging session, followed by an indefinitely growing list of detail lines over time, each generated at the specified logging update frequency. Now I ask again why you cannot write one more line of data at the physical end of the LOG file, showing the FINISH info... exactly the same line as you show in the STAT file? The LOG file would then be closed, and you'd be able to see the START line up near the very top as a "report header", and also see the last detail lines then followed by the FINISH line, as a "report footer". Doesn't this seem reasonable, to show both START and FINISH in both logging outputs?? Thanks.

How about just appending one this log finish final line at the end of the LOG file rather than requiring it to be up at the top where it really can't be placed at this time? Then you'd be showing the same log start and log finish info that you place in the STAT file? This would have the currently present log start line at the front of the LOG file and the currently missing log finish line at the end of the LOG file. Perfectly fine with me, as long as both pieces of info are present in both log files. I realize the information about log finish is probably close to the same date/time info as is implied in the final detail entry in the LOG file, and I probably don't absolutely need to see the official log finish line to know about when logging got stopped. But just for "closure" it seems showing both start and finish "title items" in both LOG and STAT files makes sense to me. I wouldn't care that it's the very final line of the LOG file rather than up at the top immediately following the log start line where it is placed in the STAT file. I'd just really like to see that currently missing line present in the LOG file, indicating the precise time that logging was terminated and confirming that the logging process terminated normally (by the presence of this "closing" line in the LOG file).

Thank you. Could I suggest that both the log start and log finish time stamps be placed in the LOG file as well as the STAT file? Seems like this information should be in both files. For some reason you added only the log start to the LOG file but didn't also add the log finish. In contrast you added both items to the STAT file. Don't know why both items shouldn't appear in both log files.

Aha! Date and time boxes should have been checked! That was the secret. I've also set my logging update frequency to 15 seconds, to reduce unnecessarily granular detail rows in LOG. Entries look useful now. Thank you. As far as the STAT file, are you saying that while the actual logging session start/finish date/time values should clearly have been displayed as part of the titling content (which they will be in the next upcoming beta), that there will in fact only be one row max per STAT file as the total content of this HTML file? Its purpose is strictly to show the minimum, maximum and average values during the entire course of the logging session, with a new pair of files started anew for each 24 hour period if logging goes on for longer than that since I have that value set? There's no way to get one line in the STAT file for each 24 hours, and not create a new file? What about having another checkbox that controls whether or not a new file is to be started at all, or whether just another additional min/max/avg row gets added to the one file every so often according to the separate specified number of hours frequency value? I really don't necessarily want a huge number of files (if I leave logging on say for a month), but rather would just like a single large file with a separate row for each 24-hour period. Just trying to understand what I should expect to see.

I want to log only "UPS battery power" over time, which is represented by the File -> Preferences -> Logging -> Power Values -> Battery checkbox item. I plan on replacing my video card with a much lower power card (at modest reduction in graphics performance) and want to see how much savings in electricity this has bought me as the machine is on 24/7. So I unchecked everything in the Logging list except for that Battery item, and then checked the "Log sensor readings to HTML log file" and hit APPLY. I don't know how often individual lines are supposed to be added to whatever HTML output is produced, but it appears that in one of the two HTML outputs a single line with the power wattage value is generated every 4 seconds (i.e. 15 times per minute, meaning 15 lines per group), which is my OSD update frequency. This would be meaningful and informative if there were actually a date/time value also generated next to the power wattage value... BUT THERE IS NOT! So there is no way at all to tell what the "raw" output items are, in terms of the date/time of that 4-second value. Then, there is a second HTML output produced which appears to show a minimum and maximum value for the power wattage. However although I assume this HTML file starts when I push APPLY with the LOG checkbox checked, and closes when I push APPLY with the LOG checkbox un-checked some minutes later, the content of the HTML file does not seem to indicate the date/time range during which this logging was taking place. It's not clear whether I should see additional lines in that second HTML output (say one line for each minute?) or what? There's certainly nothing in that second HTML file reflecting the ending time when I turned off the experimental logging activity, to see what I got. So, my questions are simple: what am I expected to see if I leave logging on for 8 hours, with my OSD update frequency of 4 seconds? I assume I'm supposed to be seeing something useful and helpful and informative, but so far I don't. Instead, no matter how long I keep logging on before turning it off, I see two sets of two HTML files (LOG and STAT), with file name suffixes suggesting the date/time at which the files were opened. The second set of two files is apparently created one minute after the first set of two files, and is eventually closed when I stop the logging function. But the contents of these sets is truly worthless, in my opinion. What am I doing wrong??? I'm attaching a sample of the two sets of HTML files (i.e. the two aforementioned sets of LOG/STAT HTML files) from a sample 5-minute logging period. Note that the second set of two files has a file time of 04:09:32AM, matching the fact that I turned off logging five minutes after I turned it on (back at 04:04:44AM, which is built into the file name). So this second set of HTML files is supposed to convey information for the five minute period during which logging was active. Why was there the first set of HTML files also generated, with a file name including the what I guess is from just first second of logging...04:04:43AM? Why was that first pair of files then closed, and the second set opened... which covered the next five minutes presumably? Log_2014-08-12_04-04-43_log.htm Log_2014-08-12_04-04-43_stat.htm Log_2014-08-12_04-04-44_log.htm Log_2014-08-12_04-04-44_stat.htm