[SOLVED] Motion detection detects **start** of motion, but not **end** (never stops, never uploads event)

Which device has the problem? Camera
Device Model Name: HTC One M8
OS Version: Android 7.1.2
AppVersion: 3.15.1 (build 1678)


I have an HTC One M8 phone that has Alfred on it, so that it can function in camera mode. The problem I noticed is that it NEVER records any events, despite motion detection being enabled.

Upon further investigation, I can see that Alfred enters motion-detection recording fine. But it never leaves the recording mode. That is, only upon movement within the camera-recorded frame, I see a “* REC” in the top right corner of the screen. The problem is that once the motion stops, the “* REC” never goes away. Presumably because the video never stops recording, it never uploads it to the Alfred servers, and never creates a motion-detection event.

How can I troubleshoot/fix this?

Hi,

Thanks for reporting the issue!

Here are the debugging steps you can try:

  1. We noticed that one of your Camera is running a rather old version f Alfred. Please update Alfred to the latest version. Alfred runs best when all devices run the same version.
  2. Turn WiFi off and back on again on the Camera.
  3. Make sure the date and time are correct.
  4. Reboot the device.
  5. Launch Google on PC > log in to your account > choose My Account > Sign-in & Security > App with account access > Tap on Manage Apps > find Alfred, and choose REMOVE ACCESS.
    ※After disconnecting the app from google account, you will be asked to give permissions when you launch Alfred again. Grant them and you should be able to log in.

The issue should be fixed afterward.

Let us know if this helps!

1 Like

Thanks. I’ve performed all of these steps (aside from 1., as that’s for another unrelated device), and the symptoms are the same.

Any other ideas?

1 Like

Hi,

From our database, your phone HTC One M8 has been logged out of our server. Could you please try to log out and log in again?

Hi Ricardo,

It’s logged back in now. Once I showed motion in front of the camera, it showed “REC” in the top right corner. And it’s remaining that way right now.

Update: Note that I’m currently traveling. I won’t be able to leave the cam online until Thursday.

Hi,

Thank you for trying that for us!

We took a closer look at the connection logs and found that your HTC One M8 has run out of battery. Devices running on battery often enable power-saving mode and reduce WiFi reception capacity, which might cause the other features such as Motion Detection to malfunction. To ensure continuous surveillance, we suggest you keep your Camera plugged in.

What’s more, we noticed that the other Camera, Back door Pantech, is running on a rather old version of Alfred. Please try the apk link here to update Alfred on your device:
https://alfred.camera/releases/Alfred_latest_version.apk

Please keep us posted if you find out anything. Wish you have a nice trip! :slight_smile: :airplane:

1 Like

Hi Ricardo,

You’re not paying attention. The battery is irrelevant. The other device is obviously irrelevant. If you look at the original post, that describes the symptoms I’m seeing with the M8. That is, Alfred never leaves the mode where it says “REC” in the top right corner, and it doesn’t upload the captured video to the servers. (Presumably because it never stops recording)

Hey,

We are sorry that the last method didn’t help.

This is what we see from your Camera’s health check:

It seems that your Camera disconnects very often every hour! Could you please try to reinstall Alfred on this device and connect it to a different WiFi?

You’re getting distracted, Ricardo. If you don’t know what the problem is, you can just say so.

Alternatively, if you could escalate this case to an engineer who can suggest something more than all purpose best practices, when I’ve clearly explained the very specific fault that Alfred is experiencing, that’d be splendid!

1 Like

Hi,

We have asked the engineering team to take a look into your logs. It seemed that

  1. This Camera phone was not logged in on our server at all.
  2. The connection on this Camera phone was very unstable.
  3. This phone had been rooted which may cause the application to malfunction.

To solve the issue, we suggest you

  1. Reinstall Alfred
  2. Reset this phone
  3. Connect this phone to a different network

When things go wrong, sometimes it is easier to start with a clean slate. Here are some of the steps you can take to give your Alfred a fresh start.

None of those suggestions are relevant. For anybody else who is playing along at home, I’ve tracked it down to a permissions problem writing the MP4 video to storage. In a default install on this particular device, I’ll see ADB log entries like this:

01-24 13:25:24.256 4976 4976 W pool-11-thread-: type=1400 audit(0.0:31): avc: denied { write } for name="mp4" dev="mmcblk0p48" ino=1556539 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0 01-24 13:25:24.258 2303 4976 W System.err: java.io.FileNotFoundException: /storage/emulated/0/Android/data/com.ivuu/mp4/tmp264 (Permission denied) 01-24 13:25:24.258 2303 4976 W System.err: at java.io.FileOutputStream.open(Native Method) 01-24 13:25:24.258 2303 4976 W System.err: at java.io.FileOutputStream.<init>(FileOutputStream.java:221) 01-24 13:25:24.258 2303 4976 W System.err: at java.io.FileOutputStream.<init>(FileOutputStream.java:108) 01-24 13:25:24.258 2303 4976 W System.err: at com.ivuu.camera.f.b(AlfredSource:330) 01-24 13:25:24.258 2303 4976 W System.err: at com.ivuu.camera.f.a(AlfredSource:276) 01-24 13:25:24.258 2303 4976 W System.err: at com.my.android.c.b(AlfredSource:788) 01-24 13:25:24.258 2303 4976 W System.err: at com.my.android.c.a(AlfredSource:53) 01-24 13:25:24.258 2303 4976 W System.err: at com.my.android.c$1.run(AlfredSource:747) 01-24 13:25:24.258 2303 4976 W System.err: at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133) 01-24 13:25:24.258 2303 4976 W System.err: at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607) 01-24 13:25:24.258 2303 4976 W System.err: at java.lang.Thread.run(Thread.java:761)

This is evidence that Alfred isn’t successfully writing to the “mp4” directory where it keeps recordings. As a result of this, the Alfred app gets confused and the symptoms are what I describe.

I’ve tried a number of things to get Alfred to successfully write its recordings, including:

  • Enable “Force allow apps on external” in Developer Options
  • Enable “Storage” in “App permissions” for Alfred. (oddly, this isn’t done by default)
  • chmod a+w /data/media/0/Android/data/com.ivuu/mp4
  • Manually add both WRITE_MEDIA_STORAGE and STORAGE_INTERNAL to Alfred via editing /data/system/packages.xml

Strangely, none of those appear to let Alfred save recordings on this particular m8 phone. One thing that does work is to disable SELinux via # setenforce 0. After this change, the relevant log lines:

01-24 13:26:11.146 7133 7133 I Thread-90: type=1400 audit(0.0:50): avc: denied { getattr } for path="/data/media/0/Android/data/com.ivuu/mp4/tmpmp41548354212974" dev="mmcblk0p48" ino=1556543 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0:c512,c768 tclass=file permissive=1 01-24 13:26:11.150 7133 7133 I Thread-90: type=1400 audit(0.0:51): avc: denied { write } for name="mp4" dev="mmcblk0p48" ino=1556539 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1 01-24 13:26:11.150 7133 7133 I Thread-90: type=1400 audit(0.0:52): avc: denied { remove_name } for name="tmpmp41548354212974" dev="mmcblk0p48" ino=1556543 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=1 01-24 13:26:11.150 7133 7133 I Thread-90: type=1400 audit(0.0:53): avc: denied { unlink } for name="tmpmp41548354212974" dev="mmcblk0p48" ino=1556543 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0:c512,c768 tclass=file permissive=1 01-24 13:26:11.156 7133 7133 I Thread-90: type=1400 audit(0.0:54): avc: denied { write } for name="pic" dev="mmcblk0p48" ino=1556540 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0:c512,c768 tclass=dir permissive=1 01-24 13:26:11.156 7133 7133 I Thread-90: type=1400 audit(0.0:55): avc: denied { remove_name } for name=".nomedia" dev="mmcblk0p48" ino=1556541 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0:c512,c768 tclass=dir permissive=1

After disabling SELinux enforcement, Alfred behaves normally, detecting movement and uploading the clips to the server as expected. But I don’t think that this is a viable workaround. But it at least gives some insight into the cause of Alfred not exiting recording mode. Why this M8, which runs LineageOS, is different than my other Android devices is beyond me…

I finally figured out how to fix this:

  1. Install the latest TWRP recovery (I used 3.2.3-1)
  2. Boot into TWRP and select Advanced -> “Fix Contexts”

This fixed the SELinux permissions in a way to allow Alfred to work.

So in summary, the symptoms I saw were not a flaw in Alfred. Alfred wasn’t working because the underlying Android OS was not behaving properly. I suppose ideally Alfred could have conveyed some more information about what the problem was under the hood at least. Though it’s not clear how common this sort of problem could actually be in the wild. If anything, victims might be able to web search to end up here.

1 Like

@anontab2016 I don’t think that this is going to be too bigger issue as judging by the average questions and comments within the pages of this forum I doubt if we have many fellow members unlocking their bootloader, installing a custom recovery and ROM and then achieving root. Most users of Alfred seem to fall into the category of click and go which is why I worry about Alfreds additional add on plans. I always agree with the keep it simple, stupid theory. Once users start setting schedules and masks ect. something is going to be missed. Anyways congratulations on your excellent diagnostics Sir. I hope you stay with us at this forum with your knowledge.
Regards

2 Likes