Fixing unexpected image folders and startrail sorting?

[natevw]

I'd had my Raspberry Pi inside below my workbench for a couple evenings. But yesterday evening (well before sundown!) was the first time it was installed outside and while it's not a great camera I was eager to at least see the startrails. Unfortunately this was the result:

This might be related to #3322 but it's unclear for sure why and what the fix would be, retroactively. I notice the same in my images folders (at least as viewed through the Web UI) is that it was placing images from 2024-06-26 in in the 2024-06-25 folder:

which is weird, because the images for a while that evening were going into the correct day's folder but then later (i.e. darker sky) it started putting them into the previous day's folder.

How does AllSky expect my system clock to be set up? AllSky itself took my lat/lon during setup but looks like /etc/timezone on the Pi generally is still set to "Europe/London" perhaps that's the problem? The system clock is otherwise correct with respect to UTC, and if it were related to this wouldn't we expect the images to go into "future" days' folders (since Pi Foundation HQ timezone is ahead of my US Pacific one…) rather than randomly into past days' folders?

Also, I'm wondering if there's any way I can re-create the startrail from last night with the correct image set now? Or is it really only practical to fix it going forward for future nights' testing?

[EricClaeys]

@natevw, Allsky uses the date and time returned by the date command to determine what folder to put the images in. Run date and see if it's returning the correct time.

Allsky treats a "day" as starting whenever you specify sunrise to be (via Angle, Longitude, and Latitude), going until the next sunrise. So pictures taken after midnight but before sunrise on, for example, June 27, will be put in ~/allsky/images/20240626 (what a person would call "yesterday"). Allsky should never put an image in 20240625 in the example above. If it does, that's an error.

Look in the Explanations -> Angle... documentation page for more info and to see how to determine when Allsky thinks your "sunrise" and "sunset" are.

There IS a way to re-create startrails but lets' hold off on that until after the other issues are fixed.

[natevw]

Thanks! So I did change my timezone to the US/Pacific option found via raspi-config menu, maybe I should have looked harder for the more standard America/Los_Angeles but a bare date command is returning the same local time our household clocks show now. (To be clear, date -u has ± always been correct as the Pi has NTP access and seems to get synced up quite soon after boot.)

I rebooted just to be sure everything picked it up; this was shortly after I posted my questions above and so most of the day I got sort of "alternating" images which makes some sense if it's using the purported local time to name/sort the images:

By evening it was past the older overlapping images and the startrail is more as expected:

Certainly not a big full circle, but I suppose the nights are short to begin with and looking at some of the images/timelapse I think we had some clouds roll over that messed with the exposure generally. This is a cheap OV5647 camera (Amazon link) to start with so I wasn't expecting any particularly stellar ;-‌) results.

Hopefully by tomorrow then it will have a full 24 hours of correct time but looking better already! It was just a little surprising that the local timezone setting mattered since I figured something like the local mean time (relative more to UTC) would be more important. Thanks for confirming, it's fun to see some results already!

[EricClaeys]

The Linux kernel only keeps track of the number of seconds since Jan 1, 1970 UTC. The date command takes that integer and displays it taking the time zone, daylight savings time, etc. into account.

When did you change the time zone? You shouldn't be getting "alternating" images like that so I assume the time zone changed (which would impact the time displayed by date, and hence the sort order). Just to be sure, double check after a full day of no time zone changes.

The star trails are a little wavy. Is your camera on something that can move with the wind?

[natevw]

Just to be sure, double check after a full day of no time zone changes.

Yep, the alternating images make sense since it uses timezone to localize the timestamps. After the overlapping time cleared, results more as expected, thanks!

The star trails are a little wavy. Is your camera on something that can move with the wind?

The later nights seem a little better, maybe it just wasn't as windy because this is still a very temporary mount for a temporary camera so it might be shifting around some :-)

[EricClaeys]

Sounds like everything is working as expected now, right?

[natevw]

Yep, thanks much for the confirmation of what was going on! This is some neat software and it's fun to watch the timelapses (even with my own sub-optimal camera/setup currently :-‌)

[EricClaeys]

Closing Discussion item. Problem resolved.