|
Peter Stoianov
|
April 6, 2014 at 3:53 am
Hi
Is there any way to improve the scanning speed and more precisely the speed with which the qr code is recognized. We had an event on last Friday and had 3 phones using the mobile app. It takes time to pull up the database but moreover it takes time to scan the qr code. We’ve noticed that eventbrite or yapsody are very fast but their QR CODES ARE MORE SIMPLE that the EE ones.
Is that an aria that could be improved? It is vital for high volume events. Please please look into it.
rEGARDS
|
|
Peter Stoianov
|
April 7, 2014 at 6:00 am
Hi,
We also are trying to optimise the speed of the database recall but our host needs to know the following:
We need to know more about the database look up/query that it’s performing in order to diagnose the issue though – what happens exactly when the QR code is read on a QR code reader?
Kind regards,
Darren
and
We would need to know more information about the SQL query that is being executed when that is scanned to help optimise this. I have added an index on the wp_events_attendee table for registration_id and attendee_id but without more information it’s going to be difficult to assist.
Kind regards,
Darren
|
|
Peter Stoianov
|
April 8, 2014 at 6:37 pm
Hello gentlemen, did you get a chance to look at it?
Thanks in advance.
|
|
Josh
|
April 9, 2014 at 8:17 am
Darren,
What was the network speed your scanning devices were connected on? When I test the QR code scanning over a local WiFi network the scans are virtually instantaneous.
|
|
Peter Stoianov
|
April 9, 2014 at 9:58 am
Hi Josh,
The speed was very fast. Its more about the the speed with which the camera scans the qr code. Just try yapsody or eventbrite and you will see the difference. They have more simple qr codes and the phone scans them in an instance. It is vital for high volume events. Also please could you answer Darrens questions about the database query please. We need to improve the speed for our next events.
Thank you very much.
|
|
Josh
|
April 9, 2014 at 11:51 am
We don’t recommend altering the database queries in the JSON API. The queries in the JSON API were written with optimization as a priority, but if you find something that looks like it needs to be optimized please let us know and we can turn it over to our dev team to review.
Can you let us know what hardware, which version of the JSON API, and which version of the mobile apps you are using? It may be more of a hardware issue since you mentioned that “moreover it takes time to scan the qr code”. The scanning is done by the device’s camera before anything is sent to the database.
|
|
Peter Stoianov
|
April 9, 2014 at 12:37 pm
Hi Josh,
We use the latest versions of everything and samsung galaxy S4s which are one of the best phones. Exactly the camera takes time to get the qr code. Please test those two providers I mentioned and you will see the difference. Their qr codes seem simpler but our phones are extremely fast when we test. Wish EE was like that. I bet you could improve the speed. Regards
|
|
Josh
|
April 9, 2014 at 12:46 pm
Peter,
Which versions of the Android Apps? (There are two different apps out there) The one that we recommend using has the coffee cup logo displayed on the ticket that’s pictured on the icon. The older app doesn’t have the logo.
Also, which version of the API are you using? Is it the JSON API or the espresso services API?
|
|
Peter Stoianov
|
April 9, 2014 at 1:03 pm
Using the nee android app as well as jason api.
|
|
Josh
|
April 9, 2014 at 2:07 pm
Can you double check? I can see that the espresso-services API is installed on your website. You can see the espresso-services message load up if you browse to
http://yoursite.co.uk/espresso-services/
where yoursite = your site’s real URL.
|
|
Peter Stoianov
|
April 9, 2014 at 3:22 pm
So shall I delete the old api? Would it make a difference to the speed, since we are using the json api as well.
|
|
Josh
|
April 9, 2014 at 3:45 pm
Hi Peter,
You’re either using one or the other, not both, unless some of the phones have one app installed, and other phones have the other app installed. You can verify which one you’re using by temporarily deactivating the JSON API plugin, then test the app. If the app lets you log in and scan, then you weren’t using the JSON API. If the app doesn’t work with the JSON API plugin deactivated, then you’ll know you’re using the app that connects to the JSON API.
The espresso-services api can be deleted if it’s not being used, and can be done using an FTP client (espresso-services isn’t a WP plugin, so it can’t be deleted through WP). It wouldn’t slow things down if you’re using the JSON API though, they work independently.
|
|
Peter Stoianov
|
April 9, 2014 at 4:26 pm
Josh I thought so. The whole point is whether you can improve the scanning speed of a phone camera by simplifying the qr code or any other method so is as fast as the services I mentioned earlier. Thanks
|
|
Josh
|
April 9, 2014 at 5:13 pm
Hi Peter,
The qr code had been simplified a while back, which made some improvements in scanning for devices like the ipod touch (no auto focus).
I’m still puzzled why you’re experiencing such slow speeds though. When I test the android app on my old Galaxy Nexus it’s much faster than what you’re describing. Can you check to see if the database tables need to be repaired? The other thing that I’m wondering is if you’ve had the opportunity to test using the iOS HD app using an Apple device?
|
|
Peter Stoianov
|
April 10, 2014 at 5:01 am
Hi, just tested with simpler QR codes (less characters on them) using the EE mobile app and it seems the cameras on our phone capture it faster. Is is not a good idea to simplify the qr code? You can see qr code examples here that are simpler:
https://bglive.yapsody.com/booking/ticket/FT53466d1f7dac5/?ticket%5B%5D=FHN148130&ticket%5B%5D=FHN735198&ticket%5B%5D=FHN272674&ticket%5B%5D=FHN391641&ticket%5B%5D=FHN541794
http://www.eventbrite.com/safe-redirect?next=http%3A%2F%2Fwww.eventbrite.com%2Fprint-ticket%2F265844291%2F10846705-265844291-tickets.pdf%2F%3Fc%3DMjAxNC0wMy0wOCAwNzoyOToyNg%253D%253D%250A%26utm_source%3Deb_email%26utm_medium%3Demail%26utm_campaign%3Dorder_confirm%26sig%3DAHTu1yY6ZZ8NqYbiLt4eCyfwDT2hX1Sozg&key=AH_ElWG676Q3LBwFTTsWTW8w-oGTkBZ7iA&utm_term=papertickets&ref=eemailordconf
|
|
Tony
|
April 10, 2014 at 6:29 am
Hi Peter,
I tested those QR codes posted on two S4’s (One on 4.4.2 the other 4.3)
The phone running 4.4.2 responded a little more slowly (4.4.2 has known issues for stability, including camera issues which effect some users but not others) than the other when scanning tickets but overall scanning both the tickets you posted and the Event Espresso tickets where exactly the same (mostly instant)
I scanned each ticket 10x using the EE Android app, each time moving the phone away from the ticket then back again. 9 times of 10 – All of the tickets tested scanned within 1 second of them being visible within the App.
It’s not that we do not believe you are not encountering issues, just that I have personally tested the QR codes on multiple devices ranging from ‘budget’ phones like the Galaxy Ace, Galaxy Mini etc to ‘Premium’ range phones such as the all of Galaxy S (1-4) range, tablets such as the Nexus 7 2013 & Galaxy Tab 3 and even a Galaxy Gear.
The ticket scanning has been pretty much instant with all of those devices with the exception of the Ace sometimes trying to focus the camera multiple times on occasion.
If this was a QR complexity issue we would expect this to happen on more of those devices (especially the budget range)
May I ask what Android version are you running on the S4? (Settings -> More -> About Device)
Is the issue with the camera taking time to focus or is the QR clear within that camera view?
Does this happen under low light or all lighting conditions?
Scanning a digital or paper ticket?
|
|
Peter Stoianov
|
April 10, 2014 at 7:45 am
Thank you Tony,
I would not waste time writing if I did not believe there was room for improving the speed. Just test yapsody or eventbrite and you will see how fast it is. It takes less than a sec to scan and approve a ticket. We have sometime events with 800 people + and we have to get them in very quickly because the queue is long and people complain. We like the EE and we bought it because of the scanning function.
We have used numerous phones over the last 10 months so it is not a phone issue I believe. I think when a qr code is more simple the phone camera does not waste much time to focus and scan.
People mainly bring a paper copy of a ticket and the light is good but we have a bit of a delay still.
I also noticed that if you scan the same ticket in sequence it is a bit faster than if you scan different codes. Also it take 2-3 sec to check the database and validate a ticket, but this is another issue. Another thing we have noticed is that qr scans better if the phones are aroung 20-30cm from the code. If you go closer it takes time to focus.
What if we try the pre release api? Would it help?
I believe you can improve the speed/qr code. May be simplifying the qr is one way to do it. But again please do a test with eventbrite/yapsody to see for your self.
Regards
peter
|
|
Josh
|
April 10, 2014 at 7:55 am
Hi Peter,
Maybe you didn’t catch Tony’s reply, but he did test the other qr codes you posted and found no difference between scanning those and the Event Espresso codes.
I’ve run other tests with a batch of tickets, each one being unique, and have not seen the slow speeds you are reporting. They let me scan as fast as I can move the device to the next ticket and tap the screen.
Maybe what we should do is send you some credentials to a site that’s hosted on one of our servers along with some test tickets that you can use and test with your own scanners. That way you can test against the same server set up we have.
Since you asked, the pre-release API doesn’t bring any new. It was something we had released a while back and what we were testing then has been merged into the stable release.
|
|
Peter Stoianov
|
April 10, 2014 at 8:01 am
Ok please do. But you should also test the the ones I mentioned by creating free tickets, downloading their apps and scan. This will give you an indication of speed. And if it is not a big problem could you just not change to a bit simpler qr code system? It may just improve the focus/scan speed.
Kind Regards
|
|
Josh
|
April 10, 2014 at 10:41 am
Peter,
Here’s an example of the data that’s encoded in an event brite code:
and Event Espresso’s
Big difference? Maybe. Is it enough to account for 5-6 seconds in latency though?
I’d really like to help you improve the speeds of your scanning setup, but I feel like at this point we are going in circles. The issues you’re having with the latency may not be the QR codes at all. If they were the QR codes, would we not also be seeing the same latency issue when we test?
The underlying issue could be, as I mentioned in the other post you started, the difference between communicating with EventBrite’s servers and your own self-hosted server running our software.
So please go ahead and test out against my test server. It’s located in the U.S., and by looking at your domain I’m assuming you’re over on the other side of the pond, so your results may be different than mine. With that, here are the ticket links:
http://eetesting.info/3.1.josh/?ticket_launch=true&id=2348&r_id=2708-5345f9ee38d0d&html=true
http://eetesting.info/3.1.josh/?ticket_launch=true&id=2335&r_id=2708-53441aadaf6da&html=true
http://eetesting.info/3.1.josh/?ticket_launch=true&id=2308&r_id=2708-53430ad064fe4&html=true
http://eetesting.info/3.1.josh/?ticket_launch=true&id=2307&r_id=2708-5343097441908&html=true
http://eetesting.info/3.1.josh/?ticket_launch=true&id=2305&r_id=2708-5342eb07eb4b5&html=true
http://eetesting.info/3.1.josh/?ticket_launch=true&id=2304&r_id=2708-5342ea69acd85&html=true
http://eetesting.info/3.1.josh/?ticket_launch=true&id=2303&r_id=2708-5342e7c887def&html=true
http://eetesting.info/3.1.josh/?ticket_launch=true&id=2302&r_id=2708-5342e71cd1e09&html=true
http://eetesting.info/3.1.josh/?ticket_launch=true&id=2299&r_id=2708-5342e3d5b2449&html=true
http://eetesting.info/3.1.josh/?ticket_launch=true&id=2286&r_id=2708-5321e79421718&html=true
I also sent credentials you can use to log into using the app to the email address we have on file for your account.
|
|
Peter Stoianov
|
April 10, 2014 at 2:16 pm
Thank you Josh,
Just tested and is feels like our own server/speed. I know it feel like we are going in circles but I believe the scanning speed could be improved a bit by simplifying the actual qr code image so the phone camera captures it faster. That is what I meant earlier.
And then if we can improve the database response time would be even faster. Can the database table be optimised somehow?
Josh when there is a long queue every second counts.
Please talk to the app developer about it as well.
Kind Regards
Peter
|
|
Josh
|
April 10, 2014 at 3:02 pm
Hi Peter,
Is your server close to where you are? If not, please talk to your host to see if you can get a server with less latency. Making the QR codes smaller and tweaking queries that are already optimized will not make a difference if you’re experiencing the same speeds testing against my server.
Reducing the latency is going to be the solution for you because I’m testing against the same server and the scans are instant. If you do not believe me I can record a video and post it to Youtube or something.
|
|
Peter Stoianov
|
April 10, 2014 at 3:19 pm
Hi Josh,
I am not saying that scanning is slow, it is good but it could be faster. I do believe you and we have used ee for 10 months now and I have a feeling for it. We used it on many phones and it works in fairly similar manner. In order for the camera to capture the qr code fast you need to position the phone around 12 inches from the paper otherwise it takes time or tries to focus. With smaller qr code (we tried other codes with the EE app) capture WORKS BETTER and from different distances.
I am just saying that making the qr code smaller would improve things. At least it works with us. If there is no much bother why don’t you just try simpler qr image/system.
Looking forward to hearing from you. We love the Espresso.
Peter
|
|
Peter Stoianov
|
April 10, 2014 at 3:24 pm
This is what our webhost asked regarding latency improvment. What else can we advise them?
We need to know more about the database look up/query that it’s performing in order to diagnose the issue though – what happens exactly when the QR code is read on a QR code reader?
Kind regards,
Darren
and
We would need to know more information about the SQL query that is being executed when that is scanned to help optimise this. I have added an index on the wp_events_attendee table for registration_id and attendee_id but without more information it’s going to be difficult to assist.
Kind regards,
Darren
|
|
Peter Stoianov
|
April 14, 2014 at 3:30 am
Hi Josh,
Please tell us is there any way to optimise the look up database speed. Can the tables be improved? It is nothing to do with the speed of our webhost. It takes 3-4 seconds sometimes to pull a record and it is vital we make it almost instant for high volume events. I can send you credentials to try it id you wish.
We will sell more that 700 tickets for our next event and is vital we don’t get any delays at the door.
Please look into it and did you consider simplifying the qr code image? It does make a bit of a difference I believe.
Kind Regards
Peter
|
|
Josh
|
April 14, 2014 at 11:51 am
Hi Peter,
We do not recommend changing the database tables that store the ticketing information, or the queries in the JSON api that are used to access them. These have already been optimized for performance.
My earlier note about latency was in respect to overall latency between you and your host (not necessarily all falling on your host’s server). That’s where I believe the bottle neck is here. The reason for this recommendation is because we get instant ticket scans when we test scanning tickets on our server.
We also do not recommend changing the size of the QR code because we have found with internal testing the size they are now works the best. If you want to experiment with changing the QR code size, you’re welcome to, but please understand that we do not support making modifications to core Event Espresso functionality.
The size of the QR code that gets generated can be altered by opening up the Espresso Ticketing add-on’s functions.php file and changing the two “135” values on line 6 to a different value.
|
|
Peter Stoianov
|
April 14, 2014 at 12:03 pm
Thank you Josh,
There is no bottleneck here, we tried it hundreds of times. I do not want to be a pain and waste your time, but I do believe you could do better regarding the scanning process. May be you should look in optimising the the tables or the JSON queries. I can send you our credentials if you wish to try an event with 250 peaple for yourself and you will notice the delay, it is not instant. But please do compare with yapsody and you find that it is really instant. By the way when will you have the EE4 ticketing addon? It would be great to have it soon.
Regards
Peter
|
|
Peter Stoianov
|
April 14, 2014 at 12:05 pm
Re: qr size what value shall we change it to?
|
|
Peter Stoianov
|
April 14, 2014 at 12:20 pm
Just to clarify I do not mean the qr size but rather the complexity of it. Could we change that or is it linked the the EE registration id? Eventbrite for instance are very simple. Is it not better for a phone camera to have it rather more simple generally?
Thank you
|
|
Peter Stoianov
|
April 14, 2014 at 12:40 pm
we@ve notice that the latency appears longer when you check someone in, i.e. when you test with a ticket already checked in DECLINED appears much faster. But if you have a group registration and scan the qr than it take 2-4 sec to check them in after selecting the number in the mobile app.
Another issue is with the event dashboard. We always bring a laptop in case to the gate. When we use it to check customers in the retrieve is always set to 50 so every time we need to retrieve the whole database in order to check the next person. This takes precious time when you have a long queue to manage in a short period. Could that be fixed too?
Thank you
|
|
Seth Shoultes
|
April 14, 2014 at 12:56 pm
HI Peter,
Hope you are well. Thank you for your feedback and reporting your findings. I just wanted to let you know that we are looking into ways of reducing the QR Code size. However, any changes we make will need to be reflected in the mobile apps as well.
We have to make changes to the QR Code generator (to remove approx. ~40 characters), schedule time with the each of the app developers, add support for backwards compatibility, test the changes, release updates to the ticketing add-on and mobile apps, etc.
As you can see, it is not something that is going to happen over night and may take several weeks to accomplish. There is quite a bit of planning, scheduling, and testing involved.
I understand that this is very important to you. However, please understand that we are working on it and ask that you please be patient while we work this out.
Thanks!
|
|
Peter Stoianov
|
April 14, 2014 at 1:47 pm
Thank you Seth,
I am glad we get a positive response this time. What about the table optimisation? That is where the latency appears. And the other couple of issues I raised in my previous post?
Thank you
|
|
Seth Shoultes
|
April 14, 2014 at 2:09 pm
Sorry, I have not had a chance to review the previous threads/comments.
Regarding the database table optimization. Have you tried repairing the tables? Here is a simple explanation and tutorial:
http://paulstamatiou.com/how-to-quickie-repair-mysql-tables-in-phpmyadmin/
Optimizing your database is also important. Here is a quick tutorial on that topic:
http://www.inmotionhosting.com/support/website/phpmyadmin/how-to-use-phpmyadmin-to-optimize-a-database
Please let me know if that helps at all.
|
|
Peter Stoianov
|
April 14, 2014 at 2:17 pm
Thank you Seth,
I actually meant whether EE will any measures to optimise the tables generally in order to reduce latency. I think that is where you should look into as well and it is important for all EE customers. Meanwhile I will look at this tutorials.
What about the dashboard retrieval issue?
Thank you
|
|
Seth Shoultes
|
April 14, 2014 at 2:22 pm
IN EE4, we have taken steps to optimize the database queries and use the WP tables more (where possible).
Sorry, I’m not up to date on all of the issues you have experienced. What is the dashboard retrieval issue? Do you have a link to a specific post?
|
|
Peter Stoianov
|
April 14, 2014 at 2:29 pm
That is the issue:
We always bring a laptop in case to the gate. When we use it to check customers in the retrieve is always set to 50 so every time we need to retrieve the whole database in order to check the next person. This takes precious time when you have a long queue to manage in a short period. Could that be fixed too?
Finally when is ticketing coming to EE4? We are still bound to use EE3 because is not available yet.
Thank you
|
|
Sidney Harrell
|
April 18, 2014 at 12:45 pm
If you just want to change the default from 50 rows to all the rows, you can go into includes/admin-files/admin_reports_filters.php and change line 266 to:
$max_rows = isset( $_REQUEST['max_rows'] ) ? absint( $_REQUEST['max_rows'] ) : 100000;
|
|
Peter Stoianov
|
May 3, 2014 at 7:16 am
Hi again Josh/Seth,
I changed the size of the qr code in espresso-ticketing – functions.php which is nice to be able to do. However, is there any way to simplify the qr code (less characters) by altering something else i.e. the length of the registration id or some other digits to do with the qr generator?
on the last post by Sidney
If you just want to change the default from 50 rows to all the rows, you can go into includes/admin-files/admin_reports_filters.php and change line 266 to:
We did it and it helped but still need to press on retrieve in order to get all the names. In other words it does not pull all the registrations. Anyway to fix this?
Thank you guys.
|
|
Sidney Harrell
|
May 6, 2014 at 9:56 am
I think it’s in includes/event-management/queries.php on line 19:
$max_rows = isset($_REQUEST['max_rows']) & !empty($_REQUEST['max_rows']) ? absint($_REQUEST['max_rows']) : 50;
If you change that 50 to 100000, it should pull in all the records by default:
$max_rows = isset($_REQUEST['max_rows']) & !empty($_REQUEST['max_rows']) ? absint($_REQUEST['max_rows']) : 100000;
Note: I think the number 100000 was chosen as in “No one would have more than 100000 attendees”, but it’s important to use it rather than another number so that the dropdown will have the option “all” selected.
|
|
Peter Stoianov
|
May 7, 2014 at 3:50 am
Thank you, this worked great.
What about the first issue on my last post? Could you look into it please?
I changed the size of the qr code in espresso-ticketing – functions.php which is nice to be able to do. However, is there any way to simplify the qr code (less characters) by altering something else i.e. the length of the registration id or some other digits to do with the qr generator?
Regards
|
|
Dean
|
May 7, 2014 at 5:24 am
Hi Peter,
Simplifying the QR codes is something we are looking into. There isn’t a way for you to custom code it yourself as the iOS and Android apps would also need to be modified to accept the simplified data format.
|
|
Peter Stoianov
|
May 7, 2014 at 5:56 am
Thank you Dean,
Any time frame for that and also when should we expect realistically a ticketing addon for EE4? It is difficult not to be able to add multiple tickets with availability on them as it is with EE3.
Regards
|
