Transconde-video on windows failing to run intermittently #189
Comments
|
Just a correction "Labyrinth 1986" Halt @ 80+% |
|
@eltito51 Thanks for filing this, my friend! I'll let @samhutchins take lead on it since I'm still sick. |
|
No Problems Don, Anything that I can do to make Transcode better is a pleasure. Hopefully I was detailed enough. Cheers |
|
I'm not sure if you're having exactly the same problem that I had or not... The error I sometimes get is Could you install |
|
let me work on that |
Here is the output from MediaInfo |
|
Is that the full output? I don't see any weird characters, so it looks like my hunch may be wrong. I'll keep digging |
|
Sam, I was getting the exact error you describe, only my cause was
Japanese characters in one of the audio track titles. The job would fail
out as it scanned the source file before transcoding started. Took me a
while to discover it was related to the unknown characters, ultimately I
ran it on a Linux/unRAID server and noticed the characters in the audio
track name where I normally saw that error.
On Fri, Jan 19, 2018, at 4:40 PM, Sam Hutchins wrote:
Is that the full output?
I don't see any weird characters, so it looks like my hunch may be
wrong. I'll keep digging> — You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub[1], or mute the
thread[2].>
|
|
Came to the computer to provide more detail. One of the things that struck me as really odd is that the Japanese characters weren't visible in MKVtoolnix or mediainfo, however the audio tracks were coded as Japanese, so it seems that perhaps Handbrake fills in the characters based on the language encoding? The thinking is I wonder if @eltito51 has other language tracks and maybe a surprise umlaut or something equally challenging. Unfortunately I didn't find a good solution, in the interest of time I just carved the audio and subtitles into a separate .mka file and left only the video track in the mkv, which transcoded without trouble. Then I pulled the unconverted audio and subtitles back into the transcoded MKV for a complete file. Not elegant, but functional. Here is a clip of the output where it doesn't fail (unRAID), notice the characters: And here is the complete mediainfo dump, notice that the Japanese audio track (#1) doesn't have the name, only the language is set as Japanese: Video Audio #1 Audio #2 Text #1 Text #2 Menu |
|
@klogg416 I think the best solution for now is to either configure MakeMKV to only rip the audio tracks you want, or to remux with mkvtoolnix to remove everything you don’t want. |
|
Guys, I will keep digging on this on my side. Something that is really weird is that those same movies transcode without any issues under linux mint. |
|
@eltito51 @samhutchins and @klogg416 My apologies for being AFK for so long. I'm feeling a little better today. And my thanks, as always, to Sam for picking up the slack! Reviewing the data so far, it's still unclear whether the problem is in El tito's Windows configuration, HandBrake's handling of his particular movies on Windows (and whether that's metadata-related), or some Windows-specific bug in my code. But at least El tito doesn't have any problems using Linux Mint! That's both heartening and frustrating since that doesn't bring us much close to figuring out what's going on on Windows. Still, I have faith that we will solve this. My only advice for El tito as he continues to dig is to reduce the failure to the simplest possible case. For example, does using |
|
I've installed Further to that, back to the LXSS installation: If I call |
|
Guys, I will keep digging on this on my side. Something that is really weird is that those same movies transcode without any issues under linux mint. |
|
Sam: The fact that some files transcode and some other fail make me agree with you that the issue should be with the Bash on Ubuntu on Windows. I will pursue the native installation as you suggest |
I think I am having a similar problem for one of my movies. For some reason I ripped it with additional audio tracks. It looks like the process is hanging up on the 4th track, which is Spanish. Is there a way to remove that one or do I just need to re-rip? thanks. |
|
@hilldw11 Weird. It appears There's no need to re-rip the video. You can remux it instead using If you give me the console output of |
|
File 'Videos/American_Sniper.mkv': container: Matroska Hopefully this is correct.... thank you |
|
@hilldw11 I also need to know which of those audio tracks is the Spanish one. I'm assuming that's the last audio track? That is, track ID 4? |
|
@donmelton Yes, track 4 is spanish. I just need track 1 for english audio. |
|
@hilldw11 OK, to leave off the last track then do something like this: To just select the English track then do something like this: |
|
@donmelton Thank you, its working now. I appreciate it. perhaps i need to create a separate thread but just a quick question. How do you ensure that |
|
@hilldw11 No problem. That's why I'm almost always online. :) I'm glad it's working. As to your question about I always examine the output of |
|
Sam, The native installation work as a Charm. I have a comment regarding your Instruction: On the other side it look like the native installation is way faster than using the undelaying unbuntu bash system. I do imagine it make sense? I am repeating some other movies to confirm everything work as expected. |
|
@eltito51 Good to hear it's working now! Let us know if the other movies are working too and I think we can close this issue. |
|
@eltito51 No, that Fonts folder is no longer required. I'll update the instructions this week |
|
@donmelton The other movies are transcoding perfectly. I am closing the ticket. |
|
@eltito51, I know this issue is closed, but I wanted to share an alternative solution to the foreign language audio/subtitle tracks issue on Ubuntu for Linux Windows Subsystem: use Debian instead. It does not have this problem. |
|
@sojojo, you got my hopes up! I installed Debain through the Windows store last night, followed Sam's set up guide for WSL, but encountered the exact same error on special characters when transcode-video scans the file. The title that it crashed out while displaying is "Bron. Säsong / Sæson 4 Episode 01 SE DK". It continues to work on a Native install and @ntodd's docker container on unRAID. Out of curiosity, did you do anything beyond setting up the Debain flavour of WSL to increase its character support? Is your Windows region configured as USA? Input #0, matroska,webm, from '../S04E01 - Episode 1 - Bluray-720p.mkv': |
|
I ran into this issue today on the latest Windows 10 and Ubuntu from the store. Seeing that the problem was to do with accented characters in subtitle language names, I first tried setting all subtitle languages to undefined in the source file metadata before transcoding, and that worked. Then wanting to test if it was specifically displaying the characters that was the issue, I tried redirecting STDOUT and STDERR to a file, by appending Sharing this here in case anyone needs a workaround until the underlying issue gets fixed. You lose on-screen feedback, of course, but you can keep an eye on the log file that this gem natively generates. The file from STDOUT isn't very readable. |
|
@vickash Thanks! I'm starting to suspect this might be an issue with parsing the text output of the initial scan from |
|
Yes, it looks like the parsing in Ruby modifies these characters somehow that makes them impossible to display? If I do |
|
@vickash Interesting. This seems like some really weird character encoding problem. |
|
Hey all, this issue has been bugging me for months. I finally got a chance to dig in, and I think I found the problem and have a fix. See #263 for details. |
|
@joshstaiger Awesome detective work, sir! |
|
@joshstaiger Re-opening this because of your fix. Sorry, I forgot to do that yesterday. |
|
@joshstaiger OK, I just took your second patch, #264. I'm going to leave this issue open until the next release and until you, @samhutchins and I can review whether any other code using |
|
@joshstaiger @samhutchins After reviewing all the code tonight, I think the only area we need to look at in depth is the call to Josh, have you seen the same kind of bug using |
|
To be honest, I've never used convert-video before. I'll give it a go on a file that has exhibited the issue when I get home a little later. |
|
@joshstaiger BTW, your buffering patch is so straightforward, that I could see applying it for the call to |
|
Okay, I ran The primary offenders for me have always been language names for audio or subtitle tracks ("español"), and it seems that However, I suppose And in fact, I noticed that |
|
@joshstaiger Very thorough detective work, sir! Thank you so much! Well, that settles it. I'll apply your patch to the |
|
@joshstaiger OK, here's the patch: Let me know if that looks right. And I'm testing it now. |
|
Yep, that looks right! |
|
@joshstaiger And my testing did turn up any problems so I just checked it in. :) Thanks for quick review and coming up with this fix in the first place! I'll leave this issue open until the release goes out next week. |
|
One other thing I'll note for completeness is that the crash seems to be limited to wsl (Windows Subsystem for Linux), which probably explains why it was so hard to track down in the first place. I installed a plain Windows Ruby and video_transcoding setup and it looks like without the buffer patch it merely mangles the multi-byte output ("espa��ol") without crashing, ... and the patch seems to fix the mangling, too, if the Windows Console codepage is set to UTF-8. |
|
@joshstaiger Interesting. So, win-win, then! :) Thank you, again. You will be mentioned in the Release Notes, sir. |
|
@joshstaiger OK, this has now been released in version 0.25.0 of the Gem. Thanks again for all your help! |
Don - Sam, as per our exchange on Tweet I am loading the .log files of my transcoding session this morning on Windows10 (Latest version). Basically Transcode work with some files and halt or refuse to run with others. Those are the same exactly files I have successfully process under the same machine with "Linux Mint". Originally I have the following message:
"/local/bin/transcode-video:transcoding failed: Input/output error @ io_write -
As per Sam suggestion, this morning I try the --dry-run and regardless the file transcode-video halt after scanning the file (No message output) or just halt with the following message:
"/usr/local/bin/transcode-video: scanning failed"
I have a bunch of .MKV movies in a folder and to discard any issues with the "Path" i am copying one by one in an exclusive transcoding working folder within it I run my "Bash" command as per tghe installation instructions. Some files Transcode-video just run fine but some others I have all the above mess. This make me thing that the issue is not related to the installation or the path but most likely some weird issue with the metadada as Sam mention on tweet.
I am attaching the picture of the file folder order i am using to troubleshoot so far the only one that run without any hiccup is the "The Shawshank Redemption 1994" (Log is attached).
From the .MKV folder I try 6 movies and 2 were completed without issues. (Number 4-6). I repeat number 4 and Transcode halt after 80+%
The Shawshank Redemption 1994.log
The Belko Experiment 2016.log
Labyrinth 1986.log
I hope the information is helpful to fix the bug or If you guys believe I am doing something wrong your help is highly appreciated.
The text was updated successfully, but these errors were encountered: