@dbosley No problem. All sorted.

@Lakotaubp Good to know, I’ll try that if it happens again. Thanks.

@Stefano Thank you for the advice. I'll try asap.

Use SSH {PuTTY on Windoof} or ADB to login into phablet's shell, export the sqlite DB as indicated and move the files to your PC, use notepad or gvim to read them.

@lduboeuf Good idea. There have been several on this topic over the years and all seem to end the same way though, no conclusive fix, yet. @UniSuperBox has pointed to a good starting point https://github.com/ubports/ubuntu-touch/issues?utf8=✓&q=is%3Aissue+is%3Aopen+mms

@guru The drawback is that if we do not mark messages as read, your unread count will explode: All groups and chats will show the blue bubble with 999+ unread messages after some time. You will not know which message you have already seen and which not. How will that work? Telegram server expects in order for you to keep track of unread messages (and also positioning the view when opening a chat on the last unread message) that you submit read receipts. They will be relayed to all other parties in this chat, if needed. You cannot influence this. I will not implement a "shadow db" that keeps track of "locally read" and corresponding network messages, since that defeats the purpose of the tdlib library which encapsulates the whole Telegram protocol and also message store for us. You m,ight however want to file an issue here: https://github.com/tdlib/td/issues - those guys could in theory provide an option to not send read receipts. Again I expect they will refuse, since if its not implemented on server side, its complicated and unreliable.

@dobey Thanks, yes, that makes sense. It would be great to have the same basic set up on various devices. One good thing about Ubuntu Touch is that the MTP set up with a desktop is far smoother than it is with Android/LineageOS.

@todrab 15sec adb from XDA developers is best for windows installed system wide. That might have been an issue.

@Pingu it works - cool !

@dobey Oh right, I read bandwith instead of band. Let say it because of lack of sleep

Same here with E4.5 paired with infotainment of Seat Leon 2019.

@AppLee Personal reasons are exactly why it was written

@mirroronthewall open apps should not access data in background. But dekko has a background running daemon and some other apps can use this kind of workaround like axolotl... But as intended by UT, an app in background shouldn't use any data or CPU.

@normandc said in Simple UI documentation, need some help.: I get the feeling that what documention there is was written by developers, not end users. Pretty much. Yes. I have experience writing documentation for open source projects, but as mentioned by @poVoq, a big change is due in the next big update (OTA-12), and to be honest I'm kind of taking a break after years of involvement in another (unrelated) project. If you change your mind - we could really do with a nice and simple documentation for regular, every day usage. Of course the design goal for the OS is to be so intuitive that everybody gets it without reading a handbook. But I think it would still be nice to have it all summarized concisely in one place. Not all the swipes are as obvious as they should be. And also, having this documentation of the obvious, would provide an indication that everything else is not (easily) possible

@ziggutas Just done that ignore the adb error message if you get it and if yours like mine is wifi you will need to pick ut yourself. Installer keeps picking LTE. Now for the waking up bit. Mine has stopped the wake up thing. It might be down to it being on the original edge channel not sure. Moved back to dev with the edge merge. Now I had forgotten the wake up thing as mine doesn't as I said. Had it up and running now for half an hour on power and still no odd wake ups. Its currently on 2019-12-23. Edit: When not on mains power I still get the occasional wake up. When on mains nothing. Might be worth someone else trying.

@Fla no the Android layer is not the reason, this is very little RAM usage. The problem is that unity8 was never optimized for low-memory devices without swap: It comes from a desktop world, and with it a lot of services that just like to spend RAM. Unfortunately the core team has no resources to tackle those issues with unity8 right now, and the Yunit project, which wanted to fork and maintain unity8, has silently died away. So currently we can only be patient with that situation.