Problems writing data (for IT)

The problem

You are hosting your SQLite database (.ddb and .tdb files) as well as images on a file server. Depending on your file server/network configuration, your system may temporarily prevent Timelapse from writing to its database.

In particular, Timelapse uses SQLite to read/write data, where SQLite is optimized to work on databases located on a local hard drive. In practice, Timelapse seems to mostly work fine when its database is on a network drive, even though the SQLite documentation warns about using it on network drives. It seems like your file server setup is one of the problematic cases for SQLite.

Recent versions of Timelapse were updated to do more robust SQL queries, including a shutdown dialog if it has any problem writing its data (to prevent any data loss). Usually, the problem stems from the database becoming read-only for a short while, which is why writing fails. This isn’t a user permissions mistake — it’s likely a transient condition on the storage/network side that SQLite interprets as I’m not allowed to write right now. We’ve just made Timelapse more resilient to brief occurrences of this (it now retries writing several times before giving up), but the underlying cause is on the file server or network path. Reducing it there will make the problem rarer and less disruptive.

Possible Causes

Timelapse writes its errors to an error log (start Timelapse, select Help | View error log to see its contents). It should provide a detailed description of the error plus a timestamp of when the error occurs, which you can try to match up with your own log files.

SQLite (like most embedded databases) relies on the filesystem to support proper file locking. It works best on local disks. When the database file lives on a mapped/network drive, anything that causes a brief interruption in the SMB/CIFS connection or locking behavior can make Windows/SQLite see the file as temporarily unwritable, even though nothing is actually wrong with permissions. The actual cause is somewhat hard to chase down, as every file server setup differs. Still…

SQLite (like most embedded databases) relies on the filesystem to support proper file locking. It works best on local disks. When the database file lives on a mapped/network drive, anything that causes a brief interruption in the SMB/CIFS connection or locking behavior can make Windows/SQLite see the file as temporarily unwritable, even though nothing is actually wrong with permissions.

  1. Antivirus / EDR real-time scanning — if the security software scans the .ddb file (or its companion -journal file, which Timelapse creates transiently during each write and removes right after) on access, it can briefly lock or delay write access. Consider excluding the Timelapse data folder / files (the .ddb and .ddb-journal files) from on-access/real-time scanning.
  2. Backup or sync agents — backup software (e.g., Veeam, Backup Exec) or sync clients (OneDrive, Dropbox, Google Drive) that touch the folder while a backup/snapshot/sync job is running can briefly lock files or flip them read-only during the operation. Check whether error timestamps correlate with scheduled backup or sync windows.
  3. Network connectivity blips — brief drops in the connection to the file server (Wi-Fi hiccups, VPN latency, switch/cable issues) can cause Windows to briefly reconnect the mapped drive in a degraded state. Check the client’s Windows Event Log (System log) around the error timestamp for “Delayed Write Failed” or reconnection events, and check the server/switch logs for the same time window.
  4. File server maintenance / replication / snapshot windows — some NAS or file-server setups briefly present a share (or a specific volume) as read-only during a VSS snapshot, storage replication, or DFS namespace failover. If you use any of these features, check whether their schedules line up with the error time.
  5. SMB protocol/version and oplocks/leases — older SMB1 or misconfigured oplock/lease settings on the server can behave inconsistently with the byte-range locks SQLite uses. Confirm the share is being accessed over SMB2/SMB3, and that oplocks/leases are enabled and functioning normally on the server.
  6. Permissions consistency — confirm the user’s account has stable, non-intermittent Modify/write permission on the folder (not just Read), and that no group-policy or ACL-refresh process is briefly reapplying more restrictive permissions.

Workarounds

SQLite-based applications like Timelapse work most reliably when their database file is on local or truly reliable storage rather than a network share. There are two workarounds to avoid this issue. Both assume your file server should always maintain the master copy of the images and database files, where they work by temporarily copying certain folders/files to your local hard drive. Both should eliminate the issue. The page Problems with Writing Data – Workarounds details both methods, as well as a video illlustrating them.