ccextractor icon indicating copy to clipboard operation
ccextractor copied to clipboard

[BUG] Issue 1077 Still lives

Open GlowTube opened this issue 8 months ago • 0 comments

In raising this issue, I confirm the following:

  • [x] I have checked that the issue I'm posting isn't already reported.
  • [x] I have checked that the issue I'm porting isn't already solved and no duplicates exist in closed issues and in opened issues
  • [x] I have used the latest available version of CCExtractor to verify this issue exists.

Necessary information

  • Is this a regression (i.e. did it work before)? {YES/NO} not a regression
  • What platform did you use? {Window/Linux/Mac} Linux
  • What were the used arguments? {replace with the arguments} /usr/bin/ccextractor -quiet "$file1" -o "$file2" > /dev/null 2>&1

Additional information

I do a lot of ccextracting of .ts files via a pipeline of bash scripts. 99% of the time this works perfectly, but 1% of the time ccextractor produces a zero length .srt file as described in issue 1077 (which is marked as closed). My script detects this condition and does 'n' retries spaced at 1-minute intervals, but the zero-length output file is reproduced each time. The REALLY WEIRD thing is that, if I grab just the ccextractor line from the script and run it interactively as the same user and with the same cwd, on the same .ts file, it works the first time, every time, and produces ~100K of subtitles. Same file, same command, different output.

For the script case, I also did obvious stuff such as making sure ccextractor was running at good priority, and that disk space wasn't an issue. And ccextractor does work correctly in my scripts, >almost< all the time. It's not a showstopper for me as the system notifies me whenever a zero-length file is created, and it's easy for me to re-run and overwrite.

Ubuntu 22.04.3 LTS, ccextractor 0.93+ds2-2 from the normal apt distribution.

GlowTube avatar Nov 03 '23 15:11 GlowTube