Jump to content
Ketarin forum

Still having trouble getting new downloads - Ketarin 1.0.2


appyface
 Share

Recommended Posts

I thought I'd start a new thread rather than continue mixing into the old thread...

 

I'm being careful to eliminate pilot error... since that may be a factor in prior difficulties (!). I saw post where Ketarin 1.0.2 had been reuploaded, I decided to have the current Ketarin go fetch it for me.

 

An existing app entry had been fetching a prior beta. I modified it by changing only the source URL to go fetch from the current 1.0.2 beta link. All else is the same.

 

1. Below is full XML *before* I modified the entry.

URL was: http://ketarin.canneverbe.com/downloads/Ketarin/Ketarin-0.9.9.22.zip

Disk file was: Ketarin-1.0.1.197_beta_20090211-093911.zip (does exist)

 

(yes that one seems weird, but that URL continued to fetch later despite looking as if it pointed to 0.9.9.22, I dunno what happens when the URL is accessed but I had been getting the 1.0.1.197 files just as the disk file name shows)

 

 

2. Below is full XML *after* I modified the entry's URL, and before I tried to update with it.

New URL: http://ketarin.canneverbe.com/downloads/Ketarin/Ketarin-1.0.2.zip

New disk file should be determined as:

{url:basefile}_beta_{f:yyyy}{f:MM}{f:dd}-{f:HH}{f:mm}{f:dd}.{url:ext}

Ketarin-1.0.2_beta_<filemodifieddate>-<filemodifiedtime>.zip

 

There is no disk filename in the download location anywhere close to this name. The only one that has even part of the right name is: Ketarin-1.0.2_prior.zip size: 744,606 modified: 2/14/2009 1:23:50 PM

 

 

3. Issued CTRL-U and Ketarin reported:

 

2/19/2009 4:07:26 AM: Update started with 1 application(s)

2/19/2009 4:07:27 AM: Ketarin redownload xxxx beta: Checking if update is required...

2/19/2009 4:07:27 AM: Ketarin redownload xxxx beta: Update not required

2/19/2009 4:07:27 AM: Ketarin redownload xxxx beta: Replacing {vers} in '{vers}' with '20090211-093911'

2/19/2009 4:07:27 AM: Update finished

 

 

4. Just now I used Orbit to fetch from the 1.0.2 source URL. Orbit downloaded a newer file, as I was expecting.

 

Orbit's default download location has always been and still is completely different where Ketarin downloads to (plus I changed the disk file name for Orbit this time, for good measure). So there is no chance of mingling any Orbit downloaded disk files with Ketarin's downloaded disk files.

 

Orbit did pick up a newer file than what is in Ketarin's download location:

Ketarin-1.0.2_new.zip size: 745,465 modified: 2/18/2009 11:16:58 AM

 

 

Ketarin's log isn't too helpful in this case as it doesn't report what was actually looked at to determine no update was required.

 

Help? I don't think pilot error is a factor in this one but please tell me if I've overlooked something! Thanks as always,

--appyface

 

 

XML of Ketarin entry *before* I changed the URL:

 

<?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="65685631-ebfb-495f-b8bb-0770bec64b3b">
   <DownloadBeta>Default</DownloadBeta>
   <DownloadDate xsi:nil="true" />
   <VariableChangeIndicator />
   <CanBeShared>true</CanBeShared>
   <ShareApplication>false</ShareApplication>
   <ExclusiveDownload>false</ExclusiveDownload>
   <HttpReferer />
   <Variables>
     <item>
       <key>
         <string>vers</string>
       </key>
       <value>
         <UrlVariable>
           <VariableType>Textual</VariableType>
           <Regex />
           <TextualContent>{f:yyyy}{f:MM}{f:dd}-{f:HH}{f:mm}{f:dd}</TextualContent>
           <Name>vers</Name>
         </UrlVariable>
       </value>
     </item>
   </Variables>
   <ExecuteCommand />
   <ExecutePreCommand />
   <Category>000100</Category>
   <SourceType>FixedUrl</SourceType>
   <PreviousLocation>D:\Stuff\filestore\Updaters\Ketarin-1.0.1.197_beta_20090211-093911.zip</PreviousLocation>
   <DeletePreviousFile>false</DeletePreviousFile>
   <Enabled>true</Enabled>
   <FileHippoId />
   <LastUpdated>2009-02-16T14:43:59.8895</LastUpdated>
   <TargetPath>D:\Stuff\filestore\Updaters\{url:basefile}_beta_{f:yyyy}{f:MM}{f:dd}-{f:HH}{f:mm}{f:dd}.{url:ext}</TargetPath>
   <FixedDownloadUrl>http://ketarin.canneverbe.com/downloads/Ketarin/Ketarin-0.9.9.22.zip</FixedDownloadUrl>
   <Name>Ketarin redownload xxxx beta</Name>
 </ApplicationJob>
</Jobs>

 

 

XML of Ketarin entry *after* I changed the URL but *before* issuing CTRL-U:

 

<?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="65685631-ebfb-495f-b8bb-0770bec64b3b">
   <DownloadBeta>Default</DownloadBeta>
   <DownloadDate xsi:nil="true" />
   <VariableChangeIndicator />
   <CanBeShared>true</CanBeShared>
   <ShareApplication>false</ShareApplication>
   <ExclusiveDownload>false</ExclusiveDownload>
   <HttpReferer />
   <Variables>
     <item>
       <key>
         <string>vers</string>
       </key>
       <value>
         <UrlVariable>
           <VariableType>Textual</VariableType>
           <Regex />
           <TextualContent>{f:yyyy}{f:MM}{f:dd}-{f:HH}{f:mm}{f:dd}</TextualContent>
           <Name>vers</Name>
         </UrlVariable>
       </value>
     </item>
   </Variables>
   <ExecuteCommand />
   <ExecutePreCommand />
   <Category>000100</Category>
   <SourceType>FixedUrl</SourceType>
   <PreviousLocation>D:\Stuff\filestore\Updaters\Ketarin-1.0.1.197_beta_20090211-093911.zip</PreviousLocation>
   <DeletePreviousFile>false</DeletePreviousFile>
   <Enabled>true</Enabled>
   <FileHippoId />
   <LastUpdated>2009-02-16T14:43:59.8895</LastUpdated>
   <TargetPath>D:\Stuff\filestore\Updaters\{url:basefile}_beta_{f:yyyy}{f:MM}{f:dd}-{f:HH}{f:mm}{f:dd}.{url:ext}</TargetPath>
   <FixedDownloadUrl>http://ketarin.canneverbe.com/downloads/Ketarin/Ketarin-1.0.2.zip</FixedDownloadUrl>
   <Name>Ketarin redownload xxxx beta</Name>
 </ApplicationJob>
</Jobs>

 

 

XML of Ketarin entry after issuing CTRL-U. It's identical to the one prior:

 

<?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="65685631-ebfb-495f-b8bb-0770bec64b3b">
   <DownloadBeta>Default</DownloadBeta>
   <DownloadDate xsi:nil="true" />
   <VariableChangeIndicator />
   <CanBeShared>true</CanBeShared>
   <ShareApplication>false</ShareApplication>
   <ExclusiveDownload>false</ExclusiveDownload>
   <HttpReferer />
   <Variables>
     <item>
       <key>
         <string>vers</string>
       </key>
       <value>
         <UrlVariable>
           <VariableType>Textual</VariableType>
           <Regex />
           <TextualContent>{f:yyyy}{f:MM}{f:dd}-{f:HH}{f:mm}{f:dd}</TextualContent>
           <Name>vers</Name>
         </UrlVariable>
       </value>
     </item>
   </Variables>
   <ExecuteCommand />
   <ExecutePreCommand />
   <Category>000100</Category>
   <SourceType>FixedUrl</SourceType>
   <PreviousLocation>D:\Stuff\filestore\Updaters\Ketarin-1.0.1.197_beta_20090211-093911.zip</PreviousLocation>
   <DeletePreviousFile>false</DeletePreviousFile>
   <Enabled>true</Enabled>
   <FileHippoId />
   <LastUpdated>2009-02-16T14:43:59.8895</LastUpdated>
   <TargetPath>D:\Stuff\filestore\Updaters\{url:basefile}_beta_{f:yyyy}{f:MM}{f:dd}-{f:HH}{f:mm}{f:dd}.{url:ext}</TargetPath>
   <FixedDownloadUrl>http://ketarin.canneverbe.com/downloads/Ketarin/Ketarin-1.0.2.zip</FixedDownloadUrl>
   <Name>Ketarin redownload xxxx beta</Name>
 </ApplicationJob>
</Jobs>

Link to comment
Share on other sites

Running newest 1.0.2 now. Same issue as above, no download on newer file from new URL.

 

And -- Ketarin is ignoring my CIV and redownloading same files again. Server file dates have changed even though same version. The presence of a CIV means do not download if CIV has NOT changed between runs, right?

 

Update log:

2/19/2009 5:32:00 AM: Update started with 1 application(s)

2/19/2009 5:32:04 AM: BooZet Double Driver: Replacing {vers} in 'd:\stuff\filestore\win_tips_and_tweaks\boozet_dd210_{vers}.zip' with '2.1'

2/19/2009 5:32:04 AM: BooZet Double Driver: Checking if update is required...

2/19/2009 5:32:05 AM: BooZet Double Driver: Replacing {vers} in '{vers}' with '2.1'

2/19/2009 5:32:05 AM: BooZet Double Driver: Update required, file modified dates do not match

2/19/2009 5:32:15 AM: Update finished

 

The only difference between the 'before' and 'after' XML files is the 'last update' datetimestamp.

 

Help?

--appyface

 

 

 

XML of Ketarin entry *before* update:

 

<?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="c7d6f628-eca5-4d54-90fd-7bf13e706e9b">
   <DownloadBeta>Default</DownloadBeta>
   <DownloadDate xsi:nil="true" />
   <VariableChangeIndicator>vers</VariableChangeIndicator>
   <CanBeShared>true</CanBeShared>
   <ShareApplication>false</ShareApplication>
   <ExclusiveDownload>false</ExclusiveDownload>
   <HttpReferer>http://boozet.org/dl.htm?product=dd&mirror=1</HttpReferer>
   <Variables>
     <item>
       <key>
         <string>vers</string>
       </key>
       <value>
         <UrlVariable>
           <VariableType>RegularExpression</VariableType>
           <Regex>(?<=a href="dd\.htm">Double Driver.*?div .*?>).*?(?=<)</Regex>
           <Url>http://boozet.org/download.htm</Url>
           <Name>vers</Name>
         </UrlVariable>
       </value>
     </item>
   </Variables>
   <ExecuteCommand />
   <ExecutePreCommand />
   <Category>000100</Category>
   <SourceType>FixedUrl</SourceType>
   <PreviousLocation>d:\stuff\filestore\win_tips_and_tweaks\boozet_dd210_2.1.zip</PreviousLocation>
   <DeletePreviousFile>false</DeletePreviousFile>
   <Enabled>true</Enabled>
   <FileHippoId />
   <LastUpdated>2009-02-16T17:44:10.56325</LastUpdated>
   <TargetPath>d:\stuff\filestore\win_tips_and_tweaks\boozet_{url:basefile}_{vers}.{url:ext}</TargetPath>
   <FixedDownloadUrl>http://boozet.org/getfile.php?product=dd&mirror=1</FixedDownloadUrl>
   <Name>BooZet Double Driver</Name>
 </ApplicationJob>
</Jobs>

 

 

 

XML entry *after* CTRL-U:

 

<?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="c7d6f628-eca5-4d54-90fd-7bf13e706e9b">
   <DownloadBeta>Default</DownloadBeta>
   <DownloadDate xsi:nil="true" />
   <VariableChangeIndicator>vers</VariableChangeIndicator>
   <CanBeShared>true</CanBeShared>
   <ShareApplication>false</ShareApplication>
   <ExclusiveDownload>false</ExclusiveDownload>
   <HttpReferer>http://boozet.org/dl.htm?product=dd&mirror=1</HttpReferer>
   <Variables>
     <item>
       <key>
         <string>vers</string>
       </key>
       <value>
         <UrlVariable>
           <VariableType>RegularExpression</VariableType>
           <Regex>(?<=a href="dd\.htm">Double Driver.*?div .*?>).*?(?=<)</Regex>
           <Url>http://boozet.org/download.htm</Url>
           <Name>vers</Name>
         </UrlVariable>
       </value>
     </item>
   </Variables>
   <ExecuteCommand />
   <ExecutePreCommand />
   <Category>000100</Category>
   <SourceType>FixedUrl</SourceType>
   <PreviousLocation>d:\stuff\filestore\win_tips_and_tweaks\boozet_dd210_2.1.zip</PreviousLocation>
   <DeletePreviousFile>false</DeletePreviousFile>
   <Enabled>true</Enabled>
   <FileHippoId />
   <LastUpdated>2009-02-19T05:32:15.041-08:00</LastUpdated>
   <TargetPath>d:\stuff\filestore\win_tips_and_tweaks\boozet_{url:basefile}_{vers}.{url:ext}</TargetPath>
   <FixedDownloadUrl>http://boozet.org/getfile.php?product=dd&mirror=1</FixedDownloadUrl>
   <Name>BooZet Double Driver</Name>
 </ApplicationJob>
</Jobs>

Edited by appyface
Link to comment
Share on other sites

OK, still in the same Ketarin launch as the redownload of Boozet Double Driver, I just did another CTRL-U on it. Hoping the author has not changed the server's file dates in the last 30 minutes. Apparently not. NOW the update log shows this:

 

2/19/2009 5:40:26 AM: BooZet Double Driver: Replacing {vers} in 'd:\stuff\filestore\win_tips_and_tweaks\boozet_dd210_{vers}.zip' with '2.1'

2/19/2009 5:40:26 AM: BooZet Double Driver: Checking if update is required...

2/19/2009 5:40:27 AM: BooZet Double Driver: Replacing {vers} in '{vers}' with '2.1'

2/19/2009 5:40:27 AM: BooZet Double Driver: Update not required, {vers} has not changed

Link to comment
Share on other sites

The first problem is rather simple, and somewhat a bit my fault: The website always serves the latest version of Ketarin (no matter what file you download), unless your referrer is "ketarin.org/ketarin.canneverbe.org". I need this to prevent direct downloads of outdated versions of Ketarin form 3rd party websites.

So no matter what download URL of Ketarin you are pointing to, it will always result in the same file (that is, the latest version). So no change in date, no change in file size and not even a change in file name. Thus, no update.

 

Regarding the second problem: As the XML indicates, you have never downloaded this application before. Probably, you deleted and reimported or changed the variable to compare for this application, so that there is no previous value for "vers" available and thus Ketarin ignores this feature altogether. I guess I'll add another log message.

Link to comment
Share on other sites

The first problem is rather simple, and somewhat a bit my fault: The website always serves the latest version of Ketarin (no matter what file you download), unless your referrer is "ketarin.org/ketarin.canneverbe.org". I need this to prevent direct downloads of outdated versions of Ketarin form 3rd party websites.

I've no argument with that... it did seem odd at first but I figured that was what was happening.

 

So no matter what download URL of Ketarin you are pointing to, it will always result in the same file (that is, the latest version). So no change in date, no change in file size and not even a change in file name. Thus, no update.

This is the part that isn't making sense to me. Perhaps you can break it down using parts from my example?

 

Here's what I see, tell me what is different from what you're saying is supposed to happen?

 

1. The old URL (....0.9.9.22) brought down new disk filenames as versions increased, but it has never brought down 1.0.2... (not sure why, seems to go against above comment about always serving newer versions). Ketarin just keeps on telling me 1.0.1.197 has not been updated... OK fine... so I changed the URL in order to download the newest version file.

 

The URL is the one you last posted of (...1.0.2). Shouldn't that serve up a {url:basefile} as Ketarin-1.0.2? Together with the rest of my disk download filename, no such disk filename exists.

 

I thought we agreed Ketarin should download a new disk file name if it doesn't exist (and 'delete prior' is NOT marked)? I looked at the XML, 'delete prior' is *false*... and I still have no new disk filename...?

 

 

Regarding the second problem: As the XML indicates, you have never downloaded this application before. Probably, you deleted and reimported or changed the variable to compare for this application, so that there is no previous value for "vers" available and thus Ketarin ignores this feature altogether. I guess I'll add another log message.

 

Yes I did re-import my jobs.xml but I have run several update attempts since then, on earlier version of 1.0.2, and including this particular app. Unfortunately since you won't store the 'last update attempt' date/timestamp :-p I can't prove to you from my XML exports that this is the case!

 

So. After my reimport of the jobs XML, you're saying that would make the CIV prior value become blank/null/not there/whatever?

 

If that is true, then I would guess Ketarin did not store the CIV on the next update attempt. If the CIV is not stored until a new download, that could be what happened here.

 

I'm (reasonbly) certain after I imported my jobs XML, and made my update attempts, the server's file dates and size were the same as they had been for that app. My disk filename still existed. If Ketarin left the CIV blank on each of these attempts, then that would explain why the file was redownloaded today, when the server file dates changed today.

 

Could that be what happened here?

 

Would it be possible to export the CIV to XML and then be reimported? That would make export/import of apps get that much closer to recreating the last known configuration of that app?

Link to comment
Share on other sites

You got it wrong. It only downloaded 1.0.1.197 and still downloads 1.0.1.197, as it is the latest (stable) version. No change in file name. It doesn't matter whether or not you want to download 1.0.2.

 

 

So. After my reimport of the jobs XML, you're saying that would make the CIV prior value become blank/null/not there/whatever?

 

Yes, because it's not stored in the XML.

 

I'm (reasonbly) certain after I imported my jobs XML, and made my update attempts...

 

Can you reproduce the problem, knowing what is happening now?

 

Would it be possible to export the CIV to XML and then be reimported?

 

I don't think so. This cached value is not a part of the application itself, and if you import it to a different database, it may just be plain wrong to assume that there is no change.

Link to comment
Share on other sites

You got it wrong. It only downloaded 1.0.1.197 and still downloads 1.0.1.197, as it is the latest (stable) version. No change in file name. It doesn't matter whether or not you want to download 1.0.2.

Why would Ketarin still download 1.0.1.197? I *changed the URL* (see XML above, post- editing) to this one:

hxxp://ketarin.canneverbe.com/downloads/Ketarin/Ketarin-1.0.2.zip

 

In any event, my output disk filename DOES NOT EXIST so Ketarin should download it anyway, but it isn't doing that either. This disk file does not exist:

Ketarin-1.0.2_beta_<filedatehere>-<filetimehere>.zip

 

Why do you say Ketarin only downloaded 1.0.1.197 and still downloads 1.0.1.197? That is the part that doesn't make sense to me. If I give that same URL to IE, Orbit, Free Download Manager, and Firefox, they all download a filename of Ketarin-1.0.2.zip. Why would Ketarin continue to download 1.0.1.197 from that URL?

 

 

So. After my reimport of the jobs XML, you're saying that would make the CIV prior value become blank/null/not there/whatever?

Yes, because it's not stored in the XML.

OK... I get that. I don't like it, but I get it :-p

 

I'm (reasonbly) certain after I imported my jobs XML, and made my update attempts...

Can you reproduce the problem, knowing what is happening now?

I'm not sure I *do* know what is happening now... are you confirming that Ketarin did not change my blank CIV despite numerous update attempts, until the server's file date changed today and Ketarin actually downloaded something?

 

Would it be possible to export the CIV to XML and then be reimported?

I don't think so. This cached value is not a part of the application itself, and if you import it to a different database, it may just be plain wrong to assume that there is no change.

Well for one thing Ketarin should NOT assume there is no change? I don't know why you would want that.

 

If the CIV is imported with the XML, it would work like this: The first time an update attempt is made, if the old CIV value and the new value are different, Ketarin is supposed to download... that's the point of the CIV isn't it?

 

And if the old CIV and new CIV are NOT different, Ketarin is not to download -- unless the disk file name does not exist, then Ketarin should download and create the disk file name.

 

So it seems that the CIV should be included in the XML, when imported it replicates the known state of the app at the time of export. That would be exactly what I want, if I'm importing from XML... I'd like to recreate what the app looked like at that time.

 

I guess I think of being able to export and import the XML as a 'restore' app function -- is there any other use of the import function that would be in conflict with 'restoring' the app to the state it was in when exported?

Link to comment
Share on other sites

Why would Ketarin continue to download 1.0.1.197 from that URL

 

That's a server side issue, as I said. Use a referrer to prevent that behaviour.

 

For the XML: Consider user Alice and Bob store Ketarin to c:\Ketarin.zip. Now Alice exports her XML (using CIV) for Bob, since Bob wants to have her definition of Ketarin, because it is more *whatever*. Bob has still Ketarin 0.9, Alice already downloaded 1.0 before. Now Bob does not detect any update after importing Alice's XML, because it contains "1.0" as previous variable content, which is correct for Alice, but not Bob.

The correct behaviour is to ignore the variable content for the first time, and instead use the file date / size as indicator. Once the file is up to date (using this kind of comparison), Bob will have "1.0" as previous value to prevent any further updates (for now), which is again the correct behaviour.

Link to comment
Share on other sites

Why would Ketarin continue to download 1.0.1.197 from that URL

 

That's a server side issue, as I said. Use a referrer to prevent that behaviour.

I'm sorry Flo, I'm still struggling with what you're saying -- are you saying your server singles out *Ketarin* as the downloader and won't let Ketarin download the 1.0.2 version of the file? Because I do get the 1.0.2 version from all other downloaders I feed this URL to. I'm not using referrers for any of them.

 

 

For the XML: Consider user Alice and Bob store Ketarin to c:\Ketarin.zip. Now Alice exports her XML (using CIV) for Bob, since Bob wants to have her definition of Ketarin, because it is more *whatever*. Bob has still Ketarin 0.9, Alice already downloaded 1.0 before. Now Bob does not detect any update after importing Alice's XML, because it contains "1.0" as previous variable content, which is correct for Alice, but not Bob.

The correct behaviour is to ignore the variable content for the first time, and instead use the file date / size as indicator. Once the file is up to date (using this kind of comparison), Bob will have "1.0" as previous value to prevent any further updates (for now), which is again the correct behaviour.

Let's go with the idea that the XML should 'restore' the app back to the state it was in when XML was created. Then yes Bob will not get the new file after importing Alice's XML, *but that would be the correct behavior*.

 

I believe we have agreed, all along, using a CIV should provide sole control of the downloading. The only exception to that being, if the output disk filename does not exist, Ketarin should go ahead and download so as to create the disk file name.

 

So if Bob restores Alice's XML, it restores her CIV to 1.0 and the current server version scrape is 1.0, that is expected behavior to me -- Ketarin should NOT download UNLESS the disk file name does not exist for Bob. Then Bob will get the file anyway.

 

A versionless output filename will not be downloaded, but any filename that contains version info will be downloaded -- because Bob's prior disk filename contains 0.9 not 1.0.

 

 

What about my prior question, can you confirm the CIV will not be updated from <empty> until there is download? I can

Link to comment
Share on other sites

I'm sorry Flo, I'm still struggling with what you're saying -- are you saying your server singles out *Ketarin* as the downloader and won't let Ketarin download the 1.0.2 version of the file?

 

Nope, I'm not. These downloaders you use probably guess referrers.

 

The XML files are not meant for restoration, but for interoperability. I really don't want to put any (or rather, further) "local" state information into it.

 

What about my prior question, can you confirm the CIV will not be updated from <empty> until there is download? I can

 

Nope, I cannot. The state will be saved independently of whether or not there is a difference in contents.

Link to comment
Share on other sites

Well, I just created a new Ketarin entry to download from the 1.0.2 URL, and it downloaded the new version file. NO REFERRER. Why is this behavior different from what you've stated should be happening? From what you've stated, I should have gotten 1.0.1.197.zip file, not 1.0.2.zip file.

 

1. No CIV

2. No 'delete prior'

3. Same URL

3. Disk file name did not exist

 

 

Here's the XML:

 

<?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="50456940-7829-4916-85c5-c2b0b49a30a3">

<DownloadBeta>Default</DownloadBeta>

<DownloadDate xsi:nil="true" />

<VariableChangeIndicator />

<CanBeShared>true</CanBeShared>

<ShareApplication>false</ShareApplication>

<ExclusiveDownload>false</ExclusiveDownload>

<HttpReferer />

<Variables />

<ExecuteCommand />

<ExecutePreCommand />

<Category>000100</Category>

<SourceType>FixedUrl</SourceType>

<PreviousLocation>D:\temp\Ketarin-1.0.1.197.zip</PreviousLocation>

<DeletePreviousFile>false</DeletePreviousFile>

<Enabled>true</Enabled>

<FileHippoId />

<LastUpdated>2009-02-19T12:08:45.439875-08:00</LastUpdated>

<TargetPath>D:\temp\</TargetPath>

<FixedDownloadUrl>http://ketarin.canneverbe.com/downloads/Ketarin/Ketarin-1.0.2.zip</FixedDownloadUrl>

<Name>Ketarin new URL</Name>

</ApplicationJob>

</Jobs>

Edited by appyface
Link to comment
Share on other sites

What about my prior question, can you confirm the CIV will not be updated from <empty> until there is download? I can

Nope, I cannot. The state will be saved independently of whether or not there is a difference in contents.

OK then I don't know how to approach the recreation of what happened.

 

What I believe happened. Last weekend (I think 2/16/09):

 

1. I exported all jobs to XML

 

2. I launched Ketarin with no reference to jobs.db, so it would create empty jobs.db

 

3. I imported the XML

 

4. I ran 'update all'. I *think* Boozet Double Driver redownloaded on first attempt though I'm not positive about that

 

5. I've since run several 'update all' attempts on different days, Boozet Double Driver has not redownloaded again (until today)

 

6. The variable used for CIV ({vers}) gets same value it's been getting, at least since 2/16. I display the {vers} variable in my custom column so I can see that part. But since I can't examine the previous value of the CIV at each update attempt, I have no idea what prior value {vers} was actually being compared to. It's not logged.

 

7. Today's download log shows no mention of the CIV, but the server file's dates had changed, so it redownloaded. As far as I know, the current CIV should have been equal to the previous one and the file should NOT have been redownloaded.

 

You've told me the CIV was blank is why the file redownloaded. But I don't know how to verify that so I can recreate it? And you've said the state should be saved independent of the download, so it should not have been blank.

 

Therefore it was not blank, it should have had the same version number and therefore not downloaded. But it did download, after reporting the server's dates have changed.

 

Did Ketarin check the server's file dates FIRST, and did not check the CIV?

 

8. Another update attempt did log the examination of the CIV and did not download beacuse it had not changed. Did Ketarin only get to the point of checking the CIV because the file server's dates had not changed?

 

 

I can try recreating this but I don't have access to a test web system where I can control the file server dates. I'll have to arrange for something like that, first. I'll also need a way to see the CIV's prior value on each update attempt. Can you help with that part?

Link to comment
Share on other sites

Yep, it should, and this is actually the result I get when I try your XML. And from what I can see, it did also download this file when you tried it (PreviousLocation)?

OK then I still don't get why you say my other XML is not supposed to download the 1.0.2.zip but continues to download the 1.0.1.197.zip file. It's the SAME URL... why the two different behaviors?

Edited by appyface
Link to comment
Share on other sites

The order of update checks is:

 

- exists?

- CIV

- MD5 / FileHippo

- Date / Size

 

If you need some place to upload files for testing, feel free to use the wiki. I think you should be able to upload files there.

 

Also, note that in older versions of Ketarin, the CIV was not working properly (did never detect any updates). Maybe you've suffered from that.

Link to comment
Share on other sites

OK then I still don't get why you say my other XML is not supposed to download the 1.0.2.zip but continues to download the 1.0.1.197.zip file. It's the SAME URL... why the two different behaviors?

 

Erm...I feel like it makes more sense to discuss this per IM. This back and forth in the forum seems a little cumbersome...

Link to comment
Share on other sites

Oh, really? Well, you don't have to...but if you want to try, I'm available on IRC, Jabber, ICQ or MSN.

 

Anyway, since I'm going to sleep now let me answer that so far, I see no two different behaviours. There is just one, that is, Ketarin downloads 1.0.1, no matter which URL you choose (this is not Ketarin, Firefox will do that as well). *Only* if ketarin.canneverbe.com is your referrer, you are free to download any of those files (Firefox does of course submit a referrer). I don't think that you should wrack your brain over this special situation which I created on my server, if you use the intended download URL for Ketarin you'll get your updates properly.

Link to comment
Share on other sites

Oh, really? Well, you don't have to...but if you want to try, I'm available on IRC, Jabber, ICQ or MSN.

 

Anyway, since I'm going to sleep now let me answer that so far, I see no two different behaviours. There is just one, that is, Ketarin downloads 1.0.1, no matter which URL you choose (this is not Ketarin, Firefox will do that as well). *Only* if ketarin.canneverbe.com is your referrer, you are free to download any of those files (Firefox does of course submit a referrer). I don't think that you should wrack your brain over this special situation which I created on my server, if you use the intended download URL for Ketarin you'll get your updates properly.

Sleep? It's only 2:13pm! :)

 

Well I'm not wracking my brain, there's nothing to wrack :) I'm out of ideas why the two app entries would behave differently when using the same source URL.

 

You keep saying you don't see anything wrong with either of them, they are each behaving correctly. Would you please take me point by point, comparing the two XMLs side by side, and tell me what is it, that is directing the two outcomes? One app continues to try to download 1.0.1.197.zip while the other downloads the 1.0.2.zip -- and both start from the same source URL?

Link to comment
Share on other sites

I'm sorry Flo, there is something very wrong here.

 

I cloned the XML from the example that brought me here (Ketarin was downloading from URL for 1.0.1.197 but I changed the URL to the 1.0.2 URL), and I changed the disk location so no ketarin file previously existed.

 

Here's the update log:

 

2/19/2009 3:00:45 PM: Update started with 1 application(s)

2/19/2009 3:00:47 PM: Ketarin redownload xxxx beta NEW LOC : Checking if update is required...

2/19/2009 3:00:47 PM: Ketarin redownload xxxx beta NEW LOC : Update required, 'D:\Ketarin-1.0.1.197_beta_20090211-093911.zip' does not yet exist

2/19/2009 3:00:51 PM: Ketarin redownload xxxx beta NEW LOC : Replacing {vers} in '{vers}' with '20090211-093911'

2/19/2009 3:00:52 PM: Update finished

 

The log doesn't show the substitutions for {url:basefile}. The output disk filename is:

Ketarin-1.0.1.197_beta_20090211-093911.zip

 

And the file version served is indeed 1.0.1.197, not the newer 1.0.2.zip file.

So that rules out disk file existing as reason for not getting the 1.0.2 file.

 

XML of this app entry after I issued CTRL-U:

 

<?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="ad935bb9-dbb7-4655-84ef-45f24fdf4012">
   <DownloadBeta>Default</DownloadBeta>
   <DownloadDate xsi:nil="true" />
   <VariableChangeIndicator />
   <CanBeShared>true</CanBeShared>
   <ShareApplication>false</ShareApplication>
   <ExclusiveDownload>false</ExclusiveDownload>
   <HttpReferer />
   <Variables>
     <item>
       <key>
         <string>vers</string>
       </key>
       <value>
         <UrlVariable>
           <VariableType>Textual</VariableType>
           <Regex />
           <TextualContent>{f:yyyy}{f:MM}{f:dd}-{f:HH}{f:mm}{f:dd}</TextualContent>
           <Name>vers</Name>
         </UrlVariable>
       </value>
     </item>
   </Variables>
   <ExecuteCommand />
   <ExecutePreCommand />
   <Category>000100</Category>
   <SourceType>FixedUrl</SourceType>
   <PreviousLocation>D:\Ketarin-1.0.1.197_beta_20090211-093911.zip</PreviousLocation>
   <DeletePreviousFile>false</DeletePreviousFile>
   <Enabled>true</Enabled>
   <FileHippoId />
   <LastUpdated>2009-02-19T15:00:51.92225-08:00</LastUpdated>
   <TargetPath>D:\{url:basefile}_beta_{f:yyyy}{f:MM}{f:dd}-{f:HH}{f:mm}{f:dd}.{url:ext}</TargetPath>
   <FixedDownloadUrl>http://ketarin.canneverbe.com/downloads/Ketarin/Ketarin-1.0.2.zip</FixedDownloadUrl>
   <Name>Ketarin redownload xxxx beta NEW LOC </Name>
 </ApplicationJob>
</Jobs>

Link to comment
Share on other sites

Good Morning Flo, hope you slept well. :)

 

I'm using THIS same source url for BOTH Ketarin entries:

http://ketarin.canneverbe.com/downloads/Ketarin/Ketarin-1.0.2.zip

 

I've added no referrer for either one, no CIV, no 'delete prior'.

 

This EXACT SAME URL returns {url:basefile} of Ketarin-1.0.1.197.zip (and it really *is* that version) for the one app entry, and returns {url:basefile} of Ketarin-1.0.2.zip for the other entry.

 

Why are two different versions of the app downloaded from the same URL?

 

I do understand you have your server set to serve specific files under certain circumstances such as with IE, Firefox etc., but I'm trying to understand why Ketarin does not retrieve the same filename under BOTH app entries, be it the old filename or the new filename.

 

Can you help me understand the difference?

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
 Share

×
×
  • 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.