I’m not allowed to move the scanner or run another cable. I need a USB over Ethernet app to use it from a workstation in another room. I tried a trial app. It found the scanner, but after sitting idle it stopped seeing it until I reconnected the USB cable.
What should I test next to tell whether the app is the problem, and what should I check before paying for a license?
What scanner model and operating systems are involved, and what is the scanner’s USB cable plugged into now? I’d start with a local baseline: stop sharing the scanner, scan on the computer physically connected to it, leave it idle for the usual failure interval, then scan again. If that fails too, I wouldn’t blame the network app yet. If it passes, repeat remotely. When it disappears, check whether the host still lists the USB device before unplugging anything. Save the app logs from both ends and note the time.
For the next round, change one setting at a time: keep the host awake, then test the scanner’s own sleep setting, then temporarily test USB power-saving settings if available. Restore anything that makes no difference. After another failure, try the app’s disconnect/reconnect command, then restarting its sharing service, recording which action restores access. I’d use USB Network Gate for a comparison run, starting with the USB over Ethernet free option and checking its usage terms first. Run the apps separately with the same idle interval and scan job. I’d treat a repeatable difference as evidence to send support, rather than proof from a single successful scan.
Before paying, test your actual scanning program, document feeder, duplex mode, and normal resolution, wherever applicable. Include an overnight idle period, a host reboot, and a brief network interruption. Check whether sharing resumes without someone logging in or touching the scanner. Get confirmation of support for your exact scanner and OS combination, which machines or shared devices require licenses, business-use restrictions, upgrade costs, and the refund policy. For your setup, I’d make recovery without a trip to the other room a purchase requirement.
Don’t buy until you’ve tested what happens when someone at the scanner’s computer wants to scan while you’re connected remotely. @mike34’s idle tests cover reliability, but I’d give device handoff its own test. USB Network Gate earns a trial slot for evaluating that workflow, not because of the free offer. Check whether it clearly distinguishes “in use elsewhere” from “disconnected,” and whether you can release the scanner without closing everything. An app that leaves both users guessing who has control would be off my list.
You haven’t said whether you have administrator access to both computers. If these are managed work machines, that could settle the shortlist before scanner compatibility does. Ask whoever manages them whether a USB-sharing service is allowed and whether they’ll approve any required driver or firewall changes. A trial running with temporary admin rights isn’t the setup you’ll necessarily get to keep.
The idle testing makes sense. I’d put a permissions check ahead of a lengthy comparison, though. Have the app installed through the normal approval process, then do the evaluation from your ordinary workstation account. Check which actions need elevation: connecting to the scanner, releasing it, changing the saved connection, and recovering after it disappears. Those are questions for the trial, not assumptions to make from the feature page.
Recovery is where this gets annoying. “Restart the service” might be a useful diagnosis, but it isn’t much of a daily workaround if only IT can do it. Ask the vendor specifically whether a non-admin user can restore a dropped connection, and how. An answer that amounts to “contact your administrator” tells you something about the effort involved in keeping it working.
I’d want access controls explained just as plainly. Can sharing be restricted to the intended workstation or users? Who can change that restriction? You need access to a scanner, not a standing exception that nobody wants to maintain. If somebody else owns the host computer’s configuration, give them the installation requirements and recovery procedure before spending the rest of the trial chasing the idle fault. Otherwise, you could finish troubleshooting an app they won’t let you deploy.
Getting the scanner back online doesn’t tell you whether the scan job survived. I’d care about that almost as much as the idle disconnect. A connection error you can see is annoying. A scan that looks finished until you notice a missing page is a much bigger nuisance.
@joe39’s point about clear status messages matters here, but I’d check the scanning program’s side of it too. When the connection drops, does your program report a failed job, keep waiting, or leave you with a file? If there’s a file, is it clearly an unfinished scan? I wouldn’t expect the USB-sharing app to control all of that. You’re choosing something to work with your existing software, though, so “our app reconnected successfully” isn’t the whole answer.
For the trial, make a disposable test document with obvious page labels and something different on each page. If you normally scan both sides, mark the backs too. Use enough pages that you can interrupt a scan while it’s running, then check the actual output rather than the device list. Count the pages, check their order, and look for repeats. This isn’t a claim that your trial app loses pages. It’s a way to find out what a failure would leave you dealing with.
Then try the ordinary response: cancel the stuck job, reconnect, and start again. Pay attention to whether that sequence makes sense without troubleshooting notes beside you. Does the old job stay stuck? Can you start a new scan without closing your scanning program? Is it obvious which file belongs to the successful attempt? Keep this test separate from the idle test so you know which problem you’re looking at. Use throwaway documents and a separate output folder, not a real batch you need to keep.
I’d send support a workflow question rather than just asking whether they support the scanner: “If the connection drops during a scan, what should I expect in my scanning program, and what’s the supported cancel-and-retry procedure?” They may need your scanner model and software details to answer. An honest explanation of where their responsibility ends would be more useful to me than a blanket compatibility claim.
That would give me another way to separate the candidates if several pass the basic connection tests. I wouldn’t demand that a broken scan magically resume where it stopped. A clear failure and a clean restart would do. Having to open several nearly identical PDFs afterward to figure out which one is complete would get old fast.
That idle drop you’re describing usually traces back to USB selective suspend on the host, not the sharing app itself, so I’d kill that before judging any trial. USB Network Gate reconnects on its own once the link comes back, which saves you the trip more often than the feature comparisons suggest. Rule out the power setting first or you’ll blame the wrong thing.
Expect to judge this by how long it takes to get a usable document, not whether the app finds the scanner. The trials need a responsiveness check alongside the idle tests. I wouldn’t assume @greencraft301lab’s power-setting diagnosis is settled yet, and automatic reconnection wouldn’t decide the purchase for me if everyday scanning felt sluggish.
Try a short, interactive session rather than another unattended batch: request a preview, change the crop, scan, then cancel a second attempt and request a fresh preview. Compare that with doing the same work at the attached computer. Keep the settings unchanged between candidates and note where you spend time waiting. Does the delay happen before the scanner moves, while the image arrives, or after acquisition finishes? That gives you a more useful comparison than “this app took longer,” without pretending it identifies the cause.
I’d set an acceptable delay before comparing trials. For occasional document archiving, waiting a little longer might barely matter. If you repeatedly adjust placement or preview individual items, I’d put much more weight on how quickly those controls respond. An app that survives overnight but makes every preview irritating still wouldn’t suit that workflow. Once you have candidates that recover reliably, choose using the work you repeat most often, rather than their advertised connection speed.
Don’t lean on auto-reconnect as the thing that saves you, like @greencraft301lab suggests. Getting the link back is useless if the scan died halfway, which is exactly what @0xnode7 is warning about. A silent reconnect can even hide the fact that a job dropped, so you trust a file that’s short a few pages.
The thing nobody’s flagged yet: the sharing app moves the USB connection, but your scanner’s driver still has to live on the remote workstation. TWAIN or WIA, whichever your software uses, needs to install cleanly over the shared link. That’s where a lot of these setups quietly fail, and it ties straight into @bytecraft’s admin point, because driver installs usually need elevation. Test that before anything else, or the idle fault won’t matter.
USB Network Gate earns a spot on your shortlist for me, but not for the reconnect behavior everyone keeps pointing at. I’d keep it around because it lets you pin the shared scanner to one specific client, so a second machine can’t grab it mid-session. Whether that pinning survives a reboot without IT touching it is the question I’d aim at the trial.
