Announcement

**Bruce Cloutier** · 02-04-2020, 08:10 AM

Something that is not so obvious but worth mentioning is that you can with the Series 4 JNIOR rollback an OS update. This might be a reason not to blindly run the All-In-One update project with the Support Tool but to simply update the OS if you are trying to be especially cautious.

The All-In-One update or really any update project that you run using the Support Tool is really a script with multiple steps. This will update the OS and load the most recent versions of various application programs. You can open and edit any update project. You can even create your own. And before you execute (publish) an update project you can disable various steps and of course only apply the update to single JNIOR or a selected set of JNIORs. So you can actually grab the All-In-One and run only the OS update step.

To roll back to a previous configuration you can run an older All-In-One. We do keep prior versions available for download. This may not be an absolute rollback however. The OS update in the All-In-One might actually check the OS version and avoid rolling the OS back. Frankly, we have never issued an update wherein a rollback to any prior state was necessary for anyone. We only really support the latest versions of OS and applications. Our first recommendation for anyone having issues with the JNIOR is to update to the latest. If your problem still exists after the update (or any other problem appears) we can address it immediately with the necessary code change(s). We cannot create branches from older versions of software. That creates a nightmare that neither of us can handle.

I have always felt that knowing how to work with the JNIOR at the console command line is the best way for you to diagnose and debug issues. It also gives you the ability to apply your JNIOR to just about any purpose and not be reliant on INTEG. Even in the face of network issues you can use the RS-232 (COM serial port) at the bottom of the JNIOR next to the Ethernet (LAN) port to gain access to the console. A USB-To-Serial adapter is a good addition to your tool box. Set it for 115.2Kbaud, 8, 2 and 1 and the port should respond to any keystroke with the login prompt.

I know we are lacking in training videos. There are articles in the knowledge base that cover some of this if you can find your way to them. But unlike a lot of companies, with INTEG you have direct access to the engineers and programmers who created the product and everything that it does or ever has done for the past 15+ years. And, we are willing to teach. There is no charge for support. All you have to do is ask for our help.

I think the lack of useful support available from most of the other corporations leaves most of us feeling like we are on our own. So when there is a problem the first thing you think of isn't to waste time calling the company. That seems to become a last resort. I know. Believe me. I also don't know how to fix that. All I can do is help you when you need it. But we need to know when we can help. And on the flip side you can repay us by letting us know when we are successful.

**Bruce Cloutier** · 02-04-2020, 09:48 AM

Another thing included in the v1.9 update has to do with IP address conflicts. Most of you plug a new or reassigned JNIOR into the network and then go off to configure its network parameters using the Support Tool (ST). In the ST on the initial Beacon tab a new JNIOR might show up as 10.0.0.201 and you can right-click to find the IP configuration. A used JNIOR would likely have some previous IP addressing that may or may not be appropriate for your network. Those numbers would should up in Beacon. The point here is that the Beacon protocol functions on a broadcast UDP level and can find and communicate with the JNIOR even when the IP configuration is completely wrong. A percentage of JNIOR support calls are in fact due to faulty network configuration.

If the newly connected JNIOR happens to have an IP address setting that matches another device presently on your network, you have an issue. You might have created an issue for the other device/computer but as the JNIOR boots up, JANOS checks to see if anyone else has its IP address. If it locates another it will force its IP address to 0.0.0.0 and should show up in Beacon as such. Well, that wasn't always true.

A customer has 3 JNIORs combined in a single chassis and applies power to them simultaneously. With all 3 being new, only one would make it to the finish line and adopt the 10.0.0.201 address. Because of the timing the others also wanting that address fall back to 0.0.0.0 but fail to report to the Beacon query. As a result they would not appear. That has been corrected. A JNIOR recognizing an IP conflict will (with v1.9) make sure that it reports that fact to the ST. This will help reduce confusion. If a JNIOR didn't show up it didn't mean that is was dead. Note that in the example system the customer needs to use the ST Identify feature to determine which JNIOR is which in making the correct IP settings. Sounds like fun, eh?

Of course, they could connect to the RS-232 COM port serially and use the iponfig command to explicitly define the IP address settings for each JNIOR. But hey, the ST is cool.

If you get into the console either through the RS-232 connection, using Telnet or using the DCP (open the web browser to the JNIOR) you can type help ipconfig to see how that works. You can just use help to list all of the commands. You can use help * to list all of the available help (or any subset using wildcards). You could use help * > help.txt and then download and print the help.txt file to create a little console command line manual for your tool box. I could do that for you but hey...

**Bruce Cloutier** · 02-07-2020, 07:20 AM

A number of places like to run port scanners. IT departments seem to do that with some regularity. A port scanner will make a HTTPS connection to the JNIOR on port 443 and then move on never completing the login exchange. This creates some security information that we would normally have to hold on to for the login. It never gets used and the result is kind of a memory leak. This would (very slowly) consume memory and at some point the JNIOR would assert and reboot. You would never see it if you power down the JNIOR routinely. It could take weeks before happening. JANOS v1.9 corrects this and properly ages the security information even when the login exchange never occurs.

We have some customers who run port scanner reports automatically every several minutes. We have had to push beta code to them to eliminate their almost predictable reboots. This was a good catch.

Just another reason to update your Series 4 JNIORs. Its the kind of esoteric stuff we are dealing with at this point. Updates can be obtained from jnior.com.

**Carsten Kurz** · 03-29-2020, 07:04 AM

Hi Bruce,

wouldn't it be useful to supply all docs pertaining specific products as a comprehensive archive? I sometimes have a hard time getting an overview over all the stuff that has been written and issued.

**Bruce Cloutier** · 03-29-2020, 08:03 AM

Hey Carsten,

Sarcasm?

I struggle with documentation. I fully agree with you that finding the information that you need is difficult and in general it is not just with us. Today's marketing bias on searches and that on website design erodes the usefulness of any of it. When you are looking for technical information for a product, all you can find is where to buy it or hype about how great it is, after a while it leads you to give up. Not to mention that days after you have searched, ads for the product flood your screen and email. It is the same thing that when you tune in CNN for an update on things after standing there having watched 5 minutes of just ads, you turn off the TV. In our case you are confronted with a lot of seemingly disjointed articles.

We struggle because we are an extremely small company running a global business. Coders need to stay focused on their code spending every possible moment on implementation, testing, debugging and optimization. That is hard enough. They cannot then take the time to generate good user documentation. That not being a simple task in and by itself. I am just happy if they properly comment their code something for which I have higher standards. If you hire someone specifically to do the documentation they obviously have to learn a product that they have not seen before. Someone has to teach them, but who? So when (if?) the manual comes out it isn't truly optimal from the tech's point of view. Documentation lags behind. It has been that way forever.

The same goes for general IT and website design. I really hate the direction websites have almost universally taken where there is some huge banner and you cannot see anything useful without scrolling down. Here I have large high-resolution screens and most sites come up with one or two places to click across the whole screen if that. Meanwhile some completely useless photo dances in front of you. Maybe it has to look good on your smart phone? I don't know.

All we can do is try to make ourselves available to you as much as we can so you can get the answers you need. I know it is difficult when all of you are on widely different segments of the planet's surface. We could charge a lot more for the JNIOR and then we could afford a larger team I guess. It doesn't help when your government orders your doors closed either.

Kevin and Tony have been busy upgrading our documents. A lot of that was rooted in the Series 3 days. Updating to focus on the Series 4 thankfully is not a huge change but needs to be done. Um, before we cut the next series.

If you are looking for something, anything, A quick email to our support email address (support [at] integpg.com) should be the first step. Even if you then find what you need on your own we can at least be there to help you interpret. That email does not go to some tech hired to answer emails and who has to learn a product that he/she hasn't seen before either. In our case, you have direct access to the original designers of the product almost 24/7. Save maybe the time we need to sleep and empty cases of beer.

**Steve Guttag** · 03-29-2020, 08:49 AM

Not all people document equally either. Making manuals is a real talent. The trick is to convey the information to the greatest number of people (which may mean pictures too since that can convey, in a single item, what it would take many words, particularly if translations are involved).

That said, without good documentation, it actually takes away form the product quality, overall. If a user/installer doesn't know what something does, how to implement it well, it might as well not be there so your coder's time is wasted too. If you spend time on the phone/email answering questions that could have been explained in the documentation, that consumed resources too (yes, there will be a substantial number of people that will ignore the documentation you provide and waste your time anyway). Then again, sometimes, one needs a specific need answered right then and there so the phone call would be more expedient than looking it up.

I was recently at a factory training on a piece of equipment and part of the test required a particular configuration and it stumped me, for a period of where the configuration was located (to me signifying that the software was not intuitive enough)...I had time so I worked through it until I found what I needed...the proctor asked why I didn't let him know what I was looking for and I responded: "the struggle to find the information on my own helps me remember where things are and the information won't leave me easily." If I didn't have the time, that would have been a different story.

In my opinion, you should value your documentation as high as your code...they go hand in hand, believe it or not. When I'm looking over a potential product, I'll look over the manual first. That is often your first or second impression you will make with a potential customer.

**Carsten Kurz** · 03-29-2020, 09:10 AM

Sarcasm?

No. One of the issues I and colleagues to which I talk to have is to get a good overview about the flexibility of e.g. a JNIOR, but it is important to show what goes where and what goes with what. There are many add on modules (I mean mostly software here) which support certain functions, and it is not easy to see through them. Maybe diagrams would help. What runs where, what is it good for, when is it needed. So people get a better understanding about when to stick to the standard package and when to add an extension package. Flexibility adds complexity.

My main concern is still the question who is actually pushing and pursuing custom projects on a JNIOR. We talked about that often. In most cinemas, it's the integrator who brings in a JNIOR, but often, they throw in a JNIOR, adjust the IP, connect curtain and light, then let it collect dust back in the rack.

On the other side, see how many ordinary people have been infected with Arduinos and RASPIs and breadboards.

- Carsten

**Bruce Cloutier** · 03-29-2020, 10:54 AM

I have no argument with any of this. You are all correct. But it is not all that simple. Most of our documents are out there in some form or another. Finding them and knowing when you've found them that they are what you need is yet another question. It is a general problem with the Internet as a whole. I get very frustrated in trying to find information myself. We can get the information to you if we know that you are looking for it. You don't know that you are looking for it until you see what is there. Sort of a deadlock. I get it.

The JNIOR is just a single-board computer without a display or keyboard. It is absolutely on the spectrum someplace between Arduino and RaspPi. It is completely generic. It is also a well-kept secret.

What makes it applicable to cinema is the Cinema.jar application that we supply. There is a manual for that. Some cinema installations don't use the cinema application but rely on Modbus. That is another application that we supply. On and on...

If we generate another document to lay it all out for you again it would just add to the mush that is out there and still be hard to find. Maybe the only solution is to take it all off the site and make none of it available. Then write one manual and supply only that. It won't be sufficient. But you will be able to find it.

I can put some of this in perspective. You probably don't realize that INTEG is a 4 person company. We are not Christie, Barco, QSC, Crestron, GDC, Dolby, or anywhere near the size of any of those companies that you are all familiar with. Yes, we have been supplying 1000s upon 1000s of controllers to better than half of the countries in the world for 15 years. They are reliable, capable and not relying on any third-party operating system or hardware. Now we are making them ourselves. We built the JNIOR 15 years ago and if we have our way it will be available 15 years from now. We supported a (non-cinema) customer with their JNIOR last week. That was installed in 2005.

So we are trying. Maybe not doing our best as we can always do better. I wish that I could issue some executive order and cause our documentation to become world renowned.

Meanwhile, let's work together and get you what you need. If you are curious about any aspect of the JNIOR just ask.

You can snoop around in here http://jnior.com/category/knowledgebase/

**Carsten Kurz** · 03-29-2020, 02:25 PM

Bruce - don't get me wrong - basically, I am suffering for every JNIOR that 'sleeps' underutilized in the back of a rack. I visit so many colleagues that tell me about their issues they'd love to be solved, but have no one to address them. I look around, I tell them 'There's a JNIOR'!, and they say: 'What?'

I think I said that multiple times: The main phase of the digital rollout happened so quickly, that techs over here rarely did more than the absolute minimum about automation, then hurried away towards the next job. Since then, no one ever took it up to improve the situation.

Announcement

JNIOR OS Update v1.9 Released

JNIOR OS Update v1.9 Released

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment