Question for any operators out there... is anyone having an issue with IC not being able to find IP address from your WiFi and then after 1 - 20 restarts it finally finds an IP address and your ready to go. It's becoming very frustrating having to spend countless amount of hours trying to get all of my Sterns and our Big Buck Hunter Reloaded to connect/find an IP address from our modem/router.

P.S. I have a Comcast Business router - full strength.

If anyone was having the same issue and found a fix... I'd greatly appreciate any insight.

Thanks

Occasionally not being able to connect is a fun feature that we all get to experience every once and awhile.

You basically do the same basic steps you would do if your computer lost connection. Rebooting modems, throwing a fit.

Get a WiFi repeater for your location. The signal strength is too weak for the devices attempting to connect to the access point. Additionally, a WiFi repeater can be used to relay a 5GHz/WEP/open connection to devices which only support 2.4GHz/WPA(2).

And make sure it’s a modern one that uses the 802.11ax standard that came out in 2021.

real time updates here .it's 8:35 EST and day has not reset yet. will check again after 9pm lol.

Does anyone know.....

The IC kits you can buy at Pinball Life etc, do the aprons come with the 2 holes for the small LED boards that shine onto the flipper area?

My TMNT Pro has the LED's

Are the apron LED's / holes stock on all games?

Thanks

I noticed that too. Maybe they finally fixed the days / timezones. *gasp* maybe next they will actually do some metrics!!! How much more do I earn on an average Sunday than a Thursday I CAN'T WAIT TO NERD OUT

My read on todays data would seem to support that they changed something.

Yep - Mine has not reset yet, it's 7:45pm. (I'm GMT -7)

Now I'll need to check every hour through midnight.. as I'm stricken with curiosity now.

YES. The apron comes with holes and there are plugs in that you can remove easy. I know I just did it to my TMNT Pro.

10:05pm EST. still same day.

11:18. Still same day. I’d guess it will end up resetting 2am EST (midnight Central time). I won’t be up but if anyone is, do report. Thnx!!

Looks like it resets at 12:00am est.

Yep, It reset at midnight local time.

Looks like it was updated to correct for the GMT global reset, and now is midnight local reset. Much better....

On the one hand it's horrifying it took 10 months to change this teeny tiny little itty bitty bug. On the upside maybe there's just a 10 month delay on creature comforts and this will be the first of many useful improvements. I'm a hopeless optimist.

As soon as I ordered my IC kit I ordered Gotfrogs kit to move the scanner to the coindoor. This came in handy since the EHOH came with docquest apron mods. Really nice to not have the scanner in your face all the time.

https://pinside.com/pinball/market/shops/1295-gotfrogs/05778-metal-stern-insider-connected-qr-code-reader-coin-door-mount

Can you give a quick summary of your programming ability?

The QR reader on our GZ stopped working. No white light, won't scan. Board shows ethernet activity and blue LEDS. Tried unplugging/replugging all cables, testing (with HV switch properly pulled out) and still no response. If I unplug/replug the ethernet cable, the white illumination briefly turns on, then turns off. Any thoughts? Figured I'd ask here before starting a ticket with Stern. Thanks.

There is a design or material defect in the original readers. Open a ticket and get it replaced. They will make you go through your distributor.

Looking at my connected games this morning (3) wish in the app I could challenge others to a game. Would be an awesome feature.

Give yours if you think accounting for GMT vs local time when you already have the numbers should take 10 months. I'm some fucking jabroni and I could learn whatever language they're using in that time. Former network engineer / programmed Cisco gear, used C++ and basic and shit is about 10x easier now.

If you have warranty, put in and get a new reader. Machines cost a lot of coin so they should work.

I have taken one apart and the main issue is the small ribbon cable joining the two pcbs in the scanner. The connectors for the ribbon cable to the pcbs were not very good (flakey contacts), on the newer pcbs there are different connectors for the ribbon cable. Issue resolved.

Opened a ticket with Stern over my QR issues. They had me run a few tests, and concluded the illumination lights were bad. No node board errors (in testing), and it will scan a QR code from my phone if the brightness is turned up. Warranty replacement incoming. There's a backlog, so may take a month or two. Stern customer support has been quite good on this and a few other queries over the year. FYI.

Hello People: please excuse the ignorance of my abbilities, however,I have a Bond Pre on order.I do not posses a cell phone.What am I supposed to do with this IC??Thank-you for reading!!

Pete-d Thank-you for your suggestion!!

We printed ours and made them into key chains.

Measuring things like "daily metrics" on a system that operates across timezones is not easy. When does the "day" begin and end? Is the "day" always 24 hours long, regardless of Daylight Savings changes, Leap Seconds, etc.? If not, are comparisons valid when one "day" is 23 or 25 hours long, and the next "day" is 24 hours long? What happens if your machine is located in Indiana, where you have zip codes that straddle the Eastern and Central timezones? What happens if you operate a machine in Central, and another machine in Eastern? What happens when you move one machine to the other timezone? What about Arizona, where they don't do DST?

If you think this stuff is easy, you have no idea what you are talking about. Companies like Google employ entire teams to deal with timekeeping problems and designing analytics and reporting platforms to deal with them.

So as a little test (lying I was just playing past 12) I wanted to see it my IC gave me credit for another day to the streak right at local time at midnight. Sure enough right at 12:05 my next game upped my streak. Thanks to the IC team at Stern.

It is pretty straight forward. Want something not fun... try managing scheduling with series and exceptions across timezones with DST Where you have to worry about the frame of reference for not just the time, but the date for WHEN and WHERE that time was picked and the DST rules for that pick (and the fact DST rules change). So you have the issues of what the --real intent for time-- was when the thing was created, and you have different viewers who each need to see their own perspective.

For reporting all you have to care about is adjusting for the viewer's perspective.. the source can always stay in UTC .. simple. You can just adjust the view based on the viewer's perspective...which can always be the current perspective or when it comes to computed reports, just pick the reference and make it known (Example: taking the location's timezone and compute based on that). You're only adjusting on presentation and don't really care about the real devil... which is a reference that spans multiple dates.

Easy: Show me something that happened 14:00 UTC in a time based on my timezone
Easy: Count all the entries between two UTC time points with a Offset picked based on a location's timezone
Hard: Bob in the UK picked the job to run at 9am on Oct 1, everyday for a year. Ensure the job runs at the same 9am relative to Bob every day, across DST, and when Alice in the US looks at when the job will run at a date in the future, show it at the right time FOR THAT date in Alice's correct time.. but it still is the correct 9am relative to Bob.

Reporting and counting with timezones and DST is not that difficult. Setting things to happen in the future and viewing their correct relative perspective is where it gets messy.

I managed a global scheduling product for over a decade that fully supported recurrences and DST. I'm well versed

This isn't that complicated because you only have one frame of reference to worry about... where the executor is. Your complexity comes on the transitions, not every day. The displayed information is dynamic and can always be adjusted from your fixed reference on the fly. Having a dynamic perspective is easy because your data's reference is constant. The challenges come in when do you process aggregate data and how closely it should be available to an end-time that in itself is relative (like play streaks).

I just want easy stuff like 'todays plays' to be accurate to the location's timezone. They weren't. That is an easy stat!

But looking at today's stats... they might actually be timezone adjusted finally. At least today right now, none of my games are showing plays from Sunday. A week or so ago, that wasn't the case.

I have a lovely little anecdote that I pull out whenever talk about software engineering around timezones comes up.

I used to go to the local Alamo Drafthouse theater to watch movies. Decent food, decent service, ironclad policies against lateness, cellphone usage and talking during the movie, as well as a well-curated slate of programming catering to niche movie lovers. Basically straddling the line between an indie theater and a big multiplex.

Anyway, one day they announced a one-night showing of Commando, Arnold's quintessential 80s macho action flick (not Predator, the other one). I snagged a ticket and hit the "Add to Calendar" button on the confirmation page to add it to my phone's calendar (because if it isn't in my phone's calendar, it doesn't exist.) A couple weeks later, I showed up fifteen minutes early for showtime, only to be turned away for being 45 minutes late. I checked my calendar, it said 8pm showtime. It was 7:45pm. How could I be late? Did the showtime get moved up an hour without me knowing?

Eventually, I figured it out. I bought the ticket while I was in Chicago, on Central Time. The theater is in Brooklyn NY, on Eastern Time. The "Add to Calendar" link just indicated "7pm" without a timezone offset, so it got added to my calendar as 7pm CT, which got changed to 8pm ET when I returned to New York.

Moral of the story: in software engineering, a time is meaningless without a timezone attached. If you don't want to deal with timezones, just use the unix timestamp and let people cleverer than you work out the displayed time.

I would disagree there, because the play streak stat appears as a badge on your profile, and your profile can be viewed globally. If you dynamically show the badge based on the viewer's timezone, you'll get different results for viewers in different timezones. Someone in Japan who is already across the date line might see that you haven't played a game that day, so your streak is over, while someone in America is still on the previous day, so your streak is alive and well. If you want the profile to appear consistently for everyone globally, you have to pick a single day-boundary time for everyone. But then you get the problem being complained about in this thread; why is the boundary at 8pm local (or whatever).

does it even use the local clock on the game it self?

Is there a way to add a game to the home team with only wifi and not the full in$ider connect kit?

Borrow a scanner, move it around to set the games and players up, return the scanner, enjoy scanner-less Insider.

They already have the timezone information, it's displayed at the top of the screen. They just didn't do anything with it until now.

Leap seconds? Dude we're trying to build a useable pallet not a piano. None of the examples you bring up would change anything about the way the thing was implemented. Account for timezone, that's it.

Note what i said and you quoted… “ The challenges come in when do you process aggregate data and how closely it should be available to an end-time that in itself is relative (like play streaks).”

Something like play streaks are not just a dynamic view but something you have computed and stored. Contrast this with something that is simply a view… like today’s plays. It’s exactly why i made that distinction in my post

Another thing is not all data is computed based on the viewer, some makes more sense to be in the location’s reference. But when dealing with just past data, it’s still much easier than dealing with a time reference into the future or having to make a comparative reference to your current date. Just keep your absolute dates.

All this is just talking in circles unless talking about a specific feature. But for simple stats and aggregates this is not rocket science. It’s all well understood. You just have to actually scope it in the requirements right… else you get the ‘everything works off server time’ like they had at launch. Just sloppy because you know their qa was more “is something there?” Instead of “does the data make sense?”.

It’s getting there … just moving at a glacial pace. Hopefully the new hired help will actually drive better requirements and acceptance testing for their outsourcing partners.

Games that are added to your gameroom will get all players listed in your home team, no need to scan on each machine. But yes, the machine needs a wifi-dongle and an SD-card. Very simple and cheap.

You guys are awesome! Looks like I have a project over the Thanksgiving break. I don't feel like shelling out for a full kit at the moment.

$25 at Office Depot, curbside later this morning.

Update: this dongle isn't being recognized by the game. Do I need a specific USB wifi?

It could also be your home network. IC is designed to work on 2.4ghz wireless while many home networks are now on 5ghz. So first I would check that you are able to broadcast a 2.4ghz signal. If are you able broadcast at 2.4ghz and it is till not connecting you may have to adjust advanced "band sterring" settings on your router that help push devices to the proper signal.

But you could also test that dongle in a different device to rule out that it is not the dongle itself that is giving you grief.

I was able to make it work with a Stern dongle, but I have tried three dongles from office max and no dice. It seems like Stern wants me to buy their kit. The last one was a tp link ac600.