Video is not actually cut, joining fails

[Hetsh]

I am using the most recent version of VidCutter from the AUR (6.0.0). The video is a tv recording with 4 audio and 2 subtitle streams. Accurate frame cutting is disabled.

I create a single clip of a few seconds by setting start and end and i do see a clip in the clip index, but the resulting file seems to be not cut at all and contains the whole video and audio:

-rw-r--r-- 1 jan jan 6,1G 25. Mär 21:39 '2019-03-22_22-25_Zero Dark Thirty_EDIT.ts'
-rw-r--r-- 1 jan jan 6,2G 23. Mär 00:59 '2019-03-22_22-25_Zero Dark Thirty.ts'

I cannot see any messages that indicate an error in the log when using the --debug flag.

Am i making a fundamental mistake when cutting the video?
Can i provide any additional information?

[Hetsh]

I experimented with two clips and found an error message in the logs this time indicating a problem while joining.
Seems to be related to #163.

[Hetsh]

When adjusting the ffmpeg call from the logs i can get it to work. I simply put the input option to the very beginning from:

/usr/bin/ffmpeg -hide_banner -v error -ss 00:05:39.430 -t 00:01:39.960 -i "/home/jan/2019-03-22_22-25_Zero Dark Thirty.ts" -c copy -map 0:0 -map 0:1 -map 0:2 -map 0:3 -map 0:4 -map 0:5 -map 0:6 -avoid_negative_ts 1 -y "/home/jan/2019-03-22_22-25_Zero Dark Thirty_EDIT_00.ts"

to:

/usr/bin/ffmpeg -i "/home/jan/2019-03-22_22-25_Zero Dark Thirty.ts" -hide_banner -v error -ss 00:02:00.070 -t 00:02:39.420 -c copy -map 0:0 -map 0:1 -map 0:2 -map 0:3 -map 0:4 -map 0:5 -map 0:6 -avoid_negative_ts 1 -y "/home/jan/2019-03-22_22-25_Zero Dark Thirty_EDIT_00.ts"

I still have to look at concatenating.

[Hetsh]

I proposed a pull request to solve the cutting issue. In the meantime, users can apply the fix from #223 manually. Arch linux users can find the file here: /usr/lib/python3.7/site-packages/vidcutter/libs/videoservice.py.

[Belboz99]

I ran into this same issue using the version from Ubuntu's repositories... it cost me around 20 hours of rework.

Today before I looked this up I tried running it on Windows to see if that made a difference... it did not.

This issue is a really severe regression, as it's essentially breaking the essential function of the software, and yet there is no error message reported.

Along with resolving the underlying issue and ensuring that the videos are indeed trimmed... there should be some work done to ensure that an error like this is actually thrown and caught by a message handler to inform the user that not everything went "OK". Better error handling alone could've prevented 20 hours of rework, even if the software was still broken.

[berkley4]

Ffmpeg's wiki page on seeking seems to indicate that it's faster and more optimal to put the '-ss' option before file input '-i', ie input seeking as opposed to output seeking.