Skip to content

RTSP Timelapse v3.7.0 - Reconnect Crash Fix + Calendar Session History

Choose a tag to compare

View all tags
@HiranD HiranD released this 26 Sep 20:20
· 3 commits to main since this release
v3.7.0
a9a943d

RTSP Timelapse Capture System v3.7.0

Reconnect Crash Fix + Calendar Session History

Release Date: September 26, 2026
Platform: Windows 10/11 (64-bit)

What's New

The app no longer crashes during a reconnect

Every 5 minutes the app closes and reopens the camera stream (the proactive reconnect), and it
does the same after an outage. If the camera happened to stall a frame read at that exact moment,
the app closed the stream while the background reader was still inside the read on it. That
killed the app outright, with no error message: Windows recorded it as an APPCRASH in
opencv_videoio_ffmpeg or ntdll, and until v3.6.1's log file there was nothing to see but a
vanished app. The bug had been there since the bufferless capture was introduced; it only needed
the camera to stall at the wrong moment.

  • The reader thread now owns the stream and closes it itself once its in-flight read returns.
    A stalled old connection lingers for a few seconds alongside the new one instead of crashing
    the process.
  • Verified on a test rig across 19 nights: more than 2,200 proactive reconnects, including seven
    that caught a stalled read, with no crash. The same rig had crashed four times in the month
    before.

The calendar shows how each night was captured

  • Green is a night captured by the astronomical scheduler. Plum is a night captured with
    the Start button or through the remote API (the NINA plugin). The legend lists both.
  • Hover any captured day to see its sessions: where each came from (Scheduled, Manual or
    Remote), start and end times, frame count, whether a video was created, and a note if a
    session failed.

Every session is recorded

Previously only scheduler sessions were written to the capture history. A night captured with
Start or through NINA was marked on the calendar only while its snapshot folder existed, and lost
its mark once Delete snapshots after creating video cleaned up — which is the standard NINA
workflow.

  • Every session is now recorded, with what started it, whether it was stopped with the Stop
    button, by NINA, or by the end of the schedule.
  • A night appears on the calendar as soon as its session ends. In earlier builds the capture
    history was loaded twice internally, so the session recorder and the calendar could each hold
    their own copy: a manual or NINA night could stay gray until the app was restarted, and one
    copy's save could overwrite the other's. There is now one history in memory.
  • The history keeps every session of a day instead of only the last one, so a short morning test
    no longer replaces the real night's record.
  • A manual Start that is stopped before any frame is saved is not recorded, so testing leaves no
    clutter behind. An empty NINA session is still recorded, as evidence that an unattended night
    failed.

The frame counter overlay switch works

Unticking Add frame counter overlay used to save nothing: the setting lived in the selected
video preset, so scheduled and remote-API renders kept stamping the counter onto every video, and
each restart ticked the box again. It is now an app setting, saved the moment you click it and
honoured by every render path — scheduled sessions, NINA renders, and the Export button.

Security

The diagnostic log file no longer contains the Discord webhook URL. With Write a log file
enabled in v3.6.1, the configuration snapshot logged at every capture start masked only password
fields, so the webhook URL went into logs\app.log in clear text. Anyone who has that URL can post
into your Discord channel. The log now also masks any setting whose name contains webhook,
token, secret or key.

If you have shared an app.log (or its app.log.1–.3 backups) from v3.6.1 with a Discord
webhook configured, regenerate the webhook in Discord's channel settings and paste the new URL
into the app.

Other fixes

  • Removed a calendar-wide tooltip that had never been able to display; the per-day hover details
    replace it.

Upgrading from a previous version

  • Easiest — in your existing app folder, replace the old RTSP_Timelapse.exe with this one
    and restart. Your settings in config\app_config.json and history in user_data\ are kept.
  • Fresh copy — extract the ZIP to a new folder, then copy your old config\ and
    user_data\ folders next to the new exe.
  • Frame counter: it is no longer part of video presets. If you want the counter on your
    videos, tick Add frame counter overlay once after upgrading; it then stays on for every
    render until you untick it. Presets saved by older versions load fine.
  • Calendar colors: nights that were only marked because their snapshot folder still exists
    (no history record) now show plum rather than green, since nothing records whether the
    scheduler captured them.
  • Rolling back later: builds older than v3.7.0 ignore the whole capture history file once it
    contains the new session-source field. If you might downgrade, keep a copy of
    user_data\capture_history.json first.

Documentation & Support

Download v3.7.0 | View Source | Report Issue

Released under MIT License

Assets 3
Loading