We have observed the same issue. Did the CodeCogs api change? 

Thanks for the help.

I ran a test (using Windows) and you're correct about the subfolder and file naming. I don't think that'll be an issue, but it's good to be aware of. If we end up having to revert to 2.9.2 for whatever reason, I think it sould still work fine if what logs we have are just copied up a directory (i.e /home/logfiles/2023/23mmdda.log ==> /home/logfiles/23mmdda.log)

The difference in the directory structure doesn't matter for my purposes.

I use linux elog, and if you upgrade to v3.x.x, it's difficult to go back to v2.9.x.  This is because the log files get grouped in year sub directories at  v3.x.x.

In 2.9.x, the logfiles are store as (made up example)    /home/logfiles/yymmdda.log

In 3.x.x they are stored as /home/logfiles/2024/24mmdda.log   /home/logfiles/2023/23mmdda.log  etc.  I think I got the labelling of the subdirectories correct, Stefan will no doubt correct if I am wrong.

I assume the same is true for the Windows version as it would be weird for a split in the program by OS for something important but trivial to impliment for all OS. 

It's a bore to sort that out if you have to revert to 2.9.x - I know, I've done it -  but I don't recall any change in format in the individual yymmdda.log files with an early v3.x.x version I tried.  There may be additions to the log files made in much more recent v3.1.x or so versions, but I guess you are ok with whatever they may be as you've checked the change log.  

Thanks. I did eveuntaully find the change log and made the decision to upgrade the at-sea machines. So far the configuration file we update for each mission still works. I have a copy of the 2.9.2 installer that if something catostrophic happens I can remove the new version and take it back, but I don't think it'll be a problem. We archive logbooks at the end of a mission, but each mission basically starts from a fresh install like state anyway.

> I get the following compiler warnings about sprintf() buffer overflows. I suggest sprintf() should be replaced by std::string msprintf() from 
> midas. K.O.

I started to convert some sprintf() to snprintf(), but I still have 824 cases to go... Ideally, all should be converted to std::string. Will be some job for my retirement ;-)

Stefan

If 3.1.4 runs safely on your laptop, there should be no problem to update the 2.9.2 one. But first do it on a copy of your logbooks from the at-sea. The get converted automatically into a newer format but that should be transparent.

On the other hand you don't really need a new system if your old installation works fine and you don't need any of hte new features.

The changelog ist here: https://elog.psi.ch/elog/download/ChangeLog

Stefan

Currently have multiple logbooks hosted with elogd. One book is having an issue with Categories. The user regulary uses the category filtering to see one subject for the whole month. This past week it hasn't been working properly. When choosing a drop down category to filter there are not logs found. I've notice the fields under the categories change randomly. Sometimes it would add a % sign where there should be --. Some other fields go from displaying -- Subject -- to just the dashes, thats when the filtered eLogs do not show. Clearing out the erroneous characters can eventually load the specified logs. Has anyone else seen this? Should I just upgrade the system and hope for the best?

PS. while writing this I was able to mitigate the issue by removing the troubled fields from the quick filter section. I'm pretty sure this will not be an issue for my end user but any input is appreciated.

Hi all,

Quick question -- I was wondering if the current Windows Binary/Installer is now compiled for compatibility for Windows 11?  

I did look through the Forum, but the the answer wasn't really clear.  

Thanks!
Frank B.