Can you please provide example data you are sending to the server? Your browser will have a "developer tab" where you can view the data and server response

Looks like it's triggering early. I get two requests to /api/barcode:

• {"barcode":"{\"st"}
• {"barcode":"ockitem\": 536}"}

It works properly if I scan the barcode into a text editor and then paste it in. I think it might be a timing issue? This scanner (Symbol DS6878) keys the data a little slow in bluetooth mode.

Now I check and apparently the processing delay is configurable, so this should be an easy fix for me. Still, might want to trim the default, this is a pretty common scanner.

100ms seems to work.

I'm not sure what changed when I upgraded, did it work differently? I assumed it submitted on the line feed after the scan, not using a timer...

@alexisvl changing the default timer will make the wait for the scan to register longer, I think we will wait for more reports before changing it.

I'm not sure who's going to get impatient at 100ms. Especially if we also respond to the line feed that most scanners send by default... It just feels like a timer is the wrong way to solve this problem. The setting also isn't super discoverable, at least from the perspective of just suddenly getting "no match" errors with no pointer to why.

Maybe the "no match" message should include the text of what it thought the barcode was? I bet this would have been a lot more intuitive to fix had I seen a partial barcode there.

The latency is dependent on a lot of factors, I would rather not start adjusting it to user setups. The shorter the delay is the snappier the interface feels.
I am open to PRs that change the language of the (English) text, it should be easy to find with GH search. I am not that good with this foreign language so not sure what to change to.

@alexisvl would you be willing to submit a PR which improves the setting description, and error messages?