I recently had to reimage my table's SD card to get my coffee table running properly after it had been shut down for several days while waiting for a replacement LED strip that I installed after the original strip failed. After reimaging the SD card, I followed instructions I had previously received from Sisyphus Support for restoring tracks and playlists. I had previously backed up "/home/pi/sisbot-server/sisbot/content", and to restore them, I SSH'd to the table, ran "sudo killall node", and then used WinSCP (an SFTP client) to delete the existing files in the Content folder and its subfolders and then copy my backed up file set.
Things looked ok until I noticed multiple occasions where playing "Hep" followed by "C Warp 3B" resulted in the ball tracing an endless loop. I had seen this before with a different pair of tracks, and Sisyphus Support determined that one of those tracks had become corrupted. Remembering that, I deleted and redownloaded both "Hep" and "C Warp 3B", and the behavior no longer occurs.
However, this leaves open the question as to why this sort of corruption occurred in the first place, either when the Content folder was originally backed up or restored. I realize that this backup and restore method is not officially supported, but given the number of playlists and downloaded tracks I have, and the number of times I have had to perform factory resets or SD card reimages to deal with the number of issues I have encountered, I would have gone out of my mind having to rebuild everything from scratch each time.
I strongly request that Sisyphus implement an official and reliable backup and restore mechanism. I can't imagine it would be very difficult to have a reliable method of packaging the Content folder into a zip file for backup and then extract that zip file when restoring. Even if it's only available from the Web interface rather than smartphone apps, it would be helpful.
Failing that, can you at least address this corruption issue? I've never encountered so many occasions with a modern device of data loss and corruption as I have with this table. Apparently data corruption/loss when the table lost power was a known issue (and one I experienced), and yet an actual "Shut Down" function was only added to the firmware very recently. And somehow when copying files back and forth, it can't be assumed that the files will all be intact? I'm not sure what accounts for this table's "digital fragility" given that it's running Linux and it's the year 2021, but if those issues can't be fixed, then that makes the case for a reliable backup and restore method even stronger.
I couldn't resist the lure of the limited edition stainless table so my current one is about to go to a new home. Thus I would love to back up my existing tracks and playlists and restore them on the new table when it arrives. A search turned up this post.
I'm enough of a nerd that I can probably work it out based on the description in this post, but are the backup/restore instructions posted somewhere? It sounds like the process is:
- Back up the content directory on the old table to another computer
- On the new table, restore the files to a temp directory
- Kill the server process
- (Back up the content folder, because paranoia)
- Replace the existing content folder with my backup
- Do something to restart the process, which I'm sure I can work out but if not I can just restart the table
Is that correct?
Still no backup capability as far as I can tell, and lack of this feature has once again bit me in the a**. I went out of town for Thanksgiving, so I shut down my Sisyphus beforehand using the capability built into the app. When I got back, I plugged it in and saw the blue LED ring at startup, and then....nothing. No lights, no motion, no connectivity through the app. I've seen this multiple times in the past even after performing a proper shutdown. So I did what I always did: hard power cycled it by just unplugging it. This time it came up, but when I opened the app, I saw a notice I'd never seen before, saying the table had been improperly shut down, that a file error had been fixed, and that the table may have been reset to factory defaults as part of that fix -- which I discovered it had been. SERIOUSLY!? "Hey, your table works again! But....all of your tracks and playlists are gone, and if you didn't back those up beforehand....well that's admittedly not your fault since we never gave you an official way to do that. So have fun putting everything back again!"
As it happened, I had an "unofficial" backup of the Content folder. So I put the table to sleep, ran "sudo killall node", and then used SFTP to replace the existing Content folder with my backup, then performed an SSH shutdown and powered back up. At that point I had my configuration, but the lights didn't work. Maybe because my backup was from January 2021 a few firmware releases ago? So I started a Factory Reset from within the app, at which point the table stopped and then....didn't come back up. As I write this, I'm figuring out if I'll need to do an SD card reimage from my laptop, which would probably be the tenth time in the 18 months I've had this table.
I don't understand how any Linux-based system can be this unreliable on something as simple as booting properly, even after it's been shut down properly. I don't understand how this table has no backup capability to spare what could be hours of reloading custom tracks and setting up custom playlists. And I absolutely hate that I bought this table. Something that was supposed to be relaxing and help take my mind off my IT work has turned into yet another IT project, and there isn't exactly a large market for a $2000 coffee table, especially one that doesn't even work reliably. I'm sorely tempted to give this the Office Space fax machine treatment.
John,
I don't know if it will change your mind at this point, but we have started rolling out a new card image which keeps the important software in a read-only partition. This is to prevent data losses such as you described. It is being shipped with Mini's right now, and is also available as the current download image: 1.10.90 RO image
As for the lights not working, you are correct in that newer updates changed the way they work. If you run a firmware update, it should restore the latest versions of the light code. I would suggest deleting the lights folder from your Content backup.
Official backup/restore of content is on our short list of future updates.
Matt
Thanks Matt. I just checked and my table is currently on 1.10.90. Do I get the benefit of this read-only partition design if I update to that firmware, or do I have to start with a 1.10.90 image for that perk?
Do you have any idea why starting up after a proper shutdown has been so unreliable thus far? I've only shut my table down maybe 8-10 times, but I've always waited at least 30 seconds to pull the plug after performing the shutdown in the app, and it seems that the table most often fails to come up properly again if it's been off for several days rather than only a few hours. I'm not sure whether that's truly a relevant factor or how/why it would be, but then again I also don't know why a Linux-based system that was properly shut down wouldn't come back in general.
Great to hear a backup and restore function is on the way. I was at least able to get my tracks back by restoring only the status.json file and the Tracks folder, without Lights.
To get the read-only benefits, you need to start with the RO image (note: it requires, at least, a 16GB card). There are too many things that could go wrong on an auto-update to this setup, that we do not want to force it on anyone. If you do update to it, the new location for your status.json is /content/status.json, and tracks go in /content/tracks/
As for why your shutdown is causing data loss, I do not know why this particular one is having issues. If the app showed the "Improper Shutdown", I would guess that it was unplugged before the shutdown process was fully completed. But that is hard to tell without a screen attached. You would have to watch the lights on the Pi underneath to be 100% sure.
Ok thanks. But to be clear, the improper shutdown occurred after I shut down, then plugged it back in and saw no activity after the blue ring animation, and THEN simply unplugged it. So in that case it was expected. The part that wasn't expected was the fact that the initial boot attempt didn't seem to get past the blue ring animation. But if users should wait some period of time after performing the shutdown in the app before pulling the power cord, it might be worth indicating that on the app itself, even if it's an estimate-based message like, "Please wait at least 30 seconds before pulling the power cord," since I would guess that most users aren't checking lights on the underside of their tables and might not be willing or in some cases physically able to do that even if they knew they should.
Matt, we had a brief power outage over here and once again my table failed to come up properly afterward. I plug it in and get nothing, not even the blue LED startup animation, even though I can lights on the components below the table. So once again I'm resorting to an SD card reimage. I thought this would be a good time to try that RO image you had linked earlier. I confirmed that my table has a 16 GB microSD card, but when I opened up BalenaEtcher, I was told that the target was too small because it's only 15.6 GB and the image requires 15.9 GB. I'm guessing that's down to GB being defined in decimal vs. binary terms, but since I'm also guessing that the image includes a fair amount of slack to allow for tracks and such to be added, is there some version of this image that can in fact be laid down on a 16 GB microSD card given that the actual content of the image is likely less than that?
John,
Sorry for that. We have found some cards that shipped in the past have slightly less space on them.
We've updated the download image to fit those as well now. Please download the latest from the support page: https://sisyphus-industries.zendesk.com/hc/en-us/articles/360004729932-Steps-to-re-image-your-Sisyphus-SD-card
That new image worked, although not without another speed bump. I was able to use WinSCP to copy the tracks and lights files from my backup into the new /content/tracks and /content/lights paths, respectively, but when it came time to overwrite the status.json file, I got an access denied error while logged in as the user "pi". I ended up having to copy it to /content/tracks and then use SSH to sudo move the regular status.json file in order to rename it, and then sudo move the version from my backup that I had copied into "tracks" to its proper location.
That official backup/restore capability can't come quickly enough....
We take your privacy seriously and will only use your personal information to provide you with the products and services you request from us. Please see our privacy policy for more details.