+Chrysalides Posted November 3, 2010 Share Posted November 3, 2010 (edited) This does not happen often, but it is rather irritating when it does. Anyone else encountered it? Mine's a year old, Oregon 300. Latest firmware, but it happened with earlier firmware as well. Upload about 1900 geocaches into it, with up to 6 logs each. I use the Colorado / Oregon macro in GSAK to load it. Caches are loaded into main memory, not the microSD card. Everything goes into one gigantic GPX. No additional waypoints. When coming up for the first time after a new GPX, it takes a long time as it is reading in the file. However, about once out of every 5 times, it will just freeze and never complete loading. I need to remove the batteries in order to reboot it. And when it boots up the second time, it would have stopped reading somewhere in the GPX, meaning some caches are not loaded. If I connect it to the computer again, and either "touch" the file or load in the exact same file, it would come up just fine. My workaround for now is to make sure it will come up immediately after loading in new caches. That way I can fix it immediately if there is a problem. Edited November 3, 2010 by Chrysalides Quote Link to comment
+pppingme Posted November 3, 2010 Share Posted November 3, 2010 This seems to be a long standing issue with no clear answer. 200's, 300's, 400's and even the newer x50 units are all affected. The two work arounds seem to be, 1st, as you've done, either touch or reload the file, and it will boot just fine the 2nd attempt, or, clear any .gpx files (just caches, not tracks, etc) off the unit and let it boot without any caches, then the next load will work. It seems to boil down to this, if you already have a "larger" file on the unit, and you replace it with another "larger" file, the unit will hang on the first boot after loading the newer file. From my testing, it seems that both conditions have to exist. I've seen the unit hang after loading smaller files when a larger file was already on the unit, but have never seen a large file hang it if the unit was cleared first. I've also never seen it hang twice in a row after reloading or touching the new file. There seems to be speculation that this is a gsak issue, BUT, it has been confirmed to happen with two pq's loaded directly to the unit. There doesn't seem to be much difference between different versions of firmware (although the earliest versions of the firmware didn't seem to be able to recover at all without clearing the file first). "Larger" seems to be anything much over 8 to 10 meg. Testing by other users varies on both ends of this. A file with 1900 caches and 6 logs will be in the ballpark range of 11 or 12meg. Quote Link to comment
+ecanderson Posted November 3, 2010 Share Posted November 3, 2010 FWIW -- I regularly load a PQ of about 3300 on my 450, created and massaged by GSAK, total size of the .gpx around 15.5MB. Mine always "hangs" about half way through, but then continues on after a bit (perhaps 30 seconds or so of delay). Have never had a condition where I had to pull batteries or employ any other heroic measures to get it to continue. Quote Link to comment
+GeekBoy.from.Illinois Posted November 3, 2010 Share Posted November 3, 2010 I saw the "hang" issue back when I still had my Colorado 300. At first, I thought it was related to the fact that I work on a Mac (even though it is running Windows natively via Boot Camp part of the time this happens). The problem persisted through my upgrading to an Oregon 400. The one thing that always seemed to work in my favor was that I prefer to load my GPX files on the SD card, so in a worst case scenario, I can pull the SD card, boot the device, then replace the card and startup a second time and it works properly. I generally emulate the same by deleting the GPX files from the SD card, startup the GPSr, clear track logs, etc. then reconnect to the computer and load new GPS files. In loading my geocaches from the SD card, I see that it generally takes about 60-85 seconds to load on the first startup, but following that, it is much faster (half that long or even faster). When this has happened, I have waited 10-15 minutes, and the screen never changed. When it hangs in this case, I am forced to pull the batteries to turn it off, the power switch will not work. Quote Link to comment
+dfx Posted November 3, 2010 Share Posted November 3, 2010 (edited) same problem here, oregon 450 with all firmware versions. i don't use GSAK, so that can't be the problem. i do process the GPXs via some scripts though, but i've had the unit freeze on me with vanilla PQ GPX files as well. currently my GPX files are about 8 MB big at most, mostly smaller (around the 6 MB mark). i don't think it depends on the number of files or their size, as i've varied that over time (one big large file vs. many small ones) without any improvement. i think the number of caches and/or waypoints is the only thing that's significant. if i only keep loading about 2000-3000 caches, i'm having no problems at all. crashes vary, sometimes it's still possible to turn the unit off, other times i have to take the batteries out. i've even had it crash on my after only deleting GPX files. that is, i've had a few thousand caches loaded, deleted those GPX files and didn't put any new ones on. on the next boot, the oregon deleted the caches from those files and never finished doing so. Edited November 3, 2010 by dfx Quote Link to comment
+g-o-cashers Posted November 3, 2010 Share Posted November 3, 2010 Ever since Garmin added the progress monitor I haven't seen this issue. It used to happen relatively frequently on my x00 and x50 (maybe one in five downloads). One thing that worked for some is to completely delete all geocaching gpx files in Garmin\GPX, reboot once, reconnect and download the new gpx file. I would recommend against the approach of just touching the file again to get it to reload (or simply pulling batteries and rebooting). In the even the unit hangs during a gpx load you should ALWAYS delete all gpx files, reboot once, and then reload. Repeat as necessary until you get a clean sequence. I've seen too many cases where people thought the unit was okay after a hung load and then got into the field with a partial or corrupted load of geocaches (myself included). Quote Link to comment
+dfx Posted November 3, 2010 Share Posted November 3, 2010 I would recommend against the approach of just touching the file again to get it to reload (or simply pulling batteries and rebooting). In the even the unit hangs during a gpx load you should ALWAYS delete all gpx files, reboot once, and then reload. Repeat as necessary until you get a clean sequence. I've seen too many cases where people thought the unit was okay after a hung load and then got into the field with a partial or corrupted load of geocaches (myself included). i've always used that technique without any problems. when the number of caches i was loading was anywhere over 4000, the procedure reliably repeated itself, every single time i updated the GPX files: connect oregon, put new GPX files on there (overwriting the old ones), start oregon, wait for the hang, turn it off (or pull batteries as necessary), reconnect it, touch files, start it again and this time it will finish loading. i never had any caches missing nor any corrupted entries this way, as opposed to using it directly after it hung during import without going through the touch/reload procedure, which did get me missing and corrupted entries. of course this isn't a solution, it makes loading and reloading a larger number of caches a major PITA. it's the most annoying and most long standing problem with the firmware, second being the occasional "won't connect up to PC even though plugged in" phenomemon. Quote Link to comment
+Maingray Posted November 3, 2010 Share Posted November 3, 2010 Old issue... happens a lot to me, I do the g-o-cashers method. Quote Link to comment
+pppingme Posted November 3, 2010 Share Posted November 3, 2010 Ever since Garmin added the progress monitor Progress monitor? Is this something in the Beta versions? I haven't seen it? Quote Link to comment
+pppingme Posted November 3, 2010 Share Posted November 3, 2010 I would recommend against the approach of just touching the file again to get it to reload (or simply pulling batteries and rebooting). Garmin tracks the date/time stamp of files upon loading (thus the reason it won't attempt to reload a file by just booting the unit again, their real goal seems to be to optimize boot time). If the file has a new time stamp (i.e. you've "touched" the file), the unit will try to reload it. Although I generally reload the same file again, its not a requirement based on Garmin's logic for deciding if a file needs to be reloaded or not, a new time stamp is all that's required. Since this issue seems to have as much to do with expunging the old file (to repeat, I've never seen it happen when there were no .gpx files on the unit to start with), just forcing a reload of the new file is all that's needed, and Garmin's logic forces this with a simple touch. For those that are unfamiliar, "touch" is a utility that has been around since the beginning on most unix systems, who's only purpose is to update the date/time stamp on a file (and to create a zero byte file if it doesn't already exist). When people refer to "touching" a file, they simply mean to force an update of the time stamp. Quote Link to comment
+Chrysalides Posted November 3, 2010 Author Share Posted November 3, 2010 (edited) Thanks for the responses, guys. I was worried I have a lemon here. I'm not sure if I should feel better or worse about the problem being fairly common Also thanks for the workarounds. The one about deleting all caches, rebooting, loading caches, rebooting is good to know in case the unit gets stubborn. The SD card workaround is also a good one. Ever since Garmin added the progress monitor Progress monitor? Is this something in the Beta versions? I haven't seen it? Same here, haven't seen something like that... and I guess only on the x50 series? dfx : I encountered the "failure by computer to recognize USB device" as well. At first I thought it was just with my desktop at home, but I don't seem to have the problem with any other USB devices except my Nuvi 755 and Oregon. Seems to be much better with recent firmware though. I did notice that it does occasionally take 30 seconds for the device to show up. Edited November 3, 2010 by Chrysalides Quote Link to comment
+Red90 Posted November 3, 2010 Share Posted November 3, 2010 As mentioned, the safe procedure is to always keep the files on the card. This allow full recovery without a hard reset in the field. Easier on a Colorado as the card pops out quicker.. Quote Link to comment
+dfx Posted November 3, 2010 Share Posted November 3, 2010 Progress monitor? Is this something in the Beta versions? I haven't seen it? Same here, haven't seen something like that... and I guess only on the x50 series? ah, possibly only the x50 models get that, yeah. it's a green progress bar showing you the progress of the GPX import. i suspect they added it after people were thinking the devices got stuck during boot while importing the GPXs. of course now it's a good indicator showing that they do get stuck occasionally. dfx : I encountered the "failure by computer to recognize USB device" as well. At first I thought it was just with my desktop at home, but I don't seem to have the problem with any other USB devices except my Nuvi 755 and Oregon. Seems to be much better with recent firmware though. I did notice that it does occasionally take 30 seconds for the device to show up. yeah, i have no problem with waiting a bit until it connects. but sometimes it doesn't connect at all. then sometimes i can get it to connect by unplugging it and replugging it, but other times that doesn't help either. occasionally the unit freezes completely so that i have to pull the batteries again. other times replugging it causes it to go back to showing the "connected" screen, but this time with the brightness turned all the way up, and when i unplug it (it still doesn't connect up) i get the "power lost, shut down now?" screen, however with the buttons unresponsive and the countdown frozen at 30. at this point i always have to pull the batteries, or replug it again to restart the whole cycle, still without getting a connection. the most frustrating part is that this happens absolutely randomly, and i hate it when software does stuff randomly. it's the whole reason why i switched to linux on my desktop. Quote Link to comment
ZeMartelo Posted November 4, 2010 Share Posted November 4, 2010 (edited) I absolutely loath adding caches to my Oregon 550t. Its almost guaranteed that it will lock midway. What a pain this thing is. This problem has been around forever, I dont understand how Garmin has not fixed it yet? Last night I spent almost one hour recovering my 550. What happened is that I was using the save battery option and put a new GPX file in the unit. The files has 4500 caches. Well, the smart folks of Garmin in their infinite wisdom decided to have the screen turn off during the booting process. Result I found myself with a black screen and no idea what was going on. After 10 minutes I figured that it locked. I pulled the batteries out and from then on the machine was so messed up that I had to remove the sd card and all the gpx files in the gpx folder for it to start otherwise it would just crash at boot. Got it to boot and imediately turned off battery saving and did the operation again... It crashed and finally worked on the second attempt.... <sigh> Edited November 4, 2010 by ZeMartelo Quote Link to comment
+2Wheel'in Posted November 4, 2010 Share Posted November 4, 2010 I shouldn't even comment...but I'm loudly "knocking on wood" with both hands...I have not experienced this anomaly on either my 450 or 550t. I always deleted loaded .gpx files before loading new one; I don't use GSAK...just copy the PQ .gpx directly to the on-board Garmin/GPX...and I don't ever load more than 1K caches + waypoints. I'll have to keep an eye on this topic. Bill Quote Link to comment
+dfx Posted November 4, 2010 Share Posted November 4, 2010 I shouldn't even comment...but I'm loudly "knocking on wood" with both hands.... ..... and I don't ever load more than 1K caches + waypoints. that's why Quote Link to comment
+g-o-cashers Posted November 4, 2010 Share Posted November 4, 2010 (edited) ah, possibly only the x50 models get that, yeah. it's a green progress bar showing you the progress of the GPX import. i suspect they added it after people were thinking the devices got stuck during boot while importing the GPXs. of course now it's a good indicator showing that they do get stuck occasionally. On the Dakota, Oregon x50 and GPSMAP 62/78 you get a file loading progress "bar" during boot. I just checked my x00 and it doesn't seem to have made it to these devices unfortunately. Edited November 4, 2010 by g-o-cashers Quote Link to comment
+Chrysalides Posted November 4, 2010 Author Share Posted November 4, 2010 On the Dakota, Oregon x50 and GPSMAP 62/78 you get a file loading progress "bar" during boot. I just checked my x00 and it doesn't seem to have made it to these devices unfortunately. Thanks for checking. *sigh* And now that the x00 is discontinued, unlikely to ever get in. Like the fat arrow on the compass screen, features I'd like to have, but not enough to upgrade to the x50. I'd pay some money for it though. Hey, Garmin, are you listening? How about letting a third party modify the firmware (with an iron clad NDA), sell it, and you collect a royalty? Quote Link to comment
+g-o-cashers Posted November 4, 2010 Share Posted November 4, 2010 I would recommend against the approach of just touching the file again to get it to reload (or simply pulling batteries and rebooting). Garmin tracks the date/time stamp of files upon loading (thus the reason it won't attempt to reload a file by just booting the unit again, their real goal seems to be to optimize boot time). If the file has a new time stamp (i.e. you've "touched" the file), the unit will try to reload it. Although I generally reload the same file again, its not a requirement based on Garmin's logic for deciding if a file needs to be reloaded or not, a new time stamp is all that's required. Since this issue seems to have as much to do with expunging the old file (to repeat, I've never seen it happen when there were no .gpx files on the unit to start with), just forcing a reload of the new file is all that's needed, and Garmin's logic forces this with a simple touch. For those that are unfamiliar, "touch" is a utility that has been around since the beginning on most unix systems, who's only purpose is to update the date/time stamp on a file (and to create a zero byte file if it doesn't already exist). When people refer to "touching" a file, they simply mean to force an update of the time stamp. What you describe is exactly how it is supposed to work. I'm saying that I've personally had cases on these devices (and read about others) where touching files or simply doing a battery pull and restarting wasn't enough to clear the corruption (ie. missing or incomplete caches). I had to delete the files (or remove the card if I was smart enough to have the files on SD card), reboot and then reinstall the files. I believe that there are corruption modes in the internal geocaching database which can only be cleared by rebooting the unit with no geocaches loaded. Quote Link to comment
+Z_Statman Posted November 4, 2010 Share Posted November 4, 2010 g-o-cashers, is this "touch utility" and actual software application or using the OS to alter the file's attributes? Quote Link to comment
+ecanderson Posted November 4, 2010 Share Posted November 4, 2010 g-o-cashers, is this "touch utility" and actual software application or using the OS to alter the file's attributes? It's a PC utility that allows you to tweak the time/datestamp on files: http://tp.lc.ehu.es/jma/win32/touch.html Quote Link to comment
+dfx Posted November 4, 2010 Share Posted November 4, 2010 g-o-cashers, is this "touch utility" and actual software application or using the OS to alter the file's attributes? It's a PC utility that allows you to tweak the time/datestamp on files: http://tp.lc.ehu.es/jma/win32/touch.html which originally comes from the unix "touch" command: http://en.wikipedia.org/wiki/Touch_%28Unix%29 Quote Link to comment
+myotis Posted November 4, 2010 Share Posted November 4, 2010 I have it lock up on my 550t on a regular basis. Today when I was out caching I discovered while I had the caches, I did not have any cache description and it would lock up each time I tried to access the description. I thought I had the caches loaded correctly but did not. With hindsite it would appear that I should be loading my PQs on the card instead of internal memory. If I had the PQs on my card if I would have removed the card, booted up, shut down, replaced the card, it would have reloaded the PQs and fixed the problem. Am I right about this? Quote Link to comment
+pppingme Posted November 5, 2010 Share Posted November 5, 2010 .Today when I was out caching I discovered while I had the caches, I did not have any cache description and it would lock up each time I tried to access the description. I thought I had the caches loaded correctly but did not.. The times I've heard about it locking up when you look at the details for a particular cache (assuming it didn't lock up when you first loaded the .gpx files to the unit) have always been traced back to a particular cache, and that cache will consistently cause problems. There may be certain characters that it doesn't like or some other data in the description or something it doesn't like. I don't have any caches in my area (that I know of) that have ever caused this issue, but I've seen it mentioned before and has always come down to a particular cache. Quote Link to comment
+myotis Posted November 5, 2010 Share Posted November 5, 2010 .Today when I was out caching I discovered while I had the caches, I did not have any cache description and it would lock up each time I tried to access the description. I thought I had the caches loaded correctly but did not.. The times I've heard about it locking up when you look at the details for a particular cache (assuming it didn't lock up when you first loaded the .gpx files to the unit) have always been traced back to a particular cache, and that cache will consistently cause problems. There may be certain characters that it doesn't like or some other data in the description or something it doesn't like. I don't have any caches in my area (that I know of) that have ever caused this issue, but I've seen it mentioned before and has always come down to a particular cache. The problem today was an incomplete load. None of the caches had descriptions, logs, or hints. (But I found all three). Quote Link to comment
+Z_Statman Posted November 5, 2010 Share Posted November 5, 2010 OK, like "fileTweak" Tks Quote Link to comment
+rovers3 Posted November 5, 2010 Share Posted November 5, 2010 One thing that worked for some is to completely delete all geocaching gpx files in Garmin\GPX, reboot once, reconnect and download the new gpx file The key here is "worked for some" I have tried and still use this method on every load and still often get the hang up when I boot my 400T after it's loaded using the GSAK colorado/oregon macro. I haven't tried the touch thingy but it always boots fine after I pull the batteries. I also check various random caches to see that they are loaded correctly and to date they always have been. Quote Link to comment
+ecanderson Posted November 5, 2010 Share Posted November 5, 2010 Perhaps one reason that my mega loads to the 450 aren't causing any problem is related to something someone suggested, and that I'd just done as a matter of course. GSAK offers a check box to delete all of the *.gpx files on the unit before adding any new ones. In my case, that just means deleting one big *.gpx before replacing it. Like I say, my progress indicator always "hangs" at about 50%, but then picks up again after a bit. Quote Link to comment
+dfx Posted November 5, 2010 Share Posted November 5, 2010 (edited) Perhaps one reason that my mega loads to the 450 aren't causing any problem is related to something someone suggested, and that I'd just done as a matter of course. GSAK offers a check box to delete all of the *.gpx files on the unit before adding any new ones. In my case, that just means deleting one big *.gpx before replacing it. Like I say, my progress indicator always "hangs" at about 50%, but then picks up again after a bit. what's the difference between first deleting the file and then putting a new one, and just overwriting the old file? i get the hang at 50% too, but that's not the terminal crash we're talking about. it can get stuck any time during the process, sometimes the progress bar had barely moved a few pixels when it dies, sometimes it hangs at 50% and never recovers, and sometimes it crashes a few pixels before the end. sometimes it dies and then the "can't find satellites" screen comes up, and when i hit "no" it goes back to the frozen progress bar. sometimes that screen pops up and then the unit is already frozen solid so that i can't even push the button any more. then (after poweroff/battery pull) i do exactly the same thing again and it works just fine. ain't making no sense dude! currently my GPXs hold 3009 caches and 3779 waypoints (incl the caches) total. it seems to work just fine with that number of caches/waypoints. guesstimating i'd say the problems start for me when i'm loading and updating 3500+ caches and their waypoints. the more they are, the worse it gets. and from my gut feeling i'd have to say that the "not connecting to PC" problems also start and get worse once the number of loaded caches exceed the magic limit and the GPX loading problems start too. PS: just updated again, and yep, worked fine. i know that once i add one or two more PQs to the bunch, the import will start dying again. Edited November 5, 2010 by dfx Quote Link to comment
+ecanderson Posted November 5, 2010 Share Posted November 5, 2010 what's the difference between first deleting the file and then putting a new one, and just overwriting the old file?To my understanding of the OS and file handling, absolutely nothing. I report that only because some have said that if they first delete the old file before adding the new one, it has some positive result. The only possible things that could be different in the delete/add vs. overwrite method are that when deleting, the occupied space is deallocated first. With an overwrite, the new file may be overlaid in the same space. Beats me. i get the hang at 50% too, but that's not the terminal crash we're talking about. it can get stuck any time during the process, sometimes the progress bar had barely moved a few pixels when it dies, sometimes it hangs at 50% and never recovers, and sometimes it crashes a few pixels before the end. Fortunately, I've never had any of those conditions on my 450 (so far). I ran a load last weekend that pushed me up near 4000, and nothing bad happened -- just took a little bit longer to complete than the usual 3200 or so that I usually load (I added another PQ to the collection in GSAK before loading). Quote Link to comment
+Chrysalides Posted November 5, 2010 Author Share Posted November 5, 2010 ...but it always boots fine after I pull the batteries. I also check various random caches to see that they are loaded correctly and to date they always have been. I'm not 100% positive, but you may want to check the last cache in your current GSAK filter and sort order when running the macro, and make sure that is loaded. The macro generates the GPX by your current sort order, and the Oregon loads them in sequentially. I've seen partial loads a number of times. Quote Link to comment
+dfx Posted November 5, 2010 Share Posted November 5, 2010 (edited) I ran a load last weekend that pushed me up near 4000, and nothing bad happened -- just took a little bit longer to complete than the usual 3200 or so that I usually load (I added another PQ to the collection in GSAK before loading). try reloading that 4000 wpt file a few times. maybe mark some caches as found before each reload. i'm curious as to what happens. of course it's perfectly possible that caches are always being loaded fine, and that it's actually the regular waypoints which cause the lockups. Edited November 5, 2010 by dfx Quote Link to comment
+Chrysalides Posted November 5, 2010 Author Share Posted November 5, 2010 of course it's perfectly possible that caches are always being loaded fine, and that it's actually the regular waypoints which cause the lockups. I eliminated that possibility by no longer loading waypoints, only GPX. Still hangs occasionally. I wonder if it is totally random or if there is some pattern behind it. Yesterday I loaded in 1891 geocaches, overwriting. No waypoints. Before disconnecting I deleted current.gpx and geocache_visits.txt. It paused a bit before coming up - not sure if it is longer than the standard loading pause since I don't have the progress bar. But it came up fine. I should start taking notes. Quote Link to comment
+out12 Posted November 5, 2010 Share Posted November 5, 2010 I've had this problem on my 300 as well. What I now try to remember to do is to start the unit up after disconnecting from the PC. If it works OK I'm all set, if not I pull the batteries and reload it. Also had a couple cases of not having all the info for certain caches but haven't figured out the reason for that yet. Quote Link to comment
+dfx Posted November 6, 2010 Share Posted November 6, 2010 (edited) updated to 3497 caches / 4331 waypoints, no problems. testing continues. my theory is that it doesn't depend on how many new caches/waypoints are being loaded, but rather on how many are already loaded and will thus be deleted/updated. Edited November 6, 2010 by dfx Quote Link to comment
+ecanderson Posted November 6, 2010 Share Posted November 6, 2010 Have also been trying all kinds of combinations here. Does its usual 15 second pause or whatever it is at the 50% point, then moves on ahead for the rest of the load. So far, can't break it. Quote Link to comment
+pppingme Posted November 8, 2010 Share Posted November 8, 2010 what's the difference between first deleting the file and then putting a new one, and just overwriting the old file?To my understanding of the OS and file handling, absolutely nothing. I report that only because some have said that if they first delete the old file before adding the new one, it has some positive result.. The key in deleting the files first is to allow the unit to boot without any caches loaded, without the boot, it makes no difference if you overwrite vs delete and create. Once the unit "reads" the caches, they are stored internally and the .gpx file is never touched again, that is unless the unit detects a difference in the .gpx file upon boot (like a new date, etc). Quote Link to comment
+pppingme Posted November 8, 2010 Share Posted November 8, 2010 my theory is that it doesn't depend on how many new caches/waypoints are being loaded, but rather on how many are already loaded and will thus be deleted/updated. Strogly agree, I believe this is a very strong factor, and is basically proven by the fact that if the unit is booted without any caches, the next load will always boot up without any problems, regardless of size (assuming your not over 2k or 5k caches and 200 files). Quote Link to comment
+dfx Posted November 8, 2010 Share Posted November 8, 2010 The key in deleting the files first is to allow the unit to boot without any caches loaded unfortunately i've had the oregon die on me during boot after doing exactly this at least once before. i.e. i deleted the files and then booted it up. it never finished booting. Quote Link to comment
+rovers3 Posted November 9, 2010 Share Posted November 9, 2010 if the unit is booted without any caches, the next load will always boot up without any problems, I've been using this method for some time now and do not agree with the above statement. For me it is "usually" but not "always" as I've had the unit freeze and need the batteries pulled after loading the waypoints. This method is better but not infallible. Quote Link to comment
+dfx Posted November 15, 2010 Share Posted November 15, 2010 does anyone of the affected people use vanilla PQ files? or at least GPXs with geocaches and waypoints seperated into different files? Quote Link to comment
+Z_Statman Posted November 15, 2010 Share Posted November 15, 2010 I load a gpx file via GSAK then also export a POI file of the same caches as a backup Quote Link to comment
+ecanderson Posted November 15, 2010 Share Posted November 15, 2010 does anyone of the affected people use vanilla PQ files? or at least GPXs with geocaches and waypoints seperated into different files? FWIW, I haven't been loading the waypoints. Probably should, as some parking info is helpful at times, but I usually scout everything in advance. All I'm loading to my 450 is a very large and slightly GSAK massaged (name field tweaked for additional info) version of the *.gpx file without the -wpts.gpx file. Another big (4200) load over the weekend, and no glitches. Quote Link to comment
+dfx Posted November 15, 2010 Share Posted November 15, 2010 I load a gpx file via GSAK then also export a POI file of the same caches as a backup so does that mean you're mixing caches and waypoints into a single file, and you're seeing the hangs? FWIW, I haven't been loading the waypoints. Probably should, as some parking info is helpful at times, but I usually scout everything in advance. All I'm loading to my 450 is a very large and slightly GSAK massaged (name field tweaked for additional info) version of the *.gpx file without the -wpts.gpx file. yes, you've mentioned that before. another thread made me realize that the inability to modify loaded caches in any way might be because they wanted to avoid having to rewrite the "extended" GPX files coming from PQs, which is somewhat understandable. now when you start mixing regular waypoints and caches into the same GPX, an edit or deletion of any contained waypoint would cause a rewrite of the whole GPX file. so maybe the firmware just assumes that caches and waypoints are never mixed in a single file and maybe that's where the problems come from. just a wild, untested and probably incorrect idea... Quote Link to comment
+ecanderson Posted November 15, 2010 Share Posted November 15, 2010 just a wild, untested and probably incorrect idea... Yes, but a darned interesting one. If I understand, you're postulating that a single *.gpx file that is a mixed bag of *.gpx data for caches and data from the *-wpts.gpx (the combined file generated by something like GSAK) might be part of the issue? Back "in the day" with the eTrex when I felt pretty constrained by a 500 cache count, I didn't even load up the extra waypoints as POI, although that wouldn't have been hard - just didn't know better. I've since grown accustomed to busting down incoming PQs and just loading the cache *.gpx files (not including the -wpts.gpx files). Haven't ever directly loaded the *.zip file with GSAK, either. So the -wpts.gpx files have always been excluded from the *.gpx result. There's certainly no reason I can't have a go at creating that sort of file to see if it breaks anything. Pause... OK - took the most recently built GSAK version of a 6 PQ load and from GSAK, added one of the -wpts.gpx files belonging to one of the PQs. Picked up a couple of dozen waypoints from that. Used the box that says "Clear GPS before sending" as I always do. "Waypoint" type = geocaches as I always do. Disconnected normally. So all normal procedure (for me) apart from the waypoints addition to the *.gpx being sent to the 450. No change. Got stuck at 50% of the load for about 20 seconds, then moved right on to complete the load --- just like always. I'll continue to follow the "adding waypoints" procedure for the next few weeks of loads and see if anything hiccups. Quote Link to comment
+dfx Posted November 15, 2010 Share Posted November 15, 2010 Yes, but a darned interesting one. If I understand, you're postulating that a single *.gpx file that is a mixed bag of *.gpx data for caches and data from the *-wpts.gpx (the combined file generated by something like GSAK) might be part of the issue? exactly. the only explanation i could come up with as to why it's not possible to delete or edit loaded geocaches at all on the device itself is that they don't want to rewrite GPX files containing the Groundspeak extensions. for this to hold true, they'd have to presume that geocaches and waypoints are always located in seperate GPX files, as they are in PQs. so maybe this assumption is important during the GPX import phase as well. Used the box that says "Clear GPS before sending" as I always do. "Waypoint" type = geocaches as I always do. Disconnected normally. So all normal procedure (for me) apart from the waypoints addition to the *.gpx being sent to the 450. No change. Got stuck at 50% of the load for about 20 seconds, then moved right on to complete the load --- just like always. that's the problem with testing this: it doesn't always do it. i haven't had any hangs myself for quite some time now, as the number of caches i'm loading these days is relatively low. Quote Link to comment
+Avernar Posted November 15, 2010 Share Posted November 15, 2010 I'm having the same problem on my 62s. I think it's the amount of time it takes to do the load. Like someone else mentioned, replacing a large previous export with another large export takes longer than replacing a small cache load. What I think is that the unit decides to do something in the background while the load is happening which causes the load to fail. I usually have the "Searching for satellites" screen cause it but had the "Chirp detected" screen do it once. With the latest firmware things changed a bit. The searching for satellites screen comes up but sometimes the buttons don't work so I can't clear it. I know the unit is not totally frozen as applying external power pops up a message. Quote Link to comment
+Avernar Posted November 15, 2010 Share Posted November 15, 2010 the only explanation i could come up with as to why it's not possible to delete or edit loaded geocaches at all on the device itself is that they don't want to rewrite GPX files containing the Groundspeak extensions. for this to hold true, they'd have to presume that geocaches and waypoints are always located in seperate GPX files, as they are in PQs. so maybe this assumption is important during the GPX import phase as well. Waypoints are loaded into a private memory region in the unit. If you load a GPX with waypoints on the SD card and pull the card, the caches disappear but the waypoints stay. I don't load waypoints into my unit but still have hanging issues. Quote Link to comment
+dfx Posted November 15, 2010 Share Posted November 15, 2010 Waypoints are loaded into a private memory region in the unit. If you load a GPX with waypoints on the SD card and pull the card, the caches disappear but the waypoints stay. huh. really? i don't think it should do that, and at least my oregon 450 doesn't. when i delete a GPX containing a waypoint and boot it up, the waypoint gets wiped from the internal memory as well. the same as it does for caches. Quote Link to comment
+g-o-cashers Posted November 15, 2010 Share Posted November 15, 2010 Waypoints are loaded into a private memory region in the unit. If you load a GPX with waypoints on the SD card and pull the card, the caches disappear but the waypoints stay. huh. really? i don't think it should do that, and at least my oregon 450 doesn't. when i delete a GPX containing a waypoint and boot it up, the waypoint gets wiped from the internal memory as well. the same as it does for caches. The x00 and x50 are very different in this respect. Avernar is describing x00 behavior. FYI, I use the GSAK export macro and always convert child waypoints to POIs so I never have a gpx with mixed waypoints and geocaches and I've seen the hang. I have not seen the hang nearly as much since the progress bar has been introduced on the 62/x50. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.