Hi everyone,
I'm new to the forum, still pretty new to the role in fact, just 4 months now!
Since I started, NScan has been at the top of my to-fix list. We're using the Motorola MC65b for hardware with both Tessitura and print-at-home tickets. I've identified that we may have difficulties with our WiFi network and we're addressing that through capital investment but, even when the WiFi is up, the NScan system doesn't respond in a particularly timely manner when there are lots of tickets being scanned concurrently. Has anyone else found this? It can be fine with just one or two scanners but once we have 4 or 6 on the go it really slows down.
I've put a couple of suggestions in to the development team that we a) separate the database 'write' elements of the code to some separate procedure and b) ensure the stored procedure is able to be called by more than one process at a time as my diagnosis seems to suggest we're seeing queuing of requests which is leading to a considerable slowdown in processing.
So far they are still pondering these ideas so I wondered what the community's experience is please and if you have any suggestions for tweaks we could employ to speed things along?
Thanks everyone, look forward to hearing from you!
Kind regards,
Paul Thompson
IT Manager
Mayflower Theatre
Paul.Thompson@Mayflower.org.uk
Hi Stefanie,
This is the one we tested: was the https://saveoscan.com/products/saveo-scan-main/
A handheld barcode scanner with an Android phone on the top. We just used an old Samsung Galaxy we had spare.
DDI: 02380 711821
Mobile: 07788 283031
In 2018, our theatre’s 90th anniversary, we will be undertaking a £3.9 million refurbishment of our Grade II Listed auditorium. To donate and for more information please visit our website.
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the Mayflower Theatre unless specifically stated. The contents of e-mails sent or received may have to be disclosed if a relevant request is made under current legislation, such as, but not limited to, the Data Protection Act 1998 and the Freedom of Information Act 2000
From: N-Scan [mailto:groups-n-scan@tessituranetwork.com] On Behalf Of Stefanie Lam Sent: 26 July 2017 08:08 To: Paul Thompson <paul.thompson@mayflower.org.uk> Subject: RE: [N-Scan] NScan response times
Thanks Paul, Tom and Dan, I appreciate your responses, that is a great help - will definitely review. Tom, sounds like the saveo scan trigger made a difference... could I ask which model did you do your testing on? Thank you!
From: Dan Spees <bounce-danielspees8805@tessituranetwork.com> Sent: 7/25/2017 2:23:02 PM
One thing we did that helped quite a bit…
We’ve found that RF interference is a more likely source of our slowdowns than anything else. Once the scanners have a connection they are good to go. But, we need to eliminate competition for those connections by taking as much RF load off the access points as possible.
Where possible we dedicate access points for scanning. In the AP configuration we white list the scanners by MAC address. This way the AP all non-scanner devices that are seeking an access point to connect to. Turning off broadcast of the SSID and using a SSID just for scanning can help too.
We’ve started hardcoding IP’s’ too. One less thing for the scanner to have to talk across the network for.
Dan
-------------------------------------------------------
Daniel L Spees
Director of Information Services and Support
Chicago Symphony Orchestra
312-294-3320
speesd@cso.org
http://cso.org
From: N-Scan [mailto:groups-n-scan@tessituranetwork.com] On Behalf Of Tom Brown Sent: Tuesday, July 25, 2017 8:16 AM To: Spees, Daniel <SpeesD@cso.org> Subject: RE: [N-Scan] NScan response times
We have been successfully using N-Scan for a number of years now.
We have used MC 50s which have been retired. We are currently using a mix of MC55 and MC40 devices.
We have had problem from time to time with slowness of WiFi or WiFi disconnects.
Our fixes have been focused on having Wireless Access Points within 5-25 feet of the Scanning Locations. This has been helpful because we work in a very old building with very thick walls in some places. We also believe that this is important because in a world where each or out customers may be bringing in one or more wireless access point in their phones configured as hotspots. We really want to make sure that the signal to our scanners are seeing are particularly strong.
Second we have done some tweaks to the WiFi configuration on the devices. I know that we hardcode IP addresses into our devices because when a signal gets dropped we want to reconnect quickly. I think that there have also been some other tweeks that our infrastructure guys have done. What to know more drop me a direct email and I will see what I can get from the team.
tbrown@bam.org
On Tue, Jul 25, 2017 at 6:16 AM, Paul Thompson <bounce-paulthompson5789@tessituranetwork.com> wrote:
Hi Stefanie, Due to a number of factors (not all the fault of NScan) we stopped scanning in the end and haven’t picked it back up as yet. We faced a number of challenges which were not related to the tech which made us park the project in spring 2016. While we were still investigating it, we tested a different type of scanner from our MC65’s, finding one which required an Android phone on top (https://saveoscan.com/), and that did perform better than the Motorola. Although it was only by a fraction of a second in most cases this was enough to noticeably speed up processing a lengthy queue. In troubleshooting the issue you describe of several simultaneous scans queuing up, and in addition to the elements mentioned already in the NScan forum, we made some tweaks to the SQL to try and prevent it waiting for the record to be updated before returning the result to the scanner – we had found that there’s an UPDATE event in the process and I postulated that might be holding things up so I was looking to ask it not to wait for that to reply. We parked the project before we really got to the bottom of that option. Sorry not to be more help! Kind regards, Paul Thompson IT Manager Mayflower Theatre Paul.Thompson@Mayflower.org.uk DDI: 02380 711821 Mobile: 07788 283031 In 2018, our theatre’s 90th anniversary, we will be undertaking a £3.9 million refurbishment of our Grade II Listed auditorium. To donate and for more information please visit our website. This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the Mayflower Theatre unless specifically stated. The contents of e-mails sent or received may have to be disclosed if a relevant request is made under current legislation, such as, but not limited to, the Data Protection Act 1998 and the Freedom of Information Act 2000 From: N-Scan [mailto:groups-n-scan@tessituranetwork.com] On Behalf Of Stefanie Lam Sent: 25 July 2017 07:40 To: Paul Thompson <paul.thompson@mayflower.org.uk> Subject: Re: [N-Scan] NScan response times Hi Paul, I know it's been a while since you originally posted this - we've also had reports of this occurring when several tickets are scanned in succession. It may scan the first few tickets and register quickly on the scanner, but then slows down considerably and holds up customers at the entry point. We can't seem to find any pattern with this occurring - it can happen on a quiet night when we have one show, or a busy night where there are shows on in multiple venues and up to 20 scanners being used. The wi-fi has been looked at and additional access points placed to boost signal, so apparently the wi-fi should not be the cause. We run Nscan on a separate wi-fi network and we are using MC40s. Just wondering if you ended up finding a solution to this? Kind regards, Stefanie From: Paul Thompson <bounce-paulthompson5789@tessituranetwork.com> Sent: 3/17/2015 10:08:28 AM Hi everyone, I'm new to the forum, still pretty new to the role in fact, just 4 months now! Since I started, NScan has been at the top of my to-fix list. We're using the Motorola MC65b for hardware with both Tessitura and print-at-home tickets. I've identified that we may have difficulties with our WiFi network and we're addressing that through capital investment but, even when the WiFi is up, the NScan system doesn't respond in a particularly timely manner when there are lots of tickets being scanned concurrently. Has anyone else found this? It can be fine with just one or two scanners but once we have 4 or 6 on the go it really slows down. I've put a couple of suggestions in to the development team that we a) separate the database 'write' elements of the code to some separate procedure and b) ensure the stored procedure is able to be called by more than one process at a time as my diagnosis seems to suggest we're seeing queuing of requests which is leading to a considerable slowdown in processing. So far they are still pondering these ideas so I wondered what the community's experience is please and if you have any suggestions for tweaks we could employ to speed things along? Thanks everyone, look forward to hearing from you! Kind regards, Paul Thompson IT Manager Mayflower Theatre Paul.Thompson@Mayflower.org.uk
Due to a number of factors (not all the fault of NScan) we stopped scanning in the end and haven’t picked it back up as yet. We faced a number of challenges which were not related to the tech which made us park the project in spring 2016.
While we were still investigating it, we tested a different type of scanner from our MC65’s, finding one which required an Android phone on top (https://saveoscan.com/), and that did perform better than the Motorola. Although it was only by a fraction of a second in most cases this was enough to noticeably speed up processing a lengthy queue.
In troubleshooting the issue you describe of several simultaneous scans queuing up, and in addition to the elements mentioned already in the NScan forum, we made some tweaks to the SQL to try and prevent it waiting for the record to be updated before returning the result to the scanner – we had found that there’s an UPDATE event in the process and I postulated that might be holding things up so I was looking to ask it not to wait for that to reply. We parked the project before we really got to the bottom of that option.
Sorry not to be more help!
From: N-Scan [mailto:groups-n-scan@tessituranetwork.com] On Behalf Of Stefanie Lam Sent: 25 July 2017 07:40 To: Paul Thompson <paul.thompson@mayflower.org.uk> Subject: Re: [N-Scan] NScan response times
Hi Paul,
I know it's been a while since you originally posted this - we've also had reports of this occurring when several tickets are scanned in succession. It may scan the first few tickets and register quickly on the scanner, but then slows down considerably and holds up customers at the entry point.
We can't seem to find any pattern with this occurring - it can happen on a quiet night when we have one show, or a busy night where there are shows on in multiple venues and up to 20 scanners being used.
The wi-fi has been looked at and additional access points placed to boost signal, so apparently the wi-fi should not be the cause. We run Nscan on a separate wi-fi network and we are using MC40s.
Just wondering if you ended up finding a solution to this?
Stefanie
From: Paul Thompson <bounce-paulthompson5789@tessituranetwork.com> Sent: 3/17/2015 10:08:28 AM