Files
bambuddy/backend
maziggy b83eea07cd Explain a print that never reached the printer's card, instead of sweeping for it (#2780)
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.
2026-08-15 15:00:16 +02:00
..