Closed n9yty closed 8 years ago
Is this for comcut or comchap? I think I came across this bug and addressed it already in one of the scripts. Seems like I didn't fix it in both.
Sorry for being unhelpful, I was trying comchap.
Also, and I am debugging it, but it processed a file, which Plex discovered, but isn't showing the chapter breaks... The log shows that it should have, it did say "Commercials were found." before running ffmpeg, but plex is not showing chapters. But I will look into that more, it was only the first file so I expect I am not getting something right. :)
Thanks, Steve
On Nov 13, 2016, at 7:05 PM, Brett Sheleski notifications@github.com wrote:
Is this for comcut or comchap? I think I came across this bug and addressed it already in one of the scripts. Seems like I didn't fix it in both.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/BrettSheleski/comchap/issues/3#issuecomment-260227251, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuu840MgMCyiKwioAmlhFWt7hdiGxuoks5q97PngaJpZM4Kw3E2.
Take a look at the beginning of the comcut script. It's basically identical to the beginning of the comchap script. I think I did the fix in comcut but not comchap. I believe it had to do with if it processed one command line argument it would skip the next, including filename specification.
I believe the command line argument processing could be copied from comcut as I think it has the fix.
I'm not near a computer for the rest of the day, so if you find the solution, I'm open to accept a pull request.
Come to think of it, I think there's a distinct commit for this exact issue in comcut. You could look at the history of that file and see the solution. My commit messages are shit, so sorry about that.
Well, I was just trying to run it with an input and output filename, no other args, and it "ate" the input filename and said it was processing the output filename as the input filename, which it couldn't open as it didn't exist. I'll look at it later, my mind is mush right now. :)
On Nov 13, 2016, at 7:59 PM, Brett Sheleski notifications@github.com wrote:
Take a look at the beginning of the comcut script. It's basically identical to the beginning of the comchap script. I think I did the fix in comcut but not comchap. I believe it had to do with if it processed one command line argument it would skip the next, including filename specification.
I believe the command line argument processing could be copied from comcut as I think it has the fix.
I'm not near a computer for the rest of the day, so if you find the solution, I'm open to accept a pull request.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/BrettSheleski/comchap/issues/3#issuecomment-260231905, or mute the thread https://github.com/notifications/unsubscribe-auth/AAuu80XuWUkzkERQ6djRWSF8Uq8mHiIWks5q98B7gaJpZM4Kw3E2.
Since my main Arch Linux machine is down at the moment, I spun up an Ubuntu Virtual Machine running 16.04.
I see what the problem is.
Specifying the output file name is something I haven't kept up on testing. It was doing a shift operation after each command line argument regardless if the argument was a 'known' argument or not.
I've added a fix for this. Give it a shot.
New install of Ubuntu, trying this out for the first time, and the script was eating my input file name by trying to process it as a 'key" value and "shift"ing it out. At least it was doing this if I only ran it with a filename, which is what I was trying.
while [[ $# -gt 1 ]] do key="$1" case $key in . . . esac shift # past argument or value done
I wrapped that section in:
if [[ $1 == "--*" ]] then . . . fi
So it would only try that section if a parameter had a -- at the front, and it lets it run. I haven't tried various combinations of with or without parameters/etc... Curious why bash is behaving differently here than it would for you. :(