Hi Dan,

Andrey is here, the developer. First of all, let me say that I am very 
sorry to hear that you had issues with wifi sync.

You are right that such issues are very hard to deal with, especially if 
you cannot reproduce the problem. From our experience in most cases, it is 
related to the network or firewall configuration issues.

>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.
This usually happens if, for example, you create a new data file which 
already contains default contexts/flags. After that, you sync this file to 
your file on the Cloud or through wifi and since you already have such 
contexts they are renamed during sync to avoid duplication. Our tests show 
that this case is handled normally by MLO. For the app they are different 
contexts and it should not be a problem for the sync.

>The solution was simply to remove all of the duplicated entries.
>Afterwards the sync was fine again.
This is very interesting. We did not hear about such causes of the sync 
issues. In our tests even if contexts are renamed to avoid duplication the 
sync works as expected. I would like to investigate this case in more 
details.

>There is no way of downloading older versions via the homepage, or is 
there?
Some old versions are available on the site, but you can always ask me to 
send you an older version.

>My goal is simply to give suggestions to make it easier to solve such 
issues in the future :-)
Thank you. This is very much appreciated.

>In cases where I could not figure out a customer problem
>I created a special debug version with extensive logging
Yes sure we have a different level of logging for debugging and release 
versions and we send debug version to users in some cases. We also have a 
closed team of beta testers who always run the beta version with extended 
logs so that we can identify the issues before the public release.

>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.
Yes sure, thanks for suggesting. We do have such a thing in MLO from the 
very beginning. So I would appreciate it if you contacted us on 
[email protected] again and help us to reproduce the problem with 
your data file which which is obfuscated by you before sending. We will 
provide all the details. I hope you still have an old backup file where you 
could reproduce the sync issue.

>Probably you were becoming just as frustrated with the problem as me.
>I totally understand that.
Thanks for that Dan. Yes, the support agents just did not know what to 
answer. They were waiting for analysis from the developers (and from me 
personally) and as you know this is usually a bottleneck. I am sorry about 
that. With your help, however, I think we could now analyze the issue again 
more effectively to avoid it in future for your and for others.

>Maybe setting up an issue tracker like (i.e. via GitHub) would be helpful.
Yes, we do have issue tracking internally which is used for the development 
and communication between support team and developers. I will see how we 
could improve this part as well, thank you.

Thank you Dan one more time for the very detailed message and for the 
suggestions. Also, I would like to invite you to the team of the beta 
testers. This team always has the latest version with new features. I 
personally have closer communications with beta testers so that we select 
new features to develop and high priority fixes. I would love to see you on 
this team. Let me know if you are interested  :-)

--
Sincerely,
Andrey Tkachuk, CEO and Founder
www.mylifeorganized.net




On Sunday, January 10, 2021 at 1:00:43 AM UTC+2 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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/mylifeorganized/5da85fbd-da5a-4e57-9db9-8dc606509d0dn%40googlegroups.com.

Reply via email to