I highly doubt that, there must be some other factor involved.

Pausing just means that bbTracker is no longer the actively displayed program. It will still be recording, it just means it no longer displays (i.e. you switched to another program or the main menu).

Just keep logging turned on and when it happens again send me the debug.txt. If it is a reproducible bug then it will show up again.

working for me when I would stay stationary for around 10 minutes or so. I finally increased my free memory from around 9 or 10M to 14M and the problem has stopped. Just a thought, maybe you could try increasing your memory. Since then I have downloaded 5.2 and it seems to be working fine also. Thanks Saua.

Hmm definitely not a memory problem. I got over 20 mb free space.

I will try to leave it tracking and hope it stops.

try running BBMaps in the background. i was having the same problem. i now run sprint navigation's compass, ensure that it has acquired a gps signal, close the active window (red button), and then turn on bbtracker. i do not lose my tracks now. prior to this, tracks would seem to randomly stop and not restart. this problem was not unique to bbtracker - it occurred with gpsed and mobile tracker, as well. i have a feeling the problem is related to the implementation of gps in the 8830.

I've read a interesting bit about constant GPS updates in the BlackBerry developer handbook. Could those of you, who've got a problem with frequent disconnects set their update interval to anything less than ten seconds for some tests? 9 seconds should be ok and what value below 10 you choose shouldn't change anything.

Because according to the developers handbook the device will permanently try to aquire new data when the requested update interval is less than ten seconds ... maybe there's some bug in the BB OS there.

Mine was set to 5 second interval. It stopped after tracking 2 points only. I didn't do anything with phone between starting track and end, other than putting in phone and it auto-locked. ( Holster lock ). Last time it tracked 46 points while being in locked mode, so that shouldn't be the problem.

I checked the log and the story is same. The log ended with entries with Startapp and Pauseapp, with 9 seconds between those 2 entries.

I will test with 15 second interval now.

*edit*
It stopped after 6 points. Log entry, other than usual info, just shows "(time) a Starting locationLister with interval 15". When I return to main screen, the "Tracking" box at top right appears again, but after 15 seconds disappears with no new point at all. I waited quite a bit, but still no new points.

I seem to be "losing" tracks.

I have set my track directory to be SDCard/Blackberry/gps, and as far as I know this is where all my tracks have been saved to until now.

However, at least some of the tracks that I save now aren't found in there, and I can't work out where they are. If I try to use the app to load a saved track, I can see them all in the list, so they aren't gone, yet they aren't all in that directory. One I saved yesterday is in there.

I have the export directory set to be the same (i.e. I haven't changed it, so it defaults to be the same). When I export these tracks, the export files are where they should be.

What could be happening here? Where else could they be? And how does it know to display all the tracks found in the normal and this other mystery location?

This wouldn't normally be a problem, but I need to save one particular track in its native format, but I can find it.

Those tracks are stored in an internal memory area called RMS. In the first versions of bbTracker that was the only way to store tracks. Since the RMS has only limited storage (64kb, even on a BlackBerry), I've added the ability to store to a directory.

Normally tracks should only be stored in the RMS when storing to the file systems fails for one reason or another in current bbTracker versions.

Currently there is no way to get the those out into a .bbt file, only exporting works, at the moment.

OK, but that means sooner or later it's going to run out of room, doesn't it? So I need to fix this.

The RAM seems ok - I can view older tracks, and I can play music, etc, on there. Is it possible that it has decided that the RAM is faulty when it isn't? Could a fault during the saving of a track cause it to refuse to save to the directory after the fault is rectified?

One fault I can think of would be if I started a track while the phone was in mass storage mode, as that would prevent the program accessing it. But should the problem persist even after rebooting the phone?

Thats right ... but I don't know what causes tracks to still be stored in RMS, so I'm not sure you can fix it.

It should not usually prevent it from saving to the directory later on. It might be possible that the OS will still report the directory as unaccessible, but I doubt it and even if it did, it would surely go back to normal when you restarted bbTracker.

The problem should definitely not persist later on. Currently if saving to the directory fails, bbTracker just silently writes to the RMS. Maybe I should make it scream instead so that the user at least knows that something might be wrong ...

I'm releasing 0.5.3. It only contains some minor bugfixes with regard to trackpoint naming/marking.

Yes, a warning might be a good idea. It's good that it can continue to operate, but given that that storage space is small, the user ought to be warned that they have limited time to fix the problem.

As well as a warning, it might be nice to display the track file location on the Details view (this might also be useful to people who have changed the location over time and want to know where a particular old track is stored).

It could also be useful to flag RMS tracks in the list that's displayed when loading tracks.

I'm going to load v0.5.3 in the hope that it shakes some sense into it. If not then I'll try uninstalling and reinstalling. Unfortunately that will mean I have to try and check which tracks might be lost this way (will RMS tracks be lost if I uninstall the program?). I'm hoping it's just some recent ones, but for all I know this has been an intermittent problem for a long time.

I guess the lesson for me is to maintain my tracks better. I always accept the default names, so I have no idea which ones I want to keep. Most are rubbish but I'd have to display them in Google Maps to have any idea what any of them are.

While I prefer BBTracker's coordinate format (degrees, minutes, seconds) I occasionally have to enter decimal coordinates into other programs. I'd like to be able to swap between DMS and decimal format.

Rather than adding another configuration option, perhaps it would be simpler to just show both formats on the Details view.

I've loaded v0.5.3 but it didn't help.

I've uninstalled and reinstalled 0.5.3. This lost the tracks stored on RMS, no great loss, but didn't fix the problem.

I tried the same again, this time rebooting after uninstalling, same problem.

I discovered a simple way to work out which tracks are stored on RMS - just change the track file directory to an empty one, then only RMS tracks show in the list when you go to load them.

I had 9 out of 96 stored on RMS. These were all fairly recent, but interestingly 3 were stored on the memory card in the time after the problem began. I'm wondering if each of these were too big for RMS and it decided to use the card instead. It would be reassuring if that was the case.

I'm at a loss to know what to try next. The card still has 130MB free on it, so I can't see why it has decided not to use it anymore.

Incidentally, 96 tracks makes the program extremely slow to display a list of them, and even just to delete one. I advise other users not to allow this many to accumulate in one directory.

I've now uninstalled 0.5.3 and installed 0.4.2, which I had been using until I upgraded to 0.5.1 recently. A test track got stored on the card like it's supposed to.

I then reinstalled 0.5.3. A test track got stored in the RMS area.

Could some other 0.5.3 users please test where their tracks are being stored? I have a Blackberry 8800, and I'm storing tracks on a 2GB micro SD card, if the exact configuration is important.

If it does turn out to be the version that's doing it, then I'd suggest it may have been introduced in 0.5.0 or 0.5.1.

I seems that it will only matter if you uninstall the application, as the tracks in RMS appear to be retained through reboots, and tracks that are too large for that area seem to be stored on the memory card instead. Tracks might also be lost if you do an upgrade without uninstalling, but I'm not sure about that.

Exported tracks get stored in the right area, which is all one would normally worry about.

If the program does now operate as above, then there's not that much cause for alarm. I'm just worried that if it's not doing what it ought to and we don't know why then we should consider this behaviour erratic and possibly untrustworthy.

Only uninstalling bbTracker should clear out the RMS, updating should retain it.

Exported tracks are always stored to the file system, as storing them in the RMS would be useless (the user doesn't have direct access to the RMS).

I think I found the root problem: In my refactoring in 0.5.0 I accidentally switched the order of the two storage locations (RMSTrackStore and FileTrackStore for anyone interested in digging into the code).

Now bbTracker *first* tries to store to the RMS and if that fails (because the RMS is full or the track is too long), then it'll write to your directory.

Thats obviously sub-optimal, since the RMS is supposed to be a worst-case thing. And now, when you actually reach a point where bbTracker can't store to your filesystem it will also be unable to store to the RMS, since it already filled that up ... not a good idea.

I will fix this in the next version.

For now a workaround would be to fill up the RMS with "useless" tracks. Then new tracks will be stored to the file system.

Thats because bbTracker currently reads at least the first few bytes of every track to find out its name. I should really start keeping an index of known tracks to speed this stuff up, but have not done so, because this usually brings with itself its own set of problems (index being out-of-sync, index being corrupt, ...).

A useful thing, for sure. But I don't think I should overload the details view any more (on large font not even the number of satellites displays correctly on my 8800).

That being said: suggestions on how to streamline the UI or how to make it look nicer are always welcome

Excellent, no cause for alarm then.

I'd forgotten that not everyone uses a small font, so perhaps there does need to be an option to toggle the coordinates format. Another way would be to allow the details screen to scroll, then you could put any amount of information on it. There could be a second page of details instead.

I'd like to announce a little change in development/release planning. I've realized that my personal testing is no longer sufficient to find every bug that might sneak into the code while developing more features. Therefore I'll be making development builds available for testing, if anyone's interested.

The upside for testers is that they can play with new features earlier than those who wait for a release and help me produce good software. The downside is that those development builds will probably be more buggy and not as polished as a release should be.

I'll post more when the first development build is available, I'd just like to hear from you if you'd be interested in testing it (it won't be a "closed beta" or anything like that. The development builds will be publicly available, just as all other builds are).