Tuesday, 22 July 2014

SECuRET LiveStream, BabyCam Monitor and Java Security Settings


Some users will likely be experiencing problems using both SECuRET LiveStream and BabyCam Monitor due to the latest security features of Java. Both SECuRET LiveStream and BabyCam Monitor use Java Applets running inside the web browser to provide the video and audio feeds directly from your Android device. When you try and access the web page served up from either app, you will now likely see this popup error message:


The problem is that the apps act like mini web servers running on your Android device, i.e. you aren't connecting to a remote web server on the internet, but rather a local web server on your Android device. Java does not recognise the location of your local web server and is presented with no certificate to verify it, and now that Java is more strict in the latest versions, it blocks the app from running.

The way around this is to add the web address given to you by either SECuRET LiveStream or BabyCam Monitor to a list of security exceptions in the Java Settings. This implies that you trust the source of the Java Applet as you know the source is a local web server on your Android device as part of either SECuRET LiveStream or BabyCam Monitor.

In Windows, the settings can be found by going to the Windows Control Panel > Java > Security tab and then add the web address given to you by either SECuRET LiveStream or BabyCam Monitor to the Exception Site List, e.g. something that looks like http://192.168.0.3:8000.

You can also set the Java Security Level slider (on the same Security tab as the Exception Site List) down to medium and this should have the same effect, but may be less secure when browsing the regular internet.

Then you should be able to initialise either SECuRET LiveStream or BabyCam Monitor and have them work as expected.

Please let me know if you need more assistance or have any concerns with performing this workaround.

Friday, 1 November 2013

Emails Not Sending in SECuRET SpyCam: SMTP Errors


Common errors when trying to send automatic emails of your photo captures in SECuRET SpyCam are "SMTP error 535" or "SMTP error 534". You will receive notification of this error within the app via a popup message stating the "Capture could NOT be emailed!" along with the error details.

SMTP error 535 means your login credentials are incorrect, so please ensure you have entered the correct details into the app settings. The settings you must verify are in Settings > General > Photo Settings > Email, and then in the Login section please enter you full Gmail address and case sensitive password.

SMTP error 534 is supposed to mean the message is too big, however I have seen this fixed in two ways not relating to file size. First is to double check your login credentials as described above for SMTP error 535. The other is that you may have 2 factor authentication enabled on your Google Account and the protocol within the app used to send the email is not capable of handling that, hence you may need to disable it on your Google Account if you wish to use this functionality. You may find that is what also causes SMTP error 535 in some cases.

Essentially, if you receive either of these SMTP error messages, please double check you Gmail login credentials and ensure you are not using 2 factor authentication. If you receive any other SMTP errors, simply perform a Google search ("SMTP error nnn") for that particular error code.

Wednesday, 29 May 2013

A Break From Active Development


After almost 4 years of developing my Android applications, I am now taking a break from active development of WiFi File Explorer, SECuRET & BabyCam. I'll still be making critical bug fixes as they arise as well as any other necessary maintenance with new Android releases and techniques, but I will not be implementing any new features or requests from users.

I still welcome ideas being sent to me and I keep a to-do list for when/if I do return to actively developing my applications. As more and more people request the same thing, features change in priority on that to-do list until it becomes immediately apparent what I should do next. So thanks for all your ideas that I still frequently receive and they all get duly noted, but as I alluded to, there is no guarantee as to when/if that feature will get implemented.

After spending all that free time developing my applications over the last 4 years, it is now the right time to take a step back, reflect on what I have achieved and enjoy the fruits of my labour. Hopefully I will return to those applications in due time, but for now I am happy concentrating on other projects and spending more time with family and friends!

Monday, 13 May 2013

Free Space - Internal Vs. External Storage


WiFi File Explorer displays a number of statistics in the top right corner of its web UI; battery, WiFi signal and free space. The free space on the device is shown via two filled bars representing the external and internal storage, as well as the actual numerical figures underneath.

The confusion lies in what these actually mean; what is the external and internal storage - flash? SD card? Internal memory? Connected drives? Well, that differs depending on the device and the version of Android, so it's quite a hard question to answer. Basically, those free space statistics are retrieved from the Android OS using a couple of lines of code that are supposed to give the "external" and "internal" storage for the system. Because each Android device may implement its storage solution in a different way, depending on the device manufacturer and version of Android, you may find that what the Android OS thinks of as being external, you may think of as internal, or vice versa. Or it may show the same statistics for external and internal. Or you may not have external, yet it tells you that you do. Confusing, huh? I know... my Nexus 4 does not have what I consider to be external storage, i.e. an SD card, yet it tells me that I have 5.67GB of internal storage AND 5.67GB of external storage.

What's even more confusing is that on my old Nexus S and many other devices I have owned over the years, it would give exactly the statistics I would have expected for external and internal storage. The moral of the story is that those couple of lines of code to retrieve these statistics work on some devices, but don't make an awful lot of sense on others. And as far as I know, because of the many different ways storage is implemented across all Android devices, there is no other universal way that should give accurate readings for external and internal storage.

So it's that old Android case of "works on some, but not on all, and some is better than none". If any developers know of a better way of retrieving these statistics, please get in contact with me and let me know.

Friday, 15 March 2013

The Ping Test


A number of my applications (WiFi File Explorer, SECuRET LiveStream and BabyCam Monitor) are all web server based applications (i.e. your Android device acts as a mini web server).  They start up and then prompt you to enter a web address into a web browser on a device on the same network to access the web interface.  Simple enough, but a common problem users email be about is not being able to connect to the application when they actually go to enter the address they have been given.

There are a number of reasons this can happen, and I have already listed out most of those at an article I wrote here at this link.  It's a very useful article and I'd urge you to read it, especially since there are many useful comments from users that have solved the problem in different ways.  However, it's over two years old now, and since writing it I have become better at recognising the cause of problem and finding a much quicker way for you to diagnose it.  So before reading the article linked to above, please read the following...

By far and away, the most common cause of not being able to contact the app when entering the address is simply that your network/router is not configured correctly.  The easy way to determine this is to perform a ping test and the results of this will confirm that or not.  If you don't now how to ping, then read this article.  So just ping the IP address of your Android device from your PC (search Google for how to find out your particular Android device's IP address) and if you don't get a reply, then we can say for certain that your network is not allowing communications between your PC and Android device.  And because these apps all use your local network, this will prevent them from being accessed... so not the apps fault at all!!  If you do get a reply, then your network appears to be OK, and so go back to reading the original article I mentioned in the previous paragraph.

More than likely though, you didn't get a reply in your ping test and the devices can't communicate on your particular network.  In that case, I am afraid it is up to you to figure out what is up with your router/network.  I can't really support you in this case because I have no idea what your network is set up for or what your particular use case for it is, not to mention the many different types of routers on the market than I am not familiar with (I usually forget how to use even my own router!), so I am in no position to offer expert support.  I can however say that a lot of users (more than you probably think) "fix" the issue simply by switching the router off and back on again (I know, right!).  Another common cause can be that you have "Wireless Isolation" (or something named similarly - basically, preventing wireless devices from communicating) enabled on your router, so check that option on your router settings.  Beyond that, I am sure a quick search on Google ("can't ping ip address") will yield enough results to help solve your network configuration problem (that's what I would do anyway).

Hopefully I have provided enough information between this article and the article here for you to be able to support yourself on this one, but if you are still stuck after that or your just need help understanding anything I have already written about, then please feel free to contact me again and I'll try to give you some personal support as soon as I am available.

Wednesday, 13 March 2013

There Are Just Some Things I Can't Help You With


If you are reading this, then more than likely I have just sent you here after you have emailed me for some support.  Now, I hope you don't think I am being rude or lazy, but sometimes I am just not in a position to help with your request - it's not that I don't want to help you, it's just that in this situation, I can't.

More often than not, the reason I can't help you is because you have asked about something to do with the actual purchasing and downloading of one of my applications from one of the various app stores they are available from.  So you could be having trouble completing the order, or maybe you are getting an error from the app store when you try and download, or perhaps you are being told the app store can't verify your purchase.  The fact is that I am an independent developer and so can only support my own applications; I don't work for any of the app stores and so I don't know how any of those systems work from a users point of view.  Therefore, I can't offer support for them and can only suggest to you to contact the support team for that particular app store.

There is one small exception in that for the Google Play Store, if you provide me with an order number, I can actually see the status of your order (and refund it if necessary).  So if you'd like me to do that then I am more than happy to; just email me with the order number and I'll see if I can help you out.  But also remember that you can see the information you need yourself simply by logging into your Google Wallet account online and looking at your transaction history.  I am afraid I can't offer the same service for any of the other app stores because I just don't have access to that information on an individual order basis.

Another typical reason you may have ended up here is that you are asking questions relating to the general operation of a particular device.  I only have a handful of Android devices myself, so although I may be able to answer a few questions, you are far better off contacting the manufacturer's support team for that particular device.

So sorry I can't be of more help to you in this situation, but hopefully this has prompted you to contact the support team that can resolve your issue in the quickest way possible.  Of course, you may still think I can help you, so please don't hesitate to contact me again and I'll see what I can do.  But just remember, I can only support my own applications... I may occasionally be able to help beyond that in some situations where my applications are a factor, but you are most likely reading this blog post because I already think I am not best person to contact for your issue.

The Dreaded "Server (IO) Error"


Occasionally, there are times when trying to upload a file using WiFi File Explorer PRO that the file won't upload.  If your eyes are in the right place of the screen (the upload section, on the box representing the file to be uploaded) and you are quick enough (before the page refreshes) you may just see the words "Server (IO) Error" and wonder just what on earth that means.

Well, it's a bit of a generic error and as you can see, not very descriptive on its own.  But luckily it only actually occurs in a handful of situations, and after reading descriptions of those below, you should be able to quickly work out which one refers to what you are doing.

So here are the ways in which you can cause the "Server (IO) Error":

1. You are attempting to upload to a read-only area of storage.  Remember that not everywhere you can view on your Android device's storage can be written to (even if you are rooted, as WiFi File Explorer does not support root operations).  If you are unsure of what areas are read-only or not, then I suggest searching the internet for information relating to your device as it can vary greatly.  Also, remember some SD cards have a read-only physical slider on the actual SD card itself and this may have been accidentally (or purposefully) switched on.

2. Your storage is full, or, you would fill it if you upload that particular file.  Not much to explain here other than to check how much storage you are using and delete as necessary if that is the issue.

3. You are uploading a file bigger than 4GB.  I am afraid that is the limit that the Flash plugin used to upload the files is able to handle (perhaps linked to the limit of a FAT32 based file system).

4. Your storage is not correctly mounted.  This doesn't just mean physically mounted correctly into the device, but also logically by the Android OS.  Switching the device off and back on again should ensure it is logically mounted again correctly, but it could also be another app doing something strange to it.

The only other time someone has reported this error, but unrelated to the scenarios above, was to do with his particular Flash installation.  He could get it working on one PC, but not the other.  However, this is purely anecdotal and I can't confirm the validity of his claim that it was to do with the Flash install.  It may be worth bearing in mind though if you can't link the error to any of the descriptions above, so perhaps try updating to the latest version of Flash.

And as always, if you still have trouble after reading this, then please feel free to email me for personal support.

Update: After updating your device to Android 4.4 (KitKat), you may find that you are no longer able to perform some functionality on the external SD card that you were previously.  This is because some device manufacturers have not changed the default behavior of Android 4.4 which is to not allow write operations to the external SD card (see point 1 above).  This "bug" is particularly evident on Samsung devices and I have no information on whether Samsung plan to address it in future Android updates or not.

Wednesday, 16 January 2013

SECuRET SpyCam Video Recording Length


One of the settings that is often questioned by users of SECuRET SpyCam is the Video Recording Length.  It specifies the length of the time you want to record for when you are capturing videos based on a motion trigger occurring.  So for example, the app detects a motion and then it will capture a video for 5 minutes, at which point it will stop and then resume to processing and detecting motion.

The first thing I should point out is why it has to be based on a length of time at all; why can't it just stop recording a video when the motion has stopped?  Well, the reason for that is simply that it is not possible to perform the motion processing on each individual frame coming in from the camera at the same time as video is recording - the two events are mutually exclusive.  So we can't detect when motion has stopped; instead we have to record for the length of time that we think we are going to expect, based on the scene you are detecting motion in.

The range of time you can set the Video Recording Length to be is from 5 seconds to 10 minutes.  So then why is the maximum only 10 minutes - that isn't as long as I want to record for?  Well, firstly there has to be a maximum of some kind, otherwise if it were unlimited there is potential for major problems.  Imagine if you had the ability to set the recording time to infinite, i.e. keep going until there is no storage left.  Sounds like a good idea on paper, but what if you intended to monitor for a very long time (a couple of days maybe) and in the first few seconds of monitoring someone just walked past the camera for a couple of seconds and then nothing else happened   Nothing at all for the next 24 hours.  What are you going to get?  A video of someone walking across the screen and then, depending on how much storage you had left, a really long, boring video of a completely still and uninteresting scene.  Then, when something does actually happen of interest on the second day, you have no storage left to record that all important piece of motion you were trying to detect.

So, the maximum of 10 minutes is there as it feels like a sensible amount of time to expect motion to be occurring or not.  In one video, at best you get 10 minutes of constant motion or at worst you only get 9 minutes and 59 seconds of stillness.  But the beauty of it is that after 10 minutes, if motion is still occurring in your scene, then it will trigger again and start recording another video, and another after that and so on, and so on.  In practice then, the Video Recording Length settings is of little consequence as it will essentially keep recording video for as long as motion is occurring and there is ample storage left - as long as motion is occurring  you will be sure to capture it (albeit over multiple video files).

I hope that clears up the confusion over the limit of the Video Recording Length and why it even exists in the first place.  It basically protects the amount of storage you are using in the most efficient way possible and ensures you don't miss a thing - you can record as much motion as possible and as little stillness as possible.