endOfNight.sh permission issue

[astrobrothers]

I have a couple questions about this script and some issues I'm having. Running v8.3.3. I'm doing some final testing of the file handling before I setup the external website. Allsky images are saved in /home/user/allsky/images - just note that I'm not using "pi" as the root user name. After that I am using sirv.com as a testing site for the file transfer stuff.

1. The files that need to be put into the /var/www/allsky folders don't copy. If I run endOfNight.sh manually on the command line, I get these sorts of errors for the data.json, keogram.jpg etc etc.

• cp: cannot create regular file '/var/www/html/allsky/data.json': Permission denied
  

• If I run sudo, I don't get the error and the files are copied to that above directory.  Am I missing something?  Do I need to add "sudo" to the capture_RPiHQ.cpp file when this script is called?
  

2. The other thing I'm not seeming to get right during this process is the image dimensions. I have a RPi HQ. Bin2 caused some undesirable effects so I'm back to bin1. Since I think I'm going to have to switch to either PNG or DNG (for photometry reasons), file size is kinda large (5-6MB) at 4K resolution with .jpg @100% quality.

• If I change the image dimension in the UI, it only seems to dictate what the endOfNight.sh script is looking for, correct?
• Is the solution to have the UI dimension and the IMG_RESIZE match?
  Thanks!

[EricClaeys]

@astrobrothers
1.
The "pi" user is in the www-data (which the web server uses) and sudo groups, which gives it permissions to write to /var/www/html and to run any sudo command. Put your login in those groups. Run addgroup --? to see how. You'll need to run it as sudo. The next release should make this easier, although it probably needs to be tested to see if the issue you have is still there.
2.
What do you mean by the "UI dimension"?
The IMG_RESIZE, IMG_WIDTH, and IMG_HEIGHT variables determine the resolution of the ~/allsky/images/DATE images. If you have CROP_IMAGE=true that'll change the resolution as well. The RESIZE_UPLOADS* variables change the resolution of the images that are uploaded to an optional Allsky Website.

Timelapse, keograms, and startrails created from endOfNight.sh use the images in ~/allsky/images/DATE so get their resolution from them, however timelapse videos can be resized, and often have to be with the RPi HD camera since it's bigger than the max allowed by the h264 codec so usually causes the timelapse to fail. Shrinking the timelapse isn't a big deal IMHO since I don't know anyone with a high enough resolution monitor to see the video full resolution. I cut my resolution in half.

FYI, Allsky doesn't support DNG files, and PNG images can take up to 10 seconds to save since the Pi doesn't have hardware support for them like it does for JPG files. If you have very short delays between images that'll be a problem.

[astrobrothers]

1. So the username I'm using is a variation of "pi" plus some characters - we have to be careful here about using common logins where I work. The name I'm using, let's say it's "pi123", is already in those two groups. Is allsky software trying to specifically use "pi" or whatever the root username is?
2. Sorry, referring to the Image Width , Image Height entries in the GUI. They seem to do something different than the IMG_RESIZE values in config.sh, right? For the sake of saving PNG's faster, I'm hoping that by cutting res by half will do the trick.

I've read through the Wiki (very helpful!) and I'm already getting good results with half rez on the timelapse, but still using the h264 encoder.

FWIW, apparently using the Pi 4 8GB and some minor tweaks, we can get the save time down to 6seconds for PNG at full resolution. I'm testing allsky software on the 64-bit Bullseye with my other 8GB RPi to see if this holds up. So far, your software is working fine on that OS build.

[EricClaeys]

@astrobrothers, The current version assumes "pi" is the login. It's hard coded in some files. If you're comfortable changing code you can grep for "pi" in all the *.sh and *.php files.
The next version uses whatever login you install Allsky as and the name isn't hard coded. I just modified the new install script to put that login in the www-data and sudo groups if not already there, based on your input - thanks!

I may remove the WebUI "width" and "height" fields. They are super confusing when comparing to the IMG_RESIZE and CROP fields. And I'm pretty sure they do something different depending on what camera model and operating system you have. In some cases, entering 100 x 100 for example produces a 100x100 pixel image from the camera centered on the center of the sensor, and in other cases you get a full-resolution image but of the 100x100 center, which is basically a "digital zoom" like cameras have.
I'm pretty sure when Allsky was originally written only ZWO cameras were supported and 100x100 give a 100x100 image, which was more efficient than writing a full-size image only to RESIZE it after the fact. Since then, Bullseye and the RPI HD cameras came along which changed things.

I spent hours and hours testing and writing the Wiki page on troubleshoot timelapse problems, and figured out almost all the problems were caused by too large a resolution image (like HD camera) or not enough swap.

When I tested saving PNG files I'm pretty sure I got what you are. The Wiki says "up to 10 seconds" to take into account slower Pi's.

[astrobrothers]

@EricClaeys Super helpful - thanks! Changing this in next version will be very helpful since I'm hoping to build quite a few of these for schools across the state.

Yes the terms and the logic behind what cropping, resizing and subframing mean can unfortunately get mushed together these days.

I found a temporary workaround. I'm not a linux expert, but I tried this and it worked to allow the endOfNight.sh to run without me having to use sudo on the cmd line.
sudo chmod 777 -R /var/www/html