Facing com.starmicronics.stario10.StarIO10InUseException: The device is in use by another host. errorCode: None

[zaibniazinnowi]

• Description

I am facing a very unusual and unexpected issue. So far, three instances have been identified over the past one and a half months, but the root cause has not yet been determined.

I pulled the Star SDK logs and will share the details here.

First instance:
2026/05/08 11:16:32.505

Second instance:
2026/05/16 13:06:14.365

Third instance:
2026/05/21 18:08:49.298

What happens is that the printer works fine initially, but whenever the printer remains in an idle state for more than 30 minutes or some cases 2-3 hours, this issue occurs.

I have included the timestamps from the Star SDK logs, which I am also attaching for reference.

I also had a call with the customer to understand how the printer recovered from the issue. According to them, they simply rebooted the printer (turned it off and then back on), after which it started working normally again.

I am using a single printer instance throughout the entire application lifecycle.

Your device where the bug occurs

• Device:
  Android Elo Touch Solutions 15in-I-Series-4
• OS:
  14 or 15

Your printer

• Model Names:

  • mC_Print3 MCP31 (STR-001)[001162347168]*

• Sdks:

  • implementation("com.starmicronics:stario:2.14.0")*
  • implementation("com.starmicronics:stario10:1.11.2")*
  • implementation("com.starmicronics:starioextension:1.17.0")*

• Interface:
  Ethernet
  Getting Star printer old instance openTimeout : 10000, getStatusTimeout : 5000, printTimeout : 90000, connectionSettings : {interfaceType : Lan, identifier : 001162347168, autoSwitchInterface : false}, information : {model : mC_Print3, emulation : StarPRNT, detail: [ lan : [ ipAddress : null macAddress : null ] bluetooth : [ address : null deviceName : null ] usb : [ portName : null usbSerialNumber : null ] ] reserved : [ {bluetoothAddress=null, macAddress=null, specifiedIdentifier=null, usbSerialNumber=null, wlanMacAddress=null, isModelEstimated=false, isFallbackModel=false} ]} with interfaceType Lan and hashcode is 240840720 with mac 001162347168

log_20260506141146128.txt
log_20260515131947921.txt
log_20260518182249440.txt

[zaibniazinnowi]

One more thing — I am calling close() before open() just to ensure a safe connection, since I already close the port once the job is completed.

printer.close()
printer.open()

This can be verified from Star sdk logs

Could this approach still cause or contribute to the issue?

[bandit-ibayashi]

@zaibniazinnowi Thanks for the detailed report and the three log files. Here's what we found so far.

Findings from the logs

All three errors follow the same pattern:

• The previous print job finishes normally, including closeAsync.
• The app stays idle for 30+ minutes (~33 min, ~39 min, and overnight in your cases).
• The next openAsync fails with StarIO10InUseException.
• close -> open retries never recover the connection.
• Only a power cycle of the printer restores it.

Likely cause

Based on the information you have provided, the most likely cause is that another process is still holding the TCP port of that printer.

Looking at the logs from May 7th, the hash code of the StarPrinter instance has changed. This suggests that the process changed overnight. Given that an inUse error occurred afterward, it's unlikely that the StarPrinter instance session from the last print on the 7th remained unchanged.

Additionally, the SDKs list stario:2.4.0. If stario is communicating in the background, a problem may occur where the stario10 cannot communicate.

Alternatively, it is possible that the Android host device has other software installed that can connect to the Star printer, or that communication is coming from other devices on the same network.

Therefore , could you please check the following? :

1. Dependencies: Your build.gradle includes both com.starmicronics:stario:2.14.0 and com.starmicronics:stario10:1.11.2. Is the legacy stario actually used, or pulled in by another library? If not used, we strongly recommend removing stario and starioextension.
2. Other code paths touching the printer: status monitoring, startup reachability checks, background workers, separate Activities/Services, etc.
3. Other hosts on the LAN: another POS, a Web config page, SNMP monitoring, etc.

On your close() -> open() pattern

Looking at the logs, it appears you are indeed closing the process during preprocessing, which I believe can be eliminated. However, I think it's highly unlikely to be related to the issue you reported.

Information that might help you avoid this issue

1. On the printer side, please consider enabling Data Receive Timeout on the mC-Print3 (disabled by default, configurable 30–300 s). With a value of around 120–180 s, the printer will proactively drop stale TCP connections without requiring a power cycle. You can set this from the printer's Web configuration page. Just make sure your app does not legitimately hold an idle connection longer than the configured value.

2. We recently released StarIO10 version 1.12.1, which fixes some issues. If possible, we would appreciate it if you could use this latest version for testing.

Thank you in advance.

[zaibniazinnowi]

@bandit-ibayashi

I have done these steps on 8 May Data Receive Timeout #9100 Data Timeout

Regarding the observation about the StarPrinter instance hash code changing overnight, I agree that this indicates the application process or printer instance was recreated.

However, even if the process changed and a new StarPrinter object was created, my understanding is that the new instance should still be able to communicate successfully as long as the previous connection was properly closed and released.

we are doing background printing in below way
The foreground service stays running
Network is available (for LAN)
You open → print → close per job (which you already do)
Nothing else holds the printer TCP port (another POS, stale session, etc.)

Other important thing to add we had another KIOSK device which has same implementation but old star sdk
implementation("com.starmicronics:stario:2.13.0")
implementation("com.starmicronics:stario10:1.8.0")
implementation("com.starmicronics:starioextension:1.16.1")

I have verified from logs connection was properly closed after doing job.

[bandit-ibayashi]

@zaibniazinnowi Thank you for the detailed update.

I'm afraid for not being aware of your previous posts. I now understand that #9100 Data Timeout is already enabled.
I also understand that this setting was in effect when the inUse errors occurred on May 16th and 21st.

You are right that, in principle, if the previous connection was properly closed, a new StarPrinter instance should be able to reconnect — and the SDK does send a proper TCP shutdown on closeAsync.

Thank you also for explaining the background printing mechanism in your system. A few observations and follow-up questions.

• I understand that this entire printing process will be handled by stario10 . In this case, how will legacy stario and starioextension be used?
  • In particular, when status monitoring using StarIoExtManager in stario / starioextension is enabled, access from stario10 is not possible. This raises some concerns about unintended conflicts between stario/starioextension and stario10.
• Does this issue also occur with other kiosk devices using older versions of the SDK?
• Does the printer have a static IP address assigned to it?
  • The Stario10 uses the MAC address as its identifier, so there's no need to be aware of the IP address. However, some Stario and other Star Micronics software specify the connection destination using the IP address.

Also, if other software is communicating on port 9100, it's possible that it might be controlling the port.

While this is only one possibility, we have never encountered such an issue during our evaluation process, so we would like to clarify these points first.

We apologize for the continued inconvenience and deeply appreciate your cooperation

[zaibniazinnowi]

@bandit-ibayashi

Below are answers to your queries

1. Our printing and status checks are handled entirely by StarIO10. We do not use StarIoExtManager or any other legacy stario/starioextension communication APIs. Status is checked once per job via StarIO10 getStatusAsync() on an open session, not via continuous legacy monitoring. Legacy SDKs were included in Gradle only because of an unused model-capability helper (StarModelCapabilityUtil) that references StarIoExt enum constants but is never invoked. We are removing stario and starioextension from our dependencies so only StarIO10 remains in the APK.

2. Yes, we observed the same issue on the kiosk around the same timeframe when it was reported on POS

3. We primarily rely on the printer’s MAC address as the identifier for discovery and communication.

Because of this, even if the application process restarts and a new StarPrinter object is created, the connection logic still targets the same physical printer device consistently through its MAC address.

At this point, could you please let us know whether the information and logs shared so far are sufficient for you to reproduce or further analyze the issue on your end?

If additional information, logs, or diagnostic data would help your investigation, please let us know and we will share whatever is required.

Thank you for your continued support and detailed investigation efforts. We really appreciate the time your team has spent analyzing the logs and providing technical guidance so far.

We understand this issue is not straightforward to reproduce, and we highly value your continued assistance in helping us identify the exact root cause. The insights you have shared have already been very helpful in narrowing down possible scenarios from both the application and network/printer sides.

[bandit-ibayashi]

@zaibniazinnowi Thank you for the detailed answers — this is very helpful.

Confirming our understanding from your reply:

• All printer communication (including getStatusAsync) is handled by StarIO10 only; legacy stario / starioextension are dependency-only and never invoked.
• The same issue is observed on both the POS (newer SDK) and the KIOSK (older SDK) around the same timeframe.
• Discovery and connection are MAC-based, so the same physical printer is consistently targeted across process restarts.

This rules out two of our earlier working hypotheses (a parallel legacy socket, and an SDK version regression).

We deeply appreciate your kind offer. We will continue to organize the information we have gathered so far and work towards identifying the cause of this issue and resolving it. We may have questions during this process.

[zaibniazinnowi]

@bandit-ibayashi
Thank you for the update. Please feel free to reach out if any additional information or assistance is needed from our side.

[bandit-ibayashi]

@zaibniazinnowi We are currently attempting to reproduce the issue based on the information you have shared. So far, we have not been able to reproduce it.

We have also clarified the conditions under which StarIO10InUseException is thrown. This exception occurs in the following two patterns:

1. Another host device is connected to the printer over LAN (i.e. it has an established connection to the printer).
2. Another StarPrinter instance on the same host device is also connected to the same printer over LAN. In this case, the exception is raised on the second StarPrinter instance.

Based on the logs you have provided, the situation appears to match the first pattern.

In addition, the mC-Print3 you are using will close the TCP session after a certain idle period if no instance is actively communicating with it.

From everything you have shared so far, we do not believe there is anything else communicating with the printer. However, one possibility we would like to consider is whether, for example, a DHCP lease renewal could have changed the printer’s IP address, causing some background process to end up connecting to a different target.
For that reason, it would be very helpful if you could let us know whether the printer’s and the host device’s IP addresses are assigned via DHCP, or whether they are configured as static IP addresses.

We will continue our reproduction efforts on our side, and if anything else comes to mind on your end, we would greatly appreciate it if you could share it with us.

[zaibniazinnowi]

@bandit-ibayashi

Thank you for the detailed clarification regarding the two scenarios that can trigger StarIO10InUseException

1. IP Address Assignment (DHCP vs Static)

We reviewed the logs collected from our host devices during the reported incidents and confirmed that the IP addresses remained unchanged throughout the affected timeframe:

• POS device: 192.168.1.73
• Kiosk device: 192.168.1.201
• Printer: 192.168.1.120

Based on this, it does not appear that a DHCP lease renewal or IP reassignment occurred on either the host devices or the printer during the incidents. While this makes a DHCP-related cause less likely in our case, we remain open to investigating any other network-related possibilities you may identify.

2. Connection Method via MAC Address

In our application, LAN Star printers are configured to connect via MAC address by default rather than IP address. Specifically, the StarConnectionSettings identifier is assigned using the printer’s MAC address unless the operator explicitly enables the “Print Through IP” option within the printer settings.

For troubleshooting purposes, our application also logs both the host device MAC address and IP address during print initialization.

With that in mind, we would appreciate clarification on whether a printer IP address change could still contribute to StarIO10InUseException even when the SDK connection target is configured using the printer MAC address.

3. Visibility Into Active Connections

Could you please confirm whether the mC-Print3 web interface provides visibility into active LAN/TCP connections or connected client devices?

It would be extremely helpful if there is a way to inspect which host currently holds an active session with the printer at the time of a future occurrence, as we currently do not have built-in visibility into that state from the application side.

If such diagnostic information is available either through the printer web portal or another recommended tool, please let us know where it can be accessed.

4. Stale Connections and Timeout Behavior

We would also appreciate clarification regarding stale TCP sessions and timeout handling.

Within our application:

• printTimeout is configured to 90 seconds (90,000 ms).
• This timeout applies only to the print operation itself and not to TCP session idle timeout or socket cleanup behavior.
• Our print flow explicitly calls closeAsync() after each print batch completes.
• Additionally, we call closeAsync() followed by openAsync() at the beginning of each new print session to ensure a clean connection state.

Based on your note that the mC-Print3 automatically closes TCP sessions after a period of inactivity when no instance is actively communicating, we would like to better understand how long a session may remain in an “in use” state from the printer side, especially in scenarios involving abrupt disconnects or stale sockets.

Understanding this behavior would help us determine whether a transient or stale connection state could persist even after our application has already closed its session.

Please let us know if you require additional network configuration details, log excerpts, or timestamps from any specific incident.