Difference between revisions of "Talk:Handbrake userjob"

Latest revision as of 19:02, 27 August 2013

I'm on gentoo, mythbackend is started as root, so this user job will run as root as well.

What? No it isn't. The stock init script for Gentoo setuids to the mythtv user account. wagnerrp 06:43, 9 May 2012 (UTC)

You are right. I will correct this. - reznor

Detecting already running

On my system (mythtv 0.25, ubuntu 12.04), user jobs are launching as `sh -c /opt/myth_make_x264.pl...` and there is another entry in `ps aux` for the resultant perl process. The script finds that shell process as another entry and thinks there is another script running. I modified to the below, which seems to work:

 my $curProcs = `ps aux | grep $scriptName | grep -v grep | grep -v "sh -c" | wc -l`;

This is my first user job, so maybe I've done something strange...but I don't think so. Bygottski 05:42, 31 May 2012 (UTC)

I'm not really sure what the intended purpose of that code is anyway. The jobqueue has an internal task limit that will prevent too many instances from being run simultaneously. I don't know why the script would need its own semaphore. wagnerrp 07:57, 31 May 2012 (UTC)

The purpose for this is limiting handbrake encoding jobs. Handbrake by default utilizes all cpu cores of the system for encoding. This code is intended to prevent heavy load on all cores by limiting simultaneous handbrake encoding jobs. I think there has been a handbrake command line switch to limit cpu core usage which is gone. Another approach would be using cpulimit. - reznor

Yes. Why do you need to limit simultaneous encoding jobs within the script? The jobqueue already does that, with a maximum number of simultaneous jobs it will run per host, defaulting to one, and configurable in mythtv-setup. Once that limit has been reached, it will not start a new task until a previous one has terminated. wagnerrp 17:23, 31 May 2012 (UTC)

Handbrake only supports threads when the encoder itself supports threads. Threading parameters must be passed directly into the encoder with that '-x' argument you use for the encoding options. By default, x264 will use 1.5x the number of logical CPUs on your system, meaning hyperthreaded is counted. You can adjust this by adding a 'threads=<n>' parameter into your encoding options. wagnerrp 17:23, 31 May 2012 (UTC)

Nice! I will update the script asap. Thanks for your investigation! - reznor

reznor, do you play on implementing this? also, I'm thinking about a command line option to skip the mythtranscode commercial cutting for recordings in which the user does not trust mythcommflag, thoughts? --Steve Adeff 19:02, 17 March 2013 (UTC)

Sorry for not answering a long time! I actually saw your post on gossamer-threads if I'm still active -- Yes, I am .. but I didn't had time or forgot to edit my entry here when there was time to do so :( I'm really sorry! I updated the script today on the wiki to what I currently have. It's not as clean as I wish, but is doing its' job reliably. -- Regards, reznor

Differing mythtranscode audio track info

Running mythtranscode on an mpeg2 file created by my Hauppauge WinTV PVR-250 gives me the following audio track info:

2013-02-19 13:44:25 INFO Selecting audio track 1: Language: 2013-02-19 13:43:51.043493 I Stream #0.2[0x1c0]: Audio: mp2, 48000 Hz, 2 channels, s16, 384 kb/s, Channels: 2 Bitrate: 256 kbit/s

Obviously, the mkvmerge command doesn't like seeing a date where the language info should be. To get the script to work I removed the $mkvmergeAudio variable from the $output line. Admittedly this is a big kludge, but unfortunately my scripting skills are not up to tinkering with the lines that create the $language variable.

mythtranscode changed its output, so now mediainfo collects this data and things should be ok again - reznor