*** zbenjamin is now known as Guest11758 | 02:47 | |
*** zbenjamin_ is now known as zbenjamin | 02:47 | |
*** Helle is now known as Guest71333 | 03:44 | |
*** Guest71333 is now known as Helle | 07:26 | |
*** Helle is now known as Guest43793 | 08:56 | |
*** frinring_ is now known as frinring | 09:35 | |
dcaliste | Hello flypig and pvuorela, you'll see that I've submitted upstream the IDLE improvements in QMF, including your fix (https://codereview.qt-project.org/#/c/255086/2) | 10:10 |
---|---|---|
dcaliste | I've also reworked the remaining patches in MER: https://git.merproject.org/mer-core/messagingframework/merge_requests/30 | 10:11 |
dcaliste | I've tarred the imap directory before rework, and then untar it on top of the modified one. git diff is then reporting the change of only one empty line removed. | 10:12 |
dcaliste | So I'm pretty confident that I didn't break too many things. | 10:12 |
dcaliste | flypig, one more question, do you think we should have some #ifdef USE_KEEPALIVE with _backgroundActivity->wait() or stop() when we're changing the _idling value in the error handlers ? | 10:14 |
dcaliste | I think that they are missing… | 10:15 |
dcaliste | They may be missing before already, I agree. | 10:15 |
flypig | dcaliste, this is great work. Thank you :) | 10:15 |
flypig | Let me just check about your question. One second. | 10:15 |
dcaliste | I wanted to do it for a long time, but was lacking motivation! | 10:15 |
pvuorela | dcaliste: excellent stuff! question part need to check myself too. | 10:24 |
dcaliste | About the question, it would make sense IMHO to join _idling = true/false; setPersistentConnectionStatus(true/false); _backgroundActivity->wait()/stop(); into a convenience function. | 10:25 |
dcaliste | Looking at it into imapservice.cpp, they are always used together, except in the error handler, which doesn't make sense to me. | 10:26 |
flypig | dcaliste, I can see that _idling seems to mirror ((account.status() & QMailAccount::HasPersistentConnection)), the exception being right at the top of initiatePushEmail() | 10:36 |
flypig | I'm not sure about _backgroundActivity thought. That looks a bit more complex to me! | 10:37 |
flypig | *though | 10:37 |
dcaliste | flypig, yes, indeed, at the top of initiatePushEmail, the setting to _idling = false is not followed by the setPersistentConnectionStatus(false); but I think it's a mistake. | 10:39 |
dcaliste | _backgroundActivity->stop() is called each time _idling is set to false, and _backgroundActivity->wait() each time it is set to true. I think. Except in the error handlers. | 10:40 |
flypig | Yes, I agree now. _idling and _backgroundActivity really are mirroring each other except in the error case. | 10:40 |
dcaliste | It makes sense, the call to wait() is here to make the phone wake up the network connections at 30s interval. | 10:40 |
dcaliste | And stop() stop the periodic wake up. | 10:41 |
dcaliste | So, imho, it should be called in the error handlers also. | 10:41 |
dcaliste | Not to let the phone wake up for nothing if the idle has been stopped due to network error. | 10:42 |
flypig | But in the case of error, the idle will restart itself after 30 seconds in IdleProtocol. | 10:42 |
flypig | Or maybe 60 seconds actually. | 10:42 |
*** Guest43793 is now known as Helle | 10:42 | |
dcaliste | Or should it be kept alive (the periodic wake up) indeed to allow the network issues to recover ? | 10:43 |
flypig | I'm not sure whether that was the intention with leaving it out of the code, but it might make sense. | 10:43 |
dcaliste | If idle is restarted from IdleProtocol, then it will resume the periodic wake-up anyway, with the call to ->wait() in initiatePushEmail(). | 10:44 |
flypig | Yes, that does seem to happen in practice, from the logs. | 10:46 |
flypig | Triggered by the `emit openRequest(this);` in IdleProtocol::idleErrorRecovery() | 10:48 |
flypig | So yes, it looks guaranteed. | 10:49 |
flypig | Okay, yes, I'm in agreement. | 10:50 |
flypig | So could all of this be added into setPersistentConnectionStatus? | 10:50 |
dcaliste | Ok, I'm waiting for pvuorela approving and will then update slightly the upstream MR with a convenience function doing the _idling update and the setPersistentConnectionStatus change at the same time. | 10:51 |
dcaliste | Indeed, maybe by modifying setPersistent…() and changing its name. | 10:51 |
dcaliste | Then, the MER patch bringing keepalive can be updated accordingly. | 10:52 |
dcaliste | (bringing less #ifdef also which is nice). | 10:52 |
flypig | That sounds very good to me. The theory looks sound, but I'd also like to test it out for a bit, once you've made the code changes. | 10:53 |
dcaliste | flypig, sure, thanks for doing it. | 10:53 |
flypig | No, no the thanks go to you! Your change will make things much clearer. | 10:55 |
dcaliste | Hopefully in a near future, just the keepalive stuff will be provided as patch by MER side… But remains also the QtAccount part which is a really big part but that maybe upstreamed later on also through a plugin mechanism for account handling. | 10:57 |
dcaliste | Well, let's finish this part first ;) | 10:57 |
flypig | Ha ha, yes, this is a good start :) Just this change will make things much more maintainable. | 11:01 |
dcaliste | flypig, I've made the changes to put _idling and _backgroundActivity changes inside the setPersistentConnectionStatus routine. | 12:50 |
flypig | dcaliste, nice. | 12:50 |
dcaliste | To test it, you need to get the upstream branch, from codereview.qt-project.org/qt-labs/messagingframework refs/changes/86/255086/4 | 12:51 |
dcaliste | Then, pull my idle branch on git MER, the one of the MR. | 12:51 |
flypig | The same MR 30 as before? | 12:52 |
dcaliste | And apply all the patches on top of the upstream. | 12:52 |
flypig | Okay, that sounds straightforward. | 12:52 |
dcaliste | Yes, I've scratched it with the new updated patches. | 12:52 |
dcaliste | The only issue that makes it not straitforward, is that since upstream is not accepted yet, I cannot update the submodule sha on MER. | 12:53 |
flypig | Okay, that's just a matter of waiting a bit to get the ordering right though, yes? | 12:53 |
dcaliste | Which means that you have to add a remote on your local git, on the local upstream, and checkout by hand to the right HEAD. | 12:54 |
Dakon | dcaliste: one of my comment to your patchset 3 is obsolete, the other ones would still stand. You may of course ignore them | 12:54 |
dcaliste | Depends if you want to test it before upstream acceptance or not ;) | 12:54 |
dcaliste | Dakon, sorry I miss your comment, where did you do it ? | 12:55 |
flypig | dcaliste, okay, I see what you mean. I'll give it a go and see how things go :) | 12:56 |
Dakon | freaking gerrit has eaten them or so | 12:56 |
Dakon | nope, should be there now | 12:57 |
dcaliste | Ah, yes I see, reading… | 12:58 |
Dakon | I still wonder why all of these has*Flag things needs to be 64 bit, but that is nothing that you introduced | 12:58 |
dcaliste | Dakon, it's a flag so it's just to be sure we have enough flag values available. 64 is better than 32 ;) | 13:08 |
dcaliste | Dakon, thank you for your comments. I've pushed a new patchset taking your remarks into account. | 13:17 |
Dakon | thx | 13:18 |
flypig | dcaliste, I have your version installed and working. I'll run some tests and keep it running on my main phone too, just to check there are no obvious issues. | 13:36 |
dcaliste | Great, flypig, thank you. | 13:36 |
flypig | NP. It looks good :) | 13:37 |
Dakon | does anyone of you know why the mail app keeps the trash folder? | 14:25 |
Dakon | use case is like this: I delete a mail on the phone (i.e. it moves it to trash) [some hours of delay] I see the deleted mail in trash on my PC and empty the trash | 14:26 |
Dakon | after a while everything deleted on the phone will be in trash again, but things that I put in trash e.g. on webmail are finally gone | 14:26 |
Dakon | and some of these deleted items are in trash like 25 times, which is particularly bad if that mail has a 1MB photo attached to it | 14:29 |
Kabouik | My SD card always is unusable on my Xperia X Compact (SFOS3) despite being perfectly readable on a Linux computer, formatted to ext4, and ownership set to nemo. Sometimes it fails to mount and throws a corresponding error, sometimes it mounts and shows no content | 14:41 |
Kabouik | Any ideas how to troubleshoot? | 14:41 |
mal | Kabouik: getting some logs: dmesg and journalctl | 15:03 |
Kabouik | Thanks mal. Nothing in journalctl, but dmesg throws millions of lines like this: [ 1789.162980] end_request: I/O error, dev mmcblk1, sector 93341864 | 15:12 |
Kabouik | [ 1789.190011] mmcblk1: error -84 transferring data, sector 93341792, nr 8, cmd response 0x900, card status 0xb00 | 15:12 |
Kabouik | [ 1789.599483] mmcblk1: error -84 transferring data, sector 93341808, nr 8, cmd response 0x900, card status 0xb00 | 15:12 |
Kabouik | [ 1789.999492] mmcblk1: error -84 transferring data, sector 93341816, nr 8, cmd response 0x900, card status 0xb00 | 15:12 |
Kabouik | [ 1790.402820] mmcblk1: error -84 transferring data, sector 93341824, nr 8, cmd response 0x900, card status 0xb00 | 15:12 |
Kabouik | [ 1790.787899] mmcblk1: error -110 sending stop command, original cmd response 0x900, card status 0x900 | 15:12 |
Kabouik | [ 1790.788000] mmcblk1: error -84 transferring data, sector 93341824, nr 8, cmd response 0x900, card status 0x0 | 15:12 |
Kabouik | [ 1790.810063] mmcblk1: error -84 transferring data, sector 93341888, nr 64, cmd response 0x900, card status 0xb00 | 15:12 |
Kabouik | [ 1790.872796] mmcblk1: error -84 transferring data, sector 96736712, nr 32, cmd response 0x900, card status 0xb00 | 15:12 |
Kabouik | [ 1790.889626] mmcblk1: error -84 transferring data, sector 96736712, nr 8, cmd response 0x900, card status 0xb00 | 15:12 |
Kabouik | [ 1790.912928] mmcblk1: error -84 transferring data, sector 69306368, nr 128, cmd response 0x900, card status 0xb00 | 15:12 |
Kabouik | [ 1791.303053] mmcblk1: error -84 transferring data, sector 69306368, nr 128, cmd response 0x900, card status 0xb00 | 15:12 |
Kabouik | [ 1791.319807] mmcblk1: error -84 transferring data, sector 69306384, nr 8, cmd response 0x900, card status 0xb00 | 15:12 |
Kabouik | [ 1791.689631] mmcblk1: error -84 transferring data, sector 69306392, nr 8, cmd response 0x900, card status 0xb00 | 15:12 |
Kabouik | [ 1792.069682] mmcblk1: error -84 transferring data, sector 69306392, nr 8, cmd response 0x900, card status 0xb00 | 15:12 |
Kabouik | [ 1792.122588] mmcblk1: error -84 transferring data, sector 69306392, nr 8, cmd response 0x900, card status 0xb00 | 15:12 |
Kabouik | [ 1792.519835] mmcblk1: error -84 transferring data, sector 69306400, nr 8, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1792.925850] mmcblk1: error -84 transferring data, sector 69306400, nr 8, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1792.968267] mmcblk1: error -110 sending stop command, original cmd response 0x900, card status 0x900 | 15:13 |
Kabouik | [ 1792.968369] mmcblk1: error -84 transferring data, sector 69306400, nr 8, cmd response 0x900, card status 0x0 | 15:13 |
Kabouik | [ 1793.002766] mmcblk1: error -84 transferring data, sector 69306400, nr 8, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1793.029765] mmcblk1: error -84 transferring data, sector 69306400, nr 8, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1793.072017] mmcblk1: error -84 transferring data, sector 69306400, nr 8, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1793.088046] mmcblk1: error -84 transferring data, sector 69306400, nr 8, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1793.119997] mmcblk1: error -84 transferring data, sector 69306400, nr 8, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1793.149584] mmcblk1: error -84 transferring data, sector 96736000, nr 32, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1793.192648] mmc1: sdhci_msm_execute_tuning: no tuning point found | 15:13 |
Kabouik | [ 1793.192787] mmcblk1: error -84 transferring data, sector 96736000, nr 8, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1793.245751] mmcblk1: error -84 transferring data, sector 53741568, nr 128, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1793.664177] mmcblk1: error -84 transferring data, sector 53741568, nr 128, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1793.686079] mmcblk1: error -84 transferring data, sector 53741584, nr 8, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1794.263785] mmcblk1: error -84 transferring data, sector 96733800, nr 128, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1794.643049] mmcblk1: error -84 transferring data, sector 96733800, nr 128, cmd response 0x900, card status 0xb00 | 15:13 |
Kabouik | [ 1794.643145] blk_update_request: 61 callbacks suppressed | 15:13 |
Kabouik | [ 1794.643170] end_request: I/O error, dev mmcblk1, sector 96733800 | 15:13 |
Kabouik | [ 1794.643204] end_request: I/O error, dev mmcblk1, sector 96733808 | 15:13 |
mal | Kabouik: NOOOO | 15:13 |
Kabouik | [ 1794.643229] end_request: I/O error, dev mmcblk1, sector 96733816 | 15:14 |
Kabouik | [ 1794.643254] end_request: I/O error, dev mmcblk1, sector 96733824 | 15:14 |
Kabouik | [ 1794.643279] end_request: I/O error, dev mmcblk1, sector 96733832 | 15:14 |
Kabouik | [ 1794.643304] end_request: I/O error, dev mmcblk1, sector 96733840 | 15:14 |
Kabouik | [ 1794.643329] end_request: I/O error, dev mmcblk1, sector 96733848 | 15:14 |
Kabouik | [ 1794.643353] end_request: I/O error, dev mmcblk1, sector 96733856 | 15:14 |
mal | Kabouik: how do you think it's a good idea to paste whole log here | 15:14 |
Kabouik | [ 1794.643378] end_request: I/O error, dev mmcblk1, sector 96733864 | 15:14 |
Kabouik | [ 1794.643402] end_request: I/O error, dev mmcblk1, sector 96733872 | 15:14 |
Kabouik | [ 1794.674659] mmcblk1: error -84 transferring data, sector 96733808, nr 8, cmd response 0x900, card status 0xb00 | 15:14 |
Kabouik | [ 1795.148728] mmcblk1: error -84 transferring data, sector 96734184, nr 256, cmd response 0x900, card status 0xb00 | 15:14 |
Kabouik | [ 1795.518345] mmcblk1: error -84 transferring data, sector 96734184, nr 256, cmd response 0x900, card status 0xb00 | 15:14 |
mal | there are things like pastebin | 15:14 |
Kabouik | Woops | 15:14 |
krnlyng | :D | 15:14 |
Kabouik | I wanted to pastebin it : | 15:14 |
Kabouik | Sorry to all the 238 people here. | 15:14 |
Kabouik | Note that the SD now is mounted (just removed it and replaced it several times, rebooted, and so on), and files are correctly listed in the file manager. But they are not read correctly (images are 99% grey blocks, songs don't play, etc.). I cleaned the card, checked that it is correctly positionned. | 15:14 |
Kabouik | Yeah I'm sorry, I did pastebin it but I screwed up with my clipboard :p | 15:14 |
Kabouik | I didn't think that mal, that's what I said | 15:14 |
Kabouik | However, see the bright side: #sailfishos just got a peak of activity today if you use the size of the logs as a proxy of the user activity. :P | 15:15 |
mal | Kabouik: have you tried to install sailfish utilities app and then in settings->utilities press the "clear media database" or something like that | 15:16 |
mal | maybe tracker is somehow in a confused state and needs clearing | 15:16 |
Kabouik | I haven't, but this should not affect files viewed from the File Browser or from a Directory-based music player, should it? | 15:16 |
mal | Kabouik: file browser is different than other things | 15:17 |
Kabouik | And files on the internal memory work fine. Again, the SD card works fine on my computer too | 15:17 |
mal | but those errors in dmesg suggest something is wrong | 15:17 |
Kabouik | Absolutely, and I can confirm something is wrong when reading the SD from the Xperia | 15:18 |
mal | Kabouik: how large is the sd card? maybe it's some unsupposed version | 15:18 |
Kabouik | It's a 128 GB card (116 GB in reality) | 15:19 |
Kabouik | It is supposed to be a card with high read speed | 15:21 |
mal | Kabouik: that could be the reason, 64 GB or bigger sometimes have issues, I had one sd card that doesn't really work | 15:21 |
mal | not sure if it was 64 that already have issues or only the ones bigger than that | 15:22 |
Kabouik | But I think it did work on my Jolla C on SFOS 2 before, I'm surprised if the Xperia X Compact with SFOS3 can't use it | 15:22 |
Kabouik | Too bad, no music for me on my 23.5h-long flight tonight :p | 15:24 |
Kabouik | (Well, two flights.) | 15:24 |
mal | could be something in the adaptation | 15:24 |
mal | like the kernel | 15:24 |
Kabouik | I would need to test again on the Jolla C one day, unfortunately I can't do it today | 15:25 |
Kabouik | But using the laptop confirmed that the card works perfectly well | 15:25 |
Kabouik | https://together.jolla.com/question/169040/sailfishx-microsd-card-not-detected/?answer=170002#post-id-170002 There is this, from 2017, blaming SFOS | 15:27 |
Kabouik | Unfortunately I don't think the issue has ever been addressed by Jolla, if confirmed. | 15:27 |
locusf | has anyone done an asterisk server on sailfish os? | 15:28 |
mal | Kabouik: I found a micro sd xc 64 GB card, I'll try on xa2 and jolla c | 15:28 |
Kabouik | People in the thread I linked reported cards as small as 16GB to be badly recognized by Xperia X phones | 15:30 |
mal | Kabouik: is the internal memory so full that you don't have any space for music? | 15:30 |
Kabouik | I put some there as a backup plan for this very emergency, but I won't have much diversity :p | 15:31 |
Kabouik | I completely deleted my partition on the sdcard and used fdisk to create a new ext4 partition from scratch, instead of the Sailfish utility or Gparted. | 16:16 |
Kabouik | It seems to be better now (I can play music files), but time will tell if it is really working or not. | 16:16 |
Kabouik | Using the Sailfish utility followed by devel-su chown nemo:nemo on the mountpoint did not work, and same with Gparted. Files were listed but couldn't be read properly. | 16:17 |
mal | looks like it just doesn't like the sd card, probably some issue with kernel | 16:22 |
Kabouik | I can confirm though that the same images previously wrongly read are now correctly displayed, same with the music | 16:23 |
mal | where are those located? in internal memory? | 16:24 |
Kabouik | No, on the SD | 16:24 |
Kabouik | The files on the internal memory were no issue | 16:24 |
mal | you said those cannot be read from sd card but then you something is shown correctly? | 16:24 |
Kabouik | Now that I repartitionned using fdisk instead of the Sailifsh storage utility or Gparted, yes | 16:25 |
Kabouik | But before, with Saiflish storage GUI or with Gparted on Linux, the files were listed but couldn't be read properly. Using fdisk (from Sailfish in ssh) seems to have improved the situation. | 16:26 |
mal | Kabouik: do you still see the errors in dmesg? | 16:34 |
Kabouik | I still some but as far as I understand, they are not dated, so I don't know if they are new or the same as before | 16:38 |
Kabouik | Yeah no, I still see some new errors in dmesg | 16:40 |
Kabouik | However the card does seem to work better | 16:40 |
Kabouik | I have to go though, I won't be able to troubleshoot any further, sorry. Thanks for your help mal! | 16:42 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!