search

transistorsoft / cordova-background-geolocation-lt

The most sophisticated background location-tracking & geofencing module with battery-conscious motion-detection intelligence for iOS and Android.
http://www.transistorsoft.com/shop/products/cordova-background-geolocation
Other
655 stars 277 forks source link

iOS does not detect a transition out of the "stationary geofence" #1129

Closed Nikos-kun closed 3 years ago

Nikos-kun commented 4 years ago

786 Your Environment

Expected Behavior

I expect my iPhone devices (6S and 11) to start recording geolocations after they get out of the 200-meter 'stationary geofence'. Save them (geoLocations) to the embedded SQL-Lite of the plug-in and when I'm again connected to a WiFi, send it to my backend.

Actual Behavior

Even though I make sure I give the 'ALWAYS' location access rights to my app, after I close the app and it goes into the 'stationary geofence' (location service off), it doesn't always start the location service.

Sometimes I must do 360m, other times 400m or 640m. There is no consistency on that. Sometimes it never goes on again even after multiple kilometers. This past week, it never went on no matter how many kilometers I did.

I have 'debug: true' so I can see its behaviour while I'm walking or while I'm in a vehicle.

The only debug notification I get when they wont start is: Authorization status changed 3.

I always have WiFi on but mobile data (internet) off.

I have tried both: desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_NAVIGATION and desiredAccuracy: BackgroundGeolocation.DESIRED_ACCURACY_HIGH

I have tried both: preventSuspend: true & false

Android devices always work correctly. I read on your wiki that Android makes use of the ActivityRecognitionApi or the later ActivityRecognitionClient.

I'm trying to pin-point the problem.

I'm wondering if the problem is that after I'm out of the 'stationary geofence', the iPhone sensors can't detect a transition as easy or as efficiently as the Android devices.

Or maybe something is not right with Apple's motionManager.

Since the same code works sometimes, I'm guessing it is not a code problem. Can this be a hardware problem? But the iPhone 11 is brand new. How can it have the same behaviour with the 6S?

I can't see how this can be a code problem.

What else can stop the device from detecting a transition?

Steps to Reproduce

  1. Install the app.
  2. Give the necessary rights for push notifications and locations.
  3. Make sure I lock and unlock the device so that I would be prompted to give full (ALWAYS) access of the locations to my app.
  4. Close my app.
  5. Make sure WiFi is on even though mobile data is off.
  6. Wait for some minutes (example->stopTimeout: 2) while my app is still on a desk. Until it gets in the stationary mode and the location service is off. This only applies when preventSuspend: false.
  7. Then I take the device/s with me and start walking.
  8. I do 200, 300, 400, 500, 600 meters and some times the location service never starts. Even when it starts it is like in 360 meters.

The last week it never got on after I went out of the stationary geofence.

Nikos-kun commented 4 years ago

Update

I used the exact same build in both devices today.

Both devices had WiFi on! Both devices had the same spot for their last geolocation.

IPhone 11 also had its mobile data on. While iPhone 6s only had WiFi on.

  1. I'm starting walking.
  2. Iphone 6s, indeed started location service and detected movement. Thus, started recording in about 210 meters from my last geolocation at the stationary state point! Iphone 11 showed me the "Authorization status changed 3" debug-notification in about 250 meters from my starting point and never started the location service.
  3. I had to manually open the app in order for it to start. After I manually opened it everything was normal. The thing is it never started on its own.

What kept the app or the plug in to start the location service?

On Jul 10, 2017 You said to #394

"It's up to iOS to awaken sleeping app and is dependent upon the nature of the network environment."

What did you mean the nature of the network environment?

christocracy commented 4 years ago

What did you mean the nature of the network environment?

Presence of Wifi signals / spacing of cell towers.

So would you like me to field-test my iPhone 11 with Cellular data disabled?

christocracy commented 4 years ago

First-of-all, Wifi is required for geofencing on both iOS / Android.

While iPhone 6s only had WiFi on.

I always test my iPhone devices with Wifi + Data enabled. I haven't had a problem with iOS devices trigging in over 6 years.

I suggest you restart your iPhone 11.

christocracy commented 4 years ago

Also, I suggest cloning the SampleApp repo and building that onto your iOS devices. This will run demonstrate the plugin performance in isolation of you application code.

Nikos-kun commented 4 years ago

I always test my iPhone devices with Wifi + Data enabled. I haven't had a problem with iOS devices trigging in over 6 years.

I see, you are testing with mobile data on. However, correct me if I'm wrong, it is not necessary for the mobile data to be on in order for the plugin to start Location Service, right?

The only difference is that they will be stored in the embedded sql_Lite and will be uploaded only after connecting to the internet. Am I right?

christocracy commented 4 years ago

it is not necessary for the mobile data to be on in order for the plugin to start Location Service, right?

No. It doesn't matter. I often turn off Cellular data while on vacation. It doesn't cause a problem.

Nikos-kun commented 4 years ago

What happens after I see the debug-notification: "Authorization status changed 3"

From my understanding, it means that the plugin recognizes that I have given all access to location (ALWAYS).

What is the next step programmaticly? What must happen after this step?

Again I'm trying to pin-point from where the problem emerges. Is it an Apple thing? Is it the plugin? Is it the spacing of the cell towers? Is it something in my code?

christocracy commented 4 years ago

I just took a short bike-ride with my iPhone 11 @ 13.4.1. Cellular-data is enabled, of course.

Are you sure your app is executing BackgroundGeolocation.ready — no matter what — each time your app is booted?

Nikos-kun commented 4 years ago

Yes, because while debug-mode is enabled, I can see that everytime I open the app, the plug in immediately opens and I start seeing debug-notifications like: "Location service is on", "moving "or "stationary"....

New Update:

My iPhone 6s again recorded everything perfectly while mobile data were off. IPhone 11 again did not open. Even though they had the exact same build. I literally builded the one device after the other again today.

Can it be another configuration that has to do with the device and not with the plug in?

I'll keep searching for a solution.

christocracy commented 4 years ago

Big bike ride on iPhone 11, mobile-data: OFF:

christocracy commented 4 years ago

I suggest you reboot your iPhone 11.

Nikos-kun commented 4 years ago

Update:

Rebooting didn't solve the problem.

Your SampleApp seems to work normally: http://tracker.transistorsoft.com/interad?device=16218&end=2020-5-19&start=2020-5-19

Yesterday's results: 4 out of 5 times the iPhone 6s worked succesfully. 1 out of 5 times the iPhone 11 worked succesfully.

  1. I installed the sampleApp on iPhone 11.
  2. I go for a walk and waiting to see if both SampleApp and my app would start Location Service.
  3. SampleApp worked everytime except one and my app worked only one time. When my app worked, I saw that both my app and the sampleApp opened the location service simultaneously.

All the above are happening with the same build on my app! The only thing I'm changing when I am rebuilding nowadays is the: 'debug: true/false' and the 'stopTimeout' which I raised, hoping it wont go off.

Why is it that some times it opens up and others not? I don't get it.

I'm 100% sure I execute BackgroundGeolocation.ready every time my app opens and it actually uploads one geolocation everytime it opens.

The problem:

The problem is, if it's in its 'stationary state' it won't always open Location Service. And this happens with the same build. Some times it will work, some others it won't.

Can it be an iOS 13.4.1 memory leak issue that kills background apps? Can it be something which I miss in the XCode settings?

Here you say:

iOS will re-awaken your app only when the device exits this "stationary geofence". NOTE: Exiting the stationary-geofence typically requires ~200 meters of movement. Even if you configure a stationaryRadius: 25, iOS will still require the device to move ~200 meters.

https://github.com/transistorsoft/cordova-background-geolocation-lt/wiki/Philosophy-of-Operation#ios-stationary-state

You say speciffically "iOS will re-awaken your app".

What stops iOS from re-awakening my app? Is there something like a hook? On what basis does the iOS choose to re-awaken or not my app?

Nikos-kun commented 3 years ago

Update:

Everything remains the same as in the above comment of mine. Can you you tell me more? @christocracy

christocracy commented 3 years ago

Make sure your app is always calling #ready when app boots, no matter what. Regardless of anything.

DomzF commented 3 years ago

@Nikos-kun Where are you located?

I carry multiple devices constantly but I, like @christocracy, am located in a majour metropolitan area. I cannot reproduce the issue, however I am now seeing complaints from multiple users (mainly on iPhone 11 and 11 pro) outside of the majour american metros.

We have tried disabling the new COVID tracking software, rebooting, uninstalling and reinstalling...

Nikos-kun commented 3 years ago

I'm located in Athens, Greece, Europe. We are in the capital city of Greece. So it's urban like.

Update:

Sometimes both iphones 6S and 11 play well and other times they don't. Usually it is the 11 that does not play.

christocracy commented 3 years ago

My SampleApp running on iPhone 11 Pro never fails to track me every day, anywhere I go.

Nikos-kun commented 3 years ago

The problem must stem from iOS not letting the plugin run again.

The last message I see when I have debug on is this: "Authorization status changed 3" and then nothing... It stops there.

Does this tell you something @christocracy ? Something that can help me figure out what happens?

christocracy commented 3 years ago

Does this tell you something

No. Status 3 = AUTHORIZATION_STATUS_ALWAYS. That's expected.

Nikos-kun commented 3 years ago

Yes, I mean what is the exact next step after this message?

What must happen next that is not happening?

christocracy commented 3 years ago

Are you aware of the Changes to iOS 13 Location Authorization that I blogged about last year?

Nikos-kun commented 3 years ago

Yes, I'm always going into settings and mannualy give it the "Allow Always" authorization. Just to be sure.

christocracy commented 3 years ago

Are you ensuring that BackgroundGeolocation.ready is called each time your app launches, no matter what?

Nikos-kun commented 3 years ago

Yes, always.

christocracy commented 3 years ago

Previously you said the SampleApp works and your own app doesn't. It must be a problem in your own application code. I would be observing the Javascript console for Javascript errors in your application code.

DomzF commented 3 years ago

@Nikos-kun if you can reproduce the issue or find out the cause can you please update this thread? I cannot reproduce on my end but I just had another user report this problem today.

Nikos-kun commented 3 years ago

@christocracy But I also said that with the same build sometimes it works. With out changing my js code. Sometimes it works and some doesn't.

@DomzF yes of course. Can you point me to that, other user, problem. Maybe if I read it, I can make something out of it...

christocracy commented 3 years ago

@DomzF If your users are reporting this, I'd be asking them to check iOS Settings->Privacy->Location Services->Your App.

"Which value is checked?"

DomzF commented 3 years ago

@christocracy She is actually one of our employees so this is a good example. She has her phone configured with location and motion, has no other tracking apps installed, and does not have power saving on.

She uses an iPhone 8 running iOS 13.5 (my primary phone is also an 8, however I use beta 13.6). Her daughter was in the car running the plugin on an iphone 11 pro using 13.5 also. They are located in an American city with roughly 1 million in the metro (there is substantial cellular infrastructure).

They went from home to the bank and this trip was captured on both devices. They then returned home and the trip was not captured on the iPhone 8.

Both users have the same configuration with scheduling enabled. Here are the timestamps of data from the 8:

image

There is a big blank between 13:11 and 13:28, unfortunately since these are production versions of the app the only logs I could pull are at warning level. Here is the associated output:

2020-06-13 12:58:03.979 ⚠️-[TSHttpService flush:failure:] Busy with previous request

2020-06-13 13:07:55.365 ⚠️-[TSHttpService flush:] Busy with previous request

2020-06-13 13:09:53.413 ⚠️-[TSHttpService flush:] Busy with previous request

2020-06-13 13:09:54.136 ⚠️-[TSHttpService flush:] Busy with previous request

2020-06-13 13:28:22.023 ⚠️-[TSHttpService flush:] Busy with previous request

2020-06-13 13:28:22.161 ⚠️-[TSHttpService flush:] Busy with previous request

2020-06-13 13:28:22.377 ⚠️-[TSHttpService flush:] Busy with previous request

Sorry if this is not the information you require.

christocracy commented 3 years ago

2020-06-13 13:28:22.377 ⚠️-[TSHttpService flush:] Busy with previous request

These are not unusual. It simply means the plugin is already performing an HTTP request when another location was recorded. The plugin's HTTP service uploads synchronously. When each HTTP request is complete, the plugin asks "are there any records in the database?", if yes, it will keep selecting records and performing http requests until the database is empty.

DomzF commented 3 years ago

@christocracy So, I just got some extra information...

The missed tracking wasn't supposed to be between 13:15 and 13:30 like I thought, it was supposed to be between 13:00 and 13:10.

The iPhone 11 has many data points in this time, the 8 does not. The data points of the 8 are all flagged with is_moving = false. That says to me at least in this case, it is something wrong with the activity recognition on the 8.

christocracy commented 3 years ago

is_moving has nothing to do with motion API. It's merely a flag representing whether the plugin is in the moving or stationary state. When the device moves about 200 meters from last known stationary position, where the device exits the plugin's "stationary geofence", is_moving is set to true. When the device becomes stationary, is_moving is set to false.

You can manually set this flag by executing BackgroundGeolocation.changePace(true) / BackgroundGeolocation.changePace(false).

DomzF commented 3 years ago

Yes thank you, I was mistaken. I was also looking at activity which for some reason is "still" despite her moving in a car.

12:58:02 is_moving true, activity still 12:58:20 is_moving true, activity still 13:05:55 is_moving false, activity still 13:06:01 is_moving false, activity still 13:07:38 is_moving false, activity still 13:08:01 is_moving true, activity still

During this time frame every location from the iPhone 11 pro is flagged with is_moving true and activity "in_vehicle".

There are 91 locations from the 11 and 6 from the 8.

image

edit

If I were to manually change pace, after detecting a significant change in location, do you think that would increase the number of locations captured?

For example in this scenario once I saw she was 1 mile away from the bank, if I changePace(true)
might that have captured more data? If I manually change pace do I need to do any cleanup or will the plugin manage that as normal?

christocracy commented 3 years ago

If the iOS motion API reports still to the plugin, the plugin will initiate the stopTimeout timer. When the stopTimeout timer times out, the plugin will essentially call changePace(false) upon itself.

You're free to call changePace as desired. No "cleanup" is necessary.

DomzF commented 3 years ago

@christocracy thanks for the information, much appreciated.

I have one more question regarding calling setConfig repeatedly, if there is a more appropriate place to ask I'll delete this part of the comment.

If I call setConfig with x = 10 and reset = true, then call setConfig with x = 11 and reset = false, => x = 10

If I call setConfig with x = 10 and reset = true, then call setConfig with x = 11 and reset = false, then call setConfig with x = 13 and reset = true => does x = 13 ? or does reset have an effect on subsequent calls, so x = 10 ?

PS im jealous of your proximity to cafe olimpico, I go there everytime im in mtl.

edit I mean setConfig

christocracy commented 3 years ago

You probably don't need to worry about reset. I only implemented that for my own testeing with the SampleApp, which has a settings screen that is used to control the config supplied to ready.

The default of reset is false.

setConfig doesn't respect reset.

Yes, Cafe Olympico is blocks away from me. I'm even closer now that I just moved.

DomzF commented 3 years ago

@christocracy @Nikos-kun I'm still having inconsistencies with the tracker and cannot for the life of me figure out why. I have experienced 0 issues on my iPhone 8, but now I've had issues on my Samsung S8 and S9, as well as my iPhone 11.

I ran 4 phones today, all using a fresh installation of my app. They all have 3.6.2 of your plugin. These are ionic apps and setup at least somewhat similarly to the sample app.

I have a wrapper class to interact with the plugin, and this is injected into my app.component.ts. In the constructor for the wrapper class I have:

this.platform.ready().then(() => {
      this.log.info("[TransistorSoftTracker.ts] constructor");

      if (!this.platform.is('cordova')) {
        this.log.info('[TransistorSoftTracker.ts] returning, platform is not cordova')
          return;
      }

      this.registerResumeSubscription();
      this.registerGeolocationEventHandlers();

      BackgroundGeolocation.ready({
        reset: false
      }).then((state: State) => {
        this.log.info("[TransistorSoftTracker.ts] constructor ready() result", state);
      }).catch((error: any) => {
        this.log.error("[TransistorSoftTracker.ts] constructor ready() result", error);
      // @ts-ignore
      }).then(() => {
        this.boot();
      });
    });

The docs say reset defaults to true that is why I put it there.

The boot method configures the plugin with a server supplied config. That is why we call ready with reset false. I learned here we need to ensure ready is called no matter what, regardless of authorization status, etc. Should I pull in the config, and if that call fails fallback to local storage?

Here is the server supplied config:

{"debug": false, "autoSync": true, "batchSync": true, "httpTimeout": 30000, "startOnBoot": true, "stopTimeout": 7, "maxBatchSize": 100, "distanceFilter": 10, "preventSuspend": false, "stopOnTerminate": false, "maxDaysToPersist": 2, "stationaryRadius": 25, "stopOnStationary": false, "autoSyncThreshold": 5, "foregroundService": true, "heartbeatInterval": 60, "stopDetectionDelay": 3, "maxRecordsToPersist": 4000, "forceReloadOnHeartbeat": true, "allowIdenticalLocations": false, "useSignificantChangesOnly": false, "logLevel": 5, "elasticityMultiplier":2, "enableTimestampMeta":true, "scheduleUseAlarmManager": true}

The server supplied config is merged with a user defined schedule, and then applied via setConfig: (The user's schedule is pulled out of local storage)

this.mergeUserConfig(config).then((config: Config) => {
            BackgroundGeolocation.setConfig(config, (state) => {

Today I set the scheduler on each phone to begin at 12:30. All 4 phones tracked identical paths. Only the iPhone 11 failed to track any data on the return, roughly 1:20pm - 1:35pm.

Here is the first part of the log:

2020-06-23 12:08:48.028 ℹ️-[TSConfig persist] 

2020-06-23 12:08:48.044 ℹ️-[TSConfig persist] 

2020-06-23 12:08:48.048 ⚠️-[TSScheduler start] Scheduler #start called with an empty schedule!

2020-06-23 12:08:52.547 ℹ️-[TSConfig persist] 

2020-06-23 12:08:52.549 🔵-[TSLocationManager locationManager:didChangeAuthorizationStatus:] status 3

2020-06-23 12:08:52.550 🔵-[BackgroundTaskManager locationManager:didChangeAuthorizationStatus:] 3

2020-06-23 12:08:52.550 🔵-[LocationManager locationManager:didChangeAuthorizationStatus:] 3

2020-06-23 12:08:52.550 🔵-[LocationManager locationManager:didChangeAuthorizationStatus:] 3

2020-06-23 12:08:52.550 🔵-[LocationManager locationManager:didChangeAuthorizationStatus:] 3

2020-06-23 12:09:46.100 
╔═══════════════════════════════════════════════════════════
║ -[TSScheduler parse:] 
(
    "TSSchedule[triggered: 0, 5:0 - 23:59, Days:2, trackingMode: 1]",
    "TSSchedule[triggered: 0, 5:0 - 23:59, Days:4, trackingMode: 1]",
    "TSSchedule[triggered: 0, 5:0 - 23:59, Days:5, trackingMode: 1]",
    "TSSchedule[triggered: 0, 5:0 - 23:59, Days:6, trackingMode: 1]",
    "TSSchedule[triggered: 0, 5:0 - 23:59, Days:7, trackingMode: 1]",
    "TSSchedule[triggered: 0, 5:0 - 23:59, Days:1, trackingMode: 1]",
    "TSSchedule[triggered: 0, 12:30 - 23:59, Days:3, trackingMode: 1]"
)
╚═══════════════════════════════════════════════════════════

2020-06-23 12:09:46.100 ℹ️-[TSConfig persist] 

2020-06-23 12:09:46.116 🎾-[TSScheduler start] ON

2020-06-23 12:09:46.116 ℹ️-[TSConfig persist] 

2020-06-23 12:09:46.117 
╔═══════════════════════════════════════════════════════════
║ -[TSScheduler findNextSchedule:] Day #3
╚═══════════════════════════════════════════════════════════

2020-06-23 12:09:46.117 ✅-[TSScheduler findNextSchedule:] Found schedule: TSSchedule[triggered: 0, 12:30 - 23:59, Days:3, trackingMode: 1]

2020-06-23 12:09:46.117 🎾-[TSLocationManager startMonitoringSignificantLocationChanges] 

2020-06-23 12:09:46.118 🎾-[TSLocationManager startMonitoringBackgroundFetch] BackgroundFetch: ON

Here is the area where it was supposed to be tracking:

╔═══════════════════════════════════════════════════════════
║ -[LocationManager locationManager:didUpdateLocations:] Sample 3 of 3
╚═══════════════════════════════════════════════════════════

2020-06-23 13:10:42.773 🔵-[TSLocationManager calculateMedianLocationAccuracy:] Median location accuracy: 65.0

2020-06-23 13:10:42.782 ℹ️-[LocationDAO shrink:]_block_invoke maxRecordsToPersist: 4000

2020-06-23 13:10:42.782 ✅-[TSLocationManager persistLocation:]_block_invoke INSERT: A58BE15B-D111-4FD4-BB31-2492DC7E80A0

2020-06-23 13:10:42.782 
╔═══════════════════════════════════════════════════════════
║ -[TSHttpService flush:] 
╚═══════════════════════════════════════════════════════════

2020-06-23 13:10:42.782 ⚠️-[TSHttpService flush:] No network connection

2020-06-23 13:10:42.782 
╔═══════════════════════════════════════════════════════════
║ -[TSHttpService finish:error:] Success: 0
╚═══════════════════════════════════════════════════════════

2020-06-23 13:10:42.785 🔵-[TSLocationManager sync:failure:] Manual HTTP sync: Network available? 0 | HttpService busy? 0

2020-06-23 13:10:42.785 
╔═══════════════════════════════════════════════════════════
║ -[TSHttpService flush:] 
╚═══════════════════════════════════════════════════════════

2020-06-23 13:10:42.785 ⚠️-[TSHttpService flush:] No network connection

2020-06-23 13:10:42.785 
╔═══════════════════════════════════════════════════════════
║ -[TSHttpService finish:error:] Success: 0
╚═══════════════════════════════════════════════════════════

2020-06-23 13:11:09.864 ⚠️-[BackgroundTaskManager createBackgroundTask]_block_invoke FORCE KILL BACKGROUND TASK: 32, remaining time: 4.021782

2020-06-23 13:11:09.865 ✅-[BackgroundTaskManager stopBackgroundTask:]_block_invoke 32 OF (
    32
)

2020-06-23 13:29:44.020 ℹ️-[TSDBLogger db_save] Log committed

2020-06-23 13:29:44.031 
╔═══════════════════════════════════════════════════════════
║ -[TSLocationManager createMotionTypeChangedHandler]_block_invoke | on_foot/66 | isMoving: 1
╚═══════════════════════════════════════════════════════════

2020-06-23 13:29:44.031 ℹ️-[TSLocationManager evaluateHeartbeatTimer] heartbeatTimer elapsed

2020-06-23 13:29:44.031 🔵-[TSLocationManager beginHeartbeat] 60

2020-06-23 13:29:44.031 🔵-[TSLocationManager onHeartbeat] Heartbeat

2020-06-23 13:29:44.031 🔵-[TSScheduler evaluate] TSSchedule[triggered: 1, 12:30 - 23:59, Days:3, trackingMode: 1]

2020-06-23 13:29:44.037 🔴-[TSLocationManager stopHeartbeat] 

2020-06-23 13:29:44.038 ✅-[BackgroundTaskManager createBackgroundTask] 33

2020-06-23 13:29:44.038 ⚠️-[BackgroundTaskManager stopBackgroundTask:]_block_invoke Failed to find backgroundTask: 32.  Ignoring.

The other devices all captured movement in that gap between 13:11 and 13:29 where this iPhone 11 did not. The total distance covered at that time was 1.3 miles.

As for the S8 and S9. In that scenario I don't have verbose logs, I will test again tonight but:

  1. Set 4 phones to track until 8:30 PM last night.
  2. Set all phones to begin tracking at 5:00 AM this morning.
  3. Both iPhones started sending data almost immediately when I left my home, but neither android device did.

edit That log doesn't look like the other verbose log, it looks like a debug log? I not only uninstalled, but I recycled the phone what the heck!!

update 2 I uninstalled, recycled, and reinstalled the same version on the 11. These are the first few lines of the log:

2020-06-23 14:58:06.459 ℹ️-[TSConfig persist] 

2020-06-23 14:58:06.473 ℹ️-[TSConfig persist] 

2020-06-23 14:58:06.475 ⚠️-[TSScheduler start] Scheduler #start called with an empty schedule!

2020-06-23 14:58:12.479 ℹ️-[TSConfig persist]

Does this mean ready is not being called? Does ready not work with just {reset: false}? Do I need to keep my user's configuration (in its entirety) on the cellphone? I used to supply a default config to ready, and let user's override it. Should that be reinstated?

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You may also mark this issue as a "discussion" and I will leave this open.

stale[bot] commented 3 years ago

Closing this issue after a prolonged period of inactivity. Fell free to reopen this issue, if this still affecting you.