Deprecation is not the same as a hint. That message is a warning to let you know that while it may work today, it may not in the near future because sys is being deprecated and ultimately phased out (and removed) in favor of util. It would make sense to write code for the packages that will continue to work, and not for things that will be deprecated.

While a lot of monitors have USB ports, unfortunately they do not provide enough amps to run an rpi. All of them will be capped at either the USB1 or USB2 spec, which is 150 to 500mA. Some newer monitors have USB3 in them, but even that will be capped at the 900mA spec. An rpi needs more than that. It might run, but you’ll get erratic behaviors and random crashes from it.

@kasy, we need more information here. What hardware are you running on, be specific. What have you done to install MM. What have you done that gives you that message? We aren’t all Gods here … like @MichMich …

While the description says it can drive both a VGA and HDMI connected monitors, resulting in a dual setup, MM is configured to launch one Electron screen. You might be able to run a side-by-side installation of MM and launch it on a secondary port, and I’m assuming it will launch a second Electron window that you will then have to position on screen. I just don’t know what will happen when/if you restart the rpi. Will it remember where the screens were positioned? only testing will answer that.

macOS is the edge case. :)

> opens nearby dictionary, flips to ‘politics’, grabs red pen and writes /* ... */ around definition <

YEP! Still works! :)

I wasn’t referring to the actual module files. I’m talking simply editing the config.js file and comment the specific module’s config section out.

Since he said smart nerds … here ya go http://bfy.tw/80wP

Note that if you are trying to move it down, you won’t be able to because the newsfeed module takes up that space. Please look at the various regions on this post: https://forum.magicmirror.builders/topic/286/regions

Deferring on the picture taking as that’s just a painstakingly long process depending on how many articles of clothing you want to store. And how, whether you’re going to wear each one, take a picture, and then clean it up, or if you’re just hanging them on some background. How are you going to do ties? Again, wearing each and cleaning up the image to only show the tie? Yeah, deferring. :)

The better practice is to store (TEXT) data like that in database tables, and create indexes that can then be quickly searched. For example, have a table with only the shirts, listing color, style, and whatever other attributes you deem necessary. Do the same for pants. Have both indexed. Then you need to create some logic that will determine what would match based on your preferences, so you don’t end up wearing colors that clash, for example (then again, maybe you are that stylist who does exactly that.)

It’s not impossible, it just takes a lot of work. The pictures part, as well as the logic part. It’s really easy to query the database for a random shirt and pants. It’s harder to query for something that makes sense.

More reflectivity means more silver particles in the material. More silver particles means less light transmission for the monitor. Every situation is different, every room is different. You will have to try it out. My suggestion is to find a place you can order sample pieces from, then go hold them up again the monitor, in the environment it’s going to be in, see what works.

Unfortunately, that’s a hard one to figure out. It’s going to have to be a trial and error for you. Generally, the higher the transmission rate, the less reflective you will get.

I don’t remove config sections … I comment them out … If I’m going to edit that file to change a flag, it’s just as easy to add a /* ... */ tag around the specific section. :)

Well, my rpi isn’t backed up. The data that’s on it is all on github so all I would have to do is restore the OS. I have yet to compile anything from scratch as I use pre-compiled packages and install via 'apt-get'. However, for other, more dedicated servers that I run, I do back them up every single day, however again, I don’t bother with the OS. What I do backup (list based on a CentOS machine):

/home - where everyone's user accounts reside
/etc - because it contains a myriad of config files for the whole system
/var/lib/mysql - all the MySQL databases live there
/var/spool/cron - because I really don't remember all the various custom service tasks that are running
/root - because I tend to keep some important, system wide stuff there
/var/mail - users tend to lose their heads if suddenly their entire INBOX goes missing

Everything is done using 'rsync' in incremental hard-links mode. This way I can keep (on average) 2 weeks worth of data without it also taking up 14x the amount of physical storage; it only copies a file if it has changed. I have a single terabyte drive that has been the backup drive for 15 different servers, storing anywhere between 2 to 4 weeks worth of data (and it’s also backed up to a secondary machine). One of the servers takes up 175GB all on itself. If I didn’t do incremental hard-links, I’d be needing a larger backup drive just for that one machine.

Should the main hard drive in any of the servers die, all I have to do is swap it out for a new one and push the power button. PXE (pixie) takes over, sees that there’s no OS on the drive, and automatically re-installs everything for me from the source OS server on the network. 10 minutes later the server is up and running, fully configured, with a restore rsync running. That’s faster than many will take to finish a hot cup of coffee in the morning.

I realize this is a more advanced setup that will not apply to 95% of you here. But then, you did ask how we backup. :)

If I were to backup my rpi, that’s the same process I would take, with the exception that rpi does not support PXE, so I will still have to manually re-image the SD card and go through the setup process to get it back up and running, prior to doing any kind of restore operation on it. And since I use my rpi only for MM, there isn’t a whole lot in terms of what needs to be redone on it, other than a few git clone commands and restoring my config file. But since I run an identical setup at my office but on a regular unix server (for when I’m bored and want to do dev work), I just copy that file over and done.

One of these days I’ll map out how my internal network runs and “maintains” itself.

In your predicted year that your rpi will crash, everything would have been upgraded anyway, libraries, OS, other programs. It makes more sense to redo it from scratch rather than reloading old (and in some cases, obsolete) software back on. What’s the point in doing that, and then spend another several hours upgrading, and recompiling anyway? Even Raspberry Pi’s OS gets upgraded a few times a year …

Honestly, this is how people get themselves in trouble with security patches that are never applied. They have a device running, in their mind it’s fine, and yet it has gaping security holes that are addressed in future upgrades. Seriously folks, stay ontop of updates, upgrades, and what not. Don’t juse assume a backup from a year ago, or even 3 months ago, is “just fine”. None of my OS (I said OS, not config files) backups are more than a few days old.

You can’t put it in a Win machine and “see” it. Those partitions are unix specific, and Windows can not read them, at least one of them it can not read. Different filesystem. If you need a backup, your question should be: what do I want to back up?

• The file system can be recovered simply by burning a new image on the SD card and reconfiguring
• MagicMirror can be reinstalled by doing a 'git pull'

As far as MM is concerned, what’s user configurable is your config.js. Any modules you’ve installed can be reinstalled with a simple 'git pull' to the repository. So you can cut and paste your config.js into Notepad. You can use FTP to transfer it …

For the other, system specific configurations, you can copy all of those config files over to a Win machine.

Honestly, I don’t backup my MM. I don’t see a need to. It’s easy enough to recover, unlike a Windows machine and all the applications on it. I can wipe the card, and start from scratch and have it back up and running within 15 minutes. Try doing that with a Win machine … unless you’re doing a full system image restore, which still takes longer.

And I’ve been running computers, servers, all types of systems for decades … an rpi running MM isn’t worth doing a backup on. And mine even contains copies of my own code that I’ve written. But since that stuff is also on github, again I don’t see a need to bother. A simple 'git pull' and 30 seconds later I have it all again.

I probably won’t, at least not on my production mirror. I will on my test mirror, but that won’t happen this weekend … maybe next.

I’m expecting my very own issue in my mailbox, together with some parts to make one … c’mon MagPi!

If your FitBit application requires running on port 8080, you will run into exactly the problem you have because MagicMirror also runs on that same port. You will have to change one of them. MagicMirror is easy to change, it’s in the config.js file. Change the port setting to something else, like 8081 …or 8585 … or 8123 … doesn’t matter, as long as it’s above 8000, and not 8080 since the Fitbit runs on that port.

You have something else on port 8080. Figure out what, change it, and the problem is fixed.

NOTE: MagicMirror runs on port 8080 by default.

If you can’t log in with that default user and password, and you never changed it to begin with, I would seriously wipe that SD card and start over. There’s no telling what happened to it or why the password is different. And since it’s an internet connected device, that’s cause for alarm, or at least be concerned.