• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Velocity Script

Status
Not open for further replies.
Anyone else having Market Updates "unsuccessful" since getting Script 29 working? I am not sure it is even related to the problem, but updating to Script 29 was one of the recent changes I made to my Ally. I am working backwards through the changes to try and pinpoint the cause.

I had also installed DroidWall last night to block network access to an app named GroceryIQ. That works great to speed up the app, but I have now undone all that and uninstalled DroidWall, cleared all the caches both in Script and in Recovery. Still am unable to update 3 apps I have been using and updating for months. I'll try restoring the aforementioned Nandroid again, going back to Script 26, and then work forward again giving market updating top priority. Hopefully the cause is something other than Velocity related issues. :)
 
The new project is updating the entire script to be Non-Posix compliant using all the modern practices and getting rid of "bashisms" So far I have about hald the menus converted and all the variables, I am also commenting it and cleaning up/rewriting most of the older functions to make them more dynamic and quicker.

I realize that by fixing the connection timeout checker, the script does take a few seconds longer to start up, I cant really avoid this, it takes a second for the ping test to resolve the ip. If its too annoying for you, you can launch the script with
Code: 
su
velocity ol

this will start it in "offline mode" and jump straight to the main menu, bypassing the startup function
 
Happy to say I reverted to my last Nandroid, then retraced my steps getting Script 29, overclocking, installing and using DroidWall again. I stopped between each new step to update a few Market Apps. No problems this time, and everything is well. So whatever was wrong it apparently wasn't Script related. :)
 
Well, I guess the game isn't over just yet. I just now realized that in the restoration process, I missed one step which may very well be the "smoking gun" for my problem with market app updates while using DroidWall.

I forgot that I had earlier used the script to move the Dalvik-Cache to the SD, and so this time I didn't yet do that.

But now that I want to try that again, using Script 29, I keep being told I don't have enough cache memory to toggle the Dalvik-cache to SD. I have tried clearing the download cache, and cleaning the Dalvik-cache, 3 times in a row, but it still won't let me run the Dalvik toggle. I am rebooting now and will try again.

Still won't work.

In option 5 available space I get:

System 33.1M
Data 28.2M
Cache 25.3M

How much cache memory do I need showing here to toggle the Dalvik to the SD card?

What else can I try to do? I'll go ahead and make sure as many apps as I can have been moved to SD, but I had been doing that all along, so I don't think it is going to matter. Perhaps if I uninstall DroidWall and THEN try toggling the Dalvik-cache?

Do you know if DroidWall was one of the apps you mentioned would have trouble with toggling the Dalvik-Cache to SD? If it is, then I'll probably just live without DroidWall because I really liked the extra space I was getting with the Dalvik on the SD, and none of my "usual" apps were complaining.

Would this operation have any concern over the fact that the battery is at 40% right now on the Ally? I remember some ADB operations won't work with a low battery. I have it on the charger now.

EDIT --

I un-installed DroidWall, then went to Recovery and wiped all the caches, then rebooted and went to Script 29 and AGAIN wiped the caches. Now I am able to toggle the Dalvik-cache to the SD card. It is rebooting from that successful process now. If you can shed some light on which of the steps in this paragraph were likely the effective ones, I would like to know for future reference.

I can say that, several times, the only way I have been able to get my GPS to lock a location while running Velocity 1 is to go into Recovery, wipe both caches, and then reboot. I have had to do this over a dozen times so far. It will sit there and grind away for half an hour and never lock until I do this, and then it will lock within a minute or two. No idea why this works, I just know it does.

I am going to re-install DroidWall to see if I eventually get the same problem updating Market Apps. If I do then I guess it is one of those apps which doesn't like Dalvik on the SD card.
 
Zoandroid said:
System 33.1M
Data 28.2M
Cache 25.3M

How much cache memory do I need showing here to toggle the Dalvik to the SD card?

What else can I try to do? I'll go ahead and make sure as many apps as I can have been moved to SD, but I had been doing that all along, so I don't think it is going to matter. Perhaps if I uninstall DroidWall and THEN try toggling the Dalvik-cache?

Would this operation have any concern over the fact that the battery is at 40% right now on the Ally? I remember some ADB operations won't work with a low battery. I have it on the charger now.
Click to expand...

Your problem is you don't have enough room in cache to put dalvik-cache on there. The script checks to see how big your dalvik-cache folder is and if you dont have at least that much room + 10MB (for expansion) it will kick back saying you dont have enough room. Before I implemented this (its new in v26 iirc) it would cause a potential boot loop because it wouldn't have anywhere to write the dex files.

Moving apps to sd will not help because it is the size of the dalvik-cache folder that is causing trouble you can try uninstalling some apps, alternativly you can try wiping your dalvik-cache, mayhap you have some extra entries. OR if your feeling brave and have a nandroid to go back to you can "trick" it by manually clearing dalvik then running the script:
Code: 
su
rm -rf /data/dalvik-cache/*
velocity
3
8

But there is a good chance you will loop, its stopping you from moving it for good reason.


Also it is strange to me that your cache is so small space left after clearing download cache, did you just install a lot of apps from market? If so your cache can be full of the temporary apk downloads you can check by:
Code: 
su
ls /cache/*.apk
[QUOTE]If you see alot of apks in here[/QUOTE]
rm /cache/*.apk

^ this may be your whole problem looking back (I will put in the next revision to have the script auto clear these files as they are unnecessary)

As for the battery nothing I write is affected by a surplus or deficit of battery juice. (and to the best of my knowledge adb doesnt mind either?)
 
Unless im missing something you cant move dalvik2sd with the velocity script. Ive seen a few people saying so and maybe you guys mean to say dalvik2cache, you can move the script cache to the sd. Before i moved dalvik to cache i had 80mb+. I have no idea what could be taking up so much space in your cache, have you tried to wipe it in recovery. Maybe you already have dalvik2cache??
 
Sorry, yes the listing in the script says dalvik2cache. But I had thought it was actually being moved to the SD card. So I don't understand to where it is really being moved. I thought the whole point was to move it "out of the phone's internal memory".

Note at the end of my previous post I mentioned using recovery to wipe the caches and that finally fixed the problem. But they apparently would not wipe from the Script menu.

Savoxis, in answer to your question about downloading lots of apk files, yes this whole issue I had today began with the discovery that, having restored a 10 day old Nandroid, the Market reported over a dozen apps in need of an update. I was able to use "update all" to update about 4 of them, and then I looked at the Ally and found it had rebooted. From there no more updates worked, even manually one at a time. So perhaps the download cache was full of temporary files and refusing to clear for whatever reason?

I'd like to learn more about the Ally's cache. Just how big it is, how it is divided up, where it is stored, and why the Dalvik cache can't be moved to the SD card? I thought all the relocating that has taken place in various efforts for the Ally was always moving things to the SD card. It seems to make plenty of sense, especially with 16GB Class 10 cards being so affordable. Unless I am unaware of some reason it can't be done.
 
Zoandroid said:
Sorry, yes the listing in the script says dalvik2cache. But I had thought it was actually being moved to the SD card. So I don't understand to where it is really being moved. I thought the whole point was to move it "out of the phone's internal memory".

Note at the end of my previous post I mentioned using recovery to wipe the caches and that finally fixed the problem. But they apparently would not wipe from the Script menu.

Savoxis, in answer to your question about downloading lots of apk files, yes this whole issue I had today began with the discovery that, having restored a 10 day old Nandroid, the Market reported over a dozen apps in need of an update. I was able to use "update all" to update about 4 of them, and then I looked at the Ally and found it had rebooted. From there no more updates worked, even manually one at a time. So perhaps the download cache was full of temporary files and refusing to clear for whatever reason?

I'd like to learn more about the Ally's cache. Just how big it is, how it is divided up, where it is stored, and why the Dalvik cache can't be moved to the SD card? I thought all the relocating that has taken place in various efforts for the Ally was always moving things to the SD card. It seems to make plenty of sense, especially with 16GB Class 10 cards being so affordable. Unless I am unaware of some reason it can't be done.
Click to expand...

Your cache partition on the LG Ally is called mtdblock1 by the system, that is the first partition of your internal NAND storage. It has 128.1M of space. The reasons I move the dalvik-cache to the cache partition instead of the sdcard are as follows

The cache partition is 128MB, since it is being used ONLY for temporary market downloads and recovery, it is difficult to come close to filling it up.

The cache partition is INCREDIBLY faster than the sdcard (even a class 10 as the phones cannot take advantage of anything higher than class 6)

The dalvik-cache is built early on during init and at this time the sdcard is not mounted, you can mount it early but this causes problems in the form of a lot of errors when you enter userland

If you where to take the sdcard out, or plug the phone into a usb cable and "mount" the sdcard your phone would crash as it needs the dex's on the dalvik-cache to run applications (and your launcher/system framework is an application)



All this being said it would be silly to put the dalvik cache on the sdcard.

It would be a moderately ok idea to put it on a secondary partition on the sdcard, this would allow you to still have full access to the card and the dalvik cache BUT as mentioned earlier the sdcard is much slower at reading and writing, and the dalvik-cache is your executable code for the applications, code that needs to be read as fast as possible for a smooth running phone. Also making a secondary partion on the sdcard is destructive, and something I would rather not include in the script for people to accidentally use and in doing so, lose all their nandroids and sdcard info.






OK now this is why your market updates where failing:
You had dalvik-cache on cache, and I am guessing a lot of applications installed making it quite large.

You whent to update a lot of apps with the market, each one was downloaded to cache before it was installed, after it downloaded a few it ran out of space (android isnt smart in this aspect and wont remove the ones it just installed right away)

When it ran out of space it griped about not being able to install the update (since it couldnt download the tmp apk)


To fix this you should have
Code: 
su
rm /cache/*.apk

This would manually remove the temporary apks in cache so you have room to get more.

If you have a WHOLE lot of apps (even on sd because the dalvik stays) putting dalvik on cache may not be the best of ideas (hence my checker to make sure you dont move a dalvik onto a cache with no space) as you will get errors and run out of space.

Unfortuanatly the Ally was not MADE to support a HUGE amount (or a few really big) applications. We devs have been able to push the envelope a bit and give you as much space as we can. But to go nuts with it you will have to either compromise speed and stability by putting EVERYTHING on sdcard, or start thinking about getting a platform with more internal memory.

Luckilly LG gave us a little leighway by making the cache partition so large, this lets us use the "extra" space for things like dalvik and script otas, phones like the G1 only have 64MB of data and a 16MB cache (I may be off a lil Im going off memory), the next time you feel like complaining about not being able to install a lot of apps think about those poor guys.

I am going to look into a few more ideas for saving space, like moving the market cache (those pesky temporary apks) and the browser cache (temporary internet files essentially) to the sdcard, this should give you more wiggle room.
 
Anyone ever tell you that you would make a good teacher? Or perhaps write very good instruction manuals? Right on both counts!

Thanks so much for taking the time to explain that very nicely as you did. Such information is priceless, especially compared to how long someone who didn't know any of it (me) would have to founder all over the web looking for it when I would have had no idea what to search for. :)

I did read a little of a wiki on Dalvik-Cache after I had posted the above, and it became clear to me that moving it to the SD would definitely hamper performance, just like how running an OS from a bootable disc runs far more slowly than from a HD. But I liked your explanation much better. :)

I do have a lot of apps installed. The whole reason I jumped on the "root" and then custom ROM "train" last fall was because I wanted to be able to move some apps to the SD card. I use my phone almost as much as I use my PCs and notebook. It is like a mini computer, and with it I run rings around the stuff I used to do with a WM phone. I have even used it as an internet source when our cable goes out (and that was before rooting). So I am very grateful for the things you and the other developers are doing that keeps raising the bar for us on the Ally, which I admit is not any sort of "high end" device. But it does everything I ask of it, and usually does it well, thanks to the improvements you folks have provided!

I'll keep your suggestion for erasing the *.apk files in the cache in mind if I get into this situation again. It seems the reason restoring the Nandroid a second time worked is because in doing so I overwrote what was likely a bloated cache with empty space. All I found when I checked after you posted how do do it earlier was a single file oddly named "downloadfile.apk". What would that be? One of the market updates in some generic file name form perhaps?

I just re-read your post because as it sunk in I did not recall reading where it was the Dalvik cache originally resides when it is not moved to that 128MB cache you described. Does it have another section of NAND memory set aside just for it (much smaller piece, I assume)? If so, when you do move it to the main cache, what happens to that piece of memory? I am familiar with how good programmers try to utilize every byte of memory they can to keep code "tight" and running as smoothly as possible. Do you get to use that section of cache for something else then?

BTW, thanks for having the script simply prevent us from trying to move the Dalvik cache if the target isn't large enough to hold it. I would much prefer being told there is no room than for the Ally to suddenly start boot looping and having no clue why. :)

I appreciate your looking into improving the use of memory even more! I am a 'more is better' kind of person when it comes to these things. I would much rather run a 300 HP motor to do 150 HP work load than to have a 150 HP motor beating itself to death trying to keep up. I feel the same way about electronics. If a PC will run "OK" with 4GB RAM, put 8GB in it (providing of course you use a version of the OS that will access all that RAM). So the more you can give us, the merrier we shall be! :D

THANK YOU !!!!
 
That what well said Zoandroid and i concur!!:D Though I'm usually super confused about most of this stuff, I learn from all of you guys and try to apply that knowledge to learn more. Thanks guys!!!
On an unrelated note, I checked out a Tbolt today. (not that I'm getting one anytime soon) And I gotta say......WOW man....SWAAANKY!!!!
 
Zoandroid said:
All I found when I checked after you posted how do do it earlier was a single file oddly named "downloadfile.apk". What would that be? One of the market updates in some generic file name form perhaps?
Click to expand...
Exactly the market names everything it downloads downloadfile.apk, downloadfile1.apk downloadfile2.apk - etc... The command rm /cache/*.apk removes them all as * is a wildcard.

Zoandroid said:
I just re-read your post because as it sunk in I did not recall reading where it was the Dalvik cache originally resides when it is not moved to that 128MB cache you described. Does it have another section of NAND memory set aside just for it (much smaller piece, I assume)? If so, when you do move it to the main cache, what happens to that piece of memory? Do you get to use that section of cache for something else then?
Click to expand...
Your dalvik-cache directory actually does not have its own partition on the nand, instead it is on mtdblock5 (data). Which is where your downloaded applications end up getting installed to at /data/app and applications configuration data and game saves and whatnot at /data/data as well as many other configuration files spread in a series of other folders (including the velocity script: when you say, tell it you want your download cache on sd, it writes to a file on data)
mtdblock5 is ~150MB on the ally with Velocity installed and dalvik-cache on the data partition (where it started) you have ~80MB left to install apks and build dalvik-cache (dalvik *usually* rises by the close to the same size as the apk) With dalvik moved to cache, data has ~130MB left, allowing you to install quite a few more applications than you originally could.





Thanks for your support and bearing with some of the bugs, I apologize for version 28 that was all caused by a lack of $BB in front of a wget call, and a lack of failsafe mechanisms.

Bear with me some more, it will only get better.
 
I see. Now it is all coming together for me. With the Dalvik cache stuck in the same portion of memory that has to hold apps and data, it is like when you put everything (apps, data, OS) on the C drive in a PC, but the C drive is small. You will quickly run out of room (especially with the way Windows OS later versions pigged out!) Too bad we can't slap more NAND memory into the Ally. ;)

Moving Dalvik makes lots of sense now. I am glad you made that easy to do.

You're quite welcome for the support! I keep looking forward to what comes next. Like I mentioned earlier in the thread, the Ally may be considered "EOL" by the vendors, but that doesn't mean we can't keep improving on it here! :D
 
savoxis said:
I apologize for version 28 that was all caused by a lack of $BB in front of a wget call, and a lack of failsafe mechanisms.
Click to expand...

Well, sure! Obviously! Anyone can see that! :p:D



But seriously, no problem. I am just really impressed how fast you got the fix out to us!! :)
 
azuma73 said:
That what well said Zoandroid and i concur!!:D Though I'm usually super confused about most of this stuff, I learn from all of you guys and try to apply that knowledge to learn more. Thanks guys!!!
On an unrelated note, I checked out a Tbolt today. (not that I'm getting one anytime soon) And I gotta say......WOW man....SWAAANKY!!!!
Click to expand...


Thanks, Azuma! I got to wondering about the HTC Thunderbolt myself, so I looked it up in this forum. I about fell off my chair! They already have it rooted and custom ROMS! These guys are just amazing wizards, for sure!

I haven't actually seen one yet. But after my son was here last weekend and showed me Better Keyboard on his Droid X I just might be able to tolerate losing the hardware keyboard which is what got me to select the Ally in the first place. (I am guessing the TBolt doesn't have a qwerty board.) I was able to thumb type pretty easily on his X using Better Keyboard.

I sure can't say the same for his BB Storm back before he got the X. I really wanted to like that phone, but the way they did the keyboard just plain sucked. I tried honestly for 45 minutes but could not type on it. Making the whole screen depress as a "key press" was silly and didn't feel right.

As many "PC" things as I do on my phone these days, typing has to be comfortable for me.
 
savoxis said:
Thanks for your support and bearing with some of the bugs, I apologize for version 28 that was all caused by a lack of $BB in front of a wget call, and a lack of failsafe mechanisms.

Bear with me some more, it will only get better.
Click to expand...


The update package you pushed out (in such short notice I might add) worked great, thanks for the support!
 
Question:

I have a single downloadfile.apk file in /cache. Why doesn't that file get deleted when I use the Script Tool's 'clear download cache' selection?
 
Zoandroid said:
Question:

I have a single downloadfile.apk file in /cache. Why doesn't that file get deleted when I use the Script Tool's 'clear download cache' selection?
Click to expand...

These are market cache from the google market, I can have my script clear them when you clear its cache too though that is not a bad idea.
 
Seems like a good idea to me. Once the app is updated, why hang onto those files? For some apps I use, like Opera mobile, we are talking 14MB. I have used some apps that are a hefty 26MB each.

Currently Opera Mobile is the largest app file I am using. But I'll bet that day I had the problems trying to toggle dalvik2cache I likely had 35 or 40MB of market files sitting in the cache. That explains why when I used the script tool 'clear download cache' it didn't help.

The Nandroid restore I resorted to using cleaned all that out. Then I was able to move Dalvik.
 
just reflashed furnisher whipped everything but my scripts won't update. trying to change my cosmetic
 
If you used the 'original' Velocity ROM package, there will be a problem with script updates. Read back thru this thread and you'll find mention of a fix posted by Savoxis. He had to change the IP address for the script server source.
 
If you guys like, you can flash the script 29 update patch from the 3rd post, this will fix the fresh flash update issues aswell, just flash it right after you flash the fresh rom.
 
Status
Not open for further replies.
Back
Top Bottom