Yeah that’s what I think, that you need to change the screenly.conf file to use the new container one:
But, remember you must tar the file back up after making the changes to upload to OSE.
Let me know how it goes.
Hmm, I just tried it and I still got that same blank red bar with no error message. This time, though, none of the assets are showing in the list, so it’s like the database wasn’t imported this time.
yeah i think you will need to enter the sqlite database file and alter the location, because if that db file has the reference of the file as /home/pi/.. then the conf file doesnt really change it…
so i’ll make it easier for you, download this program called Browser for SQLite and open the screenly.db file from your backup, edit the asset uri and apply and save it, then also edit the screenly.conf file to have the new /data/screenly_assets/ directory, so that it matches with the change you’re doing…
And as you can see, the screenly.db file will now have the updated directory location and should work.
Alright, I was able to update all the URIs and, although the import ended with the blank red error again, after a reboot the database seems to be the restored backup and all the assets are in there.
The display on the TV is working, although I a few images out of all the ACTIVE ones just show up as a white image on the TV. Not sure why a few of these are doing this, their permissions are the same as all the other asset files and downloading it from the Screenly OSE web interface results in a healthy image file that I can view. Weird…
Any idea on what could be causing that? If not then I’ll probably just delete those assets and add them again.
Re-uploading one of the affected assets didn’t work, I wonder what’s wrong with these…
So a few of the assets (images) that are restored only show up as a white image, and re-uploading them also dont work? are these regular jpegs or png etc? is their dimension something the pi’s resolution can handle? more details pls.
It’s gotta be the resolution; this one image I restored was originally 5120 x 2880, displaying as white image. I resized it down to 1280 x 720, and it displays fine. These are PNGs.
I checked a few other broken assets and they’re all 5120 x 2880.
What I don’t get about it being a resolution issue is, why did they work before? This is the same exact Pi as before, it’s just running a fresh Raspbian install.
Ah… well it isn’t only about the model of the Pi, it is the version of raspbian + packages, for example the software that plays the videos might not be the same that plays the images, or vice versa, and in this case lets say it is VLC instead of OMX, there might be some parameters that are passed onto the loader that causes this, too many potential reasons that it’s best to work with what is supported rather than go crazy trying to figure out why something worked before and now it doesn’t unless resized, etc.
But, at least you found a solution.
Yup, I did a bulk image resize of all the images that were 5120x2880 and resized them all to 1920x1080, did a fresh restore, and all is well! 
One last quick question, if you have the answer… how do I enable SSL? My backup conf had it enabled but the new install is still running on HTTP.
Sorry that one is a little trickier because you have to enable ssl on nginx and need certificates and stuff and its kinda complicated… but if you want to troubleshoot and try it yourself, I can just guide you to the proper locations.
The docker that runs the web server itself is screenly-srly-ose-nginx-1
The location of the config for that is in /etc/nginx/sites-enabled/srly-ose.conf
To get into the dockers you already know sudo docker exec -it screenly-srly-ose-nginx-1 bash
That container doesnt have nano or vi so you would need to install either one sudo apt install nano
I will warn you, it is more trouble than you need to worry about because you need to generate your own certificate for the pi, you cant just turn on ssl and it will work. If you are required to encrypt the traffic that is being transmitted between the screenly-ose server and you logging into it and changing settings and assets (because that is the only type of data being transmitted from user to web server), then you can go ahead and do all that certificate stuff, otherwise just enable Authentication on the Pi interface and that’s it, no one can access the assets or settings unless they have the login info.
I’ve done custom SSL before, no biggie. Besides, I have 2 staff members that log into the web interface and I require HTTPs for connections in Chrome, denying HTTP (to ensure secure connections), so they won’t be able to get in without me opening a security hole.
Interestingly before, Screenly had a default self-created SSL certificate by default (or at least I remember), I guess it doesn’t do that anymore? Unless the IT guy before me created one himself…
Regardless, thanks for pointing me in the right direction! I’ll figure this out
Thank you for all your help!
You are correct, the old screenly (non-dockerized/container) version had a self-created SSL certificate by default.
Problem is, remember that back then it was all in one host, you are now in need of communicating between containers, opening ports/exposing ports between different containers that need to reach each other specifically, certificate files in one container and also in another, etc, so trust me, unless you really really must do SSL traffic on the Screenly assets interface, you might head down a path of lots of config changes/troubleshooting/testing.
But, if you like that challenge, pls let me know how it goes, maybe you can write an article for others if you get it to work.