Reply to thread

Message

<blockquote data-quote="Owlsroost" data-source="post: 1107140" data-attributes="member: 83973">Just to fill in on the background (in terms of how TsReader accesses the timeshift files) - it uses exactly the same method and code to read local (single-seat) and remote files, it's just a different file path. The actual remote access stuff (SMB) is transparent to TsReader, and is handled by the OS (Windows).If the OS returns an error when TsReader requests data from a file, there isn't really much that can be done other than re-trying the read (or giving up !).My *guess* is that the 'invalid signature' errors might be because security handshaking between SMB client and server is taking too long sometimes (so rather than stalling the read for a long time the OS returns an error - a reasonable thing to do). If this is a common error condition but doesn't cause stream corruption, it's actually sensible not to log these errors normally - logging is a performance overhead.</blockquote>

[QUOTE="Owlsroost, post: 1107140, member: 83973"] Just to fill in on the background (in terms of how TsReader accesses the timeshift files) - it uses exactly the same method and code to read local (single-seat) and remote files, it's just a different file path. The actual remote access stuff (SMB) is transparent to TsReader, and is handled by the OS (Windows). If the OS returns an error when TsReader requests data from a file, there isn't really much that can be done other than re-trying the read (or giving up !). My *guess* is that the 'invalid signature' errors might be because security handshaking between SMB client and server is taking too long sometimes (so rather than stalling the read for a long time the OS returns an error - a reasonable thing to do). If this is a common error condition but doesn't cause stream corruption, it's actually sensible not to log these errors normally - logging is a performance overhead. [/QUOTE]

Verification