Playback freezing on 1.6.0 on OS X #480

Closed
opened 2026-10-05 04:24:16 +02:00 by adam · 12 comments
Owner

Hi there,
Upgraded from 1.4 to 1.6.0 on my Mac server via homebrew and I'm now getting playback freezing when a client connects.

Clients gets about 1/5th of the way through a quite large playback set (~30 channels, 1500 lines) and then sits there with no additional updates from the ZNC server.

Generated a fresh config with no change in behaviour.

User options are:

LoadModule = chansaver
LoadModule = controlpanel

MaxJoins = 15
Buffer = 1500
MultiClients = true
AutoClearChanBuffer = false

Reverting to 1.4 immediately resolves the issue.


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

Hi there, Upgraded from 1.4 to 1.6.0 on my Mac server via homebrew and I'm now getting playback freezing when a client connects. Clients gets about 1/5th of the way through a quite large playback set (~30 channels, 1500 lines) and then sits there with no additional updates from the ZNC server. Generated a fresh config with no change in behaviour. User options are: ``` LoadModule = chansaver LoadModule = controlpanel MaxJoins = 15 Buffer = 1500 MultiClients = true AutoClearChanBuffer = false ``` Reverting to 1.4 immediately resolves the issue. ## <bountysource-plugin> --- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/8669950-playback-freezing-on-1-6-0-on-os-x?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin> <!-- github-sync-id:58015204 -->
adam closed this issue 2026-10-05 04:24:16 +02:00
Author
Owner

Buffer = 1500

is probably the issue.

> Buffer = 1500 is probably the issue. <!-- github-comment-id:74807109 -->
Author
Owner

Possibly. Seems to occur even when those buffers aren't close to full though and it's been flawless on 1.4

Agree it's perhaps an "ambitious" configuration.

Edit: From some additional testing it appears the buffer size is a contributing factor but not the sole cause. I can get it to occur with buffer sizes as low as 50 though it's MUCH more consistent in failing with larger buffer sizes. Much more than 100 gets marginal.

Possibly. Seems to occur even when those buffers aren't close to full though and it's been flawless on 1.4 Agree it's perhaps an "ambitious" configuration. Edit: From some additional testing it appears the buffer size is a contributing factor but not the sole cause. I can get it to occur with buffer sizes as low as 50 though it's MUCH more consistent in failing with larger buffer sizes. Much more than 100 gets marginal. <!-- github-comment-id:74812095 -->
Author
Owner

This seems exactly like the issue I have been getting for a while now, no matter the buffer size it still hangs.

This seems exactly like the issue I have been getting for a while now, no matter the buffer size it still hangs. <!-- github-comment-id:75388706 -->
Author
Owner

Which clients are you using? Is SSL enabled? "A fresh config with no change in behaviour" means no other modules in addition to the defaults loaded, right?

I've been testing with a buffer size of 1500, ZNC joined to 30 (some of the largest according to irc.netsplit.de) channels on Freenode. No troubles so far...

Which clients are you using? Is SSL enabled? "A fresh config with no change in behaviour" means no other modules in addition to the defaults loaded, right? I've been testing with a buffer size of 1500, ZNC joined to 30 (some of the largest according to irc.netsplit.de) channels on Freenode. No troubles so far... <!-- github-comment-id:75428464 -->
Author
Owner

Client doesn't seem to matter. I get the same results with mIRC, Hexchat, Colloquy (OS X and iOS), Limechat iOS and Textual.

SSL is on. No other modules apart from defaults.

Client doesn't seem to matter. I get the same results with mIRC, Hexchat, Colloquy (OS X and iOS), Limechat iOS and Textual. SSL is on. No other modules apart from defaults. <!-- github-comment-id:75469296 -->
Author
Owner

If you disconnect client, and connect again, what happens?
Also try to run znc -D

2015-02-22 14:59 GMT-08:00 Bill Standen notifications@github.com:

Client doesn't seem to matter. I get the same results with mIRC, Hexchat,
Colloquy (OS X and iOS), Limechat iOS and Textual.

SSL is on. No other modules apart from defaults.

—
Reply to this email directly or view it on GitHub
https://github.com/znc/znc/issues/871#issuecomment-75469296.

If you disconnect client, and connect again, what happens? Also try to run znc -D 2015-02-22 14:59 GMT-08:00 Bill Standen notifications@github.com: > Client doesn't seem to matter. I get the same results with mIRC, Hexchat, > Colloquy (OS X and iOS), Limechat iOS and Textual. > > SSL is on. No other modules apart from defaults. > > — > Reply to this email directly or view it on GitHub > https://github.com/znc/znc/issues/871#issuecomment-75469296. <!-- github-comment-id:75486747 -->
Author
Owner

Disconnecting the client almost always results in a freeze at near the same point in playback, usually only a few lines different.

I'll give znc -D a shot at my next opportunity

Disconnecting the client almost always results in a freeze at near the same point in playback, usually only a few lines different. I'll give znc -D a shot at my next opportunity <!-- github-comment-id:75690111 -->
Author
Owner

Is there any logical reason running with znc -D would cause this issue not to present? Perhaps just a slow down in processing?

Twice now I've switched to znc -D and been unable to replicate the problem with the buffers set back to 1500. Revert to a normal run of just znc and the problem returns once the buffers have time to fill.

Is there any logical reason running with znc -D would cause this issue not to present? Perhaps just a slow down in processing? Twice now I've switched to znc -D and been unable to replicate the problem with the buffers set back to 1500. Revert to a normal run of just znc and the problem returns once the buffers have time to fill. <!-- github-comment-id:76657992 -->
Author
Owner

Alternatively, wireshark may help, if znc -D changes the behavior...

Alternatively, wireshark may help, if znc -D changes the behavior... <!-- github-comment-id:77036995 -->
Author
Owner

Thanks for the tip. Of course I was running with -D all the time to see what's going on. :)

If you use a client such as irssi that does not support server-time cap, you get a <***> Buffer Playback... message, but not the <***> Playback Complete. message on one of the channels and then no playback at all on the "rest" of the channels? Or how does it freeze?

Thanks for the tip. Of course I was running with -D all the time to see what's going on. :) If you use a client such as irssi that does not support server-time cap, you get a `<***> Buffer Playback...` message, but not the `<***> Playback Complete.` message on one of the channels and then no playback at all on the "rest" of the channels? Or how does it freeze? <!-- github-comment-id:77207265 -->
Author
Owner

Could you paste the output of otool -L /path/to/bin/znc?

Could you paste the output of `otool -L /path/to/bin/znc`? <!-- github-comment-id:77236066 -->
Author
Owner

Waiting for information for months, could it be assumed this issue has fixed itself?

Waiting for information for months, could it be assumed this issue has fixed itself? <!-- github-comment-id:138891719 -->
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/znc#480