Jump to content
Ketarin forum

New command: before checking for updates & export log


Recommended Posts

Currently (Ketarin there are four separate Event Commands available:

1) Before updating an application

2) After updating an application

3) After updating all applications

4) When application update fails

These are great for pre-download validation and post-update & post-check failure documentation, but they don't address every scenario.

I would like one more Event Command available: Before checking for updates for an application.

When I have parallel downloads set to 1 then it's a safe bet that the next one in the list is responsible. When I have parallel set to 2 or 3 (or more) then it's a whole lot of guessing. 

This new event would trigger before any variables were parsed (other than the name) so that I can log the progress of "update all" or "check for updates" on a selection.

This would allow me to write the pre-parse progress to a permanent log file so I can better troubleshoot errors. Currently, when Ketarin crashes (which isn't often, but is often enough that it's frustrating) I have to guess which application is responsible and which variable or URL it was within the application that might be causing the problem. I can work around some of this with special variables and the ":ps" function, but more difficult than it could be to figure out which one is responsible.

Alternatively (or in addition to) there would be an option to write to a log file that mirrors the activity in the real-time log (CTRL+L). This could either be one massive file (ketarin.log), or based on the date, or based on variables (like "ketarin-{yyyy}{MM}{dd}{hh}{mm}.log" or "ketarin-{category}.log" or even based on the "save as" destination with an additional ".log" appended: "..\{category}\{appname:regexreplace:([\s\t\r\n\-\&]+):_}-{version}.{url:ext}.log" where as-yet-unparsed variables would be replaced with dashes or underscores). Each application should have the log file name preserved for the duration of the specific application, so if the log file name were "ketarin-{yyyy}{MM}{dd}T{hh}{mm}.log" at 20240414T1345 and it took 4 minutes to process the application, all log records relating to that application update would be written to that log even though the time were actually 20240414T1349 by the time it was done.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.