I’m switching from native Raspbian to balena and when I upload/recover my backup, I get a blank red notification at the top:
Where are the logs for the docker container that I can review for this?
As far as I know the balena OSE is being reworked/updated, so it might not be fully working yet.
I dont see this exact question as an Issues on Github or on the Project Pending list, so it might need to be opened up there instead, which I suggest you do.
To see logs from docker containers just type in the Pi console: docker logs screenly-srly-NameOfContainerHere or press tab to autocomplete.
For balena logging stuff, have you read this?
Or do you see anything on the dashboard logs when you get this error? the balena logs should be showing some type of error either on the container itself or the host when doing this action.
I switched over to the version for Raspbian and I get the same blank error - I noticed that it imported all the files, though, and the database at least appears to have the media registered, but when I try to toggle them it says the file path is incorrect (I confirmed they’re all in screenly_assets with the exact same name as it appears in each asset):
Also I would adjust this forum post to remove the “balena” category but I don’t have my edit menu anymore
Can you check logs as you try to enable the assets to see what the actual error is in the backend?
To see the web server logs which is what’s doing this action type in console:
Docker logs screenly-srly-server -f
Press tab after logs so that autocomplete tells you the exact name of your container, then while the console is showing logs, try activating the asset and see what the error shows in the logs.
Exception: Invalid file path. Failed to add asset.
Traceback (most recent call last):
File “server.py”, line 672, in api_view
return view(*args, **kwargs)
File “/usr/local/lib/python2.7/dist-packages/flask_restful_swagger_2/swagger.py”, line 219, in inner
return f(self, *args, **kwargs)
File “server.py”, line 1112, in put
asset = prepare_asset_v1_2(request, asset_id)
File “server.py”, line 513, in prepare_asset_v1_2
raise Exception(“Invalid file path. Failed to add asset.”)
I just tested on a fresh install OSE with raspbian bullseye lite and installing via bash script.
I upload a picture and click get backup and downloads the tar.gz file, and in there i can see that the picture file is hashed, remember URLs are not backed up, those are better backed up using the API (let me know if you want to see how to do that).
anyway, i then deleted the picture in the active assets, then i went and uploaded the tar.gz downloaded backup and it successfully restored the image.
Not sure what is going on with your version of OSE and backup file you are trying to recover (restore).
Did you make any changes to the names of the files in the screenly_assets folder? the names are not what go on the files in there, it is the asset_id of the asset when it was added (see sample from my uploaded picture):
The API page can show you the information of your assets in json format so you could better understand how the assets are stored.
As you can see, that asset_id is the same filename inside the backup file when extracted:
Interestingly, all my assets (when restored) don’t have file extensions in the both file names and the URI location from that JSON output:
Not sure if this could be causing it? How can I navigate to this asset directory in SSH and edit the JSON file directly?
Well… I can see that your data for assets reside in the home directory of the pi user, this tells me you are not using the latest version of OSE which uses docker containers to store the data, which if you notice on my screenshot is called /data/screenly_assets/, and this is actually inside the screenly ose server container (not in the /home/pi/ directory).
You can get into the screenly ose server container by running docker exec -it name-of-container-here bash and to get data from the host to the container directory you would need to use the docker copy command.
Before continuing to troubleshoot, we need to be on the same version of OSE and using the same Raspbian OS…
Hmmm, this is a fresh install of Raspbian and OSE via bash script though… under “/home/pi/screenly” there is docker:
Not sure why it installed an older version when I used the github command?
Ok so if you have the latest version, it should match mine:
So just a little explanation on the /home/pi/screenly folder, basically when you run the install script it uses git to copy over all the github repo files/folders and puts them into your /home/pi/ directory which it needs to build everything. Those files you are seeing in screenly directory should be there.
When you showed me the location of your assets, you were pointing to the local home/pi folder instead of the folder inside the container.
To see the assets folder which is called screenly_assets as well, but inside the container, you need to use docker commands, so you would do the following:
There aren’t any assets on my container because I didnt add anything for this test.
Also, when you say you installed Raspbian, are you installing Bullseye lite?
Show me the outcome of command lsb_release -a
Ohhhh that’s just when it’s building, that makes sense! I’ll take a look at the docker container.
Here’s my release:
Not sure why yours says raspbian, maybe you’re on armhf version, i am using 64bit latest one on pi4, that’s probably the only difference but if OSE is the same latest master version, then that’s all that matters.
Ok, so now that you have the info on getting into the container that holds the assets (screenly server one), and with the information from the API GET responses, you can probably figure out your issue, although I am still trying to figure out what the actual issue is, meaning, you have a backup tar.gz file that was used on an older version, and when you try to restore it now into the latest version of OSE, you get the error but yet it is showing that the asset was recovered? why not just extract the contents of the tar.gz file, and just re-add those assets one by one, just to not waste more time with trying to recover from older file which we can probably figure out what is going on but it would be a lot of back and forth troubleshooting…
I’ll look at how many assets I have… I was leaning towards importing cause we have a LOT and they all have different durations, some are enabled/disabled, etc.
So, I think what’s happening is, after the import, all the imported assets are pointing their file locations to “/home/pi”, instead of inside the docker container in “/data”, so they can’t access them?
Imported File:
Manually Added File:
Different locations
If I could figure out where these assets are stored (in JSON or a database), I could edit them and replace “/home/pi/screenly_assets/” with “/data/screenly_assets”.
The assets are stored in screenly_assets, the file that holds the location and info about the file is a sqlite database called screenly.db:
This is just an example of the asset i uploaded called jellyfish:
You can use different ways to change the asset properties, one is potentially the API to PUT and modify the assets info but i am having issues doing that since it has certain checks before it can actually modify an asset, but the most sure way is you would need to use sqlite commands to alter the directory of the location of the file to the correct one in the record of the database (screenly.db).
Think of it as a mysql database that holds the records of the assets.
Do you have these files when extracting the original backup file? if so, can you post what the screenly.conf shows?
Here’s my CONF:
[viewer]
default_streaming_duration = 300
show_splash = off
audio_output = hdmi
shuffle_playlist = off
verify_ssl = off
default_assets = off
player_name = Lobby Display
usb_assets_key = wJiMdLCMtbcnqjrPLiVz
debug_logging = off
resolution = 1920x1080
default_duration = 10
[auth_basic]
password =
user =
[main]
date_format = mm/dd/yyyy
assetdir = /home/pi/screenly_assets
database = /home/pi/.screenly/screenly.db
use_ssl = True
analytics_opt_out = off
auth_backend =
use_24_hour_clock = off
websocket_port = 9999
Do you think it’s restoring to the docker and getting confused cause it can’t access outside the container?
In that case, I could just modify this CONF to direct the assetdir and databasedir to inside the container where it SHOULD be.