Open ghost opened 2 years ago
xPaw
commented
2 years ago Should be a simple fix here: https://github.com/thelounge/thelounge/blob/66455f2c40fd1a7b40120c4c5fddfb714fa5e955/src/models/chan.js#L239
If client.messageProvider is false, call requestZncPlayback if the cap is enabled (after the network.irc check).
brunnre8
commented
2 years ago If client.messageProvider is false,
~~It should do so even if we have a message provider. After all you can have znc in use and sqlite enabled for things like search and messages on restart still. However there may have been a downtime between TL terminating and starting back up where znc was happily logging. playback allows you to ask for a timeframe since a last received message, we should use that to query not yet received messages.~~
Mea culpa misread the code, ignore
ghost
commented
2 years ago Not fixed with #4549 that I can tell.
ghost
commented
2 years ago The Lounge (built on https://github.com/thelounge/thelounge/commit/5f7acbf9948446289054527ee9385f938a116386, which includes the linked PR) still fails to automatically get missed channel logs on server reconnect. Hexchat working as expected.
07:25:25 <xnaas> Oh no. Never got to test #4549 π¬
07:25:44 <+bookworm> no worries, I did
07:26:06 <+bookworm> and considering that I could read your convo in #ergo with slingamm I'd say it's fixed
07:27:40 <xnaas> π€Not sure if I'm missing something.
brunnre8
commented
2 years ago What's your exact config? Raw debug logs of the IRC traffic?
It loaded fine for me (been looking at the raw traffic with and without SQLite enabled)
ghost
commented
2 years ago I'm not sure what all to supply, so apologies for the extreme verbosity of this.
14:39:44 ** ZNC playback PLAY #spam 1651520235
It looks like it's trying something...but I don't get anything in The Lounge.
ghost
commented
2 years ago After that last test, I killed the docker container, sent some more messages in #spam then started up the container again. I don't see any attempt at getting playback this time.
This is the last run for the docker image being built: https://github.com/xnaas/docker-thelounge/runs/6262528859 -- I notice my version still shows as 4.3.1 in the GUI for this test container...thought it says something different when building from master? Maybe I'm misremembering.
ghost
commented
2 years ago <+bookworm> xnaas: can't reproduce on ergo, works for me
<xnaas> I'll try there as well, but it's the same software π
<xnaas> bookworm: what is your SASL auth set to?
<xnaas> does your username contain or not contain an @whatever
<xnaas> account**
<xnaas> yeah, definitely not working for me
<xnaas> joining the channel the very first time requests playback
<xnaas> but never again after thatI registered a new account there and was able to get the logs from #chat the very first time I joined, but after that, logs are never attempted to be grabbed on a reconnect.
Edit:
<+bookworm> SASL isn't enabled but that's also not part of that code path
<xnaas> So it would seem we're testing different things. π
<xnaas> This is a registered account there you're testing with?
<+bookworm> no
<xnaas> Then we've found a difference. π¬
<+bookworm> yes, but that's not part of that codepath
<xnaas> Yes, but that probably changes how ergo interacts with the client π
<+bookworm> playback is pull not push, TL needs to initiate it and you should see that in the debug logs
<+bookworm> I've a hunch but it needs to wait until tomorrow morning
<+bookworm> thanks for testing
<xnaas> I'm wondering if it's an order of operations, thing.
<xnaas> The one time I saw it actually request playback in raw logs, that was before thelounge ran JOIN against the channel.
<xnaas> Indeed. If I manually rejoin the channel, the missing logs are requested as expected.Seems like an order of operations issue.
proton-ab
commented
1 year ago This is caused by re-connection to server going to separate code path here: https://github.com/thelounge/thelounge/blob/a7b85db9906b63632fa946dee7b9385c90d82cc0/server/plugins/irc-events/join.ts#L29 which does not call for ZNC playback. The reason it does not is that the function which does it (Chan.loadMessages) also loads messages from message store provider, which would duplicate all past entries. The logic needs to be split in Chan model and then the code path above updated so that it requests playback.
Also worth of note is that we should likely print stuff like channel modes again in such cases and in case where server reports ZNC playback capability we should also likely not inject "{me} joined {channel}" by wrapping new Msg with something like if (!network.irc.network.cap.isEnabled("znc.in/playback") || !self) {
Other thing to note is that ZNC playback module takes time as epoch seconds with optional milliseconds as floating point, but we send it as milliseconds which is coerced to seconds only, losing precision and possibly fetching duplicate messages in the process.
And yet another thing - in Chan.loadMessages we do not provide ending time for playback module, which means that current time is used. While this is fine, it does result in duplicated messages if message store (such as SQLite) takes over a second to load message for given channel, during which time we delay calling playback yet we accept messages from IRC.
The Lounge version: official 4.3.0-alpine docker image
The Issue
To sorta TL;DR the chatlogs below:
CAP REQsznc.in/playbackThe Solution
The Lounge should either:
znc.in/playbackand get playback since last seen server time on reconnecthave the option to not request
znc.in/playbackIRC context
irc://irc.ergo.chat/#ergo
> \irc://irc.libera.chat/#thelounge
> \