| sicelo | i notice nearly every SMS on my Droid 4 has a 1970 timestamp, while the time is correct on the device | 17:14 |
|---|---|---|
| sicelo | am I the only one? | 17:16 |
| Wizzup | with latest conversations I suspect? | 17:32 |
| Wizzup | dsc_: ^ ? | 17:32 |
| sicelo | i'm on latest, yes. it could be the time-related commits in rtcom? | 17:41 |
| dsc_ | sicelo: if it is 1970 in `Events` @ el-v1.db, then dont think it is conversations | 18:02 |
| dsc_ | https://git.maemo.org/leste/conversations/src/branch/master/src/lib/tp/tp.cpp#L681 | 18:03 |
| dsc_ | https://git.maemo.org/leste/conversations/src/branch/master/src/lib/tp/tp.cpp#L716 | 18:03 |
| dsc_ | that first one is silly maybe hmm | 18:03 |
| dsc_ | https://github.com/TelepathyIM/telepathy-qt/blob/188dece432d090809c5ad88a91cd573c5af61c09/TelepathyQt/message.cpp#L235 | 18:06 |
| dsc_ | returns the time when this message was sent | 18:06 |
| dsc_ | do we get such information with SMS | 18:06 |
| dsc_ | some protocols support 'the time it was sent', thats why it gives precedence to that | 18:08 |
| dsc_ | sicelo: you can modify this to take .received() instead, see if it fixes | 18:10 |
| Wizzup | https://gitlab.freedesktop.org/telepathy/telepathy-qt/issues/1 | 18:11 |
| Wizzup | I don't think this will bite us in daedalus at least, time_t is not 64 bit there | 18:12 |
| Wizzup | but maybe freemangordon can confirm | 18:12 |
| sicelo | dsc_: yes ofono (and i guess sms in general) reports two timestamps: time it was sent by the network/sender, and time it was received. in most cases, they're the same time | 18:14 |
| dsc_ | there is a isValid() check on the datetime object, in case telepathy-qt returned a default one (which would eval to False) | 18:16 |
| dsc_ | perhaps you can check with dbus-monitor to see which timestamps are set | 18:17 |
| dsc_ | https://git.maemo.org/attachments/d17c4221-e82c-477f-9605-879bf1354ad0 <== message-sent, message-received | 18:17 |
| sicelo | just checked el-v1.db .. timestamps are correct there | 18:18 |
| sicelo | 185|3|1|1746884748|1746874728|1746874728|1|0|0|0|0|ring/tel/account0|<SelfHandle>|MTN MoMo||<#> Y?ello. Please enter the following code:7520 to complete your login. Be Careful. NEVER Share this code. RdbS6eMOXvx > N/RywfrtIZL>|TN MoMo | 18:19 |
| sicelo | 186|3|1|1746884846|1746874792|1746874792|1|0|0|0|0|ring/tel/account0|<SelfHandle>|MTN||You have successfully purchased 12 Daily Minutes. Your bundle will expire 11/05/2025 at 12:59:54. For Balance enquiry dial *686*5#|MTN | 18:19 |
| dsc_ | how do you see this 1970 | 18:19 |
| sicelo | 1970 in conversations UI for | 18:19 |
| dsc_ | mkay | 18:20 |
| dsc_ | ill copy that row and check myself later | 18:20 |
| Wizzup | keep in mind sicelo is on 32 bit | 18:31 |
| Wizzup | our vm images are 64 bit | 18:31 |
| sicelo | saw this while trying to chase down my repeated SMS issues, which is more annoying than the date issue | 18:31 |
| sicelo | dsc_: https://0x0.st/8y-o.png | 18:31 |
| Wizzup | this is a modem / operator issue | 18:32 |
| Wizzup | (so kernel or ofono most likely) | 18:32 |
| Wizzup | I have also had this happen to me on fremantle some times | 18:32 |
| Wizzup | it lasted for weeks :D | 18:32 |
| sicelo | never happened for me for the 10+ years that i used Fremantle. and didn't happen on the N900 with Leste the last few weeks that I used it. i'm quite sure it's Droid 4 specific in my case, kernel or ofono | 18:34 |
| Wizzup | yes, it is a problem in our kernel or ofono, but it isn't unique to us is what I meant | 18:35 |
| Wizzup | I think somewhere the modem doesn't acknowledge we received the message to the operator | 18:35 |
| sicelo | i understand you, and agree :-) | 18:36 |
| dsc_ | sicelo: \o/ | 18:41 |
| arno11 | btw it is -still- normal in conversations to not be able to see sms received while the phone is off ? | 20:51 |
| arno11 | *is it | 20:54 |
| arno11 | ah, i got the 1970 issue as well | 21:04 |
| arno11 | and phone numbers seem not shown anymore (when i receive a new sms from a known contact) | 21:06 |
| arno11 | *with last conversations | 21:07 |
| Wizzup | is it last conversations or last rtcom I wonder | 21:19 |
| arno11 | both | 21:20 |
| arno11 | ah sorry | 21:20 |
| Wizzup | :p | 21:20 |
| sicelo | mmm, arno11, messages sent while device was off are lost? why would that be? i guess network sends them when we go online next, so i don't see why we would lose them | 21:29 |
| arno11 | sicelo: quite agree but i tried several times from my andro, 100% lost | 21:31 |
| sicelo | odd. this needs investigation. i wouldn't like to lose messages. would rather have them repeated (even though it can get annoying eventually) | 21:32 |
| sicelo | i'll try and test it | 21:33 |
| arno11 | yep, sure @repeated | 21:33 |
| arno11 | ok | 21:33 |
| dsc_ | arno11: what kind of messages are lost? | 21:36 |
| arno11 | sms's | 21:36 |
| dsc_ | at least in converastions SMS are treated a bit different and never dropped if received | 21:41 |
| dsc_ | sometimes I have to drop messages when scrollback comes in but we already have it (matrix/xmpp) | 21:42 |
| dsc_ | but this mechanism active for SMS | 21:42 |
| dsc_ | but this mechanism *is not* active for SMS | 21:42 |
| sicelo | arno11: you can stop ofono, and cellulard, send yourself an sms, start ofono, monitor ofono via dbus, then start cellulard | 21:45 |
| arno11 | ok, will try | 21:45 |
| sicelo | this will hopefully show us if ofono ever receives that message. | 21:45 |
| arno11 | ok | 21:46 |
| sicelo | maybe your operator has short life for undelivered messages ... | 21:46 |
| t_F_t_ | arno11: usb port should be fine - the message on my PC is correct as well and provides feedback that the N900 is found and data is send and received via udo ./0xFFFF -m test/u-boot-2013.04-2.bin -l | 21:47 |
| arno11 | sicelo: maybe | 21:47 |
| arno11 | t_F_t_: ok | 21:47 |
| t_F_t_ | arno11: if there is a better method for the N900 - can you provide a link. I thought this one was the most detailed. | 21:48 |
| t_F_t_ | https://leste.maemo.org/Nokia_N900 | 21:49 |
| arno11 | the easier way is the method with uboot from fremantle imo | 21:50 |
| sicelo | t_F_t_: where exactly do you get a problem? i used those steps on an N900 a couple of weeks ago | 21:52 |
| t_F_t_ | sicelo: Followed everything until ./0xFFFF -b | 21:53 |
| t_F_t_ | It seemed to be working - terminal on my PC showed the output that is exactly the same as the explanation - screen on my N900 appears to be turned off - no menu whatsoever, just black. | 21:53 |
| arno11 | sicelo: @sms, really weird: it works using your process | 21:53 |
| t_F_t_ | so the screen of my N900 doesn't show a menu. | 21:53 |
| arno11 | sicelo: but not @boot | 21:54 |
| t_F_t_ | well - I have another N900 that I can try it with later - just to rule out any hardware issue. | 21:55 |
| sicelo | arno11: then it suggests your operator has a short lifetime for waiting SMSes. it seems to be a boot problem simply because of time | 21:55 |
| sicelo | t_F_t_: you can try start from scratch, and run the command like `0xFFFF ... -l && sleep 2 && 0xFFFF -b` ... you are possibly waiting too long between -l and -b | 21:56 |
| sicelo | also, as noted in the wiki page, the screen might not be backlight after the -b ... you have to look at the screen sideways or shine a light on it :-) | 21:57 |
| t_F_t_ | sicelo: thx - will probably try that tomorrow and if it fails give another N900 a spin. Battery is pretty low now on both of them - will charge them tonight. | 21:58 |
| arno11 | sicelo: not convinced @shortlife time | 21:58 |
| sicelo | arno11: you are probably right | 21:59 |
| sicelo | if tp starts long after ofono, then the message might be lost indeed, because ofono will receive it immediately and nothing's there to pick it from dbus | 22:00 |
| sicelo | so what needs to happen is - ofono must be configured to start *after* tp (or whoever fetches SMSes from ofono) | 22:01 |
| arno11 | yeah and telepathy is quite 'buggy' on boot on n900 btw | 22:01 |
| arno11 | should be complicated as tp seems to start very late after boot | 22:03 |
| arno11 | like during H-D loading | 22:03 |
| sicelo | we should wait for it regardless | 22:03 |
| arno11 | ok, i can try to block ofono on boot and start it manually once h-d is completely ok | 22:04 |
| sicelo | we don't necessarily need to fiddle with ofono itself. we could do it in cellulard ... since that's the one that brings modem only | 22:05 |
| sicelo | s/only/online/ | 22:05 |
| arno11 | ok | 22:05 |
| arno11 | let's try | 22:05 |
| arno11 | need to reboot | 22:08 |
| sicelo | mmm, cellulard runs as root. it should be able to run as user actually | 22:08 |
| sicelo | Wizzup: where/how does the tp stack get started? | 22:14 |
| arno11 | sicelo: sms still lost | 22:21 |
| sicelo | what was your process? | 22:21 |
| sicelo | do you know how the TP stack is started? | 22:22 |
| arno11 | move cellulard in home, turn off, send sms, turn on, wait for h-d loading completely, start cellulard | 22:23 |
| arno11 | once the modem online, able to receive sms, but not the one sent offline | 22:24 |
| arno11 | @tp start, no idea | 22:25 |
| sicelo | just before starting cellulard, in a separate terminal, start monitoring ofono on dbus. something like `gdbus monitor --system --dest org.ofono` should do. i'm quite sure the waited-for SMS should show up at least in ofono. either way, we do need proof to be sure it really arrives | 22:27 |
| arno11 | ok let's do it again | 22:30 |
| Wizzup | wait, you think the problem is in tp-ring? | 22:40 |
| sicelo | no :-) | 22:41 |
| Wizzup | ah, ok | 22:41 |
| Wizzup | so most of these things don't matter until the modem is onlined | 22:41 |
| sicelo | just trying to find a good time to start cellulard. just starting it at boot is not very safe for SMS, because of how ofono handles SMS | 22:41 |
| sicelo | the theory i have for now is that the modem gets onlined before tp is ready, so the SMS arrives on dbus but no one is there to pick it up. so i'm not sure 'who' exactly is that. i'm guessing tp, but i am not fully in touch with our stack | 22:44 |
| arno11 | sicelo: maybe i'm silly or tired or both but: | 22:45 |
| arno11 | still nothing from dbus | 22:45 |
| arno11 | and ofono monitor | 22:45 |
| arno11 | and i'm a ble to receive sms *without* cellulard running | 22:46 |
| Wizzup | are you manually restarting services or is this on boot | 22:46 |
| sicelo | yes, cellulard only onlines the modem. you can stop it once modem is online | 22:47 |
| Wizzup | ofono should never be put directly in online mode by anything but cellulard | 22:47 |
| Wizzup | cellulard just makes the modem offline and online basically | 22:47 |
| arno11 | (after boot, i start cellulard manually) | 22:47 |
| Wizzup | and the modem should be offline on boot without cellulard running | 22:47 |
| Wizzup | I'm confused | 22:47 |
| sicelo | arno11: but your description makes it sound like the issue is with your operator then. you're sure the offline-sms issue doesn't affect other phones? | 22:47 |
| arno11 | absolutely no issue on other phones | 22:48 |
| Wizzup | to me it seems that if you think there is a race condition then the only thing that matters if when cellulard onlines ofono modem | 22:48 |
| arno11 | i'm confused as well | 22:48 |
| Wizzup | if that should happen later, then let's make that happen later | 22:48 |
| Wizzup | ofono will start but the modems must be offline after boot | 22:49 |
| sicelo | ok. i'll give it a try on my own device (although i don't really have time) :-D | 22:49 |
| sicelo | Wizzup: yes modem definitely boots up in offline state for sure | 22:49 |
| sicelo | ufnortunatley if he doesn't see the message via ofono dbus, then we can't blame tp/conversations, etc. | 22:51 |
| arno11 | i think something is racy honestly, or another service runs cellulard (stopping/blocking it from init.d doesn't offline the modem) | 22:52 |
| sicelo | you mean that your modem is online before cellulard brings it online? | 22:53 |
| arno11 | exactly | 22:53 |
| sicelo | are you sure about this? | 22:54 |
| arno11 | and even if i stop cellulard from init.d, still able to receive sms | 22:54 |
| arno11 | current cellulard status: stopped | 22:54 |
| sicelo | onlining ofono modem is quite a chore ... nearly impossible for it to happen by accident :-) | 22:54 |
| sicelo | you first need to Power it on, then Online. | 22:55 |
| * sicelo is rebooting the Droid 4 | 22:55 | |
| sicelo | arno11: correct way to disable it is `sudo rc-update del cellulard`. this works as expected on my D4. i can try on N900 too, but really should be exactly similar | 23:00 |
| arno11 | ok | 23:02 |
| arno11 | hmm, what is exactly expected when i run the rc-update command ? | 23:05 |
| sicelo | rc-update alone tells you all defined services, and which runlevel they're applicable to | 23:06 |
| sicelo | rc-update del service removes a service from that list | 23:06 |
| sicelo | rc-update add service adds a service to that list | 23:07 |
| sicelo | in this case, the runlevel is `default`. | 23:07 |
| Wizzup | arno11: so, remember, cellulard only online and offlines ofono | 23:08 |
| Wizzup | it doesn't need to run for ofono to function, ofono just needs it to online it | 23:08 |
| arno11 | ok | 23:09 |
| arno11 | let's reboot again, and then zzz | 23:10 |
| Wizzup | so rc-update del/add can change if openrc starts a service as part of a runlevel, but it does not prevent the service from being started | 23:11 |
| sicelo | Wizzup: the d4 capacity saving script is now useless .. it stores charge_full, which is the only R/W property. as long as charge_now is reported as 0, knowing charge_full is not useful for 'new' upower. | 23:11 |
| sicelo | re: rc-update, yes. there's nothing else that starts cellulard on a normal Leste installation. and yes, we do want to start it manually later on, rc-service cellulard start | 23:12 |
| sicelo | @script, so that's why we kept wondering why after reboot the calibration is lost. script does work, but upower doesn't care :p | 23:14 |
| sicelo | anyway now we don't care either. so WONTFIX. | 23:15 |
| sicelo | interestingly, regarding the repeated SMSes ... after booting, the sms reception was fine/normal. i have 3 SMSes for the first two days from last bootup. the issue surfaced after two days up to now at 5 days uptime | 23:27 |
| Wizzup | sicelo: I think that might be good news @ d4 script, better not to have them | 23:29 |
| Wizzup | sicelo: I don't agree, I don't think the problem is when cellulard starts, the problem is when it makes the decision to online | 23:29 |
| sicelo | afaik, it doesn't make any decision :-) | 23:31 |
| sicelo | it starts, finds modem, and onlines immediately | 23:32 |
| sicelo | of course it does respect if we have set offline mode specifically, but otherwise makes no decisions of its own. and i don't see a problem with that | 23:33 |
| Wizzup | well, maybe it needs to wait for a specific dbus signal to start working | 23:34 |
| sicelo | i think we should start it as user, not root. quite sure there's nothing root-specific in it. then we could orchestrate things so user starts it once something's available to pick up any early SMSes | 23:34 |
| Wizzup | why? | 23:34 |
| sicelo | not sure i get the question :-) | 23:35 |
| sicelo | why we start as user? or why delay its start? | 23:35 |
| Wizzup | what would this additional orchestration be? | 23:35 |
| Wizzup | both | 23:35 |
| sicelo | user - makes it easy to start from session without hacks | 23:36 |
| Wizzup | what hacks? | 23:36 |
| Wizzup | We have a session script that sends a dbus signal already that says hildon-desktop is ready | 23:36 |
| Wizzup | but I don't know how you're going to ensure that tp-ring is running and initialised within the xsession | 23:37 |
| Wizzup | However, it seems something that cellulard could check for pretty easily | 23:37 |
| sicelo | delay - the problem with ofono is that it doesn't have its own store for SMSes. it's a general ofono limitation. so if you are not ready to pickup the message as soon as it shows up on dbus, it's gone forever. so you absolutely need to ensure someone's ready to pick that message up *before* you go online. by onlining after that someone is ready, no problemo | 23:37 |
| Wizzup | I understand ofono not storing things, what I don't understand is why we want add this instrumentation in the xsession script and how that would be the best way to orchestrate it | 23:38 |
| arno11 | i ran rc-update del cellulard and remove init script and the modem still goes online on boot | 23:38 |
| Wizzup | We just want cellulard not to online the modem until tp-ring is running | 23:38 |
| Wizzup | arno11: yes, you missed it, but rc-update del doesn't do what you think it does | 23:38 |
| sicelo | arno11: then your system is different from what we're running | 23:39 |
| Wizzup | 23:11 < Wizzup> so rc-update del/add can change if openrc starts a service as part of a runlevel, but it does not prevent the service from being started | 23:39 |
| Wizzup | if anything has 'depend cellulard' or something, then it will still start | 23:39 |
| sicelo | there's nothing like that though :-) | 23:39 |
| arno11 | ah ok, that was my real question | 23:39 |
| Wizzup | sicelo: like what? | 23:39 |
| sicelo | nothing that depends on cellulard | 23:40 |
| sicelo | trust me on this ... i've done this lots of times while working on ofono with fmg | 23:40 |
| Wizzup | fine | 23:40 |
| Wizzup | in any case, just rename the init script | 23:40 |
| sicelo | rc-update del should be enough on a standard leste system | 23:40 |
| sicelo | but yeah, other things can work, true | 23:40 |
| Wizzup | in any case, it seems to be we just don't want cellulard to online until a certain condition is hit | 23:41 |
| Wizzup | so we just either have it check directly or listen to a dbus signal to know this condition is hit | 23:41 |
| sicelo | agreed | 23:41 |
| Wizzup | remember that tp-ring and all other tp stuff gets started implicitly when sphone or conversations get through some part of their initialisation | 23:41 |
| sicelo | ah, so they're dbus-activated? | 23:42 |
| Wizzup | and it's pretty easy to listen to tp-ring 'joining' the dbus bus | 23:42 |
| Wizzup | yes, I'm 99% sure they are all dbus activated | 23:42 |
| Wizzup | and all cellulard does is listen on dbus, act on dbus, and listen to gconf (I think, for offline mode) | 23:42 |
| sicelo | had no idea, hence asked a number of times :-) | 23:42 |
| Wizzup | sorry, must have missed it | 23:43 |
| sicelo | then yes, i agree that's a good solution | 23:43 |
| Wizzup | cool | 23:44 |
| sicelo | arno11: btw, when your modem onlines mysteriously, you say cellulard is not running? that also proves you have something completely independent doing this onlining | 23:44 |
| sicelo | you need to find it, and remove it | 23:44 |
| arno11 | yes agree...but what's going on lol ? | 23:45 |
| sicelo | 22:54 < arno11> current cellulard status: stopped << | 23:45 |
| sicelo | heh, you tell us what you did to the system :p | 23:45 |
| sicelo | maybe in the past, you set some ofono-scripts thingy to do that for you? | 23:45 |
| arno11 | no, misunderstanding | 23:46 |
| arno11 | i just did that to test and block cellulard today | 23:46 |
| arno11 | i mean i blocked cellulard on boot and the modem still goes online | 23:46 |
| sicelo | 22:54 < arno11> current cellulard status: stopped << this was at boot, before you started cellulard yourself, but modem was already receiving sms? | 23:47 |
| Wizzup | arno11: sicelo: is saying that nothing in else onlines ofono apart from cellulard unless you have something custom | 23:47 |
| arno11 | i don't have any custom thing on boot | 23:47 |
| Wizzup | could be some weird dependency, maybe modemmanager is somehow running, who knows | 23:47 |
| sicelo | yeah, in fact that's why fmg wrote cellulard to begin with. in the past, it was started by some hack .. can't recall what that was :-/ | 23:48 |
| Wizzup | sicelo: libicd-network-ofono I think | 23:48 |
| Wizzup | btw, if you need a work around now, just set a pin for sms :p | 23:48 |
| Wizzup | s/sms/sim/ | 23:48 |
| sicelo | yup @ pin | 23:48 |
| sicelo | but then N900 gets painful to boot with sim pin :p | 23:49 |
| sicelo | fun | 23:49 |
| Wizzup | bedtime for me, ttyl | 23:53 |
| arno11 | i'm still convinced something is really racy. anyway bedtime as well, gn guys | 23:55 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
