MAD doesn't scan after update

[madBeavis]

This is the last commit that works properly, e874a1592b6850b8df6fa4cb0f50e2cd26e737da

After update, as long as devices are running, they continue to work until a reboot. Things go through their normal cycle, pogo starts but pd never injects. Whole system will go offline eventually, all atv just chilling and doing nothing besides rebooting. Same PD and RGC settings.

Running latest pd, rgc and pogo.

I setup my leveling instance as a test. Logs with -vvvvv from it are included. Logcat from atv from startup to reboot by mad. Logcat from same device running on good commit.

20200616_1309_MAD-Level.zip

atv003.zip

atv003 - good on e874a1592b6850b8df6fa4cb0f50e2cd26e737da.zip

[Expl0dingBanana]

Are you using NFS on this device?

[madBeavis]

removed nfs from magisk manager and rebooted as a random test, dropped back a version in pd. this set of versions seems to run as designed:

ATV - Readout ALL Versions RETURNING: [RGC 1.10.1 | PD 1.4.1.3 | PoGo 0.177.1 | Magisk 20.3:MAGISK (20300) | Magisk Modules fomey.smalipatcher, | ROM 1.2.8]

---

I reinstalled NFS, it continues to work:

ATV - Readout ALL Versions RETURNING: [RGC 1.10.1 | PD 1.4.1.3 | PoGo 0.177.1 | Magisk 20.3:MAGISK (20300) | Magisk Modules fomey.smalipatcher,nfsinjector, | ROM 1.2.8]

---

This set of versions were on it when it was not working:

ATV - Readout ALL Versions RETURNING: [RGC 1.10.1 | PD 1.4.1.5 | PoGo 0.177.1 | Magisk 20.3:MAGISK (20300) | Magisk Modules fomey.smalipatcher,nfsinjector, | ROM 1.2.8]

[wraythex]

I am running into this problem as well. It crops up once in a while on different devices, who will then be offline rebooting (and not injecting) for many hours. Sometimes they will fix themselves after multiple hours, usually though I have to manually power cycle the device to get it working again.

Here are the details of my most recently affected device (nfs is not installed): [RGC 1.10.1 | PD 1.4.1.5 | PoGo 0.177.1 | Magisk 20.3:MAGISK (20300) | ROM 1.2.7] Here is the logcat: logcat.txt

[TiMXL73]

I’ll add just in case it’s the same issue. If not, ignore this. Grennith already has a full logcat and I can provide one privately.

Current MAD commit: 254fd075316fe5f69708cfe9431795fb9b6385c2 PoGO(0.177.1) Droid(1.4.1.5) RGC(1.10.1) NFS: [Module not installed | Mode unknown]

Issue and Symptoms:

Randomly after a reboot, Process com.mad.pogodroid (pid XXX) has died will appear continuously in logcat and nothing else being killed/dying. Scrcpy into the device will show PD appearing and disappearing continuously in the notifications bar. The end result is PD never starts properly so the device never injects and goes offline until, sometimes and magically, another reboot starts PD normally or manual intervention.

Debug information:

It happened on multiple device types (S4, S4 Mini, Nexus 5 and S905W) so it’s not isolated to a specific device. Although I never had an issue with my boot delays previously (60-120 depending on device), I increased them to 240 to rule out PD starting too early and ended up with the same pd crash loop.

While testing, I noticed that if I manually force closed PD and restarted it, everything would work fine until another reboot. This discovery lead me to create a bash script in Magisk’s boot folder to automate those tasks while waiting for a proper fix. Since I pushed this script to my devices, they have been stable and haven’t exhibited the PD crashing behavior.

[cyphercris]

@TiMXL73 could you share this script?

[TiMXL73]

@cyphercris Sure. Instructions:

• Put in /data/adb/service.d/
• chmod +x /data/adb/service.d/zzz_tim_magisk.sh

Note1: zzz prefix in filename to make sure it goes last Note2: S905W with RGC 120 boot delay has been working fine here. Too low and you risk switching from pogo to pd and back to pogo wasting time. Note3: Keep PD's Daemon Mode enabled unless you remove/alter the if. Note4: Yes, I actually do use those beautiful block separator and comments in code that I rarely look at to remember what it does and why!

Script:

#!/system/bin/sh

####################################################################################
# Wait For Boot To Complete + Extra Safety Sleep
while [ "$(getprop sys.boot_completed)" != "1" ]; do sleep 1; done
sleep 5

####################################################################################
# WorkAround For PogoDroid Crash Looping On Startup After Reboots
# - If Daemon Mode Enabled
#    - Wait For Network + Safety Sleep (TODO: Check For Process Instead)
#    - Stop PD, Start PD and Press Start Button
PD_DAEMON_ENABLED=$(grep full_daemon /data/data/com.mad.pogodroid/shared_prefs/com.mad.pogodroid_preferences.xml | grep -c 'value="true"')
if [ $PD_DAEMON_ENABLED -eq 1 ]; then
  until ping -c1 8.8.8.8 >/dev/null 2>/dev/null; do sleep 10 ;done
  sleep 40
  am force-stop com.mad.pogodroid
  sleep 5
  am start -n com.mad.pogodroid/.SplashPermissionsActivity
  sleep 15
  am startservice com.mad.pogodroid/.services.HookReceiverService
fi

[madBeavis]

ran the script on one device, survived 3 forced reboots to test it, seems to accomplish task.

i run startup delays as follows: s905w, i use 180sec pd and rgc s912, i use 120sec for both

[wraythex]

I just had a device that was stuck rebooting for about 5 hours. I tried manual reboots, manually stopping/starting PD, it just wouldn't work correctly. I installed the script as described above and now the device has been running stable for 2+ hours. Thanks!

Delay settings: 30s rgc, 120s pd.

[TechG3n]

Got the same issue. Some times when i open PD manually it injects in the moment, some times the screen stays white and stops working. Will try the script.

[crhbetz]

@spammer23 @wraythex @madBeavis @TiMXL73 @cyphercris Can anyone of you guys tell if this issue still exists? It wouldn't be too hard to implement a functionally identical procedure into MAD I guess...

[TechG3n]

I have reinstalled PD - that solved the issue for me

[TiMXL73]

Can anyone of you guys tell if this issue still exists? It wouldn't be too hard to implement a functionally identical procedure into MAD I guess...

I removed my workaround about a month ago and haven't noticed/experienced the issue again. The recent builds of PD must have fixed the original issue.

[madBeavis]

and just for reference, this was for 32bit roms

[cyphercris]

Problem appear less after longer delays and after change to 64bit gone or just not noticed.