"Theoretically it should be impossible to get this error" about aegisub-motion HOT 10 CLOSED

Are you on Windows 10? Also, just to confirm again, you're able to produce the error with the exact file you sent me? Can you give me the line you're trying to trim on to test with, or does it occur no matter what portion you try to trim?

from aegisub-motion.

Can you upload the actual file (or a subset displaying the same issue) somewhere, along with your a-mo config and logs? If there are sensitivity or file size concerns, you can pm me on rizon or freenode, though as mentioned in the previous issue responses will be delayed

from aegisub-motion.

Here's a small section of the file. Well I haven't changed anything to the any of the files (just installed this today with DependencyControl). And if you mean the log that's saved to the temp directory, it's empty.

from aegisub-motion.

I can't reproduce this with that file on my machine. What platform and Aegisub version are you using? Can you verify it happens to you with just that sample? I'm thinking this might be related to you having an old Aegisub version and the encode using 8x8dct, but it's weird since then I don't think the file should open at all...

from aegisub-motion.

Well I downloaded this version just a few days ago (got the link from dependency control).

I checked some of the files in the batch and noticed that some work and some don't. I can't really seem to find any major differences in the video files, so I assume something went wrong when encoding the files or something. I haven't really had this issue with other files (yet) so I hope it's just this batch (but I'm still confused that you can't reproduce the error, so maybe it's indeed something with the software).

from aegisub-motion.

Yes I'm using windows 10; and yes that's correct. It doesn't matter which line I want to trim, it still gives me the same error (here's a short recording as "proof").

from aegisub-motion.

Ah okay, when I use the included subtitles I'm able to reproduce it! I was just timing a random line when testing. Thanks for the video, let me see what's up.

from aegisub-motion.

This appears to be a confusing error on a-mo's part and some suboptimal behavior in Aegisub itself. The endpoint a-mo is calling here, aegisub.project_properties(), is undocumented for... some reason. In this case, a-mo is using aegisub.project_properties().video_file, which returns a string to the video file referenced in the ASS file. This means that when its length is zero, Aegisub isn't saying the video has 0 frames, but that it's a string of zero length. This mostly comes up when loading subtitles muxed in with video, since it won't automatically change the property when loading them, so even if that value is set it's likely to be wrong.

There are a couple ways to deal with this. First, the error in a-mo should probably be clarified since this has nothing to do with frame count. Upstream in Aegisub, there are two options: either modify this endpoint/add a new endpoint that returns the location of the loaded video or automatically set the project's video file property to the current video file when loading embedded subtitles. I'm inclined to just go with the latter, but I should probably check to make sure the current behavior isn't intentional for some reason. Finally, the project_properties API should be stabilized and documented since popular scripts are making use of it and I don't see any reason for it to constantly be changing.

As for how to work around this in your case, you can just extract the subtitle track from the MKV to a separate file, load the video there, and the issue won't occur.

I'll file an issue on my Aegisub repo to deal with this upstream, and then close this one once the a-mo error is reflective of the actual problem.

from aegisub-motion.

Hmm. Well the work around works, so I'm satisfied for now. Thanks for the help.

from aegisub-motion.

Filed the Aegisub issue so I don't forget about it: TypesettingTools/Aegisub#41

from aegisub-motion.