Solution for GSAK Nuvi macro stop working

[+Chrysalides]

So today, my setup that had performed flawlessly suddenly stopped working. POI Loader threw up a "Invalid file" error message.

 

Figuring out that one (or more) of the caches was making it barf, I proceeded to divide and conquer the data. I selected smaller and smaller subsets until finally I narrowed down to one cache that it didn't like. This is quite a tedious process. Depending on how you select your data, what I did may or may not work. I used GSAK filters to select by distance, aiming for roughly half the area each time. The subset would either not load (in which case I'd half it again) or load (in which case I'd select the other half).

 

I looked at the cache, and the only thing unusual was the child waypoint. This cache hadn't been updated recently, so I suspect it could have something to do with the new GSAK (I'm running 8.0 beta).

 

I haven't looked at what exactly it doesn't like, but deleting the child waypoint allowed it to load.

 

I'll be looking into this more when I'm not so sleepy, but wanted to share this technique for anyone who encountered problems with the Nuvi macro that was previously working.

[jholly]

I seem to recall some discussion about that on the GSAK board. Something about getting a cache with the API and the child waypoint has a blank URL. Seems the POI loader gets indigestion with blank URL's. As I recall there is a macro for that.

[+Chrysalides]

I seem to recall some discussion about that on the GSAK board. Something about getting a cache with the API and the child waypoint has a blank URL. Seems the POI loader gets indigestion with blank URL's. As I recall there is a macro for that.

Thanks for the info! I did update my caches with the API because PQ was down the other week. It'll be easy enough to pull the info down again since I know which cache is causing trouble. Should be a simple patch.

[+Seditious]

..Well.. this issue has been the scourge of my life the past week.. I have narrowed it down to the SYMBOLS/CHARACTERS your gps-device recognizes. With GSAK I narrowed down to removing one cache, which has been around over a year. However, someone posted a 'found' log recently using a symbol '😄' at the start of their log...this is what has hindered my loading of my GPX file to my Garmin Nuvi 205w... it is not capable of producing the 😄. Loading GPX files with GSAK gives me the latest 5 logs on my Nuvi when I view them. I have dealt with the POI Up-loader telling me that the GSAK created GPX file is invalid, After removing this particular log ( which GSAK is capable of removing while keeping all other logs and cache information ) I am able to load my pocket query just fine as I have in the past. Hopefully this post will help others that get stuck where I have been.

[+Chrysalides]

..Well.. this issue has been the scourge of my life the past week.. I have narrowed it down to the SYMBOLS/CHARACTERS your gps-device recognizes. With GSAK I narrowed down to removing one cache, which has been around over a year. However, someone posted a 'found' log recently using a symbol '😄' at the start of their log...this is what has hindered my loading of my GPX file to my Garmin Nuvi 205w... it is not capable of producing the 😄. Loading GPX files with GSAK gives me the latest 5 logs on my Nuvi when I view them. I have dealt with the POI Up-loader telling me that the GSAK created GPX file is invalid, After removing this particular log ( which GSAK is capable of removing while keeping all other logs and cache information ) I am able to load my pocket query just fine as I have in the past. Hopefully this post will help others that get stuck where I have been.

 

It's happening every time for me now. The culprit seems to be some smartphone logs. The macro processes them into NUL (hex 0x00) and that gives POILoader fits. My temporary fix is to open the intermediate GPX using Notepad++ (Windows), delete the NUL, save it, then run POILoader again. When I get frustrated enough I'll go fix the macro code.

[+fizzymagic]

..Well.. this issue has been the scourge of my life the past week.. I have narrowed it down to the SYMBOLS/CHARACTERS your gps-device recognizes. With GSAK I narrowed down to removing one cache, which has been around over a year. However, someone posted a 'found' log recently using a symbol '😄' at the start of their log...this is what has hindered my loading of my GPX file to my Garmin Nuvi 205w... it is not capable of producing the 😄. Loading GPX files with GSAK gives me the latest 5 logs on my Nuvi when I view them. I have dealt with the POI Up-loader telling me that the GSAK created GPX file is invalid, After removing this particular log ( which GSAK is capable of removing while keeping all other logs and cache information ) I am able to load my pocket query just fine as I have in the past. Hopefully this post will help others that get stuck where I have been.

 

It's happening every time for me now. The culprit seems to be some smartphone logs. The macro processes them into NUL (hex 0x00) and that gives POILoader fits. My temporary fix is to open the intermediate GPX using Notepad++ (Windows), delete the NUL, save it, then run POILoader again. When I get frustrated enough I'll go fix the macro code.

 

There is a recent cache in your area (which is also mine) with an ampersand (&) in the cache name. While the nuvi macro checks for them in the description, it fails to do so in the cache name. Get rid of that and your file should be fine.

 

I have modified that macro so much it is no longer recognizable as the same macro. But POILoader is so picky I think I am about to convert over to calling an external Python script to generate the CSV or HTML for it.

[robertlipe]

Fizzymagic, being a fellow programmer, knows there are many places along this pipeline for different programmers to screw it up. An ampersand in a cache name is perfectly legal, but does take some care in both the reader and the writer of a GPX file, for example, to correctly deal with entity encoding. Some non-printable characters also require special handling or explicit stripping. If you're seeing a crash on specific logs or caches, always report that to your software vendor. There might be some finger pointing and volleying "well, of course, my program does a dumb thing - that's invalid output from THAT PARTY", but please take the time to work through it and get the problem fixed. That fixes it for ALL the people that may ever see that cache or that log or any others similarly affecting it.

 

GPX files are easy to check for correctness. http://www.topografix.com/gpx_validation.asp - that's a line in the sand that firmly places the "blame" on either the reader or the writer. Any writer of GPX that won't validate is broken. If they're writing bad GPX because of bad input (shame on them), it's up to them to argue the problem upstream. In the case of data shipped around in the API, there may be similar tools, but I'm not as familiar with them.

 

As perspective of cooperating parties implementing workarounds for the defects of others, only in recent months have I removed a workaround in GPSBabel for invalid GPX that was written by Groundspeak in 2003.

[+Lieblweb]

Forget POI loader.....

 

My husband found a better way to load the Nuvi and its been a whole lot nicer than the macro/poi loader route.

 

He uses the Export feature within GSAK. It's either Garmin POI, or GPX (can't remember, but can ask him later).

 

He saves the file on his computer. Deletes the original files from the Nuvi and just drops the new file in.

Edited September 18, 2013 by Lieblweb

[+Ropes]

The following works for me...

Save the gpx file to your computer

Open this gpx file in notepad

Find and delete all occurrences of ???? and maybe ??? (use the search function!)

... and from this post, maybe search for &&&& etc

These can occur in cache names or logs!

Save the file

Re-open in GSAK

Export nto nuvi ... works for me using Nuvi 255W but probably all the same...