shawn

Thank you for sharing your sources, @Hulk91. I tested both of these and you're 100% right, changing the UA alone makes no difference. They must be parsing for an additional signal or using a server-side script that tests whether it's a headless request or not. One way around this is to use Kuppet. For both apps, using Kuppet allowed the request to proceed and get a valid response. That said, for both of these, since all you're using MajorGeeks for is the version number, I would recommend you consider getting the version number from the real source (anydesk changelog or rustdesk changelog). This will reduce dependence on a single third-party (majorgeeks) that could decide to change their rules at any moment and would allow you to continue to get the data you really need.

Usually this can be resolved by changing the user-agent either for the specific app profile or Ketarin-wide. Can you share one of the app profiles you're using that's having issues? Select it in Ketarin, press CTRL+C, then paste it into a code block here.

You're almost there. There should be no space in the value for ">". Then the final step is to use the new ">" variable in the source URL of a your parsed URL as so, replacing example with the website you're parsing from: {>}https://example.com/path/ If you need additional help please post the URL.

Agreed. That's a good idea. I have not found that I need that simply because I maximize the window when I need to and don't use very long text in most columns. While I'm here though you might find that CTRL+SHIFT+C may solve your temporary problem. For example, in one of my columns I have a changelog, but it's really there just to make sure that the changelog is being processed correctly. When I need to use it though I use CTRL+SHIFT+C and paste it into N++ to see the complete URL (and other column details).

Welcome aboard @Novae7 - great to have you here. Thank you for your contribution. With Bleeping Computer not every download has a version number, so I use the date ("{yyyy}.{MM}.{dd}") for the ones that don't, like FRST. I usually parse for the redirect, too. On the /dl/# page I use this regex pattern: "\d+;\s*url=([^"]+)" That captures the redirect from the download page so you can get the actual file URL. Finally, because Bleeping Computer uses these session/temporary download URLs, I then upload the file to one of my servers using a static URL so I can automate downloading it on client devices. I use curl & ftp for that with the following syntax in the "execute after downloading" command: curl --ssl-reqd -T "{file}" ftp://user:pass@server:port/path/

no, it's not you. Adobe sometimes has significant lags between their releases and updating their underlying version-checking stuff. in this case the release notes and the actual release download (from their own download page) are out of sync. again. this is their actual download page option right now, which remains the older version: i used to contact them every 3 or 4 months when their release notes and downloads were out of sync for different products and they eventually just removed the entire all-products releases page because they couldn't be bothered to maintain it. sadly, this is just a sign of why you should avoid adobe products: if they can't even figure out how to automate such a little thing (hook it into your build process guys!), who knows what else is screwed up in their software?

It's working fine for me. Maybe you experienced an Adobe website issue? Is it still having problems?

And these are the full Reader EXE installer URLs (for English): x64 https://ardownload3.adobe.com/pub/adobe/acrobat/win/AcrobatDC/{dirtyversion}/AcroRdrDCx64{dirtyversion}_en_US.exe x86 https://ardownload3.adobe.com/pub/adobe/reader/win/AcrobatDC/{dirtyversion}/AcroRdrDC{dirtyversion}_en_US.exe

With those URLs and the JSON response I would recommend just pulling the version number directly with (as {version}): "version":"([\d\.]+)" This avoids manually fiddling with numbers that might have issues. Today they describe 2024 as the major version and use 24 internally, but who knows what they'll do tomorrow.

Currently (Ketarin 1.8.11.0) 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.

Interesting issue with the SetDefaultBrowser and SetUserFTA programs: Microsoft broke them with a recent registry service "fix" to control the browser behavior and enforce "user choice". Evil bastards.

if you don't have a lot of requests or apps then changing the UA globally is unlikely to help. if you do, then you might want to change it and keep it relatively current. the format for the version string in Chrome UA is "Chrome/major.0.0.0" - it never includes the minor or build numbers. This is similar to all other modern browsers - they don't include anything but the major version dot zero, and sometimes an additional couple dot-zeroes. Change it to: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 That alone might help. If you haven't set the Version number column to display in the main interface you might want to do that first. This ensures that you can see when new versions are detected and might help you troubleshoot this one. Since this site is one of the ones that is really aggressive about spiders you might want to test with a different one. I've attached another one (aria2) that uses Kuppet. aria2.xml

Is it detecting the version number correctly? Or is it just the download that's failing? You might also need to change the global user-agent (File, Settings, Connection, Default user agent) or at least assign one within the app profile at Advanced Settings, User-agent. By default the user-agent indicates it's Ketarin and might be getting blocked.

I recommend removing the older user-agents from the userAgentArray variable. Firefox/65 and Chrome/100 are both *very* old and many security features on websites now block them by default. The next troubleshooting step is to change the chromeVisible value in your config to true. This will allow you to watch as Kuppet operates, which might be enough to see what is failing.

One more thing about Kuppet. It has a heavy-duty cache so it doesn't re-request pages unnecessarily, even if you think it should. If you ran it, cancelled, then ran it again you might have issues. Kill Kuppet and try again to make sure it purges it's own cache.