Raw data printed out after updating to com.starmicronics:stario10:1.11.2

[zaibniazinnowi]

I have three star printers connected:
Sdk : (com.starmicronics:stario10:1.11.2)

After upgrading from com.starmicronics:stario10:1.8.0, we started observing an intermittent issue where the printer occasionally throws a "write failed" exception. Retrying the print request successfully prints the receipt, but in some cases the printer also outputs unexpected raw/junk data, as shown below.

The issue is difficult to reproduce and occurs very infrequently—approximately once in every 100 print requests.

Current implementation

Each printer is managed as a global instance, which is used to open and close the connection. These instances are recreated only when the application is restarted.

This approach has been working reliably and no issues were reported previously, but this problem has started occurring recently without any changes to the implementation.

Your device where the bug occurs
Device:
Google Pixel Tablet
OS:
Android 16
Your printer
Model Names:
Star MCP30
Interface:
e.g. Ethernet

[zaibniazinnowi]

For the receipt shown in the second image, the relevant logs are attached. The printing process for this receipt started at 2026/07/10 00:51:43.417 for ORDER#1

What happened:

This Update Receipt was required to be printed on three different Star printers (Printer IDs 8, 9, and 10 with MAC addresses ending in ...C838, ...F07B, and ...F1C8), all connected over the LAN through the same device (192.168.1.227 on the SpectrumSetup-5A2C network).

All three print jobs were started concurrently using:

batchOrders.map { async { printBatchData(...) } }.awaitAll()

The logs confirm that all three print operations were executed in parallel. During execution, the print job sent to Printer 8 (MAC ending in ...C838) failed with a print timeout exception, while the other print jobs continued independently.

Logs are attached below:

log_20260708231102747.txt

[KHosozawa]

@zaibniazinnowi
Thank you for bringing this issue to our attention.

We have begun investigating it on our side and will review the details carefully. We will get back to you as soon as we have any updates.
Thank you for your patience and understanding.

[zaibniazinnowi]

@KHosozawa
Could you also verify whether intermittent internet connectivity (network fluctuations) or printing from a remote location (higher network latency or unstable WAN/VPN connection) could contribute to this behavior?
It would be helpful to determine whether network instability during the print job can lead to write failures, or unexpected raw data being printed.

[KHosozawa]

@zaibniazinnowi
Sorry for the delayed response.

We have created and run a reproduction test based on the information you provided, but so far we have not been able to reproduce the issue on our side.

To make our reproduction test more accurate, could you please provide the following information as much as possible?

1. A photo of the printer self-test print result for each printer.
   You can print the self-test by turning the printer on while holding down the FEED button.
   Please keep holding the FEED button until the self-test printing starts.

2. Did this issue start occurring immediately after updating the library from com.starmicronics:stario10:1.8.0 to com.starmicronics:stario10:1.11.2?

3. From the photos, it looks like multiple print attempts may have been made.
   Does the unexpected output start in the middle of the first print job?
   Or does the first print job stop/fail, and then the unexpected output starts from the beginning of the next print job?

4. Does this issue occur when printing to only one printer?
   Or does it occur only when printing to multiple printers concurrently?

5. Based on the information you provided, we created a reproduction sample.
   Could you please check whether this sample matches your actual implementation and printing sequence?

• PrinterHolder.txt
• MainActivity.txt

Please note the following about the attached sample source code:

• Some comments in the sample source code are written in Japanese. We apologize for any inconvenience this may cause.
• Due to GitHub attachment restrictions, the file extension has been changed from .kt to .txt.
• The main reproduction code starts at line 165 of MainActivity.txt.

Regarding your question:

Could you also verify whether intermittent internet connectivity (network fluctuations) or printing from a remote location (higher network latency or unstable WAN/VPN connection) could contribute to this behavior?
It would be helpful to determine whether network instability during the print job can lead to write failures, or unexpected raw data being printed.

Yes, network instability could be one possible contributing factor.

If the communication path between the device and the printer is unstable, data transmission may fail or time out during a print job. In such a case, the printer may receive only part of the print data, or the application may send the next print data while the printer/application communication state is not fully recovered. This could potentially result in unexpected output.

However, at this point we have not confirmed that network instability is the direct cause of this issue, nor have we reproduced the same unexpected output on our side. We would like to continue investigating based on the additional information above and the reproduction test.