CM7 Nightly Discussion Thread [Old, please use new thread]

[Guest Scoopading]

The native sip client should hold wifi open in a different way. It doesn't keep the phone awake.

To run in the background and monitor for an incoming call, as well as keep the wifi open to do this, by definition it must keep some sections of the phone awake. That's precisely why it warns you that listening for incoming calls will reduce battery life.

But if anyone has a SIP account to hand and wants to test for any difference that'd be good to know. However they should also know their phones IP address, so they can ping the phone and make sure the setting is actually holding the connection open properly, and not sleeping the WIFI (even though it says it won't!).

I don't expect there'd be any major difference from what I found, but it's worth trying if someone has time. It does seem, to me, that the problem is elsewhere though..

[Guest Simon O]

RC2 builds are appearing on the CM mirrors now. No blade build yet but to be honest there won't be any difference between nightly 13 and RC2 anyway.

[Guest Rotmann]

RC2 builds are appearing on the CM mirrors now. No blade build yet but to be honest there won't be any difference between nightly 13 and RC2 anyway.

Thanks flibblesan, I saw you submitted some ext tweak, could you tell us what that is? Cheers.

[Guest t0mm13b]

Thanks flibblesan, I saw you submitted some ext tweak, could you tell us what that is? Cheers.

@Rottmann:

Heh! Check this...it details...CyanogenMod 7 RC2

Interesting diffing/patching occurred... looks like its by mistake, that the zte specific stuff wrt wakelocks are missing... two patches is all is needed... will recompile later on!

[Guest Rotmann]

@Rottmann:

Heh! Check this...it details...CyanogenMod 7 RC2

Interesting diffing/patching occurred... looks like its by mistake, that the zte specific stuff wrt wakelocks are missing... two patches is all is needed... will recompile later on!

Hehe, sorry for not answering on IRC, fighting with the sleepies :( Thanks.

[Guest wbaw]

To run in the background and monitor for an incoming call, as well as keep the wifi open to do this, by definition it must keep some sections of the phone awake. That's precisely why it warns you that listening for incoming calls will reduce battery life.

But if anyone has a SIP account to hand and wants to test for any difference that'd be good to know. However they should also know their phones IP address, so they can ping the phone and make sure the setting is actually holding the connection open properly, and not sleeping the WIFI (even though it says it won't!).

I don't expect there'd be any major difference from what I found, but it's worth trying if someone has time. It does seem, to me, that the problem is elsewhere though..

It obviously keeps the wifi part awake, but it isn't the same as stopping the phone from sleeping (which also keeps wifi on).

It drops a few pings, but stays connected.

64 bytes from 192.168.0.100: icmp_req=1044 ttl=64 time=22.1 ms

64 bytes from 192.168.0.100: icmp_req=1045 ttl=64 time=47.0 ms

64 bytes from 192.168.0.100: icmp_req=1058 ttl=64 time=57.5 ms

64 bytes from 192.168.0.100: icmp_req=1059 ttl=64 time=78.4 ms

64 bytes from 192.168.0.100: icmp_req=1060 ttl=64 time=110 ms

64 bytes from 192.168.0.100: icmp_req=1061 ttl=64 time=10.3 ms

64 bytes from 192.168.0.100: icmp_req=1073 ttl=64 time=209 ms

64 bytes from 192.168.0.100: icmp_req=1074 ttl=64 time=5.54 ms

64 bytes from 192.168.0.100: icmp_req=1075 ttl=64 time=149 ms

64 bytes from 192.168.0.100: icmp_req=1076 ttl=64 time=78.7 ms

64 bytes from 192.168.0.100: icmp_req=1088 ttl=64 time=6.21 ms

64 bytes from 192.168.0.100: icmp_req=1089 ttl=64 time=181 ms

64 bytes from 192.168.0.100: icmp_req=1090 ttl=64 time=125 ms

64 bytes from 192.168.0.100: icmp_req=1091 ttl=64 time=7.72 ms

64 bytes from 192.168.0.100: icmp_req=1092 ttl=64 time=3.47 ms

This is where I got it from - http://code.google.com/p/cyanogenmod/issue...tail?id=2722#c9

[Guest wbaw]

unfortunately it doesn't seem to be enough to reliably receive sip calls when the screen is off, using the native sip client :(

[Guest Simon O]

Thanks flibblesan, I saw you submitted some ext tweak, could you tell us what that is? Cheers.

The recovery image wasn't able to mount the ext partition so anybody that flashed recovery using rom manager would find they can no longer make full nandroid backups or even restore.

By default the recovery image doesn't mount ext partitions as Cyanogen has phased out the old style Apps2SD in favor of the Froyo method. But on devices with small data partitions it's pretty essential and useful to have the older method, which works fine in Gingerbread.

[Guest wbaw]

The recovery image wasn't able to mount the ext partition so anybody that flashed recovery using rom manager would find they can no longer make full nandroid backups or even restore.

By default the recovery image doesn't mount ext partitions as Cyanogen has phased out the old style Apps2SD in favor of the Froyo method. But on devices with small data partitions it's pretty essential and useful to have the older method, which works fine in Gingerbread.

Thanks, apps2ext is almost essential for cm7 on the blade until they fix the apps with native libs problem. Clockwork not recognising it is annoying.

Edited March 8, 2011 by wbaw

[Guest Scoopading]

This is where I got it from - http://code.google.com/p/cyanogenmod/issue...tail?id=2722#c9

Hmm. Interesting that it actually uses an undocumented call.. But..

unfortunately it doesn't seem to be enough to reliably receive sip calls when the screen is off, using the native sip client :(

..I take it, from what you're saying, that it didn't actually succeed in holding the WIFI connection open properly then ? :(

[Guest IronDoc]

For those saying it might be the saunlahti RIL, it shouldn't be in use at all in aeroplane mode anyway should it?

Also I thought it had been established that it wasn't blade-specific.

Someone willing could delete/replace to test anyway...

[Guest wbaw]

Hmm. Interesting that it actually uses an undocumented call.. But..

..I take it, from what you're saying, that it didn't actually succeed in holding the WIFI connection open properly then ? :(

It does hold the wifi connection open, but there seem to be gaps when it doesn't respond to pings.

If you look at the ping responses I quoted above then you can see it misses 12 or 13 pings, then responds to 4 or 5, then misses another 12 or 13, it keeps following that pattern while the screen is off. it never seems to disconnect fully, but it's not 100% properly connected all the time either. i'm not sure it's the weird wifi causing the voip incoming problem, it could be another bug in the sip client.

If I ring my voip/sip number from another phone, then sometimes theres no response & it wont connect, or sometimes it takes a while & then i just get one ring from the blade (screen comes on, shows a call, then goes straight off, no missed call notification), but it keeps ringing on the dialing phone. It rings as it should if the screen is turned on.

Can anybody confirm this bug? I'm using a free account from http://www.sipgate.co.uk We should report it, if it still happens on RC2 & it's not just me.

I've not tried answering any calls & talking to myself, I think I saw an issue on the tracker that says the calls are routed to the external speaker rather than earpiece, but i haven't confirmed it myself yet.

Does anybody know if the cm7 sip client will work on 3G? The Gingerbread one shouldn't by default, unless you use a small hack by Paul - http://android.modaco.com/content/google-n...p-without-wifi/

Edited March 8, 2011 by wbaw

[Guest wbaw]

nightly 14 is out.

[Guest flashprince]

And what's news? Where is the ChangeLog??? Cause Victor von Zeppelin don't refresh the first post.

Always when we got a new Nightly, its look like a Kinder Surprise. You never know what you got...

[Guest Daimaah]

And what's news? Where is the ChangeLog??? Cause Victor von Zeppelin don't refresh the first post.

Always when we got a new Nightly, its look like a Kinder Surprise. You never know what you got...

That's the joy of a nightly. Even with a changelog, it might not turn out to work like expected. It's like playing lottery, sometimes you win, most often you don't :(

[Guest Zythus]

Just started to flash it, hope it'll work good :(

@Edit

flashed, works good, I don't see any changes anyway lol

Edited March 8, 2011 by Zythus

[Guest brookergray]

nightly 14 is out.

That kinda sucks because other phones have RC2: http://www.cyanogenmod.com/blog/cyanogenmo...0-0-rc2-is-here

[Guest Zythus]

That kinda sucks because other phones have RC2: http://www.cyanogenmod.com/blog/cyanogenmo...0-0-rc2-is-here

If RC2 do not change anything, then what's the point of putting it out? Just for name? RC shall be more stable and have more improvements even by nightlies.

Edited March 8, 2011 by Zythus

[Guest rapidone]

That's the joy of a nightly. Even with a changelog, it might not turn out to work like expected. It's like playing lottery, sometimes you win, most often you don't :(

If you look at the devs board you can read that the last 2 days there were mostly "text" improvements and some mountings things that I don't use.

So I'll skip the next nightlies and wait for a nightly or RC2 that has major improvements like batters drain or rewake fix after call.

@flashprince:

Don't blame Victor von Zeppelin for not refreshing the first post at 7 am!!

[Guest hedgepigdaniel]

:

Don't blame Victor von Zeppelin for not refreshing the first post at 7 am!!

What are you talking about? I expect him to be refreshing the cyanogenmod download page 24/7! I demand service!

I presume that giving Blade N13 rather than RC2 is a decision not to feature-freeze the Blade given its late inclusion in the cyanogen project. If that's the case, then its good for us because we can still add new Blade specific features (Native wifi tethering perhaps?).

[Guest alex1alex2alex3alex4]

If RC2 do not change anything, then what's the point of putting it out? Just for name? RC shall be more stable and have more improvements even by nightlies.

From a user's POV a RC has at least one other advantage:

In the bugtracker you are advised to "not report issues based on nightlies", but a RC would allow you to

report problems, even when RC2 is functionally equivalent to N-something.

[Guest reluctant_traveller]

I would of thought build a RC2 for the blade would be necessary so that we can actually start reporting the issues noticed from the various nightlies up to this point; considering that we could only report bugs that currently exist only on RC1 :(

EDIT: was typing this as alex1alex2alex3alex4 was typing his reply :(

Edited March 8, 2011 by reluctant_traveller

[Guest DonJamal]

i dont think rc2 would be a big improvment, cuz some devices got nightly 14 after rc2... maybe thats why we dont get rc2.

[Guest Quu]

Typically, RC is just another nightly with some/most things fixed in last RC.

And you can report issues to tracker.

Also: 7 hours, airplane mode, battery lost 6%.

But thats almost same what i got with 3g on. And yes, i am on Saunalahti network.

[Guest Grain]

Anyways, discovered something pretty cool with Quu, he is a Saunalahti finnish user and he does not encounter any battery drain problems in CM7, his battery lasts as mine would last on FroYo, data and 3G enabled. This may be related to the finnish 2.1 Saunalahti RIL which is used in CM7

The Saunalahti RIL was also used in kallt_kaffe's JJ/Japanese Jellyfish Froyo ROM. See its first post, search for "Saunalahti". So I doubt that RIL lib alone is the problem (while of course that's not impossible).