Database Info

[Q] Soft Bricked Nexus S 4G - Save the Baby Photos!

I've spent 4-6 hours researching and trying things and have become quite familiar with rooting, fastboot, adb, sideload, and various other tools and have many installed & working, so if I make a noob comment or mistake, go easy on me. I did my best to do my own due diligence.
Here's the situation:
Nexus S 4G - stock from Sprint
Android 4.1 as pushed from Sprint
Not Rooted
Debugging Mode not enabled
Launcher, UI, Settings, Apps, etc fail ("has stopped") if they use the UI
Things not requiring UI do start and run
Android boots up normally to the lock screen (I have pattern lock). Apps start up in background fine (Locale, Alarm Clock Extreme, etc). Upon unlocking, I get "Unfortunately, Launcher has stopped." Repeatedly. It won't let me click any apps. I can, however, bring down the notification window. Selecting anything in the notification window fails, with "____ has stopped," including Settings, Messaging, Google Play, etc. When I plug in USB, I see the green Android with the "Turn on USB storage" button, but I can't click it before "System UI has stopped."
Unfortunately, most solutions warn "this will wipe all user data," and I don't have backups of a hundred or more photos and videos of my daughter's first year. So wiping data will be my LAST resort...and even then I may try forensic recovery from a dd image (I work in Computing Security, so have a fairly good technical background).
What I've tried, and result:
Reboot into recovery - I get dead Android with red exclamation
Wipe cache & reboot - no improvement (tried 5-10 times)
Reboot into Safe Mode - no improvement
Push 3rd party launcher - installs, but upon unlocking and selecting Launcher / Go Launcher (.e.g), I get "Go Launcher has stopped."
Fastboot - I get device listed/connected, but most commands cause wipe, so I haven't ventured much further
Calling Sprint and having Jellybean re-pushed to my device - it appeared to push (I saw update status message), but when I rebooted, no apparent difference (maybe it didn't push?)
Add/Remove apps via Play Store - works fine. I can remove apps (and have removed nearly all) and add apps, and they uninstall or install successfully (notification window confirms). But I can't access any newly installed apps due to the "stopped working" window.
Suggestions I can't try:
adb backup/shell/pull etc - my debugging mode is not on and I can't turn it on.
USB backup - can't enable USB Mode, and I don't have an automount capability
fastboot oem unlock - wipes phone
I want to try adb sideload <image>, but I haven't been able to confirm whether this truly wipes the user partition or not. If anyone can confirm, let me know. My phone enters sideload mode via:
1) boot to fastboot (power + vol up from OFF)
2) select recovery
3) at dead android with red exclamation, again press power + vol up and release. Menu appears only after you release.
4) 2nd option is "Apply update from ADB" which puts phone into special adb mode where the ONLY command accepted from your PC is "adb sideload."
Any suggestions on how I may be able to retrieve my photos and videos given this completely borked OS?
Thanks.

You could try this. It's Beta and buggy but might work.
http://forum.xda-developers.com/showthread.php?p=36499906

jayjay3333 said:
You could try this. It's Beta and buggy but might work.
http://forum.xda-developers.com/showthread.php?p=36499906
Click to expand...
Click to collapse
Thanks for the suggestion, but that requires Debugging Mode enabled. It's essentially a GUI for "adb backup." Unfortunately, I can't get debugging mode enabled in any way known to me yet.
Is anyone out there familiar with the adb sideload command? I'm really curious if sideloading an image into user partition in any way wipes data.

SOLVED - how I saved the baby photos
I thought I'd give a quick post on how I actually was able to recover my baby's photos. I was at my last resort and decided I'd just try to do a dd image of the card after I did a "wipe and factory reset." My hope was that a "wipe" did not actually write 0s over the entire internal SD card, but just erased the FAT. In that case, I figured, if I took a dd image, I could use a tool like Forensic Toolkit or similar file carving tool to carve out .MP4, .3GP and .JPG files.
So I selected the wipe and factory reset, but had my Linux system ready to do the dd IMMEDIATELY upon reboot. I had ALREADY plugged my USB connector into the Linux system. When the factory reset completed, the system booted directly to the "Enable USB Mode?" prompt. I enabled it, and performed a ~14 GB dump. I know this only catches the user partition, but I didn't care about the system partition, and hoped it would be re-allocated in roughly same location as previously (not stomping on my user data). After the dd was complete (about 3 hrs or so), I bit the bullet and just signed into my Google account and had Google Backup "restore settings."
Later, I was using ES File Explorer and noticed all JPGs were still in my DCIM folder. When I browsed with Gallery ALL PHOTOS AND MOVIES were still present! :victory:
I did not have any backup/recovery software installed to the best of my knowledge, except for Google's "settings backup." So my best explanation is that the wipe & factory reset DID NOT wipe my user data. This may be a fluke, or due to me having USB connected during the wipe & reset. Not sure.
Just to be sure we're all talking about the same "Factory Reset," on my stock Nexus S 4G running Android 4.1.1:
- power off phone
- press Vol Up and Power at same time -- you'll get the Bootloader
- select Recovery -- you'll get dead android with red exclamation after a few seconds
- press Vol Up and Power at same time again -- you'll get a secondary menu
- select "wipe data/factory reset"
- select "Yes" from a long list of "No" with one randomly-placed "Yes"
Hope this helps someone down the road...
I also wanted to note about the "ADB sideload" command. It can only be used to push incremental updates to the device--not full images needed to recover from a corrupted OS. I successfully sideloaded the 4.1.1 update (re-applied the 4.1.1 that I was currently running), which included "launcher2.apk" and a couple other launcher components that gave me hope. But when the 4.1.1 sideload completed successfully and I rebooted, launcher was still hosed. The 4.1.2 incremental update hasn't been released by Sprint yet.

That was hell of a read. The Samsung toolbox program you can do a temp boot and mount your SD card. But I'm too late to tell you now sorry.
Sent from my Nexus S using xda app-developers app

A few minutes googling would have told you that adb is set in the build.prop
Code:
persist.sys.usb.config=adb
OR adb with mount external
persist.sys.usb.config=mass_storage,adb
OR adb with mtp, but you need a kernel
persist.sys.usb.config=mtp,adb

Hi Can you tell us the dd command that you have used to dump the data?

My Case was little different. My friend had tried unlocking screen pattern and it got locked.
Wifi was not on neither was it rooted nor usb debugging mode enabled.
Solution:
I did a factory reset with my phone connected to PC.
once this is done during reboot a prompt came up asking whether to enable USB debugging need to be enabled.
I enabled it and I could see all my data from my PC.
I copied everything and continued with booting.
Hope this will help someone

Pavankumarvijapur said:
My Case was little different. My friend had tried unlocking screen pattern and it got locked.
Wifi was not on neither was it rooted nor usb debugging mode enabled.
Solution:
I did a factory reset with my phone connected to PC.
once this is done during reboot a prompt came up asking whether to enable USB debugging need to be enabled.
I enabled it and I could see all my data from my PC.
I copied everything and continued with booting.
Hope this will help someone
Click to expand...
Click to collapse
I wonder if this will work with a Nexus 7 on 4.3-4.4 ota soft brick

This is why rooting unlocking and a custom recovery is so important.
Sent from my XT897 using XDA Premium 4 mobile app

[Q] P5113 can't write to internal storage

I have a P5113 that's been running the CM 11 nightlies just fine until a few days ago. For some unknown reason, the internal storage is stuck in read only mode which is causing applications to fail and the tablet to reboot every few minutes. I've tried using CWM recovery to do a factory reset as well as wipe cache and reformat all partitions with no effect. Have also tried to install the latest CM 11 but after reboot the older version of the image is still installed. I also cannot write or delete any files from the file system as they reappear after a reboot. I've tried to use Odin to install a factory ROM but it keeps failing and I've tried to write a PIT file to fix the partition which has also had no affect. I've tried using adb to set read/write permissions but after a reboot, the permission revert back to read only.
I would like to know if there is anything else that can be done to repartition the internal storage and reload a factory ROM so that I can start over.
Thanks
....Mike

michaelgwilson007 said:
For some unknown reason, the internal storage is stuck in read only mode
Click to expand...
Click to collapse
As you seem to know your way around: Could you try and fetch a logcat as well as the kernel dmesg output upon boot and post it for review (pastebin or similar)? If it even fails with re-flashing a Stock ROM maybe the logs give a hint about what's going on (maybe the NAND chip became corrupted leaving fsck without a possibility to fix the filesystem?).

BoneWithABeagle said:
As you seem to know your way around: Could you try and fetch a logcat as well as the kernel dmesg output upon boot and post it for review (pastebin or similar)? If it even fails with re-flashing a Stock ROM maybe the logs give a hint about what's going on (maybe the NAND chip became corrupted leaving fsck without a possibility to fix the filesystem?).
Click to expand...
Click to collapse
Thanks for the reply. I've been doing a lot of reading to work my way around. I have never reviewed the logs or know where they are but I'll see if I can figure it out. Any info on how to extract this info would be greatly appreciated.
....M

michaelgwilson007 said:
Thanks for the reply. I've been doing a lot of reading to work my way around. I have never reviewed the logs or know where they are but I'll see if I can figure it out. Any info on how to extract this info would be greatly appreciated.
....M
Click to expand...
Click to collapse
You already used "adb", so access to Settings -> Developer Options must already be enabled and "USB debugging" turned on.
Now, simply connect the tablet to the PC and open a Command Promt (or Terminal if you're on Linux). Issue a restart on the Tablet (if turned on). Once the "Galaxy Tab 2.0" kernel logo shows up issue "adb logcat >> Downloads\logcat.txt" (Windows) or "adb logcat >> Download/logcat.txt" (Linux - you may need to add a "sudo" before adb if your udev rules aren't properly set).
adb will now display "connecting" and once Android has start "adbd", should happen rather early in the boot process, it will start logging into the text file. Once the ROM has fully booted up wait for a minute, so the system settles with starting up everything, before you press CTRL+C to interrupt adb logging.
Next would be "adb shell dmesg >> Downloads\dmesg.txt" (Windows) or "adb shell dmesg >> Downloads/dmesg.txt" (Linux). That dumps the kernel output into a text file. IF you get a error here it may relate to...: 1. Your ROM is not rooted. / 2. "adb+apps" is not set in the Developer options / 3. You are running a Sammy Stock ROM where adbd has no root powers.
If you're on a Stock ROM ... Install Chainfire's adbd Insecure (you need root!), run the app, apply the patch and reboot. Now adbd behaves like in CM or OMNI (root priviledges).
You can review the text files for yourself. If you see any obvious errors that should give you a hint about what's going on. If not, then put them up for review. Though... be warned: The files contains some private data (like the MAC address of the tablet as well as some information from your WiFi). If you don't want it to be displayed to the greater public send me a PM.

BoneWithABeagle said:
You already used "adb", so access to Settings -> Developer Options must already be enabled and "USB debugging" turned on.
Now, simply connect the tablet to the PC and open a Command Promt (or Terminal if you're on Linux). Issue a restart on the Tablet (if turned on). Once the "Galaxy Tab 2.0" kernel logo shows up issue "adb logcat >> Downloads\logcat.txt" (Windows) or "adb logcat >> Download/logcat.txt" (Linux - you may need to add a "sudo" before adb if your udev rules aren't properly set).
adb will now display "connecting" and once Android has start "adbd", should happen rather early in the boot process, it will start logging into the text file. Once the ROM has fully booted up wait for a minute, so the system settles with starting up everything, before you press CTRL+C to interrupt adb logging.
Next would be "adb shell dmesg >> Downloads\dmesg.txt" (Windows) or "adb shell dmesg >> Downloads/dmesg.txt" (Linux). That dumps the kernel output into a text file. IF you get a error here it may relate to...: 1. Your ROM is not rooted. / 2. "adb+apps" is not set in the Developer options / 3. You are running a Sammy Stock ROM where adbd has no root powers.
If you're on a Stock ROM ... Install Chainfire's adbd Insecure (you need root!), run the app, apply the patch and reboot. Now adbd behaves like in CM or OMNI (root priviledges).
You can review the text files for yourself. If you see any obvious errors that should give you a hint about what's going on. If not, then put them up for review. Though... be warned: The files contains some private data (like the MAC address of the tablet as well as some information from your WiFi). If you don't want it to be displayed to the greater public send me a PM.
Click to expand...
Click to collapse
Thanks for the guidance. I'll work on getting the log files when I get home. I'm currently on CM11 with root so hopefully I'll be able to dump the kernel without too much trouble.
Once I get the files, I'll send you a PM.
.......M

Just to wrap the thread up so it won't hang around without some conclusion as we had a private exchange...
The logs showed that there's a major problem, along with some smaller ones, going on. The kernel is spamming a "command error" message, in a infinite loop at some high repetition rate, in relation to mmcblk0 to the kernel console, and logcat shows re-occurring problems with "MtpServer" which eventually crashes the "VM" (Dalvik).
Since michaelgwilson007 already attempted the "last resort" solution to flash back to Stock with a PIT for his type of SGT2 (as he said his "sdcard0" partition wasn't even there) to restore NAND partitioning and Stock firmware... the PIT goes through but he then gets a NAND write error while attempting to flash the stock firmware. Relating what the logs have to tell to what's going on the device we seem to agree that the likelyhood of the NAND chip being defective (dead flash memory cells) is very high.
Case isn't really solved, but at least we worked out a 99% probability of a hardware malfunction.
If some of the kernel dev, knowing a bit more about the low-level layer, happens to have an idea - feel free to maybe add some idea.

I sent @michaelgwilson007 a PM. You could try running an ADB command from recovery to reformat the internal storage partition. Just make sure to wait until it finishes. The instructions are in the PM.
Sent from my Nexus 4 using XDA Premium HD app

shakatu said:
I sent @michaelgwilson007 a PM. You could try running an ADB command from recovery to reformat the internal storage partition. Just make sure to wait until it finishes. The instructions are in the PM.
Sent from my Nexus 4 using XDA Premium HD app
Click to expand...
Click to collapse
Thanks for your assistance. It turns out that I had a corrupt NAND chip based on a few other tests. I replaced the motherboard and I'm good to go again.

I'm having the exact same problem, but it's not stuck, and I can certainly open apps, or run the system, can't seem to delete or rewrite or even write anything. From a brief search I came to this thread, any solution other than giving it to Samsung service for repair?

Following

[GUIDE] Fixing resolution after using NOMone Resolution Changer

I recently tried to lower the resolution on my Samsung Galaxy Note II using NOMone to increase game performance. Unfortunately I ended up making my phone unusable (system.ui kept force closing, launcher wouldn't open, etc). After a few hours I found a way to fix my mistake without doing a factory reset. This is just a quick write up I felt I had to share. It may not help everyone but hopefully this will help someone avoid factory reset. This guide assumes your phone is rooted, has a removable sd card, and has a custom recovery.
If you had USB debugging enabled prior to changing your resolution, the process is much simpler:
1. Make sure your phone's usb drivers are installed on your computer (adb, etc...)
2. Open up a terminal or command prompt on your computer and type in:
(For android versions 4.3 and up)
Code:
adb shell wm size reset
adb shell wm density reset
(For android versions below 4.3)
Code:
adb shell am display-size reset
adb shell am display-density reset
3. Everything should be back to normal, although a reboot may be needed.
If you're a complete moron like me and did not have usb debugging enabled prior to changing your resolution, there is hope as long as you have a custom recovery.
1. Download Aroma File Manager and place on your sd card.
2. Copy your build.prop from the /system directory and place on your sd card.
3. Connect your sd card to your computer and open your build.prop using your favorite editor.
4. Add the following lines at the bottom of your build.prop
Code:
persist.service.adb.enable=1
persist.service.debuggable=1
persist.sys.usb.config=mtp,adb
5. Save and overwrite your existing build.prop with the edited build.prop and reboot your phone.
6. You should now have adb debugging enabled and should be able to follow the first series of steps to restore your resolution.

Life saver!
hjjr15 said:
I recently tried to lower the resolution on my Samsung Galaxy Note II using NOMone to increase game performance. Unfortunately I ended up making my phone unusable (system.ui kept force closing, launcher wouldn't open, etc). After a few hours I found a way to fix my mistake without doing a factory reset. This is just a quick write up I felt I had to share. It may not help everyone but hopefully this will help someone avoid factory reset. This guide assumes your phone is rooted, has a removable sd card, and has a custom recovery.
If you had USB debugging enabled prior to changing your resolution, the process is much simpler:
1. Make sure your phone's usb drivers are installed on your computer (adb, etc...)
2. Open up a terminal or command prompt on your computer and type in:
(For android versions 4.3 and up)
Code:
adb shell wm size reset
adb shell wm density reset
(For android versions below 4.3)
Code:
adb shell am display-size reset
adb shell am display-density reset
3. Everything should be back to normal, although a reboot may be needed.
If you're a complete moron like me and did not have usb debugging enabled prior to changing your resolution, there is hope as long as you have a custom recovery.
1. Download Aroma File Manager and place on your sd card.
2. Copy your build.prop from the /system directory and place on your sd card.
3. Connect your sd card to your computer and open your build.prop using your favorite editor.
4. Add the following lines at the bottom of your build.prop
Code:
persist.service.adb.enable=1
persist.service.debuggable=1
persist.sys.usb.config=mtp,adb
5. Save and overwrite your existing build.prop with the edited build.prop and reboot your phone.
6. You should now have adb debugging enabled and should be able to follow the first series of steps to restore your resolution.
Click to expand...
Click to collapse
Dude, i swear to GOD you are a life saver!! i don't use this site frequently. i had to reset my password just to be able to thank you. Can't thank you enough. You really saved my life.

Man, you saved my life after 4 years lol

ematc egq327
Nomone app crashed when I increased dpi to 600. Now tablet constantly reboots. I can not figure out how to enter recovery mode. If I can wipe data will this reset dpi? Anyone?

Bro pls help me I'm changed dpi-screen resolution and density
Now my device touch in not working pls guide me
Device-redmi note 7 pro

So my issue is actually diffrent, i DO have usb debugging, BUUUUUUUUUUT, it doesnt allow me to do any commands cuz i have my device with locked screen, and i am unable to do anything with adb, is there any last hope?

Lauris Roze said:
So my issue is actually diffrent, i DO have usb debugging, BUUUUUUUUUUT, it doesnt allow me to do any commands cuz i have my device with locked screen, and i am unable to do anything with adb, is there any last hope?
Click to expand...
Click to collapse
did you figure out what to do??

[Completed] [GT-I9515]Messed up with screen resolution and overscale - can't change it by adb

Hi,
my problem is - I have installed ScreenShift, then changed resolution and overscale and after reboot I can;t use my screen because of overscan. Tried steps provided by the author of the app, tried adb over twrp recovery (after typing command adb shell wm overscan reset I receive this error "CANNOT LINK EXECUTABLE: cannot locate symbol "stderr" referenced by "app_process"... page record for 0xb6f0404c was not found (block_size=32)"). Tried changing density inside build.prop and nothing has changed. I tried to figure out where the overscan settings are stored but with no luck.
My phone is Galaxy S4 Value Edition with Unofficial CM13 (latest from 11.09.2016) and TWRP 3.0.0.

Thread closed, OP reposted
http://forum.xda-developers.com/android/help/gt-i9515-messed-screen-resolution-t3460864

Galaxy S5 with broken screen, need help controlling it from PC

Hi, I've got an old S5 with a broken screen. There's no image going on and there's no indication that the touchscreen is working.
I'm not looking to recover data, I'm looking to play around with it by controlling it from my PC. Last I remember, the phone is running a Cyanogenmod OS (I don't think LineageOS was around at that time) with either TWRP or CWM recovery, but I'd bet on TWRP.
Now: the device reaches the OS properly, I can tell because if I try to turn the ringing sound up it gives me an audio feedback.
If I connect it to a PC from the OS:
- the phone shows up in Windows Explorer as "SM-G900F"
- Device Manager shows me a "SAMSUNG Mobile USB Composite Device" under Universal Serial Bus controllers
However I cannot access any files (Windows Explorer shows the device as empty), and if I attempt to 'adb devices' in the console it shows me an empty devices list.
Now, I suspect that USB debugging might be off. So I also tried connecting it to a PC from recovery and the exact same thing as above can be observed, PLUS:
- Device manager also shows me a "SAMSUNG Android Phone" list which can be expanded to show me one entry called "SAMSUNG Android ADB Interface"
However it's the same as before, no files available and 'adb devices' shows an empty list.
Now I heard that I can theoretically enable USB debugging through ADB, by writing to a config file. That would allow me to enable USB debugging and try something like Vysor in order to control the phone from my PC.
However that's a moot point until I can figure out why the ADB service on my PC isn't seeing the device. Any help would be greatly appreciated, and if you need more info I can provide it.
Extra info:
- I installed Samsung USB drivers at some point while trying to make it work
- Windows Explorer shows a phone icon for this device, and if I recall correctly that's what happens when it's connected through MTP (Mass Storage should show it like a memory card)

_sepiroth said:
Hi, I've got an old S5 with a broken screen..........
Click to expand...
Click to collapse
I've never experienced this situation myself but, I've seen that the following thread has worked for many individuals.
https://forum.xda-developers.com/showthread.php?t=2786395
Good Luck!
~~~~~~~~~~~~~~~
Unless asked to do so, PLEASE don't PM me regarding support. Sent using The ClaRetoX Forum App on my Apple Macintosh.

Ibuprophen said:
I've never experienced this situation myself but, I've seen that the following thread has worked for many individuals.
https://forum.xda-developers.com/showthread.php?t=2786395
Good Luck!
~~~~~~~~~~~~~~~
Unless asked to do so, PLEASE don't PM me regarding support. Sent using The ClaRetoX Forum App on my Apple Macintosh.
Click to expand...
Click to collapse
Thanks a bunch, that pointed me in the right direction with my research! I solved my issue, I can now control my phone from my PC.
By doing this I ran into a couple of problems, I'm going to describe them and their solutions:
Problem 1: couldn't ADB into the device when in Recovery Mode. That is because after a long head scratching session I came to the conclusion that I didn't have TWRP Recovery installed (I had Philz Touch CWM Recovery and LineageOS 14.1 instead).
Solution 1: ADB mode is enabled in TWRP by default. So I flashed the latest TWRP through Odin, ADB instantly started working afterwards in Recovery Mode.
Problem 2: USB Debugging was disabled inside the OS.
Solution 2: from the thread that Ibuprophen posted, you can enable USB debugging in your OS by opening an ADB shell into your device and modify the build.prop like so
Code:
Adb shell
echo "persist.service.adb.enable=1" >>/system/build.prop
echo "persist.service.debuggable=1" >>/system/build.prop
echo "persist.sys.usb.config=mass_storage,adb" >>/system/build.prop
reboot
Problem 3: /system was empty so there was no build.prop. If I attempted to create a build.prop file it wouldn't be saved after a device reboot, so USB debugging still didn't work.
Solution 3: it seems like TWRP doesn't mount /system by default, only /data. You can mount it manually through ADB like this:
Code:
mount -o rw /dev/block/bootdevice/by-name/system /system
I found this out from this stackexchange question: https://android.stackexchange.com/q...data-partitions-in-recovery-mode-in-adb-shell
Problem 4: When an app tries to use USB Debugging you need to allow it to do so from the phone. Since the screen was broken, I couldn't do this.
Solution 4: You'll need to push a public key to your device with ADB. Boot into Recovery Mode and make sure your device is recognized by your PC and type
Code:
adb push <path to adbkey.pub on your PC> /data/misc/adb/adb_keys
This solution is from: https://stackoverflow.com/questions...b-rsa-key-with-broken-touch-screen-on-android
This will make sure that you won't need to confirm debugging permissions for apps coming from your machine.
So for anyone who has a broken phone screen (my screen is dead and touchscreen/touch buttons are kaput too) and wishes to control their phone from their PC but USB debugging is disabled:
1. Boot device in TWRP Recovery (flash it if you don't have it)
2. ADB into the device
3. Make sure /system is mounted (if it's empty it means it's not mounted), else mount it manually like in Solution 3
4. Configure build.prop to have USB Debugging enabled like in Solution 2
5. Push your public key to the device like in Solution 4
6. Restart the phone (into its OS)
7. Download the Chrome extension called Vysor and launch it
8. Connect your phone through a USB cable
9. The device should appear in Vysor, connect to it and have fun controlling it
Note that if you just want to backup your files, steps 1 + 2 are sufficient. After making sure ADB works you can just 'adb pull' all your files which should be located in /sdcard. Google it, it's easy to find.
The same goes for backups, you can do them directly through ADB.
Again, thanks Ibuprophen!

Vysor does not work on all graphic cards. a good free alternative is scrcpy
btw instead of flashing twrp, you can flash a modified system partition with proper entries in build.prop (for those with no custom recovery available)

aIecxs said:
Vysor does not work on all graphic cards. a good free alternative is scrcpy
btw instead of flashing twrp, you can flash a modified system partition with proper entries in build.prop (for those with no custom recovery available)
Click to expand...
Click to collapse
Very well pointed out, thanks for this.