shawn

Nope. Keep it simple.

The UA doesn't necessarily determine what you get, though. With IE64 you might get a tarball. With wget you might get the Windows 32-bit version. With Chrome on Windows you might get an RPM. SourceForge's "latest" feature just isn't reliable enough to depend on as a source for anything with multiple builds or variations.

The last time I tried this the variable values were populated into the template when it uploaded, so I don't recommend it.

The problem with the "latest" URL format is that it's unpredictable when there are distributions for different operating systems and bit-types. Sometimes you'll get the Windows x64 version, but you're just as likely to get a tarball intended for 32-bit Linux.

Thank you Floele! I can't wait to try it. (But I have to anyway, 'cause it's Patch Tuesday)

If you check the files referenced by 131 ("authors site") and 293 (bleeping computer), the timestamp and size on them is different. Use the author's site download to get the most current version. Look at the bleeping computer app profile page and it says it was "last updated" on Aug 19th, yet the file on MBAM is dated Aug 21st and the file on BP is dated Aug 18th. Even better is that the URL from MBAM uses their static structure, which means it won't be cache-blocked or changed over time. You can use the direct link and it'll always get the current version.

So this should only be a problem for apps we're sharing?

SourceForge is a funky site. You're better off composing most of the URL yourself (see the existing Applications here, then filter for SourceForge). I know, composing the URL may not seem as elegant, but it beats dealing with individual server issues and allows you to select the specific mirror you prefer to use and bypass some unnecessary steps as well. My worksheet for SourceForge apps includes the following magic values that I tune to specific apps: http://downloads.sourceforge.net/project/APPSLUG/APPBUILD/APPNAME{version}.exe Replace APPSLUG, APPBUILD and the APPNAME/filename pattern with the "real" values and patterns used by the app and you're done. Make sure you also use the useragent "wget" or another GUI-less UA and you don't get endlessly redirected to various mirrors.

That may be the case, but without actually testing the URL variable myself, I can't investigate to see what the problem might be. I can theorize all day, but "guess" in one hand, you know? The options in your settings above are correct, which means that the problem is actually with the download itself. If the file at the URL is returning the same size and/or timestamp that it was between versions then it's not really a different file and will *not* be downloaded. You could, of course, actually run the file to ensure it really is the file version you think it is, but the version that's represented in the first image is obviously NOT the current release from the {Version} variable, which means you're downloading the wrong version. Or, simply, the URL is wrong. This isn't a Ketarin issue, but a source issue.

Assign a custom variable TheURL to {property:WebsiteUrl} then use the following: {TheURL:split:/:2}

Oh -- and I haven't had the problem since switching to the SSD.

I've saw the same thing, but assumed it was because I had a failing hard drive (I've known for over a year it was coming). I took that as the impetus needed to finally replace my main drive with an SSD. I've spent the last few days reinstalling & configuring my software. What a huge time sink.

What's the content of the URL variable? JRT recently switched ownership to MalwareBytes, so there's a good chance that it's just an archival URL problem.

You've got much of what I already use, but here's one you don't: Monitor {property:VariableChangeIndicator} I find that lacking a Variable Change Indicator is the biggest issue with app profiles I pick up from the database or novice Ketarin users. This enables me to identify them quickly.

If we're going to keep it, make sure there's a link in the forum header.

The database was last purged July 27th, 2014 which correlated with 1.7. You can navigate the active database applications through the "Applications" list at the top of the forum: https://ketarin.org/forum/apps/ It's basically a tie-in to the forum to ensure a modicum of auditing to validate applications to ensure they're both maintained and supported as well as provide a way for users to know the potential quality of the application profile. The reasoning and background is here. There's another post on it that specifically talks about building the online aspect of the db, but I don't have time to find it right now.

I like it.

One option I use on some sites is to add "?C=M" to the URL, which will change the sort order of the resulting files to the date modified. That makes the most recent stuff on the top or bottom. It doesn't work on this site, though, but for future readers -- try that first. In this situation, things are going to be ugly. They're sorting the results alphabetically which makes numbers appear wonky (100 before 20 before 42 before 5 before 8910 before 9). While it might be possible to group and sort them through Ketarin, if you can do it, use another source. It's not worth the effort for a single-use profile. Another option would be to contact Opera and have them fix it on their end. Maybe they have no idea they're making life difficult for their users.

The online database was purged with the release of the last version and the "Applications" integration in the forum. If you're not seeing update notifications, chances are you're still using Application profiles based on the old database. Make sure you're using the most recent Ketarin version and are using profiles that are currently within the app database.

Have you tried running it as successive commands? Use "&&" to proceed to the next command only if the first succeeds, which means the first process has to complete before the second command will run. "C:\Users\User\Desktop\Utility icons\Ketarin-1.7.0\Apps\Art\7zc.exe" x -y "{file}" -bd -o"C:\Users\User\Desktop\Utility icons\Ketarin-1.7.0\Apps\Art\aaa\" && CD "C:\Users\User\Desktop\Utility icons\Ketarin-1.7.0\Apps\Art\aaa\blender-*-win64" && RD "C:\Users\User\Desktop\My stuff\Art Tutorials\Art\Blender Dev" && xcopy /y /S /Q *.* "C:\Users\User\Desktop\My stuff\Art Tutorials\Art\Blender Dev\" && rd "C:\Users\User\Desktop\Utility icons\Ketarin-1.7.0\Apps\Art\aaa" /s /q

I'm in. UserVoice is so much easier than trying to manage feature requests and "+1" in a forum.

exit 1 Is how you do it. Info here: http://wiki.ketarin.org/index.php/Commands Can you share your script that's failing?

And this is the DevShare home on SF.net: https://sourceforge.net/devshare/why

This has actually been going on for *years* and is the result of SourceForge DevShare adware integration. They claim that it's a non-intrusive monetization, but it effectively eliminates the ability for offline downloading many apps unless you know the secret to getting the *real* installer. More here.

Wouldn't it just be easier to extract the individual file directly to where you want it to be stored? 7z e -y -o"..\" "{file}" "rsload.net.Asymptote.{version}\asymptote-{version}-setup.exe" Though, to be fair, the whole copying-the-file "up" a directory problem doesn't really exist if you extract only the one file, so you could do this instead to extract it directly to the location you really want it: 7z e -y -o"{file:directory}\" "{file}" "rsload.net.Asymptote.{version}\asymptote-{version}-setup.exe"