A print's dispatch says where the printer put the sliced file:
ftp://<name> for external storage, brtc://emmc/<name> for internal. Since
that there is then no file to find at any path.
That is where the printer chose to put it, which is not the same as where
port 990 can read it. The reporter's H2D - firmware 01.03.00.00, card in
the slot - reports brtc://emmc and keeps the same file under /cache: his
log has every print from 08-12 downloading from there, 19 MB included,
until the skip landed and two days of archives came out as a name and
nothing else. #2780's P2S and H2C really did 550 on every path, so both
are true and the URL alone cannot tell them apart.
So ask the printer rather than the model. The dispatch names the exact
file, which turns the question into one connection walking five
directories - against the sweep's ~110, which is the cost that made
skipping worth doing. A hit archives normally and is shared with the
cover endpoint; a miss keeps #2780's fallback archive and its reason, so
the archives banner still explains itself. Not probed when the printer
reports an empty slot, or while its file service is in TLS cool-off:
both have already answered the question.
The connection diagnostic asked the same question off the URL and warned
that the last print was out of reach. On this reporter's printer that
warning would have sent him to a setting that was already right, so it
now probes too - by directory listing, since the file it is asking about
can be tens of megabytes and the answer is a yes or a no. Capped at 6s to
stay inside the support bundle's per-printer budget, and "could not
check" leaves the warning standing.
The probe filename arrives over MQTT and becomes both a remote path and a
local temp filename, so names carrying separators, traversal or control
characters are declined rather than cleaned.
(#2780 regression)
A print of a file already on the printer -- a reprint from the
touchscreen, from Handy, or a slicer send-to-storage followed by a print
-- reports its location as a path rather than as a fresh upload:
file:///media/usb0/<name>. Since #2780 landed on 2026-08-14 Bambuddy read
anything that was not ftp:// as "the printer kept this internally",
skipped the FTPS sweep, and archived the print with a name and timing
only. Measured on an H2D: the file was listable and downloadable over
FTPS at the moment Bambuddy declared it unreachable. Before that change
those prints archived normally, so this is a regression, and it is not
confined to the H2 series the change was about -- an X1C reprint from its
own screen loses its thumbnail exactly the same way.
That module's own rule is to skip only on positive evidence, and a
file:// path is not evidence of internal storage. It now reads the path:
the printer's model cache under /userdata is a genuine skip, anything
else is unknown and sweeps, which is what it did before. Unknown rather
than external on purpose -- the empty-slot check still runs ahead of it,
so a file:// print on a printer with nothing in the slot reports the
missing card instead of sweeping for something that cannot be there.
The user-facing copy shipped this morning is corrected in the same
change, because it was written before we understood how Bambu Studio
actually chooses. Its Print button always uses internal memory; only Send
offers Cache or External, and that defaults to Cache too. So the advice
now leads with the two routes that take one step -- start the print from
Bambuddy, or slice in OrcaSlicer -- and offers Send-with-External and a
separate print start as the way to stay in Bambu Studio. The earlier
wording named no remedy at all and blamed the printer's firmware for a
choice the slicer makes. Banner and diagnostic, thirteen locales, README,
bundle rebuilt.
Bambuddy reads a print's 3MF, cover and timelapse over FTPS on port 990,
which on every Bambu model serves external storage only. Under some
configurations H2-series and P2S firmware keeps the sliced file on
internal storage, where Bambu Studio put it over the port-6000 service,
and then no path on 990 can find it.
The print command has always said which of the two it used -- `url` reads
ftp://<name> or brtc://emmc/<name>. We discarded it and swept anyway:
~110 connections per print, all certain to fail, ending in an archive
card with nothing on it and no stated reason. In the reporter's bundle
all 35 dispatches to their H2C and P2S said internal storage, all 25 to
their X1C said external, and all 44 empty cards belonged to the first two.
Read the field, skip the sweep when it cannot succeed, and record which
reason applied. A printer that uses the card is unaffected, and so is one
we have no answer for -- silence is not evidence, and reading it as bad
news would break archives that work today.
The answer is held per print and dropped when that print ends, rather
than kept as a standing fact about the printer. Plenty of prints never
announce themselves: 14 of the 79 print starts in that bundle arrived
with nothing on the request topic, started from the printer's own screen
or picked up after a restart. Left standing, one slicer print to internal
storage would suppress the lookup for every screen-started print after
it, on a printer whose files really are on the card. The sticky reading
is kept for the connection diagnostic alone, which is run after the print
that prompted it and would otherwise have nothing to report.
Two things that pointed the wrong way go with it. The archives banner
told everyone to enable "Store sent files on external storage"; the
reporter had it on for the whole three weeks and it would not have
helped. The diagnostic passed a printer whose slot was empty, because it
read only the toggle -- an empty slot is now a failure naming the slot,
and a printer that has storage and still used its own is a warning. On
P1-series that empty-slot failure yields to the existing unsupported-model
skip: the toggle cannot be switched on there at all, so telling the
operator to insert a card would promise a fix inserting a card does not
deliver (#2524).
Also close FTP sockets on the failure paths, which dropped them for the
garbage collector -- 1813 in a day in that bundle -- and drop the advice
to restart the printer, which the reporter tried twice while a single
manual connection to the same printer handshook cleanly.
This does not make the affected prints archive in full; that needs the
port-6000 protocol tracked in #2762.
maziggy