Respect multibyte UTF8 when splitting task logs

[adenwuts]

Fixes an error where task logs would be split on multibyte UTF8 characters, resulting in _tasks/actions.php returning a response with an empty body and a parsererror being triggered in the ruTorrent GUI.

This was causing issues when creating torrents with many files containing multibyte UTF8 characters (e.g. those with non-English characters), where ruTorrent would lose track of the torrent creation task and hang, despite the .torrent file being successfully created.

This setup assumes that incoming data is UTF8, but there's room to incorporate/extend some of the UTF checks from php/utlity/utf.php to potentially allow for non-UTF8 filesystem data. Let me know if you that's intended to be supported by ruTorrent, or if there's any guidance on how invalid use cases should be handled.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[anthonyryan1]

Keepalive.

[xirvik]

@adenwuts would you provide repro instructions? (a bash script or whatever that generates the test condition, or a tgz with files that trigger this, whatever).

[adenwuts]

Hi @xirvik,

It's an extremely rare edge-case, but as always Murphy's law prevails.

I've reproduced the issue after creating a torrent containing many files with multi-byte utf8 characters in their names. I generated those files with this script: https://gist.github.com/adenwuts/36e4cbc8bc4cb7f664cfa1b50475b1e8

It can take a few attempts to generate the errors, but the larger files provide more opportunities for the calls to hit a bad line. Once the error is triggered, you'll see one of:

[15.04.2026 11:10:42] Bad response from server: (200 [parsererror,tasklist])
[15.04.2026 11:13:00] Bad response from server: (200 [parsererror,taskcheck])

And the torrent creation progress pop-up will stall.

[xirvik]

Thanks for the repro script @adenwuts — we were able to reproduce the issue.

However, we found a bug in the fix itself: the outer while loop can infinite-loop. After reading a chunk, the code does fseek($f, $startPosition, SEEK_SET), which puts the file pointer back to the same position it was at the start of the iteration. On the next iteration, ftell($f) > 0 is still true, and if $currentLines hasn't reached $lines, it reads the same chunk again forever.

The original code avoided this because fseek($f, -mb_strlen($chunk, '8bit'), SEEK_CUR) moved the pointer backwards after reading. The new code lost that backward movement.

We reproduced this on rtorrent 0.16.8 with 400 files with Korean names (82KB log file) — getLastLines() hangs on the first call.

The UTF-8 boundary detection logic itself looks correct — just the file pointer management in the outer loop needs fixing. Would you be able to take a look?

[adenwuts]

Will try to take a look at this over the next couple of days and let you know.