[mythtv-users] User Job fails.

Fri Jan 15 03:35:32 UTC 2016

> On 15 Jan 2016, at 6:37 am, A. F. Cano <afc at shibaya.lonestar.org> wrote:
> 
>> On Thu, Jan 14, 2016 at 07:12:32PM +1030, Mark Perkins wrote:
>> 
>>> On 14 Jan 2016, at 1:34 pm, A. F. Cano <afc at shibaya.lonestar.org> wrote:
>>> 
>>> Hello everyone,
>>> 
>>> I've set up a frontend on an underpowered machine that can't keep up with HD,
>>> so I've tried to set up "UserJob1" to try to do automatically what I've been
>>> doing from the command line:
>>> 
>>> nice -n 20 mythffmpeg -i <file>.mpg -target ntsc-dvd <file>SD.mpg
>>> 
>>> This gets cumbersome fast trying to figure out what files go with what shows,
>>> so I set up UserJob1  ("Convert to SD") to execute this (in mythtv-setup):
>>> 
>>> mythffmpeg -i %FILE% -target ntsc-dvd %FILE%
>> 
>> I haven't tried this but I doubt it will work as input file and output file
>> are the same file. If it did / does note that it will destroy the original
> 
> That had occurred to me, so I also tried:
> 
> mythffmpeg -i %FILE% -target ntsc-dvd %FILE%SD
> 
> With the predictable result of the output file name being
> 1253_20160113180000.mpgSD but it also failed with the same message.

Yes, that would be my assumption. You will need to additionally specify paths to files (input and output) most likely via %DIR% or else hard coded if input / output path is reliably known and consistent ahead of time (ie only 1 recording directory and 1 output directory).
> 
>> file. Also I assume when you are running your command from the command line
>> you change directory to the correct recording directory first, I don't know
> 
> Correct.
> 
>> what directory is used as the current directory for myth scripts but I doubt
>> it will be the correct recording directory so you will need to incorporate
>> the %DIR% parameter into your myth command line. Finally it is different to
>> the line you are using top as it does not have the addition of 'SD'. Oh you
> 
> The thinking was that since I checked "keep the original file", myth
> would take care of the renaming, as well as whatever else it might need
> to know about the new SD recording to be able to handle it like any
> other recording.  Maybe I was assuming too much.

Short answer - no. With user jobs myth doesn't assume to know your commands purpose. It may be transcoding but could just as likely be commercial detection, email notifications or literally anything you could imagine. If it can be done by script, it can be launched by a myth user job. So while MythTV will manage the queue aspects, when it comes to your specific command it won't check beyond the return states of succeeded (0), did not succeed (not 0), or did not finish (I think housekeeping will try to restart the job after it has been running approx 24hrs). Outside of the queue mechanics, the responsibility rests entirely with your script.

At the risk of greatly, greatly oversimplifying, my understanding is mythffmpeg is mostly just ffmpeg with 'tweaks' to get it to play nicely with MythTV. So it handles media files / codecs / containers / transcoding / repacking very well but doesn't really 'care' about all the other stuff that MythTV does.

If you want to respect MythTV options like "keep the original file" you would need to use mythtranscode via the inbuilt transcoding function, otherwise you would need to write your script to query the setting from MythTV and respond accordingly.

> 
>> may need to double check mythffmpeg is located in your system path but I
>> think it should be.
> 
> It's in /usr/bin/
> 
>> My suggestion would be to create a basic script that takes the %FILE% as
>> input and does the sed (or equivalent for your preferred script language)
>> conversion to create the desired command line. I imagine it should only
>> be a few lines long.
> 
> Absent a more native way of doing this, I'll probably try that.  I am
> concerned, though, that doing this in a detailed script is doing it
> outside of myth and thus how will myth handle the new transcoded video?

The short answer is that MythTV won't, unless you specifically write your script to handle all the database aspects manually which will be both complicated and put you firmly in officially unsupported territory; - or put the resulting file(s) into a directory within the mythvideo storage group which would be the supported path.

The crux of the issue in my mind is maintaining two versions of a single recording inside MythTV recording screens. The database is created with the premise that each recording is essentially unique. I'm not saying it can't be done, just that if it is not done correctly with care you may do a LOT of damage.

Most transcode scripts around work by moving (or deleting) the original file and creating the new transcoded file in its place. But only a single entry in MythTV. Other than rebuilding the seek table and redoing commercial skipping (which need to be handled by the script although it is little more than calling mythutil with switches), MythTV is left more-or-less unaware that anything has changed.

> 
>> Although to be honest, I bet one of the bash script experts on this list
>> could write the whole script on a single line to put direct into myth but
>> I'm no expert so I would need to figure it out and test it. Maybe one of
>> them will chime in.
>> 
>>> 
>>> The menu entry appears in the jobs menu and running it starts the process
>>> (I also checked "keep the original file" so I still would have the original HD
>>> version) but when the backend finally starts the job I get this:
>>> 
>>> I JobQueue: Started Convert to SD for 'POTUS 2016 with Brian Lehrer" recorded from channel 1253 at 2016-01-13T10:00:00Z
>>> I Starting process manager
>>> I Starting IO manager (read)
>>> I Starting process signal handler
>>> I Staring IO manager (write)
>>> E JobQueue: User job 'mythffmpeg -i 1253_20160113180000.mpg -target ntsc-dvd 1353_20160113180000.mpg' failed.
>> 
>> This is interesting. The input and output are different file names
>> (different channel number 1253 versus 1353). I'm not sure how that has
>> come to be.
> 
> That's probably my typo.  I copied this manually from one screen to another.
> The computer on which the backend is running is different from the one
> I'm writing these emails on.
> 
>>> 
>>> What am I doing wrong?  My guess is that the command line is somehow not
>>> correct.
>>> 
>>> Ideally I would like the transcoded SD video to appear in the frontend screen
>>> next to the original so I can watch it, delete it or do any other action to
>>> it.  The most likely outcome is that I would watch the SD video, delete it
>>> and either delete the HD version or mark it as watched.
>>> 
>>> How can I achieve this?
>> 
>> Not easily and not in a supported way. The recommendation I think would be
>> to give both the original and new SD version files a name that was parseable
>> by mythvideo and move into a video storage group if you wanted to maintain
>> both a HD and SD version of the same recording.
> 
> Having no clue as to how to do that, can anyone chime in with the
> details?

Check the wiki for full details of what mythvideo can / cannot do but in short it is a way of making non myth files available inside MythTV - in a fashion. Two key points - firstly files through mythvideo appear in the mythvideo screens not the recording screens and are handled 100% separately to recordings; secondly there is no ongoing linkage between the recording metadata and the mythvideo metadata. For example if you watch something that you pushed to mythvideo from your recordings it won't mark it as watched in the recording screens.

In my opinion your simplest option will be to keep the original recording as is and create a script to transcode a SD version into a mythvideo directory. The challenge will be to script the creation of the new file name in such a way that mythvideo can reliably parse it with minimal or no manual intervention. If you ask others might chime in with their scripts but I don't have anything suitable. Otherwise the script mythlink.pl may be a good place to start. Note that this option will depend heavily on the quality of the metadata that you are getting from your guide provider, see some of the recent Plex threads for others having file naming troubles.

Alternatively is there anything that can be done to allow your FE to play HD? There are some great results being achieved on Raspberry Pi, what FE hardware do you have?