Not sure which category this would best fit into, but here goes. I know that when using “configuration variables” the system should be able to interpret the use of BALENA_HOST or RESIN_HOST variables. My question is on the versions of balenaOS does it make a difference if you use a combination of those 2 “commands” or better to use one over the other? I would like for all of the variables to be consistent across the board. I was thinking of changing all of the RESIN_ to BALENA_. Is this ok to do or will it possibly cause issues.
You can give it a try, but I’ll bet you it won’t work. I think RESIN is the old name, and BALENA is the new name, but I think the two groups of variables do different things. In other words, I don’t think the variables are defined twice to make this work.
Yes, thank you. I have been doing things like this for quite some time, basically ever since “Resin” has been available and through the transition to Balena. I didn’t know if Balena had rewritten their code to be totally exclusive to Balena and not use any more “Resin” code for their builds. I have seen other posts mention something similar to what I’m talking about, but nothing 100% definite on which to use in certain instances or if it even matters. Thank you again for your reply and your input about this matter.
Hi Daniel,
Resin was our old name, before we switched to Balena. The variables do the same thing, and with recent enough versions of the supervisor, the two are interchangeable. In other words, you can specify variables as either RESIN_HOST_CONFIG_* or BALENA_HOST_CONFIG_*, they both do the same thing. You shouldn’t have any problems converting all of your variables to BALENA_, but if you do, let us know, and we’ll help you get sorted. 
Thank you for the info. I do have one question for you. I have had balena/resin installed from the beginning with screenly-ose on quite a few pi3 running without issues. Now I go do an upgrade of both balenaOS and screenly, because I was adding more pi3 units in different locations in our facility. The old version would transition from graphic to graphic no issues, now that the units are updated, when the graphics change there is a brief 1-2 secs where the display shows nothing but black, then proceeds to the next graphic. The older versions of both software did not do this, it was a good transition from graphic to graphic. What would cause this brief “pause” in the “slide show”?
Hi Daniel,
As you upgraded both balenaOS and screenly, we need to figure out what one is causing the issue. Is it possible to downgrade screenly-ose to the version which you had before so we can check if the updated screenly-ose is the source of the delay?
I don’t think I can downgrade screenly, because I did a push out from hub.balena. There is no option on which version of screenly to push out to whichever app you choosse. I tried running the most recent version of balena then try to install older version of screenly on top like I did in times past, but screenly would never install correctly. Thank you for your time with this.
Can you tell us more about the issues you faced and what instructions you used to run Screenly (Old version) with recent version of balenaOS. To be sure, did you follow these instructions - screenly-ose/balena.md at master · Screenly/screenly-ose · GitHub Thanks!
Yes, I did those instruction steps. As far as running an older version of screenly with a new balenaOS. I have backed up images of the original balena/screenly install so I burned an image to a new micro sd and put it into one of the new pi3b. Then I go to my blaena dashboard and find said device to start setting up certain variables for that device. Once the device has been connected to the balena dashboard for a couple of minutes it starts to update on it’s own, but doesn’t update screenly. Once it gets through updating I can see the latest version of balenaOS and the latest supervisor version, but here is where it gets a little strange. Even though screenly is technically installed on said sd card, screenly will not fully operate correctly with the latest version of balena, it’s like the screenly software freezes up while it’s trying to start up all of it’s process. So in turn I could not get the “older version” of screenly to work correctly with the latest balena, granted the version of screenly I have is one of the first version released.
Hi, is it possible to specify the two versions of balenaOS and screenly that work and do not work, respectively?
Hey there, following on from my colleague’s question, what you can also do is try the latest version of Screenly on both the working and non-working OS versions if you haven’t already. If the problem exists only on the newer balenaOS version, then we know it could be a change made to balenaOS which introduced the issue, but if the problem exists on both then it’s possible that a change in Screenly introduced the issue. Once we have an idea where the problem started hopefully that’ll give us a better idea of where to look next.
Hi, there is already another thread in which you described the problem in further details. The title also matches the specific problem better, so let’s move the conversation there.