Repository navigation
Releases: Ninja-FSE/dccore
Release list
v1.18.0 - The Fair Share Release
- Fixed: a refused
!rarrequest now says why it was refused (a folder the bot does not offer, an artist root, a folder with nothing to pack, or one over the size limit for packed folders) instead of always saying it was an artist root folder. - Fixed:
@<nick>-remove <file>with a line copied from the list, or with the file's folder in front, now removes that file, instead of saying it is not in your queue and sending it anyway. - Fixed: a folder still being packed for a nick that was just paused now stops at once, so the next folder request no longer waits for it to finish.
- Fixed: the dashboard's Settings page did not say when the rehash after a save failed. It said "Rehash started" and nothing more. Now it waits for the rehash and says whether the new settings are in effect; if the rehash failed (an
admin_config.pywith a syntax error, for one), it says the settings were saved tosettings.confbut the bot may not be running them, and that the bot's log says why - the same words as the admin console. - Fixed: a send could be stopped as slow after Packet size was lowered. With Max upload speed and Stop sends slower than (
SLOW_SEND_MIN_KB) set, lowering Packet size (DCC_BLOCK_SIZE) while sends were running could leave the sends started afterwards with less than their share of the upload speed, and one of them could be stopped as too slow although only the cap held it back. Every running send now uses the new packet size from its next packet on. - Fixed: files already queued for a nick paused for failed downloads could still be sent. With Failed sends in a day before a nick is paused (
DAILY_SEND_FAILS_LIMIT) set, a nick paused after a nick change could keep getting the files left in its queue. A paused nick's queued files are now removed, and nothing more is sent to it until the pause ends. - New: channels where a finished transfer is not announced. With Announce finished transfers in the channel on, list the channels whose rules forbid that kind of message in Don't announce finished transfers in these channels (
ANNOUNCE_TRANSFERS_EXCLUDE, for example#alpha, #beta) on the Settings page under Advertising & search, or in the mIRC settings window under General > Advertising. The advert still goes there; only the "sent" line does not. Empty, the default, announces everywhere as before. - Fixed (security):
DAILY_SEND_FAILS_LIMITnow treats a user who changes nick between downloads that never connected as one downloader, not two. - Fixed: someone paused for failed downloads (
DAILY_SEND_FAILS_LIMIT) could get round the pause by changing nick. Their failed sends today and the pause now follow them to the new nick, as their queue does, until midnight orunpause <nick>. - Fixed: with a Max upload speed set, a send crawling on the downloader's slow link was never stopped by Stop sends slower than (
SLOW_SEND_MIN_KB) while your faster sends kept the cap full. A send getting about its even share of a full cap is still kept; one well under it is now judged as if no cap were set. - Fixed: with One large file at a time (
LARGE_FILE_MB) on, a finished!rararchive was sent at once even while another large file was being sent. A!rarfolder is still never held back while it waits to be packed, since its size is not known yet; once packed, a large archive now waits its turn, keeping its place, like any other large file. - Fixed: a settings change from mIRC or the console said it was in effect when the bot could not apply it. If the reload that applies a save fails (an
admin_config.pywith a syntax error, for one), the console now says the settings were saved tosettings.confbut not applied, and that the bot's log says why. The mIRC settings window says so with the updateddccore.mrc; an older script shows the bot's message as a raw[SETAPPLYERR]line in@DCCore, never as a success. - Fixed: saving a setting on the dashboard could log you out. A page that asked the dashboard for something while the bot was reloading its settings was sent back to the login, and a correct password typed at that moment was refused.
- Fixed: after being kicked or banned from a channel, saving any setting made the bot think it was back in. It said "Rejoined", stopped trying to get back in, and sent its advert there again. It now counts a channel as joined again only when the server confirms its own JOIN.
- Fixed: the bot could say its debug channel was never joined, and keep asking to join it, while it was in it. It joins the debug channel first now, and counts the member list of every channel it is in whenever the server sends it.
- Changed (security): some names in the fetched files folder. A file without an extension that you fetch to the top of
data/fetched/now keeps the request id in front of its name, which leaves plain names there to the bots' own folders (A folder for each bot's files); if a file already has a bot folder's name, a download from that bot stops with a message naming the file to move or rename. A fetched list whose bot or channel name had to be cleaned to make a folder name now has a longer tag on its folder, and a list you hold is moved to it once, when the bot starts. - New: each bot's downloads in a folder of its own. Turn on A folder for each bot's files (
FETCHED_FILES_PER_BOT, off by default) on the dashboard's Settings page or in the control panel, and what you fetch from SomeBot is saved indata/fetched/SomeBot/, the way mIRC can file downloads under the sender's name. Files you already have stay where they are, and fetched lists keep their own place. A nick with characters a folder name cannot hold, like[Alfa], gets a tag after its name (Alfa-1d8be4d71c298166), so two bots do not end up in one folder by accident. - Fixed: a debug channel the bot did not get into went unnoticed. When every channel in
CHANNELanswered, nothing checked the debug channel. Now it is checked too: if it never confirms, the bot says so in its log and on the dashboard and asks for it again, as it does for any other channel. The advert still does not wait for it. - Fixed: the List Browser's filter could hang for minutes after the bot started, while it re-indexed the lists you hold. It now says the search index is still being filled and to try again in a minute.
- Fixed: after a restart, a channel the server refused with "target change too fast" was asked for again too early. The bot now waits as long as the server says (a
[JOIN WAIT]line says until when), asks again right after, one channel per wait, and lets the rest of its JOINs wait their turn, so it is back in every channel within minutes instead of being refused again. - New (mIRC): the script is one download,
dccore-mirc.zip, attached to each release (https://github.com/Ninja-FSE/dccore/releases/latest/download/dccore-mirc.zip). It holdsdccore.mrcwith itsdcxanddllfolders and a short README: extract it into your mIRC folder, or over the old files to update - your settings and token are kept. - Fixed (mIRC): the control panel's Connection row could take the wrong shade after a theme switch. With the panel open, switching between the light and dark theme gave the row's green, amber or red the other theme's shade until the panel was reopened. It now follows the panel's theme, which changes the next time the panel opens.
- Fixed (security): a
!rararchive now holds only the files the list lists, and a folder whose only packable files the list leaves out is no longer packed. A pack also waits in the queue, keeping its place, while the disk the archives are built on has no room for it (a folder that fits goes ahead meanwhile, and one larger than the whole disk is refused), or while as many packed archives as there are send slots already wait to be sent; it carries on by itself. - Fixed (security):
checkupdatesandconsolefeedwith an argument now ask for unlock in a token session, likeset. A console that logged in with a paired token typesunlock <password>once before it turns the daily update check or the console feed on or off; with no argument they still just report the setting. The updateddccore.mrcshows the request in@DCCore, and the control panel's "Console feed on" box goes back to the bot's setting and says to unlock first. - Fixed (security): logging in to the admin console with a paired token no longer clears the address's count of wrong passwords. Only the admin password, at the login prompt or in
unlock, clears it now. A token login is still not counted as a wrong password, but the wrong ones before it still add up to the three that block the address for 15 minutes. - Fixed (security): failed dashboard logins over IPv6 are counted per /64 network, and per /48. Three wrong passwords block the whole /64 for fifteen minutes, and thirty from anywhere in one /48 block that /48; an IPv4 client seen through an IPv6 socket or NAT64 counts as its IPv4 address.
- Fixed (mIRC, security): the script now accepts the bot's login only once the password it asked for in the same chat was answered. The bot always asks first, so logging in works as before; a login line before that is ignored, the window says so, and the script stops reconnecting until you
/dccore connect. A password typed in the separate console window is now shown as********there too and keeps its spaces, and the menu's Console command box hides what you type at the password prompt. Updatedccore.mrcto 1.21.0 and reload it with/reload -rs dccore.mrc.
v1.17.0 - The Control Panel Release
Project page: https://ninja-fse.github.io/dccore/
mIRC script: download dccore-mirc.zip below. It holds dccore.mrc with its dcx and dll folders and a short README. Extract it into your mIRC folder, or over the old files to update; your settings and token are kept. Then /load -rs dccore.mrc the first time, or /reload -rs dccore.mrc to update.
Upgrading the bot: new settings appear on the dashboard's Settings page, all off or at safe defaults.
Security: this release fixes GHSA-x9w3-xf6g-9747.
- The bot points people at the project page: the reply to CTCP VERSION and the top of every list now show https://ninja-fse.github.io/dccore/. The update check still finds the releases from it. A
PROJECT_URLyou set to the GitHub address keeps working. - New: how long DCCore Chat's history is kept, and how big it may grow. Two settings under Settings → Private messages on the dashboard, and on the control panel's mIRC side (Chat page): Keep the chat history in mIRC for (100 days out of the box) and Largest chat history in mIRC (100 MB). 0 is no limit. The bot sends them to
dccore.mrc, which deletes the oldest months of its history files by them. - Fixed (mIRC): the control panel's start page said "connected" with the bot stopped. It showed the stopped bot's start time and the old session's figures as if they were current. The Connection row now has a coloured dot - green when connected, amber while the script is connecting, red and
offlinewhen not - and while offline Up since, Today and Library show-and Sending says(bot offline), instead of old figures. The page also updates by itself when the link drops or comes back. Updatedccore.mrcto 1.20.0 and reload it with/reload -rs dccore.mrc. - New (mIRC): DCCore Chat keeps a history, on by default. Every line the chat window shows, private conversations included, is written as plain text to mIRC's log folder (
//echo -a $logdir), inDCCore-Chat\: a file per channel and per private conversation for each month, kept for as long and up to the size the bot's settings say (100 days and 100 MB out of the box, #1401). The window says where when it opens, and shows the last 200 lines again, so closing it or restarting mIRC loses nothing. A line that arrives while you are in another window, or while mIRC is in the background, is counted in the chat window's title, lights its button, and makes mIRC flash in the taskbar while it is in the background. Untick Keep a history file or Flash on a new line in the window's right-click menu to turn either off; the menu also opens the folder. Reloaddccore.mrcwith/reload -rs dccore.mrc. - New: someone whose downloads keep failing is paused until midnight. Failed sends in a day before a nick is paused (
DAILY_SEND_FAILS_LIMIT) stops a downloader whose client never accepts your offers, sits behind a firewall, or drops every transfer, from holding your slots all day: once their sends have failed that many times since midnight, the files left in their queue are removed and new requests are refused until midnight, with a notice telling them to check their client. A transfer the downloader closes or cancels in their own client before it finishes counts as a failure, since the bot cannot tell it from a client that drops every send. Taking something out of the queue (packcancel,@<bot>-remove) does not count, nor does a failure on your side (a file that vanished, a network share that stopped answering), and admins are never paused. Offers nobody connects to stop counting once offers to several downloaders in a row go unanswered with no send connecting in between, until a send connects again, so a wrong address or a lost port forward on your side does not pause everybody. Before turning it on, know that someone who keeps connecting to your DCC ports can get in ahead of a downloader and make their sends fail, which with this limit can get them paused: set it high, or leave it off where that is a concern. The console'sstatusshows who is paused, andunpause <nick>lifts it. 0, the default, is off; set it on the Settings page under Transfers or in the mIRC settings window. - New: stop a send that crawls while others wait. Stop sends slower than (
SLOW_SEND_MIN_KB, in KB/s) stops the slowest send when its downloader has received less than that over the last minute, but only while every slot is taken and someone is waiting for one, and only while another of your sends is reaching that speed - so a full uplink, a slow disk or your own Max upload speed never gets a send stopped, and with one slot it never fires. Never in a send's first minute. The slot goes to the next in line. A file that was waiting in the queue stays queued: it counts as a failed try against Max send failures, the person goes to the back and is told why, and their client can resume it later. A file sent straight away without waiting is dropped, and they ask for it again. Set it on the Settings page under Sharing & queue, or in the mIRC settings window. 0, off, out of the box. - New: one large file at a time.
LARGE_FILE_MB(Settings, Sharing & queue; off by default) makes a file of at least that many MB large, and only one large file is then sent at a time, so a few multi-gigabyte requests no longer hold every slot for hours while everyone else waits. Someone whose next file is large keeps their place and waits while another large file is being sent; the slot goes to the next in line, and the console and the Queue page show them as "waiting: one large file at a time". The bot's list never counts as large, and a folder packed with !rar is never held back: its size is not known until it is packed. - Fixed: replies lost to "Target change too fast". When a busy bot answers many people in a row, Undernet drops a message with numeric 439 (707 on other networks). The bot now waits as long as the server asks, up to 120 seconds, and sends the dropped reply again once, with a
[QUEUE]line in the bot's log, instead of losing it silently and running into the same limit again. - Fixed: renaming or replacing a folder while the list rebuilt cost the whole rebuild. The bot kept serving the previous list, which was older still - it named the same folder and lacked everything added since. A folder renamed, replaced or deleted during the scan is now left out of that list, with a line in the log saying so, and the next rebuild lists whatever took its place. A configured folder (or the share it is on) going away mid-scan still stops the rebuild and keeps the previous list.
- Faster (mIRC): the control panel opens faster. A page's menus, frames and tables are made the first time the page is shown rather than all at once when the panel opens (a page full of colour menus takes a moment the first time), and opening and closing the panel also leaks fewer Windows GDI objects with DCX.
- Fixed: asking for a file the bot does not have could leave you "busy" for minutes. A request for a name that is not in the bot's list made it search every folder on disk for it, which on a large or network library takes minutes; meanwhile every further request from that person was answered "Busy looking up other files". The list is now what the bot serves: a name it does not have is answered "File not found" at once, and a file you add is requestable after the next list rebuild. File types you leave out of the list are not served either, even to someone who knows a file's exact name.
- New: read-only console tokens.
pair <name> <version> readonlyat the admin console gives a script a token that can look at the bot (status, queue, sends, library, bans, the feed) and change nothing: no bans, queue changes, rebuilds, settings or shutdown, and it cannot be unlocked. It also never takes the console over from you: while you are logged in with your password or a full token, a read-only login is turned away until the console is free. Handy for a stats script or a status widget that you would rather not trust with everything. - New (mIRC): a dark theme and icons.
/dccore theme darkdarkens the script's windows (or Follow mIRC, which takes mIRC's own dark mode), and/dccore icons onputs an icon beside each of the script's menu items and control panel pages; both are on the control panel's mIRC side too. Two small DLLs of DCCore's own do it,dccore_ui.dllanddccore_icons.dllinscripts/mirc/dll/(sources beside them); without them the script looks as before. Copy thedllfolder besidedccore.mrc, updatedccore.mrcto 1.20.0 and reload it with/reload -rs dccore.mrc. - Fixed (console): the library's totals come on time and say the right thing. After a rebuild, the new totals reach dccore.mrc's start page as soon as they are counted, not up to 30 seconds later; the search index no longer says "still being filled" for days after it was repaired; a list whose figures cannot be read says so instead of showing as empty; and
librarygives a short rebuild's time in seconds. - Fixed: list rebuilds after a crash or a failed start. A rebuild you ran by hand that crashed no longer gets the bot's next rebuild killed within seconds: the bot read the leftover progress report as its new rebuild's, "silent for twenty minutes". Now it reads only its own rebuild's report, and clears a leftover one first. A rare failure could leave a rebuild running with nothing following it, refusing every later rebuild as "already running"; the bot now ends it. A rebuild that failed while starting could leave searches and file requests paused until a restart; they now resume, and the rebuild is recorded as failed and raises a dashboard notice. While a rebuild starts, the dashboard now says "Checking the library's folders…" instead of "Scanning the library". On a network drive that stopped answering, that is where it waits.
- **Fixed: a list rebuild stopped with the bot was reported a...
v1.16.2 - The Hardened Release
- Fixed (security): several holes in admin access are closed.
dccore.mrccould accept a new login token from someone other than your bot, so update it to 1.19.4 and reload it with/reload -rs dccore.mrc. The console's fallback connection now waits for you alone. Console logins made at the same time from one address no longer get more password tries than the limit. A!rehashthat cannot readsettings.confkeeps the settings it had, and a line you delete fromadmin_config.pyis gone after a!rehash.unpairnow says so when it could not revoke a token. Update if you use the DCC console ordccore.mrc. - Fixed (mIRC): the settings window's Unlock accepts a password with a space at either end or two spaces in a row. Such a password could log in but not unlock the window. Update
dccore.mrcto 1.19.4 and reload it with/reload -rs dccore.mrc. - Fixed (security): the dashboard's login and sessions are harder to abuse. Failed logins sent all at once are now counted like any others, and only a few passwords are checked at the same time. The dashboard refuses requests made under a web address it does not know, which stops a hostile page from locking you out of the login. Logging out, or changing the password, now ends the session on the server, so a copied session stops working. No other page can show the dashboard inside a frame. If you open the dashboard by a name rather than an IP address,
localhostor your computer's own name (a router or VPN name, a reverse proxy), add that name to the newWEBUI_ALLOWED_HOSTSsetting. - Fixed (security): a download request could reach more than the file it names. On Windows, a specially written name could read hidden data stored alongside a shared file, including where the file was downloaded from. With several lists, a channel could be sent another channel's list. Such requests are now refused. A resumed download that sent nothing is no longer counted or announced as sent.
- Fixed: with rejoining turned off (
REJOIN_ATTEMPTS = 0), the kick notice no longer says the bot will rejoin on the next advert. - Fixed: the List Browser's filter finds a name whether it is written with composed or decomposed accents, as libraries copied from a Mac often are - for Vietnamese, Cyrillic, Japanese and Korean names as well. The search index is rebuilt once after the update, from the lists you hold.
- Fixed (security): names and text from other IRC users are kept in their place. A bot's nick could make DCCore keep its fetched list in a folder that held other bots' lists, so fetching or removing that list could delete or replace theirs; a file fetched under one particular name could make every later list fetch fail; some bot nicks could empty the List Browser's sidebar or break the @find results on the dashboard; text typed in a channel could act on the operator's terminal when the bot printed it; and each private message from a stranger cost a disk write while the bot was reading from the server. A list held under a nick or channel whose folder name changed is moved once, when the bot starts. Also fixed: a
?in a ban mask (and inADMIN_HOSTMASKS) now matches one character, as on IRC - before, a ban written with?was accepted but matched nobody. - Fixed (mIRC): a password with a space at either end, or two spaces in a row, can be typed in the
@DCCorewindow. mIRC closed such spaces up before sending, so the bot refused a password the dashboard accepted, and the script could not be paired. The script now sends such a password encoded and the bot decodes it; every other password goes as before. Updatedccore.mrcto 1.19.4 and reload it with/reload -rs dccore.mrc. - Fixed: a second login arriving while the console was checking a first one's password could close your live console and leave no console open at all. The replaced login is now simply turned away.
- Fixed: a damaged audio info cache is moved aside and a new one started, instead of every list rebuild from then on being written without audio lengths until the file was deleted by hand. The damaged file is kept beside it as
audio_info.db.corrupt-<date>. - Fixed: a failed save of the Downloads history was never tried again while nothing changed, so a restart could lose finished downloads or bring back deleted rows. It is retried on the next tick.
- Fixed: two saves at once could leave an older copy on disk - the download queue (an emptied queue could come back after a restart, a new one go missing) and the record of fetched lists (pointing at a list file already replaced). The newest copy is now always the one written last.
- New (mIRC): a settings window for the bot.
/dccore settings(or Bot Settings / Settings... in the menus) shows the bot's settings as the dashboard's Settings page has them - six tabs, the pages of each down the left, Apply / OK / Cancel - with the dashboard's labels, help and checks: a value the bot refuses comes back with its reason and nothing is saved. It also edits the on-connect commands, the served lists with their channels and folders, and the bans and ignores, and previews a colour theme before you save it. Updatedccore.mrcto 1.19.4 and reload it with/reload -rs dccore.mrc; the bot must be on this version too (an older bot is told apart, and the window then says to update it). - New (mIRC): nicks, channels and the search term can have colours of their own in the
@DCCorewindow./dccore optionshas Search text, Nicks and Channels under the Show checkboxes, and Nicks can be per nick: each nick always gets the same colour, picked to be readable on the window's background, so one person's searches and requests stand out. Until you pick one, the window looks exactly as before. Updatedccore.mrcto 1.19.4 and reload it with/reload -rs dccore.mrc. - Fixed: an advert interval of 0 made the bot advert as fast as it could.
ANNOUNCE_INTERVALnow has to be at least 60 seconds; a smaller value is refused when saved, and one already insettings.conforadmin_config.pyis used as 60. - Fixed: with more than one list, an unplugged drive on the main list stopped the bot from starting although the other lists were readable. It now starts while any list has something to serve, and names the list that has nothing.
- Fixed: changing only the capitalisation of the list name (or of the nickname it follows) kept the bot on its old list on Windows and macOS. The old files are renamed at the next start and cleaned up by the next rebuild, and the newest list is chosen by its date.
- Fixed: one broken line in
settings.confmade the bot offer the first-run setup, which could replace your admin password and then fail. The bot now names the file and the line and stops, the setup check says the same, and neither setup writes anything until it knowssettings.confcan take the answers. - Fixed: the Settings page saved a music folder that does not exist, and the bot then would not start. It is refused when you save, with a hint if the path has quotes around it.
- Fixed:
configure.pyand the Settings page accepted channel names the browser setup refuses, such asmychannelor#one #two. All three now use the same rule: each channel starts with#, several are separated by commas. Asettings.conffrom before still loads: its real channels are joined, and the log names any entry that was dropped. - Fixed: a list name with a character like
|saved fine and then broke every list rebuild on Windows. Saving one is refused, with the name to use instead; one already insettings.confis kept where your system accepts it (so your published list keeps its name) and corrected where it does not. - Fixed:
configure.pysaid a folder pasted with quotes (Explorer's "Copy as path") does not exist. The quotes are taken off, and only a full path is ever offered for creating. - Fixed: a new console time format took effect only after a restart. It now applies from the next line.
- Fixed: a
settings.conferror named the line after the real one, and sometimes a section the file does not have. - Fixed: two people asking for the same folder no longer break each other's download. The second request could delete the archive the first person was waiting for, or a failed attempt could remove it, so the first person got "Could not send". The waiting archive is now sent to both. A finished archive is also no longer deleted while someone else's queue still needs it, and one is no longer left on disk because a different album has the same name.
- Fixed: a queued file from a folder you stopped sharing is no longer sent. A file queued from a folder you then removed on the dashboard's Folders page is dropped when its turn comes, and the user is told it is no longer shared.
- Fixed:
@<bot>-removeduring your own folder's packing now stops the pack. Before, the user was told the queue was removed, and the folder was packed and sent anyway. A file already being sent stays, and the notice now says so. - Fixed: a nick change while a folder was packed no longer locks that user out until a restart, and the archive goes to the new nick. Running out of file handles at the moment a send starts no longer loses a slot either.
- Fixed: a list rebuild that failed at the wrong moment could leave the bot with no list until the next successful rebuild - @find said there was no list and the advert went quiet. The previous list is now always put back.
- Fixed: a multi-disc album (CD1, CD2 ...) can be packed with
!raragain. Its row in the album list was refused every time it was pasted. The row itself is unchanged, so requests already queued in AutoQ still match. - Fixed: the album list no longer offers the library folder or an artist folder just because a loose track sits in it. The bot always refused those. The tracks are still listed and requestable by name.
- **Fixed: wit...
v1.16.1 - The Bot Forgets on Purpose
- New: purge every held list at once, in the console (
purgealllists confirm) or the List Browser ("Purge every held list"). Recommended once after upgrading from before v1.16, since a bot's list held from back then can have its channel stuck wrong - each list rebuilds on its own with its channel resolved fresh. Updatedccore.mrcto 1.17.2 and reload it with/reload -rs dccore.mrc.
v1.16.0 - The Channel-Aware Release
- Fixed (security, Windows): a list archive from another bot could make DCCore write to a device instead of a file. A file inside a fetched zip or RAR list named like a Windows device (
NUL,COM1,con.txt) was opened as that device, which could stall fetching lists. Such names are now unpacked with an underscore (NUL_.txt), as DCCore already does for names it is sent elsewhere. - Fixed: a large download queue drew more slowly and
dlcancel allcould take tens of seconds. The Download queues window's snapshot is now capped per message like the Downloads window's already was (the full count still shows), and cancelling several requests - ordlcancel all- lets them all go in one pass instead of one at a time.dlcancel allfollowed by extra words is refused instead of cancelling everything. Updatedccore.mrcto 1.17.1 and reload it with/reload -rs dccore.mrc. - Fixed (mIRC): "Clear the queue of ... and ignore for..." no longer clears the queue when the ignore is refused. The two steps used to run unconditionally; the queue is now only cleared once the ignore has actually taken.
- Fixed: a search reply's
From:line could start with!under a custom theme. A border, separator or text-box colour set to certain text could put it, unescaped, at the very start of the line. The line now always starts with the literal textFrom:, under any theme or custom colour. - Fixed: the settings preview now shows an unsaved change to "Answer @find searches" too, the same as it already does for the theme colours.
- Fixed:
-helpno longer mentions searching when it is turned off. - Fixed: a bot or an album folder named like a Windows device name (AUX, NUL, COM1 ...) could collide with one already named with the usual safety suffix. Each now gets a short, stable tag instead, so the two can never be mistaken for one another.
- New: a bot's other channel-bound list is discovered and held automatically. A bot bound to a different list per channel (the same feature DCCore itself has) used to only ever give up its first list, and a wrong second fetch could even wipe it out. Discover a bot's other channel-bound lists (Settings → Grabbing lists, off by default) watches for a genuinely different, stable list in another shared channel and holds it alongside the first - never instead of it - with no manual step, and keeps it fresh from then on.
- Fixed: a request to another bot goes to the right channel. A bot that serves a different list per channel could silently get a file/folder request that landed where it answers nothing. Requests now remember which channel a bot's list came from and reuse it automatically - including a retry of one, from either the dashboard's "Try again" button or
dlagainin mIRC. - Fixed: a late folder archive from a slow bot could be filed under the wrong queued row. When several folders were requested from one bot at once and one took too long, its archive could end up attributed to the NEXT folder in line instead - shifting every label after it and losing the true last one. A folder's late answer is now matched to the request it actually belongs to. A file request held back for retry could also, rarely, have its answer taken by an unrelated folder request to the same bot; this is fixed the same way.
- Fixed: a rare timing issue could reconnect the bot when an ignore from the dashboard landed at the wrong moment. An ignore or "stop ignoring" set from the dashboard or console could, very rarely, collide with the bot's own once-a-minute flood check and force an unplanned reconnect. It is now properly synchronised and cannot happen.
- Changed: a file asked for by private message is handled as part of the channel its sender shares with the bot. Its notices follow that channel's mode, the console and the @dccore window name that channel (before, they named your first channel, where the person might never have been), and nothing is announced in any channel for it. Someone who shares none of your channels is no longer served by private message - before, they were when a slot happened to be free and dropped when they had to wait. File requests by private message no longer show on the dashboard's Messages page.
- New: search can be turned off. Answer @find searches in Settings → Sharing & queue (on by default). Off,
@findand@locatorget no reply and the channel advert saysSearch: OFFinstead of theSearch: ONit always showed. - New: search replies can say which folder each result is in. Turn on "Name the folder in search replies" (
SEARCH_SHOW_FOLDER) and an@findreply puts aFrom: <folder>line above each folder's results - once per folder, not per file - so a studio, a live and a tribute version of the same song can be told apart. The result lines are exactly as before, so they can still be copied as requests, and theFrom:line can never be mistaken for one. A long folder is shortened from the left (From: ...allica\1988 - ...And Justice for All); "Longest folder shown" (SEARCH_FOLDER_MAX_CHARS, 80) sets how long. Off by default. - Fixed: Download selected in a RAR list fetches folders, and many can be queued. Ticked rows of another bot's RAR list were asked for as files that never arrive, so the request repeated every minute and failed. They now go as folder requests, any number can be queued at once, and DCCore asks for one folder per bot at a time, starting the next when the one ahead has finished or failed. The same folder asked for twice is one request.
- New: a channel can be Quiet or Request only. In Settings → Served lists each channel a list serves has a mode next to its tick box. Quiet sends no advert in the channel but answers requests and sends its usual notices; Request only sends no advert and no notices either, and serves silently. The "Sent:" line posted in the channel after a transfer is dropped in both. A private-message request takes the mode of the first list-bound channel the user shares with the bot. Every channel is Normal until you change it, so an update changes nothing by itself.
- Fixed: a search word is matched against the file name only.
@find infoornfoused to match every file, and the bot's own nick matched the whole list, because the words were also looked for in the!nickat the start of each row and the::INFO::size tail at the end. Now only the file name counts, as in the filter bar across lists. A size or bitrate (320,10MB) is no longer something you can search for. - New: the Stats page shows how transfers ended, and a success rate. Failed and cancelled sends, folder packs that failed, and downloads that broke off are now recorded beside the completed ones. A new "How transfers ended" table shows, for the chosen period, how many files, albums and lists were attempted, completed, failed and cancelled, and the success rate - completed out of completed and failed, so a stop or a cancel of yours does not count against it. Export CSV has a status column. Counting starts when you update; transfers before that all read as completed.
- New: a bot that keeps failing is paused for a while instead of being asked again and again. After 3 of your download requests to the same bot fail in a row (no answer, an offer that cannot be reached, or a transfer that breaks off), DCCore stops asking it for 15 minutes; its requests wait, and go out in order when the pause ends, even across a restart. The Downloads page says "Paused until 14:32 after 3 failures" with a Resume now button. A bot that answers "not found" or "busy" is not counted. Both numbers are in Settings (
FETCH_BOT_MAX_FAILS,FETCH_BOT_COOLDOWN_MINUTES; 0 turns it off). - New: users are told when the next slot is likely to free up.
@nick-queand@nick-statsnow say "Next free slot: ~4 min" (or "now", or "not known yet" before the sends have a speed), worked out from how much the current sends have left and how fast they are going; the dashboard's Live Transfers page shows it too. It is when a slot frees, not when it is your turn. - Changed: asking a bot for its list (
@nick) no longer waits behind everyone's files. The list takes the next free slot ahead of queued files (and goes at once if a slot is free), so a newcomer sees what the bot has straight away; the notice says "Your list is next". Only one list at a time can jump ahead, so a flood of list requests cannot hold up file sends, and asking for the list does not cost anyone their place for the files they already queued. - New: ignore a nick for a while.
ignore <nick> <minutes>in the console, or Ignore on the dashboard's Queue page: the nick's requests are dropped without a word until the time is up, even across a restart.unignore <nick>(or Lift) ends it early, andbansshows the time left. - New (mIRC): ignore a nick and change the queue from the menus. Right-click a nick in a channel → DCCore → Ignore for... (asks for the minutes), Clear the queue of ... and ignore for... or Stop ignoring. The @dccore window's right-click menu has the same for the selected queue row, Move earlier / later in line, and prompts for ignore, unignore, move and remove under User control. Update
dccore.mrcto 1.16 and reload it with/reload -rs dccore.mrc; an older script just does not have the items, and an older bot answers "unknown command" toignoreandqueuemove. - New: move, remove and clear in the queue. On the dashboard's Queue page each nick has arrows to go earlier or later in the line for a free slot, and Clear (it asks first); each of its files can be moved up or down or removed - the nick gets the same "Removed ... from your queue" notice as when they use
@<bot>-remove <file>themselves. The console hasqueuemoveandqueueremove, andqueue <nick>numbers the files. A file being sent, or a folder being packed, is never moved, moved past or removed. A nick whose list is waitin...
v1.15.0 - The Bot Gets Faster
- Changed: with track lengths and quality on (
LIST_SHOW_AUDIO_INFO), the list is published first and the lengths are read afterwards, in the background. No rebuild waits for them, there is no time limit any more (LIST_AUDIO_INFO_MINUTESis no longer used), and when they are read the list is updated with them - keeping its date, so other bots do not fetch it twice. One rebuild or reading runs at a time, and a rebuild stops a reading in progress without losing what it read.update_list.pyrun by hand publishes and says how to read the lengths;update_list.py --read-audio-inforeads them in the foreground. The @dccore window, the dashboard and the bot's own window show how far the reading has got (andaudioinfoin the console, asked while one runs), and Read audio info on the Tools page or under Library in the mIRC menu starts one by hand. Updatedccore.mrc(1.12) for the menu and the progress. - Faster: the List Browser turns pages at once. Every page re-read the whole list - seconds each on a big list, and gigabytes of memory on a very big one of your own. A page now reads only its own folders, and looks exactly the same.
- Fixed: on a network drive, a track's length and quality could come out wrong in the list. A drive that answered a read in pieces made a variable-bitrate MP3 look constant-bitrate, so the same file could show differently from one rebuild to the next. The whole header is read now, however it arrives.
- Fixed: the List Browser's filter could show no results from a bot that it said matched. Rows from lists you do not hold (an offline bot with a similar name, a list a bot no longer offers) could fill the page first; a bot whose nick has no letters or digits never showed any. And a list a bot stops offering is now removed from the search index on the next fetch, and everything of a bot when you Forget it.
- Faster: the List Browser's filter answers short prefixes at once. Typing the first letters of a search took up to a second or more per keystroke on big lists; it is a few milliseconds now. The first start after upgrading rebuilds the search index once from the lists you hold - up to about a minute per million files, before the bot connects - and says so in the log. The index takes about half as much disk again as before: make room for it if the disk is nearly full.
- New: 256 KB in the send block size menu, for a fast seedbox, where it uses less CPU per file sent. A bigger block no longer drops a very slow downloader either: the bot waits longer for it in proportion. The default stays 64 KB, and the help says why.
- Faster: rows pasted from the list are found straight away. When someone pastes several rows from one album, each after the first is looked for in the folder the first was found in - but the size pasted with the row never matched, so every row searched the whole list instead, seconds each on a big library. It matches now, whichever way the size is written.
- Faster: the List Browser's filter no longer slows down with many bots. With a filter active, the sidebar was checked bot against bot every few seconds - about a second each time with a thousand-odd bots. It is worked out once per pass now.
- Lighter: the dashboard no longer downloads the Downloads list and the List Browser's bots while you look at another page, or while the browser tab is in the background. Each is fetched fresh when you open it.
- Faster: a list rebuild scans a big library many times faster. On a library with many folders the scan slowed down the more folders it had - 41 seconds for 137,000 files, slower with more threads than with one. It takes about 3 seconds now.
- Faster: a list rebuild writes the list about four times faster. Each row's name was cleaned up a character at a time; almost none needs it, and only those are touched now. The list comes out exactly the same.
- Quieter: the console no longer logs every user who leaves a channel. A line meant for testing DCCore Chat said so for every ordinary departure, and on a busy channel it pushed the useful lines out of the log. It shows only with debug mode on; a Chat peer leaving is still logged.
- Faster: the end of a list rebuild on a big library. The cache of track lengths and quality was rewritten whole on every rebuild - about 15 seconds for a million tracks while searches waited. Only what changed is written now.
- Faster: a bot with many hard bans keeps up with a busy channel. The ban list was read and worked out again for every message in the channel - at 2,000 bans the bot could handle about four messages a second. It is read again only when it changes.
- Fixed: the List Browser's filter no longer freezes while a fetched list is being indexed. Each keystroke waited until the new list was written - several seconds, or most of a minute for a very big list. It answers at once now, from the lists as they were until the new one is in.
- Lighter: installing a fetched list uses about a third of the memory. Every row of the list was held twice while it was added to the search index, only to be counted; it is streamed in now.
- Faster: reading a list - a search, or a fetched bot's list in the List Browser - takes about a third less time. Two checks ran on every row that only a few rows need.
- Faster: a search of the bot's own list is about three times faster on a big list. Every line of the list cost more work than it needed; the answers are exactly the same.
- Fixed: after the cross-list search index was rebuilt, a bot's RAR list showed as having no match in the List Browser's filter. Only each bot's main list was put back into the index. Every list it holds is now.
v1.14.0 - The Bot Keeps a Record
- Faster: a finished send no longer rewrites the whole download-count file. Each one rewrote every count the bot had ever kept - most of a second on a bot that has sent many different files, with other saves waiting behind it. The counts move into
data/download_counts.dbon the first start;data/download_counts.jsonis left exactly as it was, so going back to an older version still shows the counts up to the upgrade. - Faster: the Stats and Live Transfers pages no longer re-read whole files every few seconds. On a bot that has sent many different files, each refresh re-read and sorted the download counts and recounted the RAR list - seconds each time, and finished sends waited on it. Live Transfers now asks only for its own figures, and the rest is worked out again only when the files change.
- Changed: the bot keeps up better when many people join or leave channels at once. Work that grew with the square of the number of people now grows with the number.
- Changed: Live Transfers is its own page, and the Stats page follows one period. Speed, slots and the queue moved from Stats to a new Live Transfers page. On Stats, pick 24 hours, 7 days, 30 days or all time and the whole page answers for it: one row of Sent figures (files, size, lists, top and average speed, average wait, files and size received), Most downloaded files and albums, and the nicks. The two Most downloaded tables are one now, and the old Total/Today/Yesterday Sent cards are gone. All time still counts everything the bot sent before the record began.
- New: the bot keeps a record of every finished transfer, and the Stats page shows it. One row per transfer goes into
data/transfers.db: what it was (a file, a packed folder or a list), its size, its speed, how long it waited in the queue and the nick it went to or came from (in lower case; no host and no channel is stored). On the Stats page, pick 24 hours, 7 days, 30 days or all time to see what was sent and received, the speeds, the average wait in the queue, the files sent most and the nicks you sent to and received from most. Look up one nick, Forget it when somebody asks (every row with that nick is wiped from the file), or Forget everyone; both ask first. Export CSV saves the period as a spreadsheet.TRANSFER_LOG_FILEsets where the record is kept; empty turns it off. - Changed (mIRC): the @dccore right-click menu is grouped by what you do. Script Settings (the old Options) and Console command come first, then Info (status, slots, queue, uptime, version, command list), Lists, Library, User control (bans, ban, unban, clear a queue) and Control (update check, console feed, reload the bot, and last, behind a line, Stop the bot). Connection and Window follow; DCCore Chat and Downloads window are now inside Window, and Clear finished downloads is called Clear finished... and now asks first (only the list is cleared, no files are deleted). Everything that was in the menu is still there, and Stop the bot and Reload still ask first. Update
dccore.mrc(1.11) and reload it with/reload -rs. - New: KeepTrack's per-nick history can be imported. Choose
KTData.txton the Stats page: you see how many nicks and files it holds, the top ten each way and any lines it could not read, then import it. Each nick's KeepTrack totals are added to what the bot has recorded for them since. Only nicks and totals are kept - the hosts in the file are not. - New: KeepTrack's totals can be imported too. The Stats page's import reads KeepTrack's files and bytes sent and received from the same mIRC
vars.inias OmenServe's. If both counted your sends - the same sends twice - you choose which totals to keep. KeepTrack's received totals go into the new transfer record, and the preview says when KeepTrack began counting and which file types it counted (its default list leaves out .rar and .flac). - New: on Windows the bot can run minimised, or with no window at all. Settings > Debug & logging > The bot's window:
normal(as before),minimised(in the taskbar) orhidden(no window; what it says goes todata\logs\dccore.log). The first run always has its window, for the setup. - New: ways to stop the bot without its window.
start-dccore stop(on Windowsscripts\windows\start-dccore.bat stop) asks the bot to stop and waits until it has; the dashboard's Tools page has Stop the bot, the admin console hasshutdown now, and the DCCore menu indccore.mrchas Stop the bot.... All of them stop it the way Ctrl-C in its window does. - Fixed: the List Browser's filter showed a list from a bot whose nick is only symbols (such as
^_^) as holding no match. It is found now. - Fixed: a Save of the on-connect commands that was refused put the saved ones back over what you had typed. What you type now stays in the box until it is saved.
- New: the bot keeps a log file. Everything its window shows is also saved in
data/logs/dccore.log, with the date on every line, so it is still there after the window is closed. At 5 MB a new file is started and five old ones are kept; Settings > Debug & logging changes that, or turns it off. - Fixed: asking for the same file again no longer queues it again. A request for something already waiting in your own queue, or already being sent to you, is not added a second time; the bot tells you once that it is already queued and where, or already on its way. Before, asking over and over could fill your whole queue with copies of one file, and each copy was then sent.
- Fixed: the bot could take most of a minute to start when it held many fetched lists. On every start it read the whole cross-list search index (several GB on a busy bot) just to see which lists were in it. It now asks about each list directly, which takes a fraction of a second.
- Changed: DCCore's files are tidied into folders. The program's modules are now in
src/, and your ownsettings.confandadmin_config.pyinconf/. Nothing to do: the first time the new version starts it moves your two files intoconf/by itself, and the start scripts find them there.oserve.py,configure.pyandupdate_list.pystay where they were, so the commands that start and set up the bot do not change; the one that makes the admin console's password hash is nowpython src/adminchat.py. If a guide or a script of yours openssettings.confby its path, point it atconf/settings.conf. - New: the bot checks that its on-connect commands worked, and sends them again if not. In a net split the X login can go nowhere, and the bot used to sit in its channels with its real host until it reconnected. Now, if the commands set a user mode such as
+x, the bot checks a minute after joining and then every 5 minutes (Settings > Identity & network; 0 turns it off) - for+x, that the host really is hidden - and sends them all again if not, up to six times per connection. Resend commands, beside Save on-connect commands, sends them right away. It works whether or not a channel let the bot in - on Undernet a+rchannel refuses it exactly when the X login did not take. - Fixed: a send slot no longer stands idle while a folder (
!rar) is being packed. When the person who had just finished had a folder next in their queue, the freed slot was left unused for as long as the packing took - up to half an hour - and a new request was queued instead of sent. It now goes to whoever has waited longest. - Fixed (security): in the DCCore Chat window, an answer to someone who wrote to you privately could go to a channel instead. If a line arrived from a channel while you were typing a private reply, the reply was sent to that channel. A private conversation now stays private until you pick another target yourself.
- Fixed: Cancel on the Downloads page could delete a file that had just finished downloading, if it finished while the "Nothing has been downloaded yet" question was open. Cancel now only ever lets go of a request that has not started; a finished one stays, and the page says so.
- Fixed:
@<nick>-remove <file>did nothing for someone who had just left the channel - no reply, and their queue on disk was not updated. It removes the file and says so now. - Fixed: with an older
dccore.mrc, the DCCore window filled with[PEERS] ...lines after the bot was updated - on every connect, every ten minutes and whenever another DCCore bot came or went. The bot now sends those lines only to a script that can read them (1.7 or later). - Fixed: the DCCore Chat window's title always said your next line would go "privately", and named the wrong place when you had picked a channel or a person to talk to. It now names where the line really goes.
- Fixed: with DCCore Chat on, your own bot's
[ServersChat]lines showed in the channel window. Every line your bot relayed - what you typed, or what it passed on from another bot - also appeared raw in the channel. They are hidden there again. - Fixed: "Download again" on a failed folder (
!rar) download now asks for the folder again. From the dashboard or the mIRC Downloads window, it asked in a way that made DCCore refuse the album when it arrived. - Fixed: a download that waited a long time in another bot's queue, then had to wait for disk space, could be given up on too soon after it was queued again. Its new place in that bot's queue is now timed from when it got it.
- Fixed (security): many people joining a channel at once could make dashboard searches come back empty. DCCore Chat checks each newcomer to see whether it is another DCCore bot, and those checks queued up ahead of the search. They are now limited and kept out of the search's way.
- Fixed: a large download that had to wait for disk space, or was cut off by a restart, could be asked for again and again without ever starting while your disk had less than twice its size free. It now starts as soon as it ...
v1.13.2 - The Bot Says What It's Doing
21 changes since v1.13.1, dominated by the debug channel and console feed becoming visible when something is quietly wrong, and the DCCore Chat peer sidebar finally clearing correctly.
- Fixed: clearing the debug channel from the dashboard now leaves it right away, and asks first. Whenever the bot does stay behind (any other way of clearing it), it now says so in the debug channel and admin console too, not just its own log.
- Fixed: the
dccore.mrcwindow now says why it only shows "STATUS" and nothing else. A new checkbox/menu item (consolefeed on|off) turns the rest of the feed back on. Updatedccore.mrc(now 1.7). - Fixed: a DCCore Chat peer's sidebar could show the same nick repeated many times over, because clearing it before redrawing silently did nothing.
- Fixed: a DCCore bot reconnecting could take up to 10 minutes to reappear in the DCCore Chat sidebar - now within moments.
- Fixed: a mass rejoin in a big channel no longer makes the bot stall.
- Fixed: a list rebuild is no longer reported as failed when only the saved track lengths could not be written.
- Fixed: adding or removing a second list no longer throws away the saved track lengths and quality.
- Fixed: after a restart, downloads from a bot you were queued at no longer stall for up to 12 hours.
- Fixed: removing a download that another bot has queued no longer warns that a downloaded file will be deleted.
- Fixed: the dashboard's version line and Library cards now change straight away when you switch language.
- Fixed: "Online only" in the List Browser no longer hides a bot that came back under a new nick.
- Fixed: another bot's answer could be applied to the wrong download, when one file's name is the end of another's.
- Fixed: a track that could not be read once no longer loses its length and quality for good.
- Fixed: a file asked for from another DCCore bot while it was reloading its settings was turned away when it arrived.
- Fixed: on Windows, a list rebuild could fail because someone was downloading the list by its file name.
- Fixed: a download added at just the wrong moment could skip a pause or the low-disk check.
- Fixed: one user can no longer make the bot answer "busy" to everyone else.
- Fixed: a list rebuild reading track lengths from a network drive that stops answering no longer hangs for ever.
- Fixed: automatic list grabbing no longer gives up on bots it never asked.
- Fixed: with automatic list refresh on, old lists from bots that have left no longer block the refresh of everyone else's.
- Fixed: downloads waiting from before a restart or a reconnect no longer fail as "no response".
- Fixed: a download bigger than your free disk space no longer fills the disk over and over.
- Fixed: a folder or list download that had to be asked for again asked for the wrong thing.
- Fixed (security): a crafted private message could freeze the bot. Update if you run v1.13.1.
- Fixed: a request could be sent a different file with the same name.
Full changelog: docs/UPDATES.md in this PR's branch.
Extracted per docs/PUBLIC-REPO-WORKFLOW.md's checklist from dccore-dev at a90396d: dev-only tooling and its dedicated tests stripped, changelog swapped, links rewritten. Full suite run in the extracted tree itself: 7021 tests, OK.
🤖 Generated with Claude Code
v1.13.1 - "The Fetch Queue Looks After Itself"
23 changes since v1.13.0, dominated by an AutoGet-parity overhaul of the fetch-from-other-bots side (understanding other servers' replies, per-bot pacing, pausing a bot that keeps failing, waiting on a full disk, automatic list grabbing, list expiry, online-only search, slots/queue/speed shown per bot) plus faster/less-blocking list rebuilds, audio length-and-quality in the list, and an update-check notification.
- Added: automatic list grabbing (off by default).
- Added: a "New" mark on fetched lists in the List Browser.
- Improved: lists from bots that show no date are refreshed too, at 14 days.
- Added: the List Browser shows each online bot's free slots, queue and speed.
- Added: "Online only" in the List Browser's search.
- Added: a "Responsible use" note in the README.
- Added: a bot that keeps failing is paused, and a full disk makes downloads wait.
- Added: the Downloads queue looks after itself (waits for an offline bot, paces per-bot, survives a restart).
- Changed: searching and downloading keep working while the list rebuilds (pauses only for the swap, not the whole rebuild).
- Fixed: fetching from a busy bot now works (queue-position and refusal replies are understood).
- Faster list rebuilds on a network drive (folders scanned several at once).
- Added: your list can say how long each track is and at what quality.
- Added: a checkbox for the update check in the mIRC window too.
- Added: the bot tells you when a new version of DCCore is out.
- Added: the list can rebuild itself on a schedule.
- Added: put words in quotes to search for them together.
- Fixed: re-running setup could collapse more than one services host to just the first.
- Added (mIRC console): the @dccore window's button lights up like a channel's.
- Fixed: pasting a batch of requests could mute you and then ban you for an hour.
- Fixed: pasting several lines from the list at once could be answered "Busy looking up other files".
- A download that fails because your client never answered now says so.
Full changelog: docs/UPDATES.md in this PR's branch.
Extracted per docs/PUBLIC-REPO-WORKFLOW.md's checklist from dccore-dev at 5bc79b7: dev-only tooling and its dedicated tests stripped, changelog swapped, links rewritten. Full suite run in the extracted tree itself: 6661 tests, OK.
🤖 Generated with Claude Code
v1.13.0 - "The Audit Release"
The largest release yet: the tree behind this is the result of four adversarial audits and the fixes they produced, most recently a 145-finding sweep across twelve independent auditing lenses (all fixed or otherwise resolved) plus a hardening pass on the admin console itself.
Security
- The admin console can now be locked to your services account, not just your nick: setup optionally asks for your services host right after the admin nick question and wires it into
ADMIN_HOSTMASKSfor you, blank to skip as before. A stolen nick alone can no longer run admin commands. - The admin console's
listenmode no longer locks the operator out of their own console when the operator and the bot share one home router (a NAT hairpin): the operator's own connection arrives with a private address rather than the shared public one it advertises, and is now accepted alongside it - without opening the door to a stranger on the public internet. - The dashboard and console login throttles no longer remember every address that ever mistyped a password indefinitely; a link from another site can no longer log you out or submit dashboard actions with your session; the first-run setup link is now good for one browser only.
Also in this release
- A download nobody accepted is now reported as such, with a configurable wait (
DCC_ACCEPT_TIMEOUT) instead of a fixed 30 seconds. - Multi-list operators get an accurate per-list "List update completed" line instead of only the first list's count.
- Only one DCCore runs from a folder at a time.
- Several
!rarpacking races and cleanup issues, a handful of mislabelled/confusing log and dashboard messages, and a long list of documentation corrections (stale file names, stale step numbers, stale claims about what's implemented).
133 changes in total - see docs/UPDATES.md for the full writeup, and docs/INSTALL.md for upgrading from an existing install.
🤖 Generated with Claude Code