This project has moved and is read-only. For the latest updates, please go here.

Handbrake Burn Subtitle SRT not Found

Jan 2, 2015 at 9:15 AM
Edited Jan 2, 2015 at 9:17 AM
Hey, first off thanks so much for all the work you do, this program while a little tricky to set up properly for my needs is amazing and a lifesaver. Now on the issue I've noticed with the new version 2.4.1:

It seems that when the CLI command is generated and passed to handbrake, it sets the SRT location to something like ex. "C:\Samples\Test_1.srt". The issue occurs that handbrake reads this as C:SamplesTest_1.srt when it gets to the part where it tries to find and start burning the subtitle.

I've run a few tests through the GUI (viewing activity log) and manually against the command line (also looked online here) and discovered that the directory needs to be escaped as __"C:\Samples\Test_1.srt"__ in order for it to be properly passed and located.

Pretty sure its technically a bug, let me know if you need logs (I know its standard but issue seems easily reproducible and seems like it just needs and adjustment in your code, not sure about that just assuming since I can't find the exact spot where it generates the commands)

Also it seems that the encoder (even through latest GUI handbrake) fails with quick sync not enough sync points and not enough resources if the qsv preset is set higher than balanced. I'm currently on 3960 the latest version and have tried about 6 different versions of the graphics driver, even the recommended one (forgot the version).
Jan 2, 2015 at 2:18 PM
Yes please can you attach a link to the log. We haven't seen any issues with the burning so the log will help to isolate/replicate it.

For the qsv encoding, are you using a custom profile/settings or the default one?
Jan 2, 2015 at 7:29 PM
OK I uploaded 2 logs for 2 different files here, although it seems to happen with any subtitle files.

Also I worked off the original MP4 High Profile and edited some values, then when I was happy I looked at the logs and copied and copied the values that MCEBuddy edited for the hardware encoding. Here's my profile:
[TV Shows]
Description=Convert TV Shows to a compatiable Chromecast format for streaming to Plex.
order=handbrake
handbrake-general=--denoise="weak" --loose-anamorphic --verbose=2 -T -f mp4 -O 
handbrake-video=--start-at duration:0 -e qsv_h264 -q 22 --h264-level 4.2 -x tu=2:trellis=2:ref=4:keyint=-1:b-pyramid=1:la-depth=1 --crop 0:0:0:0
handbrake-audio=-E faac -R auto -B 200 -D 2.5 -a 1,2,3,4,5 -6 stereo
handbrake-audioac3=-E faac -R auto -B 200 -D 2.5 -a 1,2,3,4,5 -6 stereo
handbrake-ext=.mp4
handbrake-audiodelay=skip
handbrake-AudioOptimized=true
handbrake-VideoOptimized=true
handbrake-UsingHardwareEncoding=true
PreConversionCommercialRemover=false
2ChannelAudio=true
FixedResolution=true
SkipCropping=true
SubtitleBurn=true
PostCustomCommandPath=C:\Python27\python.exe
PostCustomCommandParameters=""C:\Users\Media Server\Scripts\MCEBuddy\Process TV Shows.py" "%convertedfile%""
PostCustomCommandHangPeriod=
PostCustomCommandCritical=true
PostCustomCommandUISession=false
PostCustomCommandShowWindow=false
I want all my videos to go through hardware encoding and just fail it runs into an issue related to the video itself.

And sorry for seeming like I'm telling you how to update your program, lack of sleep just makes me talkative.
Jan 3, 2015 at 7:34 AM
Ok did some extensive testing and tried a few things. First off I had permissions issues on some of the folders and fixed those now so I'm sure that is not the issue. Then tried running MCEBuddy and the issue persisted again, failed conversion. Then copied MCEBuddy generated handbrake command and placed files where they were supposed to go (never realized Mcebuddy copied the srt file to the conversion directory) and tried running the command from the command line calling the handbrake cli from the command prompt. The conversion failed again saying it could not find the srt file. Then I tried double backslashing the passed argument for the SRT file to be burned and IT WORKED!!! WOOHOO!!! It seems like this is the issue, srt file location argument seems to be the only time that it needs to be "\" for some reason.

Let me know what you see when you go through the logs, and what ever else you need or tests you need.
Jan 3, 2015 at 3:06 PM
Thanks for reporting this, we've fixed in the today's BETA build 2.4.2 which will be up on the server in the next few hours.
Marked as answer by rboy1 on 1/3/2015 at 7:06 AM
Jan 3, 2015 at 3:12 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.