mirror of
https://github.com/CCExtractor/ccextractor.git
synced 2026-02-04 05:44:53 +00:00
-stdin option returns almost immediately after the first few bytes of data. #136
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @enternoescape on GitHub (Apr 4, 2016).
Originally assigned to: @canihavesomecoffee on GitHub.
I tried 0.79 pre-compiled Windows binary and compiled the latest git with the same results.
Example command line:
type video.ts | ccextractorwin.exe -stdin -in=ts -out=srt -o video.srt
I am trying to use this as part of a program and it's very desirable to be able to use stdin instead of reading the file from the disk as it's being written.
EDIT: I forgot to include "-o" for the output filename.
@canihavesomecoffee commented on GitHub (Apr 4, 2016):
Running the same file regularly works?
@enternoescape commented on GitHub (Apr 4, 2016):
Correct.
I also wanted to mention that when I compile the version for Linux, stdin works without issue. This is just a problem for Windows. I'm using Windows 8.1 if that helps any.
@canihavesomecoffee commented on GitHub (Apr 4, 2016):
I asked if it was running because I wasn't sure you got the output command correct, but I see you've added the -o.
Besides that, if it's running fine when passing it directly instead of through a pipe/stdin, it's indeed some windows-related bug.
@enternoescape commented on GitHub (Apr 4, 2016):
I figured as much, I was trying to work out what was going on myself, but I wasn't really getting anywhere. All I've really noticed is that the program only gets one successful buffered read of 1083 bytes and then no subsequent reads are successful. It's like stdin is closed.
@canihavesomecoffee commented on GitHub (May 22, 2016):
I've done some testing, and in my case (depending on the input size) the amount of bytes it's able to read before it stops receiving data varies (from 299 to 95959 bytes). It also varies depending on if you specify an -in, or use -autoprogram (in the latter case it seems to read more).
I can't really find any useful hints or similar issues either online, so I'm afraid that at the moment this one will remain open 😢
@cfsmp3 commented on GitHub (May 31, 2016):
These seem to be good hints
http://stackoverflow.com/questions/30968377/command-line-tool-to-get-binary-data-as-string-in-windows-like-cat
http://stackoverflow.com/questions/7924365/windows-pipes-in-binary-mode
@cfsmp3 commented on GitHub (Nov 4, 2016):
This is likely a duplicate of this:
https://github.com/CCExtractor/ccextractor/issues/434
@enternoescape can you check if the problem is fixed for you? (precompiled binaries available on that ticket)
@enternoescape commented on GitHub (Nov 4, 2016):
I didn't see any binaries. I downloaded the latest code and compiled it. Unfortunately, the issue described here still exists.
@cfsmp3 commented on GitHub (Nov 4, 2016):
Can you try this binary?
https://github.com/CCExtractor/ccextractor/files/530373/ccextractorwin.0.83.alpha2-windows.binary.zip
On Fri, Nov 4, 2016 at 1:53 PM, Joseph Shuttlesworth <
notifications@github.com> wrote:
@enternoescape commented on GitHub (Nov 5, 2016):
It has the same problems.
@cfsmp3 commented on GitHub (Nov 9, 2016):
Code-in task created.
@cfsmp3 commented on GitHub (Dec 15, 2016):
@enternoescape We've released 0.83 today - does this problem still happen to you?
@enternoescape commented on GitHub (Dec 16, 2016):
It is still exhibiting the same behavior.