search

Nornec / Midinous-Issues

2 stars 0 forks source link

1.0.5 - User setting related error log produced when starting up Midinous #12

Closed worblyhead closed 1 year ago

worblyhead commented 1 year ago

Repro steps:

1) Have a windows explorer open to %localappdata%/Midinous 2) If error log files already exist, rename/move/delete them 3) Start up Midinous and NOTE app opens as expected 4) Inspect %localappdata%/Midinous directory and NOTE error logs are produced (see attached files) 5) Quit out of Midinous

6) cd to %localappdata%/Midinous/user and rename the user setting json fiel. E.g.

settings.json ==> settings_backup.json

7) Restart Midinous. NOTE, app starts up as expected (you will also see the tutorial Splash page this time around) 8) Inspect %localappdata%/Midinous directory and NOTE error logs are still produced

log.txt log_error.txt log_full.txt

worblyhead commented 1 year ago

One thing I noticed looking at the log_error.txt file was that the file paths use hybrid Windows ('\') and Unix ('/') file separators. Could this be a filepath parsing issue?

Nornec commented 1 year ago

One thing I noticed looking at the log_error.txt file was that the file paths use hybrid Windows ('') and Unix ('/') file separators. Could this be a filepath parsing issue?

This is ok. It doesn't cause an issue in file referencing.

As for the issue, i'm not sure what you're seeing as a problem. Midinous creates the log files if they don't exist, and a header is printed for each run, regardless of whether the program encountered any issues. This is to keep runs consistent if comparing files. It also does this for the settings.json file and other files that may not exist. I believe this to be expected behavior.

worblyhead commented 1 year ago

I guess my point here was that the error log file produced actually points to an error. If the particular error in the error log file is innocuous, then maybe it shouldn't be reported to the log as it really is just noise. However, as you are the only developer currently then you'll know whether to ignore. In my experience, it is always less confusing when log files are kept as clean as possible so it is easier to spot real issues, especially in really long log files.

Nornec commented 1 year ago

Generally, my idea is that people dont go looking for logs unless i tell them to. It's more for me than the typical user, so they are verbose on purpose.

On Sat, Oct 15, 2022, 08:30 worblyhead @.***> wrote:

I guess my point here was that the error log file produced actually points to an error. If the particular error in the error log file is innocuous, then maybe it shouldn't be reported to the log as it really is just noise. However, as you are the only developer currently then you'll know whether to ignore. In my experience, it is always less confusing when log files are kept as clean as possible so it is easier to spot real issues, especially in really long log files.

— Reply to this email directly, view it on GitHub https://github.com/Nornec/Midinous-Issues/issues/12#issuecomment-1279736054, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFQ2UVSAX4UE7BXS5CAJTVTWDKPWDANCNFSM6AAAAAARFF4HDM . You are receiving this because you modified the open/close state.Message ID: @.***>