d99kris / nchat

Terminal-based Telegram / WhatsApp client for Linux and macOS
MIT License
524 stars 40 forks source link

Read messages on Telegram app are still marked as unread in nchat #249

Closed fulalas closed 3 weeks ago

fulalas commented 1 month ago

Current behavior: 1- open nchat and select user A chat 2- receive a message on Telegram from user B 3- read it using mobile app, not nchat 4- there's still a * in nchat beside user B

Expected: The * should disappear when we read the message outside nchat

nchat 4.86

d99kris commented 1 month ago

Thanks for reporting a bug. Do you happen to know if this is a recent regression or have you encountered this even before v4.86?

esaaprillia commented 1 month ago

I experienced the same problem, telegram messages in the group were not updated. nchat versions 4.86 and 4.50

fulalas commented 1 month ago

It's not a new issue, but I'm not sure if it ever worked.

d99kris commented 4 weeks ago

Thanks 👍 I will look into it.

esaaprillia commented 3 weeks ago

@d99kris @fulalas

https://github.com/tdlib/td/issues/2924

esaaprillia commented 3 weeks ago

@d99kris

https://github.com/tdlib/td/commit/7e950e1b880161d52d46f6dd82c2a1abe829aa5e

fulalas commented 3 weeks ago

@esaaprillia, thanks for the heads up. But today I noticed this issue also happens with WhatsApp protocol, so this is either a big coincidence or nchat has something to do.

predators46 commented 3 weeks ago

@esaaprillia, thanks for the heads up. But today I noticed this issue also happens with WhatsApp protocol, so this is either a big coincidence or nchat has something to do.

i have tried python-tg same problem too

d99kris commented 3 weeks ago

Hi - thanks for all the inputs. I'm quite certain this is an issue in nchat (not tdlib). I will look into this bug when I find some time.

d99kris commented 3 weeks ago

The bug should be fixed with above commit. The fix only addresses Telegram. I'm not able to reproduce the problem on WhatsApp. Perhaps you can help to report a new bug for WhatsApp if it's reproducible on your side @fulalas.

predators46 commented 3 weeks ago

@d99kris

no found v4.87 or v4.88

d99kris commented 3 weeks ago

no found v4.87 or v4.88

Can you please help explain a little bit more, do you mean you cannot update to that nchat version? Are you installing from source or from a package manager (which one)?

predators46 commented 3 weeks ago

no found v4.87 or v4.88

Can you please help explain a little bit more, do you mean you cannot update to that nchat version? Are you installing from source or from a package manager (which one)?

https://github.com/d99kris/nchat/releases

d99kris commented 3 weeks ago

https://github.com/d99kris/nchat/releases

Okay, so the fix is only available from git master (git clone https://github.com/d99kris/nchat) at this point. Then on a quarterly basis I'll be releasing stable versions of nchat. The next quarterly is end of this month.

predators46 commented 3 weeks ago

https://github.com/d99kris/nchat/releases

Okay, so the fix is only available from git master (git clone https://github.com/d99kris/nchat) at this point. Then on a quarterly basis I'll be releasing stable versions of nchat. The next quarterly is end of this month.

is the master branch version v4.88? this must be known

d99kris commented 3 weeks ago

is the master branch version v4.88? this must be known

Yes current master is v4.88.

predators46 commented 3 weeks ago

is the master branch version v4.88? this must be known

Yes current master is v4.88.

There should be no need to change version v4.86 if this is an improvement over version v4.86. you should change the version if you release the latest version

d99kris commented 3 weeks ago

Most users install nchat from git master source (like git clone or downloaded tar-ball), and I need a way to identify a particular "snapshot" of the code (tar-balls don't have git commit hash), so I chose to increment the version number for every functional change. So users can use the version number when reporting bugs or asking questions. You can think of the repository having rolling releases (latest git master) and then the Github releases section simply containing tags/releases identified to be more stable.

I know this approach is not common practise for release versioning, but it was chosen for pragmatic reasons.

fulalas commented 3 weeks ago

It's working for me now. Thanks a lot! :)