Slow network-enabled DYMO label maker on Linux?

I'm not sure how many people have stumbled upon the same problem I did, but this problem has been annoying me enormously today.

I recently purchased a DYMO LabelWriter 550 Turbo (soon to be lobotomized to take any label brand) for the purpose of keeping inventory at home.  We use Grocy combined with a handy label-making routine in Home Assistant to get homemade foods inventoried for freezing.  Our previous label maker, a NIIMBOT B21 Pro, was being too flaky for us to continue using, so — despite how cute it was — I sold it — and in its place, we got the DYMO one.

The DYMO labeler arrived today; in preparation for the printer to be used, I had set up a CUPS print server and tested it to be working properly with its virtual PDF printer.  Then, after unboxing and networking the printer, I followed the "standard routine" of adding the DYMO printer — which uses the AppSocket / JetDirect protocol on port 9100:

• (in Fedora) Install package dymo-cups-drivers-lw5xx.
• Open CUPS at localhost:631.
• Go to Administration, authenticating as root.
• Add a new printer.
• Select socket connection, type in the IP address of the printer, and confirm port 9100.
• Select brand DYMO, model LabelWriter 550 Turbo.
• Confirm.

The problem

Test page came out okay, except for one "small" issue.

Right after printing, the CUPS jobs listing page showed the job as active — it clearly was not, as the label was fully out and printed, and the printer had already reported 100% completion to CUPS.  That stupid print job job stayed there for at least a minute, sitting there like an idiot, with CUPS saying "Waiting for printer to finish".

This happened with every label we printed!  Of course, with the print queue clogged by this finished job, no further labels can be printed.

Needless to say, a label every minute and a half is not exactly Turbo.

I might be okay with this, if it took me a whole minute to prepare and inventory a jar or a container of food — but that's not really the case.  While it's strictly an improvement over how flaky the NIIMBOT printer was, this behavior still ruins the food prep flow; the last thing I want to think about when I'm apportioning food is "stupid printer is stuck".

The solution

It appears to be the case that DYMO networked printers don't respect the AppSocket / JetDirect protocol properly and don't send EOF when the print job is truly done, which is causing CUPS to linger on for a very long period of time before concluding that, yes, the job is indeed done (or perhaps we don't care about it anymore).

The fix for this problem is not available via the CUPS Web interface, but it can be done manually, and it works every time.

See this example /etc/cups/printers.conf that doesn't work (it exhibits the problem outlined above):

# Printer configuration file for CUPS v2.4.16
# Written by cupsd
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
NextPrinterId 2
<Printer DYMO_LabelWriter_550_Turbo>
PrinterId 3
UUID urn:uuid:590836de-3e6d-3c79-7537-3d9b800a6a0b
Info DYMO LabelWriter 550 Turbo
Location Bookshelf
MakeModel DYMO LabelWriter 550 Turbo
DeviceURI socket://label-maker.dragonfear:9100
State Idle
StateTime 1775163349
ConfigTime 1775131466
Type 53316
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>

In bold, you'll notice the device URI, which indicates to which host and port the CUPS server must connect to (and send print jobs to).

That doesn't work.  That sticks the printer up for a minute after each printout.  Here is what works:

First, stop CUPS completely (systemctl stop cups.service cups.socket).

Then, edit the printers.conf file to have the content in bold below added:

# Printer configuration file for CUPS v2.4.16
# Written by cupsd
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
NextPrinterId 2
<Printer DYMO_LabelWriter_550_Turbo>
PrinterId 3
UUID urn:uuid:590836de-3e6d-3c79-7537-3d9b800a6a0b
Info DYMO LabelWriter 550 Turbo
Location Bookshelf
MakeModel DYMO LabelWriter 550 Turbo
DeviceURI socket://label-maker.dragonfear:9100/?waiteof=false
State Idle
StateTime 1775163349
ConfigTime 1775131466
Type 53316
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer
</Printer>

Then restart CUPS (systemctl start cups.socket cups.service).

Why the fix works

This waiteof=false parameter instructs the CUPS socket backend — the thing in CUPS that sends print data to the printer and receives print progress status from it — not to wait until the printer sends an EOF to consider the job done.  This circumvents the bad end-of-printing behavior that DYMO label makers have.  The rest of the protocol works fine, and CUPS is able to queue / serialize print jobs without issue.  This workaround is effective!

Now I can finally print a gazillion labels a minute, just like DYMO promised.

Final tip on procuring a label maker

If you're buying a label maker, and you have only a laptop, don't buy a non-networked printer.  You eventually won't use it anymore, because you'll be connecting and disconnecting the damn thing every time you want to use it... and that gets old fast.

Don't buy a Bluetooth label maker either; these printers have nonstandard protocols, so you're stuck with "the app"... which by the way, if the manufacturer stops supporting the printer in a future app update, you are now in possession of a brand new old e-waste paperweight.  They're also often flaky and slow, even when they're new.

Buy a networked label maker, stick it into your network, and configure your computers to print directly to it.  You already know how to do this on Linux for DYMO devices — you just learned!  They also ship perfectly cromulent Windows and Mac drivers for the NPCs.

The extra $30 or so you pay for the network feature is more than worth the money.  Just make sure the printer is not Wi-Fi (for robustness) and doesn't require "an app" to set it up.