Some applications continiously update themselves

[Stalker]

Some applications (foobar2000 and Spybot S&D for example) will be downloaded every time you request an update even if the file already downloaded is up to date.

 

Here's an entry for foobar2000:

<?xml version="1.0" encoding="utf-16"?>
<Jobs>
 <ApplicationJob xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Guid="2e0c06f9-9318-433c-9e58-e24a6ba072e1">
   <CanBeShared>false</CanBeShared>
   <ShareApplication>false</ShareApplication>
   <HttpReferer />
   <Variables>
     <item>
       <key>
         <string>url</string>
       </key>
       <value>
         <UrlVariable>
           <Regex />
           <Url>http://www.foobar2000.org/?page=Download</Url>
           <StartText>Latest stable version</h2>
 Download <a href="</StartText>
           <EndText>">foobar2000</EndText>
           <Name>url</Name>
         </UrlVariable>
       </value>
     </item>
   </Variables>
   <ExecuteCommand />
   <Category>Music</Category>
   <SourceType>FileHippo</SourceType>
   <PreviousLocation>D:\Distrib\foobar2000_0.9.5.6.exe</PreviousLocation>
   <DeletePreviousFile>true</DeletePreviousFile>
   <Enabled>true</Enabled>
   <FileHippoId>foobar2000</FileHippoId>
   <LastUpdated>2008-11-24T22:02:45.987+02:00</LastUpdated>
   <TargetPath>D:\Distrib\</TargetPath>
   <FixedDownloadUrl>http://www.foobar2000.org/{url}</FixedDownloadUrl>
   <Name>foobar2000</Name>
 </ApplicationJob>
</Jobs>

I use FileHippo way of updating the application. Using a static URL seems to fix the problem.

 

Here's an entry for Spybot S&D:

<?xml version="1.0" encoding="utf-16"?>
<Jobs>
 <ApplicationJob xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Guid="da9a0fa1-1364-4a70-90cb-fe470298f313">
   <CanBeShared>false</CanBeShared>
   <ShareApplication>false</ShareApplication>
   <HttpReferer />
   <Variables />
   <ExecuteCommand />
   <Category>Security</Category>
   <SourceType>FileHippo</SourceType>
   <PreviousLocation>D:\Distrib\spybotsd160.exe</PreviousLocation>
   <DeletePreviousFile>true</DeletePreviousFile>
   <Enabled>false</Enabled>
   <FileHippoId>spybot_search_destroy</FileHippoId>
   <LastUpdated>2008-11-23T00:15:28.607</LastUpdated>
   <TargetPath>D:\Distrib\</TargetPath>
   <FixedDownloadUrl />
   <Name>SpyBotSD</Name>
 </ApplicationJob>
</Jobs>

Note: I have disabled Spybot because of the issue I'm describing.

 

All other apps I update from FileHippo work fine so I don't really know if it's Ketarin or FileHippo problem.

[floele]

Both actually work fine for me. If you really want to know what's going on, get VS2008 Express, load Ketarin and check the ApplicationJob.RequiresDownload() method

 

Well, otherwise, a log file I will eventually implement might help.

[Stalker]

Well, I was unable to properly attach the debugger (it will show assembly instead of source code) but judging from the function source I see you check MD5 for FileHippo downloads. The problem is that MD5 for the local file is FA5C04F993BDF0E91B91917723A4E32F and for the remote file is 41238C451571C4992948CCB2A7B6223F. I think this is due to the fact that I have "Do not download beta versions" checked because FA5C04F993BDF0E91B91917723A4E32F is a checksum of the latest non-beta foobar. Same goes for Spybot (the latest version on FileHippo is beta).

 

On an absolutely unrelated note wouldn't it be more efficient to check m_SourceType == SourceType.FileHippo first and !string.IsNullOrEmpty(m_FileHippoId) afterward because IsNull check doesn't make sense when source is not FileHippo ?

[floele]

Ah, that could make sense. Thanks, I'll check it.

[floele]

m_SourceType == SourceType.FileHippo first and !string.IsNullOrEmpty(m_FileHippoId)

 

Neither the IsNullOrEmpty() nor the comparison are slow. In fact, both operations are very fast. Thus, there will be absolutely no difference when changing the order of the conditions.

[Stalker]

The new version has a reverse bug I guess I have Spybot S&D to download betas regardless of global settings and it continuously re-downloads itself.

Oh and by the way I tried to compile the source of Ketarin found on the main page and it won't compile due to a bunch of files missing (presumably from CDBurnerXP).

[floele]

The files from CDBXP are not put into the ZIP file automatically. Whenever a file is missing, just give me the name and I'll add it.

[floele]

I found the problem now, will be fixed in the next version.

[hherrie]

For me this works right with the latest version!

[Stalker]

The files from CDBXP are not put into the ZIP file automatically. Whenever a file is missing, just give me the name and I'll add it.

All files from CDBurnerXP folder in the project are missing.

 

I found the problem now, will be fixed in the next version.

Good to know. Thanks.

 

For me this works right with the latest version!

Yup. Works fine with 0.9.9.10.

Edited December 15, 2008 by Stalker

[floele]

They are not missing, they just need to be included in the project file. They all exist in the ZIP package within the folder "CDBurnerXP".

[Stalker]

Aha, got it. Thanks. Now it errors out on System.Data.SQLite. Do I need some headers or whatever is C#'s alternative ?

[floele]

You need to download (sf.net) and reference the DLL. The easiest way is to just use the DLL that ships with Ketarin.

[kwe]

For me this works right with the latest version!

Yup. Works fine with 0.9.9.10.

 

 

@floele

I'm using 0.9.9.19 and I see a variation on this bug. If I change the target path and move the download folder to match the new target, Ketarin will still download the file even if the version is the same and the file is exactly where the target path says it has been changed to, and even if the filename is unique to each version.

 

This only happens if I use FileHippo with "no beta versions" and it only happens the one time after I change the target path and only if I spec a target folder, not a filename. I don't suppose this is a big deal, except that the filename is unique (it includes the version in a different format than you extract from FileHippo.com), so you aren't matching and retaining the FileHippo version to the unique filename. If I spec the filename using the FH {version}, this problem doesn't happen because the version string matches exactly.

 

I only mention this in case it turns out useful to match the unique filename to the FileHippo version string. Of course, if the filename is not unique per version, I suppose using the MD5 is the best alternative. Nevermind. :-)

[floele]

What does the log window say?