This is my first time playing with Linux/Android and I was trying to sync repo on my Ubuntu machine. I left my laptop sitting for a while because it was taking a long time to download everything.
When I got back I had this message:
Initializing project platform/external/tesseract ...
remote: Counting objects: 1885, done.
remote: Compressing objects: 100% (1020/1020), done.
fatal: The remote end hung up unexpectedlyMiB | 18 KiB/s
fatal: early EOF
fatal: index-pack failed
error: Cannot fetch platform/external/tesseract
My laptop was plugged in to the wall so I don't think it went to sleep, but who knows. Do I have to sync all over again? What is the impact of the error above?
Related
I'm getting a lot of these errors in my log, and suspect it's may be the cause of my battery draining quickly just on standby.
Are others getting this error, or might it be just a stray app?
Getting them too!
First off, I had to post here since I haven't made over 10 posts yet.
If you're getting a persistent allocation error when trying to flash the grfs.img (webtop) no matter what method, it might have to do with your computer lacking resources (not enough RAM).
Short of installing more RAM, you can try to increase your virtual memory (Control Panel>System>Advanced System Settings>Advanced tab> Performance (Settings)). My PC is only at 1GB of RAM, so I bumped my virtual memory up to 1522 (from 1024) and then restarted (to allow changes to take effect).
After it reboots, you should be able to flash the image. HOWEVER, IT WILL TAKE A LONG TIME TO DO SO MAKE SURE YOU HAVE A FULLY CHARGED BATTERY. The grfs.img is ~1.3GB so it takes some time for the system to handle it. It took over an hour for my machine to finish and you couldn't do anything else while it was trying to load the image. I recommend keeping the number of running programs to a minimum (sorry, no interwebs).
This allowed me to revert to a factory version of 886 and ultimately get to 901 rooted.
Hopefully this helps someone...
I killed my battery doing this.
I went to VZW and told them that their upgrade killed my battery (not a complete lie) and they gave me a new one. I restored the phone, charged the battery and completed the upgrade.
How long did it stay at the DOS prompt while trying to parse the image? Was the battery fully charged? If your battery only lasted an hour or two, then you had some underlying issues. When I finally got back up and running, I had between 60-70% left, and that's including flashing several other items after the webtop image.
Its posted in the right section anyway
5 stars. Thanks eluisve (Still searching for how to register a "Thanks" for the thread.)
Desktop is having I/O issues and my netbook was failing at unbricking my Droid Razr because of this error. I'd say I feel silly because I didn't grasp what was going wrong, but if we always grasped the obvious immediately, there'd be little use for support forums
Hello guys,
I have a problem with my camera.
When i enter camera app or any other camera related app i get:
Warning "Camera auto recovering".
I have no live view, but if i'm quick enough like i have 4 -5 seconds to press record i get image and video is recording.
also i can make pictures in that 4-5 seconds interval.
Sometimes Random I get live preview and everything works normal!
When i go to *#0*# in megacam
i get: Warning "camera failed"
This is what i get in ADB(logcat :*W):
Code:
E/SecCameraHardware( 1912): FimcV4l2 poll: error 0
W/SecCameraHardware( 1912): nativeGetPreview: warning, ESD Shock(0). Reset the camera device (10)
E/ISecCameraHardware( 1912): previewThread: error, nativeGetPreview
E/SecCameraCoreManager( 1912): notifyErrorCallback(1, 1010, 0)
E/SecCamera-JNI-Java(15002): Error 1010
W/SecCameraHardware( 1912): nativeStopPreview ++++++++
W/SecCameraHardware( 1912): nativeStopPreview ---------
W/ISecCameraHardware( 1912): stopPreview: warning, preview has been stopped
E/ISecCameraHardware( 1912): CAMERA power off noti. HAL is completely released
E/ISecCameraHardware( 1912): preview window is NULL!
W/AudioFlinger( 1912): session id 369 not found for pid 1912
W/AudioFlinger( 1912): session id 370 not found for pid 1912
W/AudioFlinger( 1912): session id 371 not found for pid 1912
I appreciate any help.
hello you could solve the problem
Warning "Camera auto recovering".
regards
EK GN120 Overheating/Heating/Battery Drain
I also have problem with my ek gn120... first i fully charged it before putting it inside the cabinet for storage then the next morning i get it to transfer files to computer then i notice its warm but the room is cold because of the airconditioning.. then when i try to switch it on it wont open because the battery is drained.. so meaning it is using the battery when battery is connected because the camera is warm when i took it and battery is now drained... then i tried to charge it now and it is super slow to charge. i charge it overnight from 2% and now it is 12% but before i only need to charge it like 4-6hrs then its ok.. i already did the factory reset but still doing the same thing. when its turned on the battery is not charging not like before. so is it the battery need replacement or there's more to my problem other than the battery? thankyou and have a nice day. :crying:
I know this is a very OLD problem, with the battery drain... but have you solved or at least figured out why it drains so badly? I purchased one recently that does the same.
Let me keep this short and to the point. As numerous other users, I am also extremely bothered by the huge Android OS drain while on standby. On average, standby drain is 3% - 4% per hour,which is unacceptable. Let me describe my condition and my findings.
My setup
Stock OpenBeta 10 - 12, stock kernel, with Magisk and greenify. Dual sim (Airtel + Jio). 4G mobile data always active on Jio. Drain remains same if I disable both/ one of the sims, turn off data, or switch to flight mode.
What I tried
Used this command from a PC to check if any rogue app is using too much CPU. It once showed me Google drive was constantly using 6% CPU, but it was an one time bug, rebooting fixed it and never showed up again. Clearly, active usage was not problem, only the standby.
Code:
adb shell top -m 20 -s cpu
Then I checked BetterBatteryStats and I always see such alarming "Wake (Screen Off)" times. As you can see in screenshot in attachment. It is almost 50% of total standby. It might seem if the wakelocks are due to Google Play Services or GoogleQuickSearchBox, but no! Google's app take wakelock only if the phone is already awake, the primary reason of waking up has to be checked by this tool called Battery Historian by Google
To use it,
Download the repository as Zip file from https://github.com/google/battery-historian
Install python 2.7 and add python to your path.
Unzip Battery Historian after downloading as ZIP and go to scripts folder.
Run these two commands in cmd with phone connected in USB Debugging mode
Code:
adb shell dumpsys batterystats > batterystats.txt
python historian.py batterystats.txt > batterystats.html
If you cant get python running, skip the second command and upload the txt file here.
Now you will have a HTML file, possibly around 4-5MB. Opening it takes a bit of time to fully load in browser, like 1-2mins. Be patient.
In this graph, compare your screen, wake_lock* and wake_reason rows. In my case, the wake reason is almost always QCOM SMD-MODEM or QCOM SMD-MPM. And loads of wakelock from RILJ_ACK. Both of these point to possible screw ups from OnePlus at proper optimization of the radio interface.
I am not exactly sure what this means as I don't have much expertise on the kernel level, instead I am an app developer. I highly suspect it is a bug at the firmware/radio level.
I urge everyone to post their own findings and also help in fixing the problem with proper explanation if anyone possesses the kernel level expertise. I have also included my own battery stats in the attachments, if anyone is interested in further investigation
RESERVED
Damn Audioserver daemon rears its ugly head again. Slowly sucking up my battery since this morning. Sigh.. Can we realistically stop this stupid service from scanning during battery and only scan on charge or something? I never understood why it was always the reverse (never active during charge, only active during battery). It's really not that hard to comprehend that it should be on when it is powered and not the other way around. Seems like it also has a tendency to trip over files and gets stuck in a loop - but just cannot see which file specifically (when you have 2000 mp3's on the phone it is pretty hard).