On Jan 13, 2018, at 6:33 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
> The problem is that the code in libwiretap that *reads* from the capture file - or the standard input - is buffered, even when reading from a pipe, in such a way that 4096 bytes need to have been written by the program piping to TShark before it'll even finish *opening* the input. That means that the first packet probably *won't* be seen by TShark until *several* packets have been written by the program piping to it (enough packets to cause at least 4096 bytes to be written to the pipe).
>
> Please file a bug on this, at http://bugs.wireshark.org/. (Fixing it would be a bit complicated; putting a bug in the bug database 1) leaves a record in the bug database to keep track of the bug and 2) provides a place to put the analysis of the bug.)
OK, I've made changes to make that work, so the bug you filed:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14345
should now be fixed in the master branch, and thus will probably be fixed in 2.6.0 when it comes out (unless there's an unfixable problem with my changes). It will *not* be fixed in any 2.4 or 2.2 release, as the changes are a bit more complicated than I'd trust to backport.
(As a side-effect of other changes I made when working on this, reading uncompressed files and doing filtering/some statistics/etc. may speed up a bit, due to handling seeks that don't actually change the file position by doing nothing rather by than discarding all buffered data and moving the underlying file seek pointer by 0 bytes and reading from there. It might also affect doing so on compressed files, but not by nearly as much; I may look at that as well.)
