Dan, It sounds to me like you would be a perfect person to have on the beta testing team! I wish I understood how to do the analysis you described there.
Just one point - The MLO developers *do *run some issue tracking, on Jira. I'm not convinced Jira has the best system for prioritisation of issues - New issues or ideas don't get seen or promoted because the items with the most votes sit at the top of the list gathering more votes. Others have noticed that issue reports and feature requests often don't get a response, until they are fixed. We just have to trust that the MLO team will take the best ideas and most urgent issues and focus on them. On Saturday, 9 January 2021 at 23:00:43 UTC Dan wrote: > I've figured it out and fixed it. > > ------------------ > > For anyone who is interested. The sync process initially syncs all the > delta data from Android to the PC. This worked flawlessly. Afterwards the > delta data from the PC to the Android device is synced. > Here always the problem occurred. It had to do with the context and and > flag elements in the app! These were duplicated. This was noticeable as the > same names were existing multiple times but had added "1", "11" and "2" at > the end. > I myself have never created or modified any contexts or flags. Seemingly > they must have been duplicated during an older app update or after > restoring the app. What was very noticeable was that the flags had 2 > designs. > Some with one color (material design) and some with let's call it pixel > art. The pixel art ones I strongly believe where the ones MyLifeOrganized > used with an older version. > Seemingly the upgrade did not convert these flags correctly. This then > caused the issue at hand. > But these are all my assumptions as I am not the developer of this product > ;-) > > The solution was simply to remove all of the duplicated entries. > Afterwards the sync was fine again. > > Just as a note to myself. These are the currently working versions so that > I know what to go back to if it should break again in the future: > - Android = 3.4.2 > - PC = 5.1.0 > > There is no way of downloading older versions via the homepage, or is > there? > > ------------------ > > In general I am happy that I can now finally since 9.9.2018 (!) can use > the sync again. So basically can start using the PC version again. > However getting to this point was an ordeal! I tried so many times to > figure it out and contacted support and just gave up with frustration. > > I don't want to come across as mister know-it-all. My goal is simply to > give suggestions to make it easier to solve such issues in the future :-) > Your software has great and unique features! However if these aren't > usable you might loose customers. The WiFi sync (I don't want cloud) > between PC and Android was the reason I bought the software in the first > place. > As seemingly nobody else has this on the market I stuck with it even > though I had given up hope that this sync issue would ever be solved. > > I totally get that every software with a certain complexity will have > bugs. Also as I am a developer myself I fully understand that figuring out > a customer issue that you cannot reproduce yourself can be the absolute > worst. > > However it would be helpful to have better logging. For one maybe for the > customer but more importantly for you :-) > The exception and the log totally misleads you. One does believe it must > have to do with the network. So all the wrong places are checked over and > over: firewall, router, Android settings, network traffic etc. > Via procmon of Sysinternals Suite I could figure out that there is a debug > registry setting that MLO checks. However setting it did not change the > logging for me. Maybe I used the wrong value or something else is also > needed. > Maybe that would be the right place to use in these cases. > > Just as a suggestion. In cases where I could not figure out a customer > problem I created a special debug version with extensive logging to track > down how far the code comes until the issue occurs. > This is usually the last resort but then most of times very productive to > find and fix it. > > In general having to ask the customer for their data file to analyze the > problem is not ideal. I for one have some private data in my tasks which I > do not want to give to strangers. > So maybe a mechanism to override the title and notes with "gibberish" in > another profile would be a solution so that it is no problem to send that > profile to you if the customer cares about their privacy. > > Furthermore the support response times via e-mail were frustrating after > it had gone back and forth for a while: > - 8.1. and 15.1.2019 (another as I didn't get any response) -> 15.1.2019 > - 16.1. and 29.1.2019 (another as I didn't get any response) -> 29.1.2019 > - 22.4.2019 -> 25.4.2019 > - I gave up as after 7 e-mails (the first 2 had fast response times) it > seemingly was going nowhere. Since then I only used the Android version and > thought I wasted money for the PC version which had worked for the first > years. > - On Wednesday I sent another e-mail as I thought it's not right that I > paid for this software (even bought updates in the hopes it would fix it) > and have to figure it out by myself. I got an automatic reply that there > will be a response within 1 or 2 business days. I haven't had any response. > > Probably you were becoming just as frustrated with the problem as me. I > totally understand that. > Furthermore maybe the support person was on holiday or was sick. But > shouldn't then the ticket go to somebody else? > However other customers then might give up on you and will avoid your > products in the future. Some will want their money back. > > As a last suggestion. Maybe setting up an issue tracker like (i.e. via > GitHub) would be helpful. Then it easy to keep track between bugs and > future requests and if they are solved/rejected and so on. > Inside Google Groups this just goes under. At least in my opinion. > > Best regards, > Dan > Dan schrieb am Samstag, 2. Januar 2021 um 11:55:02 UTC+1: > >> To make it more concrete. This is seemingly the interesting part from the >> wifi log: >> 000005bc 11:06:36: ENTER: >> CWiFiServerProtocol::ProcessGetModificationsRequest() >> 000005bc 11:06:36: Calling callback... >> 000005bc 11:08:06: Callback returned. >> 000005bc 11:08:07: ENTER: >> CWiFiProtocol::SendCommandV() >> 000005bc 11:08:07: SendCommandV buffer - 30e64a0 >> 000005bc 11:08:07: SendCommandV nLen 12 >> 000005bc 11:08:07: SendString(`OK 62360,209 >> `) >> 000005bc 11:08:07: SendBlock(size: 13) >> 000005bc 11:08:07: 13 bytes sent >> 000005bc 11:08:07: LEAVE: >> CWiFiProtocol::SendCommandV() >> 000005bc 11:08:07: SendBlock(size: 6000) >> 000005bc 11:08:07: 6000 bytes sent >> 000005bc 11:08:07: SendBlock(size: 6000) >> 000005bc 11:08:07: 6000 bytes sent >> 000005bc 11:08:07: SendBlock(size: 6000) >> 000005bc 11:08:07: 6000 bytes sent >> 000005bc 11:08:07: SendBlock(size: 6000) >> 000005bc 11:08:07: 6000 bytes sent >> 000005bc 11:08:07: SendBlock(size: 6000) >> 000005bc 11:08:07: 6000 bytes sent >> 000005bc 11:08:07: SendBlock(size: 6000) >> 000005bc 11:08:07: 6000 bytes sent >> 000005bc 11:08:07: SendBlock(size: 6000) >> 000005bc 11:08:07: 6000 bytes sent >> 000005bc 11:08:07: SendBlock(size: 6000) >> 000005bc 11:08:07: 6000 bytes sent >> 000005bc 11:08:07: SendBlock(size: 6000) >> 000005bc 11:08:07: 6000 bytes sent >> 000005bc 11:08:07: SendBlock(size: 6000) >> 000005bc 11:08:07: 6000 bytes sent >> 000005bc 11:08:07: SendBlock(size: 2360) >> 000005bc 11:08:07: 2360 bytes sent >> 000005bc 11:08:07: Cleaning up >> 000005bc 11:08:07: Cleaned up >> 000005bc 11:08:07: LEAVE: >> CWiFiServerProtocol::ProcessGetModificationsRequest() = 1 >> 000005bc 11:08:07: ENTER: CSocketClient::GetLine() >> 00002648 11:08:36: ERROR: Timeout obtaining socket >> read availability (code 0) >> >> Why can the callback take 1,5 minutes? Is this regarding the PC or the >> Android device? >> If I interpret the log correctly it then continues but my guess is that >> because of the lost 1,5 minutes the socket timeout is reached and therefore >> it is closed. >> >> In general the communication over my wifi is fast between the devices and >> I haven't had any issues apart this one with MyLifeOrganized?! >> I am simply stumped :-( >> Dan schrieb am Mittwoch, 30. Dezember 2020 um 20:44:29 UTC+1: >> >>> Hi, >>> >>> I cannot get WiFi sync to work. The initial connect with the PIN is ok >>> and the first sync also. All tasks are synced. However if I try another >>> sync after roughly a minute the error "java.net.SocketTimeoutException: >>> Read timed out" pops up. This is then the case for every sync. >>> >>> I have tried/analyzed dozen of things but with no success: >>> - Resetting >>> - Reducing amount of tasks >>> - Checked network settings (i.a. Windows firewall) -> However it does >>> not really make any sense that it is network related as the first sync >>> works or am I mistaken?! >>> - Checked the logs. >>> - Tried different MLO versions. >>> - Contacted MLO support ages ago but it ended with no solution. >>> - etc. >>> >>> Has anybody got an idea? Thanks for any help! >>> >>> Best regards, >>> Dan >>> >> -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To unsubscribe from this group and stop receiving emails from it, send an email to mylifeorganized+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/89498b91-23dd-4f19-813c-2932a0803383n%40googlegroups.com.
