Velocity Script - Page 3

Zoandroid · April 21st, 2011, 11:15 AM

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.

jmar · April 21st, 2011, 01:03 PM

No problem getting to 29! Thank you!

savoxis · April 21st, 2011, 01:23 PM

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

Zoandroid · April 21st, 2011, 01:53 PM

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.

Zoandroid · April 21st, 2011, 03:50 PM

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.

savoxis · April 21st, 2011, 04:07 PM

Quote:

Originally Posted by Zoandroid

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.

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
			
		
	
	
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?)

KingOfGreen · April 21st, 2011, 04:15 PM

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??

Zoandroid · April 21st, 2011, 05:20 PM

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.

savoxis · April 21st, 2011, 05:54 PM

Quote:

Originally Posted by Zoandroid

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.

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.

Zoandroid · April 21st, 2011, 08:50 PM

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!

THANK YOU !!!!

azuma73 · April 21st, 2011, 09:10 PM

That what well said Zoandroid and i concur!!

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!!!!

savoxis · April 21st, 2011, 10:23 PM

Quote:

Originally Posted by Zoandroid

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?

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.

Quote:

Originally Posted by Zoandroid

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?

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.

Zoandroid · April 21st, 2011, 10:30 PM

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!

Zoandroid · April 21st, 2011, 10:35 PM

Quote:

Originally Posted by savoxis

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.

Well, sure! Obviously! Anyone can see that!

But seriously, no problem. I am just really impressed how fast you got the fix out to us!!

Zoandroid · April 21st, 2011, 10:42 PM

Quote:

Originally Posted by azuma73

That what well said Zoandroid and i concur!!

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!!!!

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.

artcloud · April 22nd, 2011, 07:36 AM

Quote:

Originally Posted by savoxis

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.

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

Zoandroid · April 22nd, 2011, 09:57 PM

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?

savoxis · April 22nd, 2011, 10:00 PM

Quote:

Originally Posted by Zoandroid

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?

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.

Zoandroid · April 22nd, 2011, 10:29 PM

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.

bnitty · April 23rd, 2011, 08:01 PM

just reflashed furnisher whipped everything but my scripts won't update. trying to change my cosmetic

AndroidKris · April 24th, 2011, 07:39 AM

Quote:

Originally Posted by bnitty

just reflashed furnisher whipped everything but my scripts won't update. trying to change my cosmetic

Frunisher does NOT include the VELOCITY scripts...of course it won't update.

bnitty · April 24th, 2011, 09:37 AM

meant I reflashed from furnisher to velocity

Zoandroid · April 24th, 2011, 09:44 AM

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.

savoxis · April 25th, 2011, 07:53 PM

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.

Matt's 175 · April 28th, 2011, 07:06 PM

What does "Stagefright Toggler" do?

KingOfGreen · April 28th, 2011, 08:42 PM

Quote:

Originally Posted by Matt's 175

What does "Stagefright Toggler" do?

enables or disables stagefright which is a video playback/streaming thing. thats about all i understand from it. there are posts by trident explaining it better when we first got root access to 2.2 in febvruaRY I THINK.

imnotmikal · May 1st, 2011, 04:44 PM

Just posting this because I see savoxis hasn't posted it yet.
For those of you wondering what V30 does.

Script V30
Updated OTA Rom options, added md5 check
Various script updates for cleaner code
Added 12 backdoors for cmdline script execution

Zoandroid · May 1st, 2011, 04:49 PM

What, no Video Chat?

Maximum PC | Google Rolling Out Native Video Chat for Android Phones

We could put a periscope on the camera to face it forward.

dautley · May 1st, 2011, 05:08 PM

Quote:

Originally Posted by Zoandroid

What, no Video Chat?

Maximum PC | Google Rolling Out Native Video Chat for Android Phones

We could put a periscope on the camera to face it forward.

Your assuming that anyone would want to look at that mug of yours, LOL!

Zoandroid · May 1st, 2011, 10:40 PM

Quote:

Originally Posted by dautley

Your assuming that anyone would want to look at that mug of yours, LOL!

What's not to love!??

afastyzfr1 · May 2nd, 2011, 11:11 AM

I am running Velocity 1.0 and I'm trying to update script and upgrade to new velocity but this is what I am getting

KingOfGreen · May 2nd, 2011, 12:19 PM

Quote:

Originally Posted by afastyzfr1

I am running Velocity 1.0 and I'm trying to update script and upgrade to new velocity but this is what I am getting

Try downloading and flashing the script patch in the Beginning of this thread

afastyzfr1 · May 2nd, 2011, 08:48 PM

Where is that?

KingOfGreen · May 2nd, 2011, 09:05 PM

Quote:

Originally Posted by afastyzfr1

Where is that?

its in the first few posts of this thread actually

azuma73 · May 2nd, 2011, 09:08 PM

Quote:

Originally Posted by afastyzfr1

Where is that?

http://savoxis.awesomazing.com/scriptv29-signed.zip
I believe this is what you're lookin' for!

dautley · May 3rd, 2011, 12:22 PM

Last night my phone updated to script 31. I haven't seen anything about that posted on here so just thought I'd ask. It said something about updated to include D2ALL's server and some other stuff I can't remember

Zoandroid · May 3rd, 2011, 09:45 PM

I just updated to Script 31 as well. So far so good. Making a Nandroid now to prepare for Velocity 1.1

xepicxacidx · May 5th, 2011, 06:30 AM

Is there a way to disable ota updates

Zoandroid · May 5th, 2011, 10:24 AM

Quote:

Originally Posted by xepicxacidx

Is there a way to disable ota updates

Do you mean OTA updates from your carrier or OTA updates from Velocity (scripts and ROM updates)?

For carrier updates you can just tell it to download and install, reboot after the "installation", and it will fail to install. Then clear your notifications and it should stop appearing.

savoxis · May 7th, 2011, 02:00 PM

Ok, I have been super busy, I want to get some things cranked out probably tomorrow or monday so far I have:

Support for changing boot animations with VeloMorph
Md5 functionality for font zips and themes (this way if a d/l fails you dont have to clear dl cache)
Import a few themes from UOT

Am I missing anything?

azuma73 · May 7th, 2011, 07:41 PM

Could anyone please explain difference in governors for me?

dots · May 7th, 2011, 08:05 PM

Quote:

Originally Posted by azuma73

Could anyone please explain difference in governors for me?

Look at the Govenors for Noobs section

Look at the governors for noobs section. Just a little description of each.

(DO NOT USE THIS KERNEL ON THE ALLY, IT IS FOR ANOTHER PHONE.)

azuma73 · May 7th, 2011, 08:54 PM

Thanks man, that shed some light on it. Seems, based on link info, ondemand or performance makes most sense. But, I guess it'd be fair to say Smartass is most compatible with Vel. 1.1? Since it is default. .....and it just sounds cool!

Anyway, any further tips would be greatly appreciated. Ya know, pros and cons?

I might try ondemand and see what happens?....... For shnitz and giggles..

Thanks for your time man!!!!

Zoandroid · May 7th, 2011, 09:24 PM

As I understand it from reading a few articles, Smartass is sort of a "best of both worlds" compromise between the other 2 selections. That is why it is seen as the most popular choice, and probably why Velocity uses it as the default selection.

Hi Dots! Didn't your location used to say Michigan?

azuma73 · May 9th, 2011, 06:54 PM

Governors for NOOBS:
interactive - Instead of sampling the cpu at a specified rate, the governor will scale the cpu frequency up when coming out of idle. When the cpu comes out of idle, a timer is configured to fire within 1-2 ticks. If the cpu is 100% busy from exiting idle to when the timer fires then we assume the cpu is underpowered and ramp to MAX speed.
smartass - Is an improved version of interactive governor
ondemand – Available in most kernels, and the default governor in most kernels. When the CPU load reaches a certain point (see “up threshold” in Advanced Settings), ondemand will rapidly scale the CPU up to meet demand, then gradually scale the CPU down when it isn't needed.
conservative – Available in some kernels. It is similar to the ondemand governor, but will scale the CPU up more gradually to better fit demand. Conservative provides a less responsive experience than ondemand, but can save battery.
performance – Available in most kernels. It will keep the CPU running at the “max” set value at all times. This is a bit more efficient than simply setting “max” and “min” to the same value and using ondemand because the system will not waste resources scanning for CPU load.
powersave – Available in some kernels. It will keep the CPU running at the “min” set value at all times.
userspace – A method for controlling the CPU speed that isn't currently used by SetCPU. For best results, do not use the userspace governor.

savoxis · May 10th, 2011, 11:14 AM

Amount I have spend on hosting and bandwidth for the Velocity OTA servers: $92.00
Amount I have received in donations from users: $46.00
The knowledge that no matter what we do people will still bitch and complain: Priceless

I was wondering this morning, why I had no money for gas, and after looking at the online statement from rackspacecloud I see that you all have been using ******ed amounts of bandwidth.

Needless to say this will be the last month of online functionality for the script unless something changes, I cant justify spending this much money when I dont even get "the love"

Especially because now I am pissed, with no money for gas trapped 50 miles away from home, because I cant budget and the servers are on automatic withdrawl

Zoandroid · May 10th, 2011, 03:54 PM

Say no more, my friend! A donation is about to happen NOW. I know it might not get you home, what with gas at $4+ gallon now, but perhaps others will follow suite shortly.

Edit:

Check your PayPal account. That should get you a few gallons.

Thanks for all the hard work. Whatever decisions you have to make, I for one understand and support you. My Ally is way better because of your efforts!!

savoxis · May 10th, 2011, 07:43 PM

I would like to thank you guys.

Not only was I able to get home, I also have enough now to offset this months hosting.

I have been thinking about it and should be able to keep OTA functionality, just on the slower servers.

Again, thanks guys!

azuma73 · May 10th, 2011, 08:44 PM

Today I tried out a lock-screen app, didn't like it so I immediately uninstalled it. After that I noticed that, for some reason, my phone decided to uninstall Wireless and Wired tether ......as well as Velocity wallpapers?
I'm not sure what happened and I didn't do anything different or drastic today.
So If anyone knows of some way I could get these apps re-installed I'd greatly appreciate it. Thanks guys!!!

dautley · May 10th, 2011, 09:18 PM

Quote:

Originally Posted by savoxis

I would like to thank you guys.

Not only was I able to get home, I also have enough now to offset this months hosting.

I have been thinking about it and should be able to keep OTA functionality, just on the slower servers.

Again, thanks guys!

I was wondering if you should just disable the upgrading from 1.0 to 1.1 via the scripts after a certain date to save some bandwidth and make everyone download the full ROM after that? Also with the new release and the Messaging glitch which made some have to reinstall I'm sure your servers saw far more that the normal traffic for May so far.