saintbyte / openbmap Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/openbmap
License: Other
Automatically exported from code.google.com/p/openbmap
License: Other
What steps will reproduce the problem?
1. Upload a track for which upload failed earlier.
2. Examine the files in /sdcard/org.openbmap.
What is the expected output? What do you see instead?
New files are created for each upload attempt, the timestamp in the filename
reflects the export date/time.
What version of the product are you using? On what operating system?
0.7.5 on Cyanogenmod 10.1.3
Please provide any additional information below.
I would suggest basing the timestamp for the filenames on the data the file
contains, not on export date/time. For example, use the timestamp of the first
GPS position. The timestamp in the filename will still be monotonous, but files
which failed to upload will not be duplicated but overwritten on the next uplad
attempt. (Uploads may fail for a number of reasons - the phone may run out of
battery, the network may become unavailable for a long time, storage runs out,
the app may terminate unexpectedly...) Also, it will make it easier to identify
files (particularly interesting if you use your GPX files for OSM).
Original issue reported on code.google.com by [email protected]
on 4 Oct 2013 at 8:42
What steps will reproduce the problem?
1. Download APK from the web site (using an Android device)
2. After download finishes, try to open it.
What is the expected output? What do you see instead?
Until now (last tried on September 5) the APK would download and install. Today
I tried various APKs and got an error message trying to open the downloaded
file. I notice the downloaded file has a .zip extension; files downloaded
earlier had a .apk extension. However, if I rename the downloaded file, giving
it an .apk extension, I can install it with no problems.
What version of the product are you using? On what operating system?
Build 8e96a4f883b4 on Cyanogenmod 10.1.3-RC2.
Please provide any additional information below.
I recently updated from Cyanogenmod 10.1.3-RC1 to 10.1.3-RC2 but can rule that
out as the source of the error, as other APKs (I tried
download.navit-project.org) download correctly.
I suspect Google Code has changed something about downloads from source
repositories, e.g. reporting a different MIME type or similar.
On a side note, supplying the .apk in the code tree is quite an unusual way of
distributing it. Other projects I have seen use the Downloads section. Maybe
that behaves differently. (That would also be a good place to download the WiFi
catalog and blacklists from.)
Original issue reported on code.google.com by [email protected]
on 11 Sep 2013 at 11:32
What steps will reproduce the problem?
1. Track data
2. export
What is the expected output? What do you see instead?
Old and new client should produce the same kind of data.
When looking at the XML produced I can spot a difference in the cllular data
exported:
In the old client 0.4.99 a value rxlev was present for gsmserving cell and
gsmneighbour.
In the new client 0.7.5 rxlev is only set for gsmneighbour, not for gsmserving.
Another difference is the wifi bssid that is separated by colons in 0.7.5 but
wasnt in the old client.
Attached are files tracked at the same location using old and new client on the
same Phone in 2G only and 3G only mode. They have been then edited to contain
the sames cells and wifis, and the whitespace is edited to be better comparable
in a diff.
What version of the product are you using? On what operating system?
0.4.999 and 0.7.5 on a Motorola Defy running Android 2.2.2
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 2 Oct 2013 at 2:59
Attachments:
What steps will reproduce the problem?
1. Start logging.
2. Go to Map view.
3. Drive around and wait for blue dots to appear as you spot new WiFis.
What is the expected output? What do you see instead?
Expected: a trace of blue dots behind me as I move through an inner-city street.
Instead: no dots in the last few meters behind me; as I move on, they suddenly
pop up. If moving very quickly, the area does not get refreshed before it
scrolls off-screen.
What version of the product are you using? On what operating system?
Rev c4f48ccb716e built from source, on Cyanogenmod 10.1.2
Please provide any additional information below.
In the source code I see that apparently the WiFi overlay gets refreshed every
100 meters. However, this may result in noticeable delays:
Car on motorway: 2-3 seconds
Car in built-up area: 6 seconds
Bicycle: 10–30 seconds
On foot: 1 minute
This may confuse users: at first glance, it looks as if no WiFis were tracked.
I would suggest triggering updates based on time rather than distance. A
refresh rate between 2 and 5 seconds seems suitable to me. From a user
experience point of view I would tend more towards 2 seconds (more responsive)
and increase as needed if resource usage is too high. Optionally, we can still
introduce a distance threshold of some 10–20 meters (typical error in GPS
position) and refresh only if it is exceeded.
Btw, what is a typical event delivery rate for WiFi scans? If it is not too
high (i.e. not more than once in 2–5 seconds), we could just refresh on every
WiFi update. (Implementing the combined time/distance threshold would then be
very easy: just lower the distance threshold to 10–20m.)
Original issue reported on code.google.com by [email protected]
on 26 Aug 2013 at 2:16
What steps will reproduce the problem?
1. I downloaded the map of germany and the wifi catalog.
2. Enable both
3. Go to the map view of the client
4. click on the zoom out button about 10 times
What is the expected output? What do you see instead?
After the 10 or 11th zoom out the map is no longer responding and after a few
seconds a crash message is shown and the client exits.
It now will keep crashing when the app is started again and you switch to the
map view.
I could solve this by downloading and enabling a very small country
(luxembourg). This seens to reset the invalid zoom level so it then enabled the
german map to work again.
What version of the product are you using? On what operating system?
This happens for any of the apks in git on a Samsung Galaxy Y (GT-S5360)
running Android 2.3.6
Please provide any additional information below.
-
Original issue reported on code.google.com by [email protected]
on 3 Sep 2013 at 11:50
What steps will reproduce the problem?
1. Walk around the block until maps starts to scroll
2. Walk a few steps back, so the inital area scrolls back onto screen
3. You'll observe some strange display artifacts (basically unrelated gpx
points are connected with a line)
What is the expected output? What do you see instead?
Please use labels and text to provide additional information.
The cause is that only visible gpx trackpoints are loaded and then connected
according to their timestamp. So it might happen that some points are
incorrectly connected (this is due to the fact, that only visible points are
loaded, i.e. some points might be mssing)
Original issue reported on code.google.com by wish7code
on 9 Sep 2013 at 9:00
What steps will reproduce the problem?
1. Click on "delete" on a tracked session
What is the expected output? What do you see instead?
Confirmation message is titled "Session uploaded", which is wrong, because I
clicked on "delete" without uploading.
What version of the product are you using? On what operating system?
0.7.5 (c2cdf8f)
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 30 Sep 2013 at 11:37
With experimental builds downloaded from Google Drive, it is not always clear
which version of the source code they have been built from (which is important
when reporting issues or testing whether a particular issue has been resolved).
Suggestion: display the SHA1 ID of the last git commit in the Credits screen.
See attached tutorial (this is how I implemented it in SatStat, tested on
Eclipse, F-Droid should work but has not been tested so far).
Original issue reported on code.google.com by [email protected]
on 25 Sep 2013 at 10:51
Attachments:
What steps will reproduce the problem?
1. Press a menu button
2. Select Settings
3. Select "Download map"
What is the expected output? What do you see instead?
An item reading "United States of America". However, I saw no such item.
What version of the product are you using? On what operating system?
I'm using a 1.0 version, on the Android OS.
Please provide any additional information below.
It'd be useful to have a list of states instead of a single map for the whole
USA.
Original issue reported on code.google.com by [email protected]
on 25 Aug 2013 at 9:49
The Lat/Lon fixer script uses only the swver attribute to determine which
flavor of the lat/lon bug the file has.
However, the lat/lon bug happens on export and is therefore dependent on the
export version. Files created with one version and exported with a later one
may have a different flavor of the bug than indicated by the swver attribute.
Files that have the exportver attribute set (to 00.7.01 or higher) don't need
fixing at all (currently the fixer would swap the already correct lat/lon,
corrupting an already-intact file).
Files with swid=00.7.00 and no exportver are also easy to handle, as they will
be affected by the 00.7.00 lat/lon bug (unless someone downgraded and exported
00.7.00 data with a 00.6.0x version).
Files with swid=00.6.0x and no exportver are trickier, as they may have been
exported either with 00.6.0 or 00.7.00 and thus have either flavor of the bug.
That can be determined only by examining the file and the locations in it. If
the distance between the two positions of a scan is very long, and swapping
lat/lon in the second scan decreases it, this is a sign of the 00.7.00 bug.
An attempt at identifying such files is in my version of the DB loader script at
http://www.gitorious.org/openbmap/openbmap/source/e579c96eac30fcb78987ffa2c86c79
83c7f02f61:tools
I have taken a very crude approach to estimating distance, namely
approx_dist = sqrt(delta_lat^2 + delta_lon^2). This should work sufficiently
well outside of polar regions.
Note that my version still has a bug, as I examine only the first scan in the
file. If lat and lon are nearly equal (i.e. near a curved line going from 0°E
on the equator to the North Pole), it may mis-guess the type of bug. A better
approach would be to examine all scans and use only those where the difference
between lat and lon is above a certain threshold. E.g. if the timestamps differ
by one second, lat/lon should differ by at least 0.001 degrees, which is about
100 m on a great circle.
Original issue reported on code.google.com by [email protected]
on 11 Sep 2013 at 12:21
The radiobeacon client currently lists the sessions with the oldest on top.
When you decide to keep the sessions after upload you always have to scoll down
if you want to access the most recent sessions.
In a reverse oderdered list the most recent sessions at the top would be more
easy so select.
Original issue reported on code.google.com by [email protected]
on 7 Sep 2013 at 11:20
What steps will reproduce the problem?
1. Start logging.
2. Fire up another application (with Radiobeacon logging in the background) and
drive to work.
3. Arrive at work, return to Radiobeacon and briefly look at the map.
4. Stop logging.
5. Discover you haven't been anywhere new and delete the log.
What is the expected output? What do you see instead?
After deleting the log, Radiobeacon is forced to close.
What version of the product are you using? On what operating system?
Revision 8e96a4f883b4 on Cyanogenmod 10.1.3-RC2
Please provide any additional information below.
See also issue 27, which deals with a similar (and possibly related) kind of
crash. Looking at this logcat, though, the issue seems to be caused by
something else.
Logcat attached, the exception occurs at line 927.
Original issue reported on code.google.com by [email protected]
on 16 Sep 2013 at 9:01
Attachments:
What steps will reproduce the problem?
1. Start logging.
2. Switch to map view.
3. Start moving. The map view will not update.
4. Stop and save. The app will be extremely slow to react.
5. When you get an ANR message, tap "Wait".
6. Continue the log and go to map view.
What is the expected output? What do you see instead?
I expect the map view to update constantly, as in previous versions (since at
least 0.6.0 and up to 0.7.5). Instead, when I resume the log, I see that only
the first points have been logged and there is a huge gap up to the point where
I restarted logging.
What version of the product are you using? On what operating system?
0.7.6, as published on F-Droid. Cyanogenmod 10.1.3 on Nexus S.
Please provide any additional information below.
Earlier versions were occasionally somewhat slow to react in map view, but that
could usually be rectified by stopping and restarting the log. 0.7.6 is so bad
that I could not produce a useful log with it, and ended up downgrading to
0.7.5 in the field.
Original issue reported on code.google.com by [email protected]
on 19 Oct 2013 at 7:19
What steps will reproduce the problem?
1. Go to settings an enter some random data into username and password
2. Upload a new session
3.
What is the expected output? What do you see instead?
It should display an error about username/passwort being invalid, but upload
claims to be successful.
So we might have users that think the files have been uploaded but actually are
not when the username/password was incorrect.
What version of the product are you using? On what operating system?
0.7.5 (c2cdf8f) doanloaded from google drive on Android 2.2.2
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 2 Oct 2013 at 9:55
I have a bunch of data that I collected with earlier versions (00.6.00 to
00.6.02) of Radiobeacon, which had several issues:
* Lat/Lon bug (Issue 9)
* Versions prior to 00.7.00 apparently skipped large portions of the data on
export. When examining a batch of log files from one export, each WiFi log file
would span less than a minute of data, then there would be a gap of ~5 minutes
to the next one.
Data in the database seems complete and correct. I have seen data in the DB
that definitely didn't get exported with 00.6.02. With 00.7.00 it gets
exported, but reports the old version - so the receiving end will not know if
the file is suffering from the lat/lon bug.
Those of us who have kept their databases still have all the data we spent a
lot of time collecting, but we don't know how much of it actually made it into
OpenBmap.
I would therefore like a feature to re-upload data collected with these old
versions, with a version code that clearly identifies the file as not suffering
from the lat/lon bug so the receiving end can parse it correctly.
Original issue reported on code.google.com by [email protected]
on 3 Sep 2013 at 11:32
What steps will reproduce the problem?
1. Start logging.
2. Go to map view.
3. Drive around town for some time (~30-60 minutes).
What is the expected output? What do you see instead?
Expected output: Map scrolls and displays layers (map, WiFi catalog, track,
WiFis from current session).
This works for some time (about 30-60 minutes or 1500-3000 WiFis). At a certain
point, refreshes will disappear gradually: First no new WiFis will be shown
(though the counter on the first tab still goes up, hence new WiFis are still
being found). Then the track will not be updated - the section that has already
been drawn stays, but the arrow "detaches" itself and new movements are no
longer redrawn. Eventually the WiFi catalog and map layers stop updating and
the screen goes black as the already-updated area scrolls out of view.
Scrolling works to the end, it is just that data updates are not being handled
any more.
What version of the product are you using? On what operating system?
Afaik rcd0f69c46f5b, Cyanogenmod 10.1.3-RC2.
Please provide any additional information below.
Stopping and resuming the log will rectify this for some time, but symptoms
will reappear after an even shorter period of time. Yesterday I stopped logging
and started a new log, after which things went back to normal. Looks like some
resource isn't released properly and is exhausted eventually.
Original issue reported on code.google.com by [email protected]
on 18 Sep 2013 at 10:11
For the wifi catalog and map files add a version or date check so one can see
when a new version is available and the file could be downloadad again.
Original issue reported on code.google.com by [email protected]
on 7 Sep 2013 at 11:28
What steps will reproduce the problem?
1. Export cells, keep upload files
2. Open xml file
What is the expected output? What do you see instead?
XML files should have the cell type in plain text instead of numerical value
To be:
<gsmneighbour .. act="UMTS"/> instead of <gsmneighbour .. act="8"/>
Original issue reported on code.google.com by wish7code
on 24 Sep 2013 at 1:27
See announcement at
http://sourceforge.net/p/myposition/discussion/785485/thread/31a12799/?limit=50#
c125
Please update as soon as new version is available (probably in the course of
today). A separate announcement on new client will follow..
Original issue reported on code.google.com by wish7code
on 3 Sep 2013 at 8:30
What steps will reproduce the problem?
1. Log a WiFi with non-ANSI characters (Unicode?) characters in the SSID.
2. Export
3. Run the XML files through the database loader
What is the expected output? What do you see instead?
Some XML files end up in the krank folder. Examples attached.
What version of the product are you using? On what operating system?
00.7.05 (as well as earlier ones) on Cyanogenmod 10.1.3 (as well as RC1 and
RC2).
Please provide any additional information below.
Looking at the XML files, this seems to happen whenever the SSID of some
networks contains bytes < 32. I don't know how a WiFi would need to be set up
for that, I suspect they use a Unicode string as their SSID. Everything else
looks OK, there is also a healthy-looking hash.
Possible solutions:
- Properly sanitize the SSID field, escaping not only characters which have a
syntactic meaning in XML (such as <>"&) but also all characters <32 and
anything >=127.
- When a "strange" SSID is found, don't include it in the XML file (provide
just the
hash).
Original issue reported on code.google.com by [email protected]
on 26 Sep 2013 at 8:16
Attachments:
I tried installing the new radiobeacon client on my old Motorola Defy (MB525)
that is running Android 2.2.2
None of the apks available in Git can be installed. I only get the same error
message:
Parse Error
There is a problem parsing the package.
The old openbmap cliend worked fine on that device.
Original issue reported on code.google.com by [email protected]
on 3 Sep 2013 at 11:38
What steps will reproduce the problem?
1. Upload a session
2. as soon as the status dialog appears rotate the device
3.
What is the expected output? What do you see instead?
Upload should continue.
But: As soon as the device is rotated the dialogs dissappear.
When an upload was running this than crashes a few secons later in
https://code.google.com/p/openbmap/source/browse/android/src/org/openbmap/soapcl
ient/ExportManager.java#319
The command
mDialog.dismiss();
fails with error "View not attached to window manager"
Rotating the device seems to close other dislogs too.
For example the version check that appers when uploading while offline, or the
delete confirmation are no longer visible after rotation.
What version of the product are you using? On what operating system?
0.7.5 (c2cdf8f) doanloaded from google drive on Android 2.2.2
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 2 Oct 2013 at 1:57
What steps will reproduce the problem?
1. Collect data.
2. Save.
3. Upload.
What is the expected output? What do you see instead?
A dialog with a progress bar appears, but progress stays at 0/100 until the
dialog is dismissed.
What version of the product are you using? On what operating system?
9463714701c9 (iirc) on Cyanogenmod 10.1.3.
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 2 Oct 2013 at 10:25
What steps will reproduce the problem?
1. Upgrade from 0.7.5 to 0.7.7 (the Nov 13 version on F-Droid)
2. Start app
What is the expected output? What do you see instead?
Expected: a working app. Instead it crashes on startup. Uninstalling (wiping
all data, including the old db) and reinstalling fixes it.
What version of the product are you using? On what operating system?
0.7.7 (there are two 0.7.7 buil on F-Droid, I am using the later one dated Nov
13). OS is Cyanogenmod 10.1.3
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 17 Nov 2013 at 2:44
What steps will reproduce the problem?
1. Log cells for a while
2. Go to cell overview and analyse UMTS measurements
What is the expected output? What do you see instead?
At least PSC should be available. Instead all cells have base id = -1 and psc =
-1. (Cell id is also -1 , but this is normal for UMTS according to Android
documentation).
Tested with Nexus 4, r1dc7729faa03
Please use labels and text to provide additional information.
Original issue reported on code.google.com by wish7code
on 1 Oct 2013 at 11:02
What steps will reproduce the problem?
1. Record a session and save it
2. Export it
What is the expected output? What do you see instead?
After export completes, a notification appears that Radiobeacon has closed.
What version of the product are you using? On what operating system?
Downloaded APK from revision fdd40e50ccf1, on Cyanogenmod 10.1.3-RC1
Please provide any additional information below.
Logcat shows error:
Activity org.openbmap.activity.SessionActivity has leaked window
com.android.internal.policy.impl.PhoneWindow$DecorView
Looks like either:
- a dialog is opened twice
- the dialog is not dismissed when the activity that called it is paused or
destroyed.
See
http://stackoverflow.com/questions/12000940/android-activity-has-leaked-window-c
om-android-internal-policy-impl-phonewindow
Original issue reported on code.google.com by [email protected]
on 30 Aug 2013 at 9:14
What steps will reproduce the problem?
1. With a WiFi catalog selected, start logging and go to map view.
2. Zoom out 2 levels.
3. Watch the WiFi markers (both current session and from catalog).
What is the expected output? What do you see instead?
Markers are displayed as expected. However, they will frequently disappear,
apparently in preparation for a refresh, and may take several seconds to
reappear. Both markers for WiFis in the catalog and for current measurements
are affected.
What version of the product are you using? On what operating system?
Revision 8e96a4f883b4, Cyanogenmod 10.1.3-RC1.
Please provide any additional information below.
A high density of WiFis in the catalog seems to aggravate the situation. I have
parsed all of my past uploads and added the average position of each WiFi to
the catalog, thus areas that I frequently visit have a high density of markers.
As map coverage will increase, this is likely to become a more serious issue.
This might be an upstream bug in mapsforge.
Original issue reported on code.google.com by [email protected]
on 12 Sep 2013 at 3:07
What steps will reproduce the problem?
1. Start F-Droid client and look for Radiobeacon
What is the expected output? What do you see instead?
Expected: most recent version. Instead I see a "version 1.0" updated on August
25.
What version of the product are you using? On what operating system?
F-Droid 0.50 on Cyanogenmod 10.1.3-RC2
Please provide any additional information below.
In the F-Droid repo Radiobeacon's Update Check Mode is set to RepoManifest,
i.e. F-Droid will look at the version numbers in the manifest to determine if a
new version is available. So those numbers would need to be bumped with every
update.
Original issue reported on code.google.com by [email protected]
on 5 Sep 2013 at 8:46
What steps will reproduce the problem?
1. Enable export of GPX file.
2. Start logging.
3. Drive about town for about 40 minutes, collecting some 1800 WiFis and 35 GSM
cells. (Note that the Nexus S can retrieve only the current cell.)
4. Export.
5. Examine the GPX file and the log files produced.
What is the expected output? What do you see instead?
In a log I created today, trackpoints as well as WIFI waypoints and CELL
waypoints start appearing at 18:24 and continue until 19:09. When analyzing the
WiFi XML files, the earliest one starts at 18:57 and the latest ends at 19:09.
Cell XML files seem to span the entire period (though the serial number in the
filename is not contiguous, but that is confusing at the worst).
What version of the product are you using? On what operating system?
Revision 8e96a4f883b4, Cyanogenmod 10.1.3-RC1 on Nexus S.
Please provide any additional information below.
Vversions prior to 00.7.00 had a similar bug: they would skip a number of scans
between XML files (each log covered less than a minute and the next file would
begin at least 5 minutes after the end of the previous one). 00.7.00 introduced
the current behavior, with the first 30 of 40 minutes missing and the rest of
the log data being contiguous.
Also, when re-exporting with 00.7.00 a log that I had created (and previously
exported) with 00.6.02, I noticed that 00.7.00 produces significantly more
files for the same log than 00.6.02.
Original issue reported on code.google.com by [email protected]
on 12 Sep 2013 at 7:32
What steps will reproduce the problem?
1. Enable "Save GPX track" and "Keep upload files"
2. Record a log
3. Upload it
What is the expected output? What do you see instead?
The GPX file has timestamps that are some 600 years into the future and don't
seem to change for at least the first trackpoints (the event rate of the GPS is
normally 1 per second).
What version of the product are you using? On what operating system?
00.7.00, on Cyanogenmod 10.1.3-RC1
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 3 Sep 2013 at 11:18
What steps will reproduce the problem?
1. Collect data.
2. Save.
3. Upload.
What is the expected output? What do you see instead?
After some time, Radiobeacon FCs.
What version of the product are you using? On what operating system?
9463714701c9 (iirc) on Cyanogenmod 10.1.3.
Please provide any additional information below.
I tried uploading over a mobile data connection, which is currently throttled
to 64 kbit/s (exceeded the data limit for this month). I suspect this
contributes to the issue, as I have had this happen a few times with mobile
data but, as far as I rememebr, never with WiFi. To simulate the reduced
transfer rate, try limiting mobile data to 2G (GPRS/EDGE) networks.
Logcat is attached, it seems the crash is caused by an NPE just after upload
finishes.
Original issue reported on code.google.com by [email protected]
on 2 Oct 2013 at 10:22
Attachments:
What steps will reproduce the problem?
1. Open client
2. Start logging
What is the expected output? What do you see instead?
Expected output: Client logging
What I see: Client crashes for no apparent reason
What version of the product are you using? On what operating system?
Beta 0.6.0 (built from source, commit d8301e18b980, July 21) on Cyanogenmod
10.1.2 (Android 4.2.2)
Please provide any additional information below.
Logcat is attached.
Looking at the file, the error is apparent: the exception is caused by
WirelessLoggerService line 623. Apparently mTelephony.getNetworkOperator
returned an empty string, thus attempting to get the first 3 chars from it will
throw a StringIndexOutOfBounds exception. The empty string was possibly caused
by a dropped connection (I happened to run into this in my own project just a
few days earlier...)
A better approach would be: call mTelephonyManager.getNetworkOperator and store
it in a variable, then test if is an empty string. In that case, we can
probably return null as we don't have a network connection. (Multiple calls to
getNetworkOperator are better avoided, as in very rare and unfortunate
circumstances we may get dropped from the network just between the if statement
and the getSubstring call...)
Original issue reported on code.google.com by [email protected]
on 20 Aug 2013 at 5:51
Attachments:
What steps will reproduce the problem?
1. Start a log.
2. Switch to the map.
3. Zoom in or out.
4. Stop and save, then return to home screen.
5. After some time, start another log and switch to map view.
What is the expected output? What do you see instead?
Instead of the zoom setting selected in the previous session (which was
retained in 00.6.0x), the zoom resets itself to a very close-up zoom level.
What version of the product are you using? On what operating system?
00.7.01 on Cyanogenmod 10.1.3-RC1
Please provide any additional information below.
Versions up to 00.6.02 would preserve the zoom level across sessions; 00.7.00
and higher reset it.
Original issue reported on code.google.com by [email protected]
on 5 Sep 2013 at 1:56
What steps will reproduce the problem?
1. Start Radiobeacon
2. Rotate screen into landscape mode
3.
What is the expected output? What do you see instead?
Expected: Layout adapted to fill full screen width
Actual: Layout squeezed into leftmost two thirds of screen (see screenshot)
What version of the product are you using? On what operating system?
Rev c4f48ccb716e built from source, on Cyanogenmod 10.1.2
Please provide any additional information below.
Other layouts may have the same issue.
Original issue reported on code.google.com by [email protected]
on 23 Aug 2013 at 10:20
Attachments:
I'd like to have your software start automaticaly when I start my driving or go
out of my house.
Currently I use NFC tag program
(https://play.google.com/store/apps/details?id=com.jwsoft.nfcactionlauncher)
but I know other not NFC-binded software available.
Currently it's possible to start program in batch with other, but manual action
required to start scanning. I'd like to have a way to run program then start
new scan (or continue last scan).
there available kind of "action" in that batch taskers. Please, add some
callback action to make autostart in background mode possible - without a human
interaction at all.
Original issue reported on code.google.com by shtripok
on 5 Nov 2013 at 9:42
What steps will reproduce the problem?
1. One thing I noticed is that all the "krank" files I looked at somewhere had
picked up a WiFi with an ampersand sign in the SSID, which appears as a literal
ampersand, not escaped, in the XML files.
What is the expected output? What do you see instead?
SSID has to be sanitized before upload.
Please use labels and text to provide additional information.
Original issue reported on code.google.com by wish7code
on 29 Aug 2013 at 7:29
What steps will reproduce the problem?
1. rotate device in landscape orientation
What is the expected output? What do you see instead?
- On the session list only 1 1/2 session lines are visible. The area for
scrolling is very small. Could be optimized by placing the red map image to the
right side of the the title text lines that are above. Screen is wide enought.
- Credits screen is not scrollable so I cannot read all the content on that
screen.
What version of the product are you using? On what operating system?
Motorola Defy MB525 running Android 2.2.2
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 30 Sep 2013 at 11:49
What steps will reproduce the problem?
1. Currently in wifi detail screen wifis are sorted by their SSID
What is the expected output? What do you see instead?
Add option to sort them by time-stamp ('as-you-walked')
Please use labels and text to provide additional information.
Original issue reported on code.google.com by wish7code
on 9 Sep 2013 at 9:01
What steps will reproduce the problem?
1. Start recording
2. Export session, keeping files
3. Examine XML files produced
What is the expected output? What do you see instead?
In the gpx element of both the cell and WiFi files, the lat attribute reports
longitude and lon reports latitude. The internal DB has correct values,
corruption seems to happen on export.
What version of the product are you using? On what operating system?
Different builds of Radiobeacon, on Cyanogenmod 10.1.2 and 10.1.3-RC1
Please provide any additional information below.
A lot of bogus data has probably been collected this way (I must have added
plenty of data just off the Somali coast :-). That data can be fixed to be
usable (so we didn't collect it for nothing.)
An updated version of Radiobeacon with the issue fixed must report a different
version number in its XML output (e.g. swver="00.6.01" instead of
swver="00.6.00") to allow for identification of files affected by the bug. This
cannot be done by just looking at the data (there are some ways to do this but
they won't catch everything.)
Also, a bunch of bogus data has probably been uploaded to the server that way.
Therefore data on the server must be analyzed and anything collected with
Radiobeacon needs to get its lat and lon swapped.
Since we never know for how long someone will use a buggy version of
Radiobeacon, that code would need to stay on the server permanently and fix any
Radiobeacon 00.6.00 file that comes in.
We may be lucky as imports on the server seem to have been unavailable for a
few weeks (since about August 1), so maybe we don't have any bogus data up
yet...
Original issue reported on code.google.com by [email protected]
on 1 Sep 2013 at 10:16
What steps will reproduce the problem?
1. Start tracking and watch.
What is the expected output? What do you see instead?
Application crashes for no apparent reason.
What version of the product are you using? On what operating system?
Built from source, revision c4f48ccb716e, on Cyanogenmod 10.1.2.
Please provide any additional information below.
Analysis of the logcat reveals that the app tries to acquire a wakelock
(WirelessLoggerService.java:372) but is lacking the permission.
For a fix, merge
http://gitorious.org/openbmap/openbmap/commit/8e150a6db328fd6de79b2fd13be4458987
0648b5 (not tested as I don't have a build environment here.)
Original issue reported on code.google.com by [email protected]
on 29 Aug 2013 at 10:37
Attachments:
What steps will reproduce the problem?
1. Long-press a log from the list.
2. Select Delete
What is the expected output? What do you see instead?
I would strongly suggest a confirmation, as it is easy to tap the wrong menu
item. Generally, anything that can't be easily undone should require an extra
confirmation.
What version of the product are you using? On what operating system?
00.7.01 on Cyanogenmod 10.1.3-RC1
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 5 Sep 2013 at 1:52
What steps will reproduce the problem?
1. Enable export of GPX track.
2. Wait until 13:00.
3. Start logging.
4. Stop and upload/export.
What is the expected output? What do you see instead?
The file name of the GPX file will have the time in 12-hour format (with no
AM/PM qualification), whereas all other files use 24-hour format.
What version of the product are you using? On what operating system?
00.7.03 (apk as of Sep 15), on Cyanogenmo 10.1.3-RC2.
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 22 Sep 2013 at 3:34
What steps will reproduce the problem?
1. Start logging (with some ~60 sessions already in the DB, ~2000 WiFis each)
2. Go to map view
3. Move around and watch the update
What is the expected output? What do you see instead?
WiFis are often very slow to update. On many occasions, they don't get
displayed at all before they scroll out of view.
What version of the product are you using? On what operating system?
rcd0f69c46f5b, Cyanogenmod 10.1.3-RC2
Please provide any additional information below.
This issue may be distinct from Issue 30 (it happens much earlier). I don't
understand exactly how the code for DataHelper.loadWifisOverviewWithin() maps
to a SQL query, but I suspect it searches an unindexed column, requiring a
costly table scan. Just a shot in the dark: which table is used to look up the
session_id? It's indexed in wifis but not in positions. The query would work
either way, but looking up positions.session_id would take a lot longer...
Original issue reported on code.google.com by [email protected]
on 19 Sep 2013 at 3:40
What steps will reproduce the problem?
Log and upload, keep and examine XML file
What is the expected output? What do you see instead?
As of 00.7.00, each scan element in the WiFi log contains (in that order):
- one gps element with correct lat/lon
- a wifiap element for each wifi found
- a gps element *with lat/lon swapped*
What version of the product are you using? On what operating system?
00.7.00 (revision f32ec9f623e3)
Please provide any additional information below.
Possibly same with cell logs, haven't looked at them yet.
Original issue reported on code.google.com by [email protected]
on 4 Sep 2013 at 11:28
What steps will reproduce the problem?
1. Start monitoring.
2. After capturing a decent amount of data, save.
3. Upload.
What is the expected output? What do you see instead?
Expected: data is exported and uploaded, confirmation of successful upload at
the end.
Actual:
1. I get a warning message that my client version couldn't be verified because
either I'm offline, the server is down or my client is too old, and am asked if
I want to continue at my own risk. (See screenshot.)
2. After continuing, data is exported into a set of ~10 files and upload starts.
3. The logcat (alogcat.2013-08-23-11-26-50+0200.txt) shows errors about some
files not uploading successfully. Apparently not all the data was uploaded
successfully.
4. In another instance, I cannot upload the log at all. It exports to file but
the upload progress bar never moves. Apparently something did get uploaded, as
I see in the logcat (alogcat.2013-08-23-23-59-19+0200.txt), but I can't tell if
that's all.
What version of the product are you using? On what operating system?
Built from source, revision c4f48ccb716e, on Cyanogenmod 10.1.2.
Please provide any additional information below.
Is there a particular reason that each log is split up in about 10 files for
each object type? That makes it a lot harder to keep track of which file got
uploaded and which one didn't.
Also, at the moment the state of server data is unclear: cell data seems to be
3 weeks old (judging by the timestamps in the raw data zip file), the zip file
for raw wifi data is corrupt and can't be opened, and there is no indicator
showing when the last update took place. (I've opened tickets for that on SF:)
Original issue reported on code.google.com by [email protected]
on 23 Aug 2013 at 10:39
Attachments:
Create the heat maps (especially for cellular) not only from the active session
but also from previous sessions already uploaded to openbmap.
It's frustrating to start at zero every time after uploading data - and
openbmap doesn't offer comparable heat maps yet.
Original issue reported on code.google.com by [email protected]
on 30 Sep 2013 at 5:04
The latest versions of Radiobeacon have introduced increasingly elaborate
filtering of WiFi networks whose geographic location is expected to change
frequently. I am quite skeptical of doing this kind of filtering locally,
before uploading data, as there is quite a risk of false positives:
- Driving along a motorway one might still pick up a signal from a building in
the vicinity. Service stations come to mind... nowadays they are pretty sure to
have at least one access point, and these are perfectly stationary. Filtering
them out on the basis that they are located close to a motorway will discard
some perfectly valid data.
- MAC ranges associated with mobile devices: do we know for sure that chips
with this MAC range were never built into in stationary equipment?
- SSIDs: users can choose any SSID they want, thus finding strings such as
"iPhone", "ASUS" and the like in the SSID are indicators that this access point
MIGHT change its position, but not a sure indicator.
- Finally, there may always be the odd owner of a cabin in the woods who has
taped his old smartphone to the wall and uses it as a WiFi access point.
Despite being a mobile device by all means, its position won't change, and it
may even be the only WiFI around, making it even more valuable. Or a homebrew
WiFi router which uses a USB or PC card WiFI adapter which would be classified
as a mobile device due to its MAC.
On the other hand, there are cases which will never be caught by this approach:
- People or offices moving: they frequently take their equipment with them.
That equipment is fixed in nature, and once it has moved to a new location, it
will stay there for some time. However, after the move the database will still
report them to be at their old location, until someone scans the new location,
after which the database will have both locations.
- Fixed equipment used in temporary installations. I am wondering how many of
these I have picked up as I cycled around the Oktoberfest. They're there for
only two weeks, and who knows where these BSSIDs are going to surface next.
Conclusion: dealing with moving WiFis is a lot more complex than just comparing
against a blacklist of SSIDs and BSSIDs. It will always be a guessing game, and
the more data we base our guess on, the better it is. To get a maximum of data,
we would need to run such heuristics on the server.
As a primary input I would use the actual movements of the WiFi. A conventional
WiFi covers a range of some 100 meters around the base station, so I would
consider a WiFi to have moved whenever two subsequent positions for that WiFi
are significantly more than 200 meters apart. To establish the position of a
WiFi we should then only consider the data collected after the last move.
Additionally, we could introduce a score for each WiFi, which indicates how
reliable position estimates for this WiFi are. That score could then consider
the blacklist criteria, as well as some more:
- Partial SSID match = bad, full SSID match = very bad.
- MAC range match = bad, full MAC match = very bad.
- Mean time between moves: the longer, the better.
- Number of moves recorded: the fewer, the better.
- Time since last move: good if considerably lower than mean time between moves
Clients trying to determine a position based on nearby WiFis could then take
that score into consideration and give preference to WiFis based on two
criteria:
- Good positional stability based on the above score
- Proximity to other WiFis received at the same time: if the positions of two
WiFis in the DB are significantly more than 200 meters apart, it is a sign that
one of the two may have moved.
Original issue reported on code.google.com by [email protected]
on 27 Oct 2013 at 8:25
What steps will reproduce the problem?
What is the expected output? What do you see instead?
When clicking on Wifi Details display heatmap of network strengths on map
Please use labels and text to provide additional information.
Original issue reported on code.google.com by wish7code
on 10 Sep 2013 at 12:24
What steps will reproduce the problem?
1. Start logging.
2. Switch to Map view.
3. Stop logging.
What is the expected output? What do you see instead?
Instead of returning to the track list, Radiobeacon crashes.
What version of the product are you using? On what operating system?
Revision 8e96a4f883b4, Cyanogenmod 10.1.3-RC1
Please provide any additional information below.
Logcat attached. Apparently the crash is caused by a NullPointerException in
some GPX display-related code that runs in an AsyncTask.
Original issue reported on code.google.com by [email protected]
on 12 Sep 2013 at 5:43
What steps will reproduce the problem?
1. Download and install Radiobeacon from F-Droid
2. Go to credits
What is the expected output? What do you see instead?
"Unknown build" is reported instead of the latest commit SHA-1. Apparently the
code for setting the build string hasn't made it into the F-Droid build recipe,
or it doesn't work properly.
What version of the product are you using? On what operating system?
0.7.7 (Nov 13) from F-Droid, Cyanogenmoa 10.1.3
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 17 Nov 2013 at 2:47
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.