search

mrworf / photoframe

Software to pull random photos from Google Photos and show them, like a photo frame
GNU General Public License v3.0
223 stars 38 forks source link

How to make progress on the Python3 branch and Bullseye update? #191

Open dadr opened 3 years ago

dadr commented 3 years ago

I'm excited about some work I've done and wanted to share it with you. And also get a little discussion going.

I built a photoframe for my son's birthday. I started with an HP Z24i monitor, RPi 3A+ and manual install on top of the March 21 release of Raspberry Pi OS lite. I added a photo sensor, and got the wrong one. So I updated the code to work with a second photo sensor in addition to the first. I also stumbled into learning about the DDC channel for adjusting monitors from a PC. That works on a RPi too, and the HP monitor allows changing brightness and temperature. So I also updated the colormatch module so that it could adjust the monitor rather than running the script that recolored the picture. A side effect is that the screen can change while a picture is being shown - which is really nice for those of us who set a picture to show for long periods of time. I also have to say that changing the brightness based on the current lux is really very nice on the eyes and something that really wasn't there before. And while I was at it I also added HEIF conversion for pictures taken on iPhones. (It seems image magick is still not working 100% correctly with HEIF on RPi). Anyway, this is all in a branch here: https://github.com/dadr/photoframe/tree/Philip along with notes in a re-written README.md.

The lux-brightness is so nice that I'm thinking about modifying some of my other photoframes that are based on the NT68676 LCD controller. I think it should be possible to create a PWM output on the RPi that directly feeds the brightness lead on the inverter for these displays. That's something to think about.

That brings me to the subject line. I have no interest in having a permanent alternate branch. How do we want to get to the point where I can get this back into the photoframe repository here? I can see an easy path: to create a new distribution image with a clean break from the 2019 image. But I also think that there's an implied requirement that improvements need to be able to be rolled-out using the standard update process in photoframe, and I don't see how to reliably get that done from where we are to where we want to be. I've tried upgrading a number of RPis with mixed results. I think that path has a lot of potential breakage. Does anyone know if there is a way to reliably re-image the RPi from a running system? That seems like the best approach for upgrades. I'd love to see some discussion and direction on how to move this forward.

mrworf commented 3 years ago

My experience is that re-imaging a running system is (like you found) prone to disaster.

The better way would be to break off the master branch and simply refer to it as the version 1.0 branch, start a new branch with version 2.0. This allows the older frames to get small updates and stay functional. The web ui could get a blurb about the amazing new version 2. No path to update from v1 to v2 would be provided, HOWEVER, an export function should be written allowing the user to download their configuration. Then once the frame has been re-imaged, I can see this backup work in two ways:

  1. You simply upload it from the web ui, frame reboots and presto, back in working order
  2. Place the backup file on the SD card and during boot, if present, will do the import and restart

Personally I think this satisfies all the needs. Anyone happy with current setup need to do nothing, but the people who want the amazing new features can migrate in a way that's least amount of hassle.

For this to work though, there's a number of things that need to be done:

  1. New branch for v2 (no biggie)
  2. Create a python3 version for manual install + instructions (sounds like we're almost there thanks to you)
  3. Use better auto update method which can handle versions (so you can have a frame update from another branch). This is something I actually started working on and should not take much longer.
  4. Add export function to v1
  5. Add import function to v2 based on file from SD card
  6. Add import function to v2 based on upload from WebUI
  7. Create new image for Photoframe v2

Thoughts?

(Also, sorry for the radio silence, I got a new job and it's been difficult to get back in a good work/life balance. )

mrworf commented 3 years ago

Obviously steps 3-6 will require a fair amount of testing, but should be doable. I have a few RPis around 😄

dadr commented 3 years ago

My thought is "That sounds like a great approach."

One question for clarification. Do you see python3 also going to the V1 branch? I personally think it would be good if V2 was both the jump to Buster and also to python3. So far I've tried to keep features and fixes that rely on Buster in separate branches so that the python3 branch could be used with either Stretch or Buster.

Finally, no need to apologize for radio silence. Life is not perfect, and I'm sure that photoframe isn't anyone's day job. ;-)

mrworf commented 3 years ago

Python3 is definitely a part of v2, I think once we embark on this road, v1 (photoframe today) will be put in maintenance mode and only crucial issues will be fixed going forward.

shigadeyo commented 2 years ago

Python3 is definitely a part of v2, I think once we embark on this road, v1 (photoframe today) will be put in maintenance mode and only crucial issues will be fixed going forward.

@mrworf ... Is there an update regarding photoframe v2?

dadr commented 2 years ago

@mrworf, @shigadeyo, This is a lot of my bad. I was working on this, and then "things happened." However, I got back on the problem, and learned a helluvalot about threading and flask, and I think I have addressed the comments mrworf had on my last pull request.

@mrworf: No PR yet for the Master branch to include the backup function - I'd like to see if the current approach is "good" first. I'm also wondering if just a "backup" button is sufficient, or if you'd like to see the restore as well.

shigadeyo commented 2 years ago

@dadr ... No worries and no rush. Was just curious. Thanks for the update!

dadr commented 2 years ago

@mrworf: I'm thinking if the current PR is acceptable, then I can sync up with the changes you have done on the Python 3 branch. And then, I think we should see how much breakage there might be by jumping to the Bullseye "legacy" release. If it's manageable, I'd suggest that we create an image using that distro rather than Buster. WDYT?

mrworf commented 2 years ago

Let me take a gander and I'll get back to you in an hour or so

dadr commented 2 years ago

Good News! I've had a chance to try the normal Bullseye lite release, and discovered that the tvservice and vcgencmd programs have been moved to /usr/bin. (I thought they were removed) I made the changes in path names and viola! it worked. @mrworf if you're amenable, I'll push the changes for Bullseye into the python3 PR and we can jump to that release for the Python3 V2 branch. Also, see the comments in that PR - I'm looking for a response about what versioning to enforce. I'm suggesting not to enforce anything (yet). If that's OK with you, then I think we can sync up.