Jump to content

Cachemate 4.0


Maeglin

Recommended Posts

Ummmm.  All of a sudden the previous logs aren't showing up.  I create the Cachemate file through GSAK and have it set for 5 previous logs.  THe logs do show up in GSAK.  I looked at the settings in Cachemate and it's selected to show logs in the overview, but no dice.  It used to work, so I'm assuming I'm doing something different but I can't figure it out.  Anyone see this problem?

Are you using the memory card support? If so, is the memory card in place when you check and the logs are missing? That's the only reason I can think of on the CacheMate side as to what may be going on.

 

Another thing is, is GSAK actually putting the logs into the CacheMate file. If you export to a CacheMate file and send that to the support email address, I can tell you that. As far as GSAK options that you may have changed, causing the logs not to show up, I'm not a GSAK user (yet) so I don't know what to tell you there.

 

----

 

In other news, now that Jeff's got his plugin support in and the SDK has apparently passed the acid test (of sorts), I'm definitely feeling better about it. Version 1.0 of the SDK has been out for a few days now... any developers that are interested can download it and see what they can do.

Link to comment
Ummmm.  All of a sudden the previous logs aren't showing up.  I create the Cachemate file through GSAK and have it set for 5 previous logs.  THe logs do show up in GSAK.  I looked at the settings in Cachemate and it's selected to show logs in the overview, but no dice.  It used to work, so I'm assuming I'm doing something different but I can't figure it out.  Anyone see this problem?

Are you using the memory card support? If so, is the memory card in place when you check and the logs are missing? That's the only reason I can think of on the CacheMate side as to what may be going on.

 

Another thing is, is GSAK actually putting the logs into the CacheMate file. If you export to a CacheMate file and send that to the support email address, I can tell you that. As far as GSAK options that you may have changed, causing the logs not to show up, I'm not a GSAK user (yet) so I don't know what to tell you there.

 

----

 

In other news, now that Jeff's got his plugin support in and the SDK has apparently passed the acid test (of sorts), I'm definitely feeling better about it. Version 1.0 of the SDK has been out for a few days now... any developers that are interested can download it and see what they can do.

It's still a mystery. I tried reimporting the file a mess of different ways, creating new db's etc. I think I'm going to try to create some different .pdb exports with GSAK and see if it's on the creation side.

 

Any idea of how I might be able to examine a .pdb on the PC side to see if the logs are contained in the file?

 

-t-

Link to comment

ok, i'm trying to make cm2gpx and it fails ... here is the blah blah blah

 

[planetrobert:~/Desktop/cm2gpx-1.0.1] ralann% make
make  all-recursive
Making all in src
make  all-am
if g++ -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -MT pdbreader.o -MD -MP -MF ".deps/pdbreader.Tpo" -c -o pdbreader.o pdbreader.cpp; \
then mv -f ".deps/pdbreader.Tpo" ".deps/pdbreader.Po"; else rm -f ".deps/pdbreader.Tpo"; exit 1; fi
In file included from pdbreader.cpp:20:
common.h:81:19: wchar.h: No such file or directory
make[3]: *** [pdbreader.o] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

 

os 10.2.8

 

I'm probably dumb <_<

Link to comment
Any idea of how I might be able to examine a .pdb on the PC side to see if the logs are contained in the file?

Not really... that's why I mentioned sending it to me. I have tools that will let me look at it, and also know what the file format should be like. It's not exactly human-readable <_<

 

Another idea would be to try Andy's suggestion of uninstalling and reinstalling GSAK.

 

ok, i'm trying to make cm2gpx and it fails ... here is the blah blah blah

Weird... it's worked in other versions of OS X, but apparently yours is missing the Unicode header file. On the other hand, for some strange reason Apple may have made it unnecessary... try commenting out or deleting that line in common.h and run make. If it works, then it's apparently not needed, and I can edit the config script to check for it. If you get more errors (missing wchar_t type or something), I should be able to get it working on your version with some code changes... the only thing I'm using Unicode stuff for anyway is for UTF-8 encoding of the GPX file.

 

Actually, I just checked and I am using at least one Unicode-related function. Anyway, let me know what comes of that test, and I'll see what I can do.

 

I've added a 'Found by me' columnd to the display but it is always blank. Why is that? I've added a 'Found' column and that is correct.

You added a what? There's no facility in CacheMate for adding display columns of any kind...

Edited by Maeglin
Link to comment

twilliams, Maeglin: The logs do show up on the Overview page for me after after exporting from GSAK. I didn't have this option enabled in CacheMate and after enabeling it I still didn't see the logs. Once I exited from CacheMate and then ran it again the logs did show up. It appears the logs are being included.

Link to comment
twilliams, Maeglin: The logs do show up on the Overview page for me after after exporting from GSAK. I didn't have this option enabled in CacheMate and after enabeling it I still didn't see the logs. Once I exited from CacheMate and then ran it again the logs did show up. It appears the logs are being included.

Changing that option doesn't automatically rebuild the Overview display, but it will take effect the next time that happens (via opening the record or changing any of the text). I've just updated the documentation to reflect that.

Link to comment
ok, i'm trying to make cm2gpx and it fails ... here is the blah blah blah

On second thought, wait for an email from me. I'm going to put in a check for that header file (which seems to be missing from everything before OS 10.3.x) and put in some kind of poor man's conversion in there. The last thing I really want to do is muck with proprietary OS X string conversion functions (the only other choice in that case) when I don't have the hardware to test or debug it.

Link to comment

FYI - in case you can't export logs from GSAK to Cachemate at somepoint.

 

Problems exporting logs from GSAK - both to Cachemate and to .gpx files can be resolved by Repair/Defrag-ing the database you are exporting from. I guess Gsak can run with corrupted databases without showing symptoms until export.

 

-t-

Link to comment
Alrighty, I think I'll try to DL JeremyA's latest cmconvert which i BELEIVE contains cm2gpx, the app doesn't work for me but i can extract cm2gpx from the package.

The one I sent you didn't compile either? What error messages did you get?

 

As far as the one that Jeremy compiled, he has a 10.3.x version so yeah... he should have no problems.

Link to comment
Thanks Maeglin, I was able to get what you sent to work.  Worked on the first try.

Cool! Not a perfect solution (the change log reflects that much), but it seems to work in a pinch. I just didn't want to resort to proprietary methods, if I didn't have to, because an OS (or early versions of it, in this case) chooses to do a half-a** job at standard Unicode support.

 

Bah... a censoring forum :lol:

 

if you have a db on the memory card is there an option to merge the two parts into a single gpx file?  this would put your logs into the main gpx file.

There isn't... it just does a simple conversion, not any kind of merging. I might put something like that in there later, but no promises.

 

As far as merging in the logs, the log you enter in CacheMate doesn't use the same XML namespace as GC.com logs anyway. You'd need something specially written to do something with them, so why not do the merging there?

Link to comment
As far as merging in the logs, the log you enter in CacheMate doesn't use the same XML namespace as GC.com logs anyway. You'd need something specially written to do something with them, so why not do the merging there?

just realized that, also noticed after reading the man a couple time that it doesnt export logs and some other stuff.

Link to comment

Found a BUG :lol:

 

ran GPX files IN AND OUT of cm2gpx and cachemate repeatedly with wonderfull results...

 

now for the kicker...

 

IF I create a plain record in CM and export it then the record's name is used in the <desc> field as it should be, AND as it is with PQ based imported/exported files.

 

IF I create another OR duplicate OR alter the first record by adding a Long Description then there is a problem... that long description shows up in the <desc> field along with in the correct location.

 

I have a sample GPX i can email you if you can't/don't want to try yourself. I have tried the following...

 

copying a desc from an imported record

copying a desc from an imported record with owner info and all that other garbage.

importing good records in with the new records

 

just doesn't work for me :lol:

 

Just had an idea, ill try it with the version JA compiled...

 

EDIT: My last idea wouldn't even run on my system... os difference... i think... :(

 

MORE EDIT: First one has NO long description... Second one DOES

  <wpt lat="42.233333" lon="-121.783333">
   <name>XUBNPU</name>
   <desc>TestWPT</desc>
   <sym>Waypoint</sym>
   <type>Waypoint</type>
   <Groundspeak:cache available="True" archived="False" xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0">
     <Groundspeak:name>TestWPT</Groundspeak:name>
     <Groundspeak:type>Waypoint</Groundspeak:type>
   </Groundspeak:cache>
   <cmlog:log version="1.0" found="false" xmlns:cmlog="http://www.smittyware.com/schema/cmlog/1/0">
     <cmlog:start_time>2004-12-01T01:35:00</cmlog:start_time>
     <cmlog:end_time>2004-12-01T01:35:00</cmlog:end_time>
     <cmlog:notes />
   </cmlog:log>
 </wpt>

  <wpt lat="42.233333" lon="-121.783333">
   <name>XUBFFK</name>
   <desc>This is my long description which shouldn't even get into that other field but it still will when i convert it</desc>
   <sym>Waypoint</sym>
   <type>Waypoint</type>
   <Groundspeak:cache available="True" archived="False" xmlns:Groundspeak="http://www.Groundspeak.com/cache/1/0">
     <Groundspeak:name>SampleWPT</Groundspeak:name>
     <Groundspeak:type>Waypoint</Groundspeak:type>
     <Groundspeak:long_description html="False">This is my long description which shouldn't even get into that other field but it still will when i convert it</Groundspeak:long_description>
   </Groundspeak:cache>
   <cmlog:log version="1.0" found="true" xmlns:cmlog="http://www.smittyware.com/schema/cmlog/1/0">
     <cmlog:start_time>2004-11-30T00:00:00</cmlog:start_time>
     <cmlog:end_time>2004-11-30T19:44:00</cmlog:end_time>
     <cmlog:notes />
   </cmlog:log>
 </wpt>

Edited by ralann
Link to comment
IF I create a plain record in CM and export it then the record's name is used in the <desc> field as it should be, AND as it is with PQ based imported/exported files.

 

IF I create another OR duplicate OR alter the first record by adding a Long Description then there is a problem... that long description shows up in the <desc> field along with in the correct location.

That's not a bug. That's how it's supposed to work for what it can't determine to be a geocache waypoint record.

 

It determines that a record is a geocache record by checking that either there is something in the difficulty and terrain fields, or the type name contains the word "cache" (either by itself or as part of a word). If a record meets those criteria, it builds the GPX type and desc fields the same way that GC.com does, using the information that it has. Otherwise, it does what you've described as a "bug".

 

I've just put in an option to use the record name in all cases like that, though, and it seems to work well.

 

1) define which catagory a waypoint is in like it does for waypoint type

And where would I put this category name in the GPX file? There's nothing in the <wpt> element for that. The category option on the cm2gpx command line is a selection filter, based on what's in the PDB file.

Edited by Maeglin
Link to comment

How about here...

 

    <sym>Geocache</sym>
   <type>Geocache|Unknown Cache</type>

 

   <sym>Waypoint</sym>
   <type>Waypoint</type>

 

make the second part of the seecond example look like the first...

 

   <sym>Waypoint</sym>
   <type>Waypoint|My catagory</type>

 

also thanks for adding the other option :rolleyes:

Link to comment
make the second part of the seecond example look like the first...

Ah, ok... there are up to 3 fields like that for geocache records. What I could do, as another option (someone may get screwed up if I make it always-on), is to add the category as an addition pipe-delimited "field" in the <type> element. I could do that for both geocache and non-geocache records.

 

Will probably make it "-T" or something, since the "c" options are taken and it involves the <type> element.

Edited by Maeglin
Link to comment
make the second part of the seecond example look like the first...

Ah, ok... there are up to 3 fields like that for geocache records. What I could do, as another option (someone may get screwed up if I make it always-on), is to add the category as an addition pipe-delimited "field" in the <type> element. I could do that for both geocache and non-geocache records.

 

Will probably make it "-T" or something, since the "c" options are taken and it involves the <type> element.

That sounds like a great idea, options are better than hard coding. -T sounds good, that was the option calling thing t would use.

 

I look forward to this feature.

Link to comment
I look forward to this feature.

Didn't have to wait long :rolleyes:

 

From the official announcement...

 

CMConvert 1.8.7 changes the way that most string filters are processed, adding multiples together instead of each one replacing any previous filters, and adds the ability to read frequently used filters from text files.  CM2GPX 1.0.2 adds a workaround for platforms that lack standard Unicode support, as well as better UTF-8 translation.  A couple of options were added, as well, for enhancements and tweaks to the GPX output.

That only covers the command-line version of CMConvert. The Windows GUI version wasn't changed at all this time, so it remains untouched at version 1.8.6.

Edited by Maeglin
Link to comment

YOU are my hero.

 

This solves all my problems, well the ones you are qualified to solve. :rolleyes:

 

Been playing with the different options and they work as advertised. BUT I have a little confusion...

 

    -s " symbol"

Specifies the default waypoint symbol, for when a waypoint cannot be

determined to be a geocache.  If not specified, the default symbol is

\fBWaypoint\fP.

 

    -t " wpt_type"

Specifies the default waypoint type, for when a waypoint cannot be

determined to be a geocache and a type is not defined in the waypoint

record.  If not specified, the default type is \fBWaypoint\fP.

 

... this part is throwing me a loop -s i can undrstand but -t looks the same(sorta) but I am missing something as I don't see that it does anything.

Link to comment
    -s " symbol"

Specifies the default waypoint symbol, for when a waypoint cannot be

determined to be a geocache.  If not specified, the default symbol is

\fBWaypoint\fP.

 

    -t " wpt_type"

Specifies the default waypoint type, for when a waypoint cannot be

determined to be a geocache and a type is not defined in the waypoint

record.  If not specified, the default type is \fBWaypoint\fP.

 

... this part is throwing me a loop -s i can undrstand but -t looks the same(sorta) but I am missing something as I don't see that it does anything.

Not quite the same. If there's no type specified for a record in the PDB file (it can happen, for instance, if you ran CMConvert on a file with no waypoint type info and then ran that PDB through CM2GPX), that option lets you specify a value for the GPX file. Otherwise, you wouldn't have a <type> element for those waypoints.

 

Since it looks like you're mainly testing with PQ files and records created from CacheMate, those all have type info so it overrides what you specify with that option.

Link to comment

Hi,

I'm real new at this paperless caching. Could someone explain to me if I can (and EXACTLY how to) connect my GPS to my PDA and transfer my 'not found' caches so I don't have to type them into the GPS?

I am using a Garmin GPS Map 76, a Palm Zire 72, Cachemate and MacCMConvert. I am also running Mac OSX 10.3 if that's relevant.

I don't know what a serial hot synch cable is or a serial GPS cable is.

ALSO, when I get my pocket query, convert it and hotsynch to my Palm, I don't get any of the past logs. I deleted all the caches from Cachemate and reloaded them, same thing. I really want to have the past logs. Can anyone tell me why I'm not getting them and what I can do about it?

Thanks,

Thelma and Louise

Link to comment

You can't do that. The Zire 72 is crippled by having no universal connector, so there is no way to connect a GPS to it. You'll have to transfer the waypoints via PC. You should have received a cable with the GPS. If you didn't, you'll have to buy one. I don't have a Mac, so someone else will have to explain MacCMConvert for you. For the PC version, you specify the number of logs using -N x where x is the number of logs you want included. If MacCMConvert is a GUI, then there should be someplace in it to specify the number of logs you want.

Link to comment
ALSO, when I get my pocket query, convert it and hotsynch to my Palm, I don't get any of the past logs.  I deleted all the caches from Cachemate and reloaded them, same thing.  I really want to have the past logs. Can anyone tell me why I'm not getting them and what I can do about it?

1) What's the format used for the Pocket Query file? It should be GPX if you want that kind of information (though, if it was LOC, you'd be missing descriptions and hints as well).

 

2) There's a selector box on MacCMConvert for setting the number of past logs to include. If you don't set that, that would explain why you aren't seeing any. As far as I know, the default is zero, but I could be mistaken.

Link to comment

I'm looking into something for the next release that will allow a wider selection of serial ports than the current version allows, and may help it work better with some devices. The latter is something I'm currently trying with someone who's wanting to get Kirrio's GPS device for the Tungsten E to work with it (have a theory there, but need to patch CacheNav tonight and send her that to test it).

 

I'll be taking the normal serial port and adding that and whatever the OS says is installed to a list to pick from, which will include Bluetooth when available. The list will basically be the same as that in the Palm OS Connection preferences panel, with the addition of RS232, for stating that specifically (something that's needed a lot of the time for my m125).

 

Another option, which will be there on most devices, is infrared... I'm keeping that in the list I get from the OS because I don't want to discriminate and it's also an option in Cetus. What I'm curious about, though, is has anyone ever seen a GPSr that can connect to a Palm OS device via IR? I can't say that I've seen one yet :(

Link to comment

I have a few weird things going on with Cachemate on my Handspring Visor Deluxe. I can connect to my Garmin using a serial cable. Nav seems to work fine, and I get all the data when the GPSr is set to NMEA. However, problems arise when trying to find nearest caches using the "From GPS" button in any page. If I request nearest caches, I get an "Acquiring Position" dialog box with the correct coordinates (if I choose either NMEA or Garmin Host). That's where it goes bad. It just sits there... freezes. If I hit the "Cancel" button I get the Fatal Error message:<Form.c, Line:3744, No event handler>. It has a reset button and my Visor has to do a soft reset.

 

Oddly, I did a Nearest Caches search from the Overview page from the coordinates of a particular cache, and nothing bad happened. I, of course, had to allow such a search in the View dialog menu. Is that where the problem was, or was it searching from the current GPS coordinates like I'm trying to do?

 

Thanks in advance.

 

Parsa

Link to comment
If I hit the "Cancel" button I get the Fatal Error  message:<Form.c, Line:3744, No event handler>. It has a reset button and my Visor has to do a soft reset.

So there is a device out there with that problem after all... weird.

 

Back when I released 4.0 (almost 3 months ago), I was having a similar problem in the emulators I was testing with, and determined it to be an OS problem on anything older than 3.5, but which also resurfaced in 6.0. I have a workaround for the new (as yet unreleased) OS version, but that didn't work with the older OS versions. I disabled that plugin for anything older than 3.5, but then some people with the older versions that had no problems missed it, so I changed it back.

 

Oh well... time to add that to the known issues list, then...

 

If you want to use the NMEA query plugin with that device, you should turn location averaging off... sounds like it's currently enabled. Oh, and it didn't freeze, most likely, it was just averaging. From the plugin documentation:

 

This plugin will perform simple coordinate averaging, when paired with CacheMate 4.0 and that feature is enabled.  When valid location samples start to arrive, the average will be displayed in the progress dialog.  Once this happens, tap Cancel to end sampling.

 

As for the other question...

 

Oddly, I did a Nearest Caches search from the Overview page from the coordinates of a particular cache, and nothing bad happened. I, of course, had to allow such a search in the View dialog menu. Is that where the problem was, or was it searching from the current GPS coordinates like I'm trying to do?

It apparently works fine for you, then. The catch is basically in there to keep people from accidentally shooting their foot, unless they know for sure that they won't have a problem (which, for some reason, some don't).

Edited by Maeglin
Link to comment

CacheMate 4.0.3 and CacheNav 1.04 were released today, a few small additions and improvements going into both.

 

The official announcement...

 

These releases add expanded selection of serial ports and baud rates for plugins that use the serial port.  This allows support for, among other things, the GPS and adapter hardware from Kirrio for PalmOne's USB-bound Zire and Tungsten E models.  Related plugins and the plugin SDK have been updated for this functionality.

 

Other additions to CacheMate are improved record import speed (imports into new databases slow down a little, while merging imports speed up a lot), and default import categories taking hints from import database names.

Link to comment

Thanks for the information. I did indeed have averaging on. I'll try it without and see how it works.

 

On another issue, I just got a Magellan GPS Companion for my Visor in the mail today (Ebay $50). I also got a Visor Prism (the color unit) that I have yet to try with the Magellan.

CacheMate and CacheNav both recognized the Magellan fine. Woo hoo! I hope to turn the Prism into a car navigation system. I just need a DC auto cable for the Magellan and the Prism. I may get one of those flex PDA mounts that attach to the passenger seat bolt.

 

I tried to go out the other day with only my Garmin 12XL, my Visor and Cachemate. I was trying to get caches to hunt near the place I had just dropped off my daughter. The process was not very easy without maps. I was also getting over a cold, so I was looking for fairly easy caches. What I tried, and failed to do (see above post) was get nearest caches from my GPS position. I ended up manually entering coordinates and getting a list. However, the "nearest" list page doesn't show terrain or difficulty. I ended up looking at my Garmin screen and finding the nearby caches that I had loaded from a Pocket Query. I then looked them up one by one using the waypoint list on CacheMate. Slow, but it worked. It would be cool if I could filter the "nearest" search to give only certain ratings, and then have a list of those generated that I could keep going back to. I know I could do several varied pocket queries, but that's hard to do when you're out in the field.

 

I just want to say that CacheMate is a fantastic product, and I look forward to using it for all my cache searches. Thanks for all your work.

 

Parsa

Link to comment
However, the "nearest" list page doesn't show terrain or difficulty. I ended up looking at my Garmin screen and finding the nearby caches that I had loaded from a Pocket Query. I then looked them up one by one using the waypoint list on CacheMate. Slow, but it worked. It would be cool if I could filter the "nearest" search to give only certain ratings, and then have a list of those generated that I could keep going back to. I know I could do several varied pocket queries, but that's hard to do when you're out in the field.

I don't know about another filter, given the lack of room in the filter dialog, but I can look at putting D/T info into the nearest cache display.

 

I just want to say that CacheMate is a fantastic product, and I look forward to using it for all my cache searches. Thanks for all your work.

Thanks :rolleyes:

Link to comment

One thing that geobernd was telling me via email indicated that the problem with crashes doing nearest cache searches from the overview display may have gone away, since he was having the problem before and isn't anymore. I'm wondering if anyone else who was seeing the problem could try to reproduce it with 4.0.3 and let me know what you find.

 

If this is somehow the result of the record import overhaul (about the only thing that's changed in that area with this release), then I'm left even more curious as to why it was happening :lol:

Edited by Maeglin
Link to comment

Quick question: When I am in cachemate, in the overview section, is there a way I can use the buttons or any other shortcut to move to the Log tab? Right now I have to hit the little L in the top right corner where I have all the different tabs. I'd prefer doing this using the buttons/stick (Palm Zire 71) instead, since this is easier in the "field".

 

Hope I am making sense. Thanks

Link to comment
Quick question: When I am in cachemate, in the overview section, is there a way I can use the buttons or any other shortcut to move to the Log tab? Right now I have to hit the little L in the top right corner where I have all the different tabs. I'd prefer doing this using the buttons/stick (Palm Zire 71) instead, since this is easier in the "field".

http://www.smittyware.com/palm/cachemate/faq.php#left_right

Link to comment

Version 1.14 of the NMEA Query plugin is now on the site. It adds a compatibility fix specifically for Kirrio devices (seems that the only location-related NMEA sentence they send is GPGLL... weird), but could also help with other hardware that's equally strange :rolleyes:

 

I'm still curious, as I haven't gotten any reponses about it, whether those who were getting crashes when doing nearest cache searches from the Overview screen are still getting those with version 4.0.3. Scroll up a bit for my post on 12/18 for details.

Link to comment
Quick question: When I am in cachemate, in the overview section, is there a way I can use the buttons or any other shortcut to move to the Log tab? Right now I have to hit the little L in the top right corner where I have all the different tabs. I'd prefer doing this using the buttons/stick (Palm Zire 71) instead, since this is easier in the "field".

 

Hope I am making sense. Thanks

I'd like to second this. I just upgraded to a Treo 650 and it seems like every app has 5-way navigation support except for CacheMate. I can use a hard button to switch between screens, but most apps support using the nav buttons to move through elements in the screen so you don't need to use a stylus.

Link to comment

I seem to have been having the same problem as twilliams was a couple of months back.

 

I have PQs delivering me .gpx files of caches, which I import into the GSAK database. When I look at the caches in GSAK, I can see the logs of previous finders on each cache page as I select it. However, when I export caches to a Cachemate file, there are no logs in them. When I first started using GSAK/CM the logs were there, and though I didn't spot it at the time, it's been since upgrading to version 4 of CM they're not there. I have changed the dialog box in the Export Cachemate File popup window (before the file is generated) to 1 log, 10 logs, and numbers in between, but when I sync the files onto my Palm, there are no logs.

 

I've just re-scanned my memory card, and it says "a change has been detected in the files on the memory card. The card will be scanned for new/updated records". So then it lets me import a load of records (582 in fact) which have logs, but appear to be from before I upgraded to the new version of CM - the logs are from October/November last year. It's like it's resurrecting the previous database - each cache has the same name as the currently existing ones, so I get 2 of everything.

 

So I've deleted my entire Default database on CM and will be reinstalling the stuff tonight. Hopefully there'll be logs in the cache records! Maybe I should totally wipe my memory card so it can't rescan/reinstall these old records?

Link to comment
So I've deleted my entire Default database on CM and will be reinstalling the stuff tonight. Hopefully there'll be logs in the cache records! Maybe I should totally wipe my memory card so it can't rescan/reinstall these old records?

That, or just delete the CacheMate related files if you can identify them on the card. It would be best to Repair the GSAK database as well, since that was the fix for twilliams.

Link to comment
So I've deleted my entire Default database on CM and will be reinstalling the stuff tonight. Hopefully there'll be logs in the cache records! Maybe I should totally wipe my memory card so it can't rescan/reinstall these old records?

That, or just delete the CacheMate related files if you can identify them on the card. It would be best to Repair the GSAK database as well, since that was the fix for twilliams.

Darn, that didn't work. I did repair/defrag, then generated new pdb files, which I stipulated should have 10 logs, but none of the cache records have any logs in. Could I send the .pdb file to the support address and have you check if they're actually there? Let me know what address to send one to...

Link to comment
Darn, that didn't work. I did repair/defrag, then generated new pdb files, which I stipulated should have 10 logs, but none of the cache records have any logs in. Could I send the .pdb file to the support address and have you check if they're actually there? Let me know what address to send one to...

Yeah, the support address is fine... support (at) smittyware.com

Link to comment
Darn, that didn't work. I did repair/defrag, then generated new pdb files, which I stipulated should have 10 logs, but none of the cache records have any logs in. Could I send the .pdb file to the support address and have you check if they're actually there? Let me know what address to send one to...

Yeah, the support address is fine... support (at) smittyware.com

OK, just sent virtual.pdb to you, let me know what you discover...

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...