Sorry to bother you guys again. I got the original script (not cayars) working on my host Plex system (2013 iMac) locally. My storage drives are connected externally via Thunderbolt 2. It’s working fine. However, to save the host CPU (i5) I would like to use this (cayars) script from another PC on my network. I have a state of the art windows 10 PC on the network with the new Skywell i7 @ 4ghz and would love to run cayars custom script from it. I’ve mapped these external drives to this PC. For example, I’ve mapped one of the drives to: \192.168.1.240\j and on that drive I have a folder called “TV Animated”. I don’t want to run this script locally, because moving all of the files to your “process” folder and then moving them out of the “converter” folders would just be way to much hassle. I would just like to point the program to the correct folder: \J\TV Animated" or whatever and have them convert the files in place. Is this possible?
In my attempt, I’ve changed the autoProcess.ini file option "output_directory = ". Now when I run manual.py it prompts me to “Enter path to file:” but whenever I try to enter the network drive path in, I get the error: “File xxx is not in the correct format”.
Any guidance would be greatly appreciated. I want to offload this work from my host Plex server onto this much more powerful and stagnant PC that’s on my local network.
Just noticed something with your script that the other one isn’t doing. It’s renaming all my files and appending “(2)” at the end. For example, it’s taking “Little Bear - S03E01 - Owl’s Dilemma.avi” and creating a “Little Bear - S03E01 - Owl’s Dilemma(2).mp4” when it’s done. Why is it doing this?
@cayars said:
Not a problem to do that. Actually the VERY BEST THING you can do is to instruct ffmpeg to only use 1 thread at a time with the “-thread 1” option.
By doing this you will get better compression as all routines use the same thread. Since you have 4 cores you could then run 4 separate conversions at the same time each with the 1 thread option.
HOWEVER, what I would not do is run it with the default “-thread 0” option which tell it to use all core while running multiple conversions which will give you degraded compression.
Granted this isn’t a big deal and we’re not talking more than 3% difference, but if you plan on running multiple and are going to do this to your whole library you might as well do it “right”. I can tell you how to do it or I can provide you with an update to a file that will do this for you if interested. Just PM me.
Carlo
Hi Carlo, can you explain how I would do this exactly? Right now, I’m starting manual.py on a seperate PC on my network and pointing it to a directory, ie: "J:\Movies" . So to do the above, would I just do “J:\Movies\ -thread 1” or do I change autoProcess.ini setting to: “ffmpeg = ffmpeg.exe -thread 1” or is this a setting somewhere else in your scripts I need to change?
@shpankey said:
Just noticed something with your script that the other one isn’t doing. It’s renaming all my files and appending “(2)” at the end. For example, it’s taking “Little Bear - S03E01 - Owl’s Dilemma.avi” and creating a “Little Bear - S03E01 - Owl’s Dilemma(2).mp4” when it’s done. Why is it doing this?
Are you writing it to the same directory it is found in? If it’s an MP4 extension it can’t overwrite what it’s reading from so you may get the (2). If the file was an MKV, AVi or any other extension it won’t need to do this.
Ok, that’s probably it then. I don’t remember the extension it had, so it was probably an .mp4 to begin with. This explains why it’s not doing it on all of them. I had a lot of .mp4’s already so that explains it.
Any chance you can write a script that looks for any .mp4 files with (2) in it and rename them stripping it from the title?
I can probably do it myself on the host iMac system… it has some kind of Script Automator program that’s pretty simple to create stuff like that, I’m just not very good with it myself. But I could probably fumble my way through it if I had no other choice.
@shpankey said:
Ok, that’s probably it then. I don’t remember the extension it had, so it was probably an .mp4 to begin with. This explains why it’s not doing it on all of them. I had a lot of .mp4’s already so that explains it.
Any chance you can write a script that looks for any .mp4 files with (2) in it and rename them stripping it from the title?
I can probably do it myself on the host iMac system… it has some kind of Script Automator program that’s pretty simple to create stuff like that, I’m just not very good with it myself. But I could probably fumble my way through it if I had no other choice.
p.s Carlo, I know you were talking about a version 2 re-write… might be a nice option to add to deal with that. You could do it like you do now, then once you delete the original, go back and rename the .mp4 that was just created, stripping the (2) out of its name. Then move on to the next file. Not sure if that would be hard to do or not, just throwing it out there. Not that I’m complaining, but I know programmers/devs like you like to hear about requests.
Ok, got the single thread method working. Question, running 4 of these simultaneously on my networked PC, is my network speed going to come into play? Both the host Plex iMac and this PC are wired via cat 6 on an ASUS 3200. I don’t know if this will saturate the connection or cause any issues?
Depends on the file you are processing. You can tell yourself. Just open up resource manager and check to see if you are network or CPU constrained.
Personally, I would copy the file down to the PC before processing it. Nothing worse than being 99% done a file to have a network issue and loose everything you’ve just spent an hour or more working on. Either way you still need to read/write the same amount of traffic so I’d prefer to do it safely.
Nah, that’s too much extra work. It’s been processing them in place just fine w/o issues.
Anyhow, yeah, looks like this pegged the Ethernet. Before, CPU was ~95 - 100%… now it’s 4 - 8% and Ethernet at the max transfer speed my network can do.
Dang, this sucks. I guess I’ll go back to the multi-threaded way. How big a difference does this single thread method make in quality?
cayars, one big issue for me I just thought of… DTS. I have a lot of content w/ DTS and I would like your script to skip over .mkv files w/ DTS tracks in them, for obvious reasons. Any way to customize this to do that?
@cayars I’m curious - have you adopted ffmpeg v3 yet?
I have a similar script that I wrote myself a couple of years ago (though not as sophisticated as yours), and when I dropped in v3 I found that, for the exact same CLI parameters, the conversion seems to be much slower.
Unfortunately I haven’t had chance to properly investigate why this might be, so was wondering if you (or anybody else) has had the same experience?
Interesting… I changed out cayars ffmpeg for a new one I just built. Will be interested if this is still the case and why… perhaps it’s doing better compression?
Getting this error now: An unexpected error occurred, processing of this file has failed
‘charmap’ codec can’t decode byte 0x9d in position 5586: character maps to < undefined >
Just in case you’re wondering, I put your FFMPEG back in, still the same error.
@shpankey said:
Nah, that’s too much extra work. It’s been processing them in place just fine w/o issues.
Anyhow, yeah, looks like this pegged the Ethernet. Before, CPU was ~95 - 100%… now it’s 4 - 8% and Ethernet at the max transfer speed my network can do.
Dang, this sucks. I guess I’ll go back to the multi-threaded way. How big a difference does this single thread method make in quality?
You can copy a file down while one is being processed having a queue ready to go. This way Ethernet doesn’t matter much.
@shpankey said:
Interesting… I changed out cayars ffmpeg for a new one I just built. Will be interested if this is still the case and why… perhaps it’s doing better compression?
I routinely upgrade to the latest ffmpeg as well. I probably should update the ZIP file more often so it contains the latest version.
@shpankey said:
Getting this error now: An unexpected error occurred, processing of this file has failed
‘charmap’ codec can’t decode byte 0x9d in position 5586: character maps to < undefined >
Just in case you’re wondering, I put your FFMPEG back in, still the same error.
Most likely a unicode issue. The python scrips could use a upgrade in this department. If the file has asian chars in it that will normally do it.
You can copy a file down while one is being processed having a queue ready to go. This way Ethernet doesn’t matter much.
How would I go about doing that in some automated fashion? That’s the thing, I am just setting this and letting it run… going over a library as big as your own… so this is something that will run for weeks.
I have a similar script that I wrote myself a couple of years ago (though not as sophisticated as yours), and when I dropped in v3 I found that, for the exact same CLI parameters, the conversion seems to be much slower.
Unfortunately I haven’t had chance to properly investigate why this might be, so was wondering if you (or anybody else) has had the same experience?
Well, just did some informal testing and you’re right. With the very latest ffmpeg, it is quite a bit slower than with the ones cayars has. Not sure what’s up with that, but it’s very noticeable, just guessing it is roughly twice as fast w/ his.
