[BUG] windows v0.94 truncates output file to last subtitle (with 708 CCs)

[julowe]

CCExtractor version: 0.94 windows only

In raising this issue, I confirm the following:

• [x] I have read and understood the contributors guide.
• [x] I have checked that the bug-fix I am reporting can be replicated, or that the feature I am suggesting isn't already present.
• [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 checked the pull requests tab for existing solutions/implementations to my issue/suggestion.
• [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, worked in command line windows v0.93 (no option in GUI for 708 CCs)
• What platform did you use? Windows
• What were the used arguments? --gui_mode_reports -autoprogram --nofontcolor -dru --service 1

Video links

• sample file uploaded to sampleplatform

Additional information

When using the windows gui or command line, CCExtractor will output all expected 708 CCs to the .p0.svc01.srt file, but will then truncate it to the last set of CCs.

This fails for v0.94 on windows, but works on all tested versions in linux and most versions in windows. Testing info below:

Ubuntu 20.04.4 LTS

ccextractor 0.87 from apt standard repos command: -svc all -nofc -dru get: empty .srt file. good .p0.svc01.srt file with 9 sets of CCs (expected amount)

ccextractor 0.94, compiled from github commit ca303d, 2022-04-11 command: -svc all -nofc -dru get: empty no .srt file (as expected). good .p0.svc01.srt file with 9 sets of CCs, but has different timings in srt file and a last line of N/ that is not in 0.87 linux output. (File also has trailing whitespace differences)

Windows 10 stable 1809 VM

Edge developer virtual box image downloaded from microsoft, on above linux host os

ccextractor 0.87 portable binary, gui command: --gui_mode_reports -out=srt -lf -bom -utf8 --nofontcolor -dru -svc 1 [+input files] get: empty .srt file. good .p0.svc01.srt file (same output as 0.87 linux)

ccextractor 0.88 portable binary, gui command: --gui_mode_reports -out=srt -bom -utf8 --nofontcolor -dru -svc 1 [+input files] get: good, same output as with 0.87 portable binary (and same output as 0.87 linux)

did not test intervening versions.

ccextractor 0.93 msi, installed, gui no option for 708 captions, so no output when ran with command: --gui_mode_reports -autoprogram --nofontcolor -dru get: empty .srt file and did not output .p0.svc01.srt file (as expected)

ccextractor 0.93 msi, installed, command line command: -autoprogram --nofontcolor -dru --service 1 get: good, same as with 0.87 portable binary (and same output as 0.87 linux)

ccextractor 0.94 msi, installed, gui can not select .mov file or drag into program. need to click 'add more files' then type * in file box and hit enter and then can select file. command: --gui_mode_reports -autoprogram +[input files] (default command) command: --gui_mode_reports -autoprogram --nofontcolor -dru --service 1 +[input files] get from both: empty no .srt file (as expected). final .p0.svc01.srt file only has last set of CCs, but intially CCExtractor puts out same 9 sets as linux 0.94 of CCs and then truncates file to last set

Questions

Is it the expected behavior to output an empty {filename}.srt and have the 708 CCs only in {filename}.p0.svc01.srt? Or is this an odd behavior edge case, or is CCExtractor operating as expected on a weird file? This is not ideal as I know some less experienced users/customers I am trying to pass usage instructions on to will be confused.

Can the windows gui be configured to allow all files to be selected and dragged in? I can create a separate issue for this, but wasn't sure if this was a design decision or if I missed an option somewhere. Already posted as an issue in the GUI repo

[PunitLodha]

Ubuntu 20.04.4 LTS ccextractor 0.94, compiled from github commit ca303d, 2022-04-11 command: -svc all -nofc -dru get: empty .srt file. good .p0.svc01.srt file with 9 sets of CCs, but has different timings in srt file and a last line of N/ that is not in 0.87 linux output. (File also has trailing whitespace differences)

0.94 was improved to have better timings and subtitle extraction. Do let us know if it got worse for you

ccextractor 0.94 msi, installed, gui can not select .mov file or drag into program. need to click 'add more files' then type * in file box and hit enter and then can select file. command: --gui_mode_reports -autoprogram +[input files] (default command) command: --gui_mode_reports -autoprogram --nofontcolor -dru --service 1 +[input files] get from both: empty .srt file. final .p0.svc01.srt file only has last set of CCs, but intially CCExtractor puts out same 9 sets as linux 0.94 of CCs and then truncates file to last set

I'll look into this when I get some time and report back

Is it the expected behavior to output an empty {filename}.srt and have the 708 CCs only in {filename}.p0.svc01.srt? Or is this an odd behavior edge case, or is CCExtractor operating as expected on a weird file? This is not ideal as I know some less experienced users/customers I am trying to pass usage instructions on to will be confused.

See #1448

[julowe]

Apologies, I had one detail wrong. Original issue message edited to reflect below.

v0.94 when run on windows or linux with indicated commands does not produce an empty .srt file, as you describe in #1448. That was my sloppiness in running a bunch of tests quickly one after another. v0.94 does still truncate the .p0.svc01.srt file to the last set of CCs though, so that is still an issue.

Thanks for pointing me towards that issue - that helped and made me double-check my results.

[cfsmp3]

Closing - it seems like a non-issue after all? @julowe feel free to reopen if needed

[julowe]

Hi @cfsmp3 - this is still a problem. I think I may have given too much info above?

I just checked again, downloading the portable version 0.94 for windows. When I run it against the same files as above, I still get a .p0.svc01.srt file that only has the very last subtitle from the video. If I watch that .p0.svc01.srt file during ccextractor's processing of the video files I can see that it indeed writes all the subtitles I expect from the video file to the srt file, but then ccextractor at the end of processing, truncates the file to just contain the last subtitle set of 3 lines.

Please let me know what other info I can provide, or to try to clarify in my above infodump. This seems like just some odd filesystem/write behavior, and not a huge bug? Heh but who knows hard to find.

[cfsmp3]

I just checked again, downloading the portable version 0.94 for windows. When I run it against the same files as above, I still

We'd need you to test with the current master. 0.94 doesn't have any of the last fixes. @canihavesomecoffee can you point @julowe to the last Windows artifact?

[canihavesomecoffee]

That would be https://github.com/CCExtractor/ccextractor/suites/11510033399/artifacts/595056084 (from https://github.com/CCExtractor/ccextractor/actions/runs/4399364302)

[julowe]

thanks for that link. But trying to run it gets me a series of error windows. (either running the exe in a directory by itself, or moving aside the .msi installed exe and running this one from that install folder) 1st: The code execution cannot proceed because VCRUNTIME140D.dll was not found. Reinstalling the program may fix this problem., then the same but about VCRUNTIME140_1D.dll, and then ucrtbased.dll Apologies as I haven't really used windows since xp, so I'm out of my depth here. I am using Windows 10 stable 1809 VM Edge developer virtual box image downloaded from microsoft, on Ubuntu 22.04. I had Microsoft Visual C++ 2010 x64 redistributable and 2012 and got those errors. Then repaired 2012 and installed 2015 RC3 for x64 but still got same errors. I'll also point out I uploaded a sample file here in case you don't want to deal with my random host/setup problems.

[julowe]

@cfsmp3 error still present in https://github.com/CCExtractor/ccextractor/suites/11510033399/artifacts/595056084

Tested with Win 10 build 19045, with previously uploaded sample file running above artifact with -autoprogram --nofontcolor -dru --service 1 spits out a .p0.svc01.srt file with only the last set of subtitles.

just to be sure, I also re-tested v0.93 on this new Windows instance. Running that command with command line version of v0.93 (just downloaded 2 minutes ago) does successfully put out all 9 sets of subtitles in the .p0.svc01.srt file - as expected.

[julowe]

@cfsmp3 This is still a problem, can you reopen this issue? (I do not have permissions to do so)