OFark

No worries, I have just pushed a new version that will allow you to choose if you want to copy subtitles or not, plus other data, attachments, metadata, as well as pick a different subtitle encoder. Note on that: be sure about the source files, FFmpeg cannot encode Text to bitmap or visa versa. If you are going to choose a subtitle encoder make sure all your source files can be encoded. Otherwise just choose copy.

I've just pushed a version that should fix the fixed Frame rate issue in a two pass scenario.

So that error: [mp4 @ 0x55572bad8e80] track 1: codec frame size is not set [mp4 @ 0x55572bad8e80] Could not find tag for codec subrip in stream #3, codec not currently supported in container Isn't a problem I can fix. That's basically saying that the file type you've chosen (MP4) doesn't support the subtitle coming from the source. The original file is a Matroska MKV container, and MKV supports a lot more than MP4 does, although MP4 is supported more on older devices, MKV is a lot more universal. I'll do some research into how I can better manage Subtitle options, but for now, if MKV files are the source type, with subtitles, your going to need to keep using MKV.

Does it work with a Same as source option?

8kbits vs 8mbps. Yes I see that confusion. FFmpeg defaults to kbits, hence why I'm using that. I'll make that a bit clearer in the next release. X265, basically, creates the same quality video with less data, because it's using more compressible B-Frames. Which is a massivly over simplified answer, but still valid. FFmpeg is throwing an error: x265 [error]: fps mismatch with 1st pass (1199/50 vs 24/1) [libx265 @ 0x55ecbd2ee900] Cannot open libx265 encoder. 1199/50 is sooooo close to 24/1, but not quite. I'll see what I can do about that but in the mean time, could you try leaving the Framerate option in the FFmpeg preset blank, this will use the existing video's framerate, and see if that works, please? I'll see if I can find some time today to see why it might be doing that, maybe tomorrow.

Ok found it, probably too tired for this but I found it. When using an encoder that doesn't have the pass number built into specific options it wasn't passing through the fact that the first pass was indeed the first pass and no log file was being generated. X265 doesn't have this issue, and I was mostly using that for testing. Ok I guess I must have only been using that for testing, I missed it. So I've fixed it, Docker is currently building it. I'm no expert but countless hours of testing has given me enough experience to offer this advice: 8kbit/s is no where near enough data for anything resembling watchable, unless it's tiny frame size. If your trying to save space I would recommend the following: Remove the bit rate Auto calculate the Quality control Use the "Happy Medium" auto calculation feature with what your willing to accept for compression 60% Compression and 98.5% SSIM is my usual, but it depends on your requirements. Use libx265 encoder, it's soo much better for compression than x264 Software encoding is much better than hardware encoding for quality everyday These are just my recommendations, and I may be completely wrong, due to your requirements. Thank you again for squashing a bug.

Hi, Thanks for the feedback. The encFile.mp4 is created when it encodes the sample. So the sample.mkv is a short sample of the original video and the encfile.mp4 is the result of, or is supposed to be the result of, a test encode with FFmpeg. I assume, as you didn't mention it, there are no FFmpeg errors mentioned in the log? A week or so ago I released a version that should have stepped over any issues creating samples, but it looks like it's falling over in the right place, so to speak. So that error line matches current code base. Honestly I'm surprised it got that far if it didn't actually create any files. I'll add some error checking, and maybe a better error message, in the next version. Though that's probably not going to solve your issue. Have a look in the Logs folder at the log files, see if there's a message from FFmpeg about why it may have failed to encode. If you can't figure it out, send me the latest log file that contains the error and the appsettings.json file from the application root, a screenshot/copy&paste of the options page info at the bottom, and I'll take a look.

Well then from what I've seen it does indeed look like Handbrake isn't using QSV, but I know it works, I've done it myself. What CPU are you running it on?

What encoder are you using in Handbrake?

Have you passed /dev/dri to both? I use QSV in Handbrake just fine.

Well it seems like it's not doing anything hardware. Hardware decoding is next to pointless these days. Very little if any benefit from hardware decoding. Hardware encoding should be eating up quite a bit of GPU resources, but then the quality is never going to be as good as CPU encoding, so I'd leave it as it is.

Support for Sonarr has been release.

Ohh yeah absolutely, software encoding is almost always better. It gets updates where hardware can't.

Ohh yeah, that's my fault. I'm currently working on the Nvidia support branch which has FFmpeg everywhere, the non-Nvidia doesn't. You do have VAAPI enabled and available if it's in the drop down options. Or at least FFmpeg is reporting it's available. Depending on your CPU you may need extra parameters. This, however, I haven't had time to learn just yet, so I can't help you with those right now. If you want to take a look at FFmpeg and Vaapi you maybe able to learn more.

The "File length mismatch" is due to the fact that FFmpeg threw an error and the output file length isn't the same as the input, a very basic check for "did this work", before we proceed. I'm not particularly happy with Xabe's output from FFmpeg errors, there's always a lot of data to plough through to get to the reason. But I cannot see an error in there. It looks like FFmpeg just bailed with no error message. But there something we can do: In the options page make sure the "Insert file names into FFmpeg previews" is on, then go to the Jobs page click the (i) button next to your movie and copy the argument that it creates. Go to the Compressarr Docker, in Unraid, and open it's console. (Click the Icon, select Console) FFmpeg is a global app in the console so just type "ffmpeg" a space and then paste in the arguments that we copied earlier. This should do exactly the same thing that Compressarr was trying to do, and you should get an error. FFmpeg usually prints it at the end in Red, but clues can appear through the output in yellow. If the error isn't obvious, let me know what it says and I'll see if I can help.

Thanks for letting me know and including the log. I have now fixed this and pushed a release. It takes Docker ~20mins to build the latest release.

QSV support is there, if you've passed through /dev/dri. But the options for the QSV encoder are an absolute mess and I haven't put in any time to create a nice UI for them. But you can still just enter the options yourself.

Compressarr Support Links: GitHub Docker Compressarr is an application to take a filtered set of media from Radarr, Sonarr or a folder and process it with customisable FFmpeg presets. It will even attempt to find the best settings for each video. Then you can import the result back into Radarr/Sonarr. Please use GitHub to report any bugs & read the wiki/readme. Please ask any questions here. If someone wants to design a better logo, please, PLEASE, go for it.

It's all good, I've figured it out.

So I know how to use Docker, now I'm trying to build my first Docker app. Code's on GitHub, Repository is on Docker, it auto-builds from my GitHub checkins. But Unraid doesn't recognise that there is an update. What do I have to do, I guess to my Docker image, to get Unraid to recognise a new version?

I've been searching for this for ages, I've found no end of people complaining about this error and getting no response from the community. Perhaps this info could be relayed in the Unraid Log. "Have you left a console window open?"

Good. I could swap this one to XFS, but tbh it's already dead. I'll put in a new one, XFS and hope 6.9 comes out sooner rather than later.

I'm learning a lot here, but from what I can see this relates to a RAD-1 scenario, which I don't have. But yeah, I am seeing everything else.

Just to add my two pence: That's 141TB on a 128GB drive in 296.5 days. Basically the drive is a dead drive walking. 128 GB M.2 NVME in less than a year.

Hi all, A query I have; I have an NVME drive failing SMART because it's passed it's probable amount of data it can store ok. This is an unassigned drive, on it is Docker.img, appdata, libvirt, and my VM images. I have one VM (proxy gateway) that I setup a few weeks ago. I have a dozen Docker images, Plex, and the supporting containers . Nothing that I would consider to be write intensive to itself. I mean, I know Plex will store media files etc, but what I have seems out of the ordinary: Power on time is 296.5 days, less than a year. 141TB??? It's a 128GB drive, 32gb for Docker.img, 90GB used in total. I've done some reading and I know I could over-provision it, but is there something I can check for? Is there someway to identify whats being written so often to the drive so I could move it to rust? I'm thinking of putting a 256GB in there, but if that's not going to last 2 years, it's a costly expenditure.