[Solved] Variablies for jobs and job failure

Have a MythTV related problem? Ask for help from other MythTV users here.

Moderator: Forum Moderators

Post Reply
MTXRooster
Newcomer
Posts: 13
Joined: Sun Apr 22, 2018 9:53 pm
United States of America

[Solved] Variablies for jobs and job failure

Post by MTXRooster »

Hey all, as the topic says, I'm looking for the variable that is associated to the tv show name. I want this for naming transcoded (comm_ripped) videos.

I'm making a job to strip the commercials out, using the cutlists already generated, but every attempt fails. (not sure why exactly, will post what I have), but one thing I'm having problems with is the output name. I want it to be the TV Show name and the originalairdate (for looking up season/episode info manually). I don't use the fancy paid service, so I don't get any of that data/detail, just the show names and description. Below is a sample of result I get in my log:

Code: Select all

Apr 22 16:49:49 MythBuntu1 mythbackend: mythbackend[1316]: I UserJob_687 jobqueue.cpp:2410 (DoUserJobThread) JobQueue: Started Transcode withnocomm for "Fresh Off the Boat" recorded from channel 1151 at 2018-03-14T02:30:00Z
Apr 22 16:49:49 MythBuntu1 mythbackend: mythbackend[1316]: E UserJob_687 jobqueue.cpp:2445 (DoUserJobThread) JobQueue: User Job '/sammy/transcoded/mythtranscode --chanid 1151 --starttime 20180313193000 --mpeg2 --honorcutlist --verbose all --logpath /sammy/xcode.log --outfile "Fresh Off the Boat__nocomm.mpg"' failed.
I used %TITLE% after randomly trying several options which leaves the show title, including spaces, in the title. I'm not a linux expert but I've been using it for years (google is my friend), but I know linux doesn't like spaces the way MS OS's tolerate them. I used quotes around the desired name, which worked in that it did put the title there, but it fails for no known reason. Despite the verbose setting to all, it told me literally nothing, the exact same as it did when I didn't use a verbose option. (ugh) So one question is will that work for sure and properly doing it like that or should I not use %TITLE% quoted, or is there another variable for title that will use underscores instead of spaces?

I tried using - (single dash) options, eg -o filename, job failed. I tried using -- (doubledash) eg --outfile, job failed (for ALL options not just the outfile).
I tried not using a variable for the outfile name (eg -o transcoded.mpg), job failed.
I added --logpath line to see if mythtranscode would generate it's own log separate of the main mythtv-backend log.. no file/log created.


I KNOW the line is right - I do it manually all the time (looking to do a lot less typing especially of chanid's and starttime/filenames, lol) and I use the exact same routine, WITHOUT the variables all the time, to the same folder etc.. ...and it always works. I don't understand (partially because it doesn't give me any reason; in client GUI actually give a bit more, albeit useless to me info, stating under statistics/job queue "ERROR: User Job returned non-zero, check logs. There perhaps another log out there?

What am I doing wrong for what should be something super easy to do? :(

Thanks in advance,

Rooster
User avatar
bill6502
Developer
Posts: 2323
Joined: Fri Feb 07, 2014 5:28 pm
United States of America

Re: Variablies for jobs and job failure

Post by bill6502 »

"%TITLE%" is correct. But you pass that to your own User Job.
If that's the only parameter passed, the it will appear as argument
1 ($1). mythtranscode isn't aware of the percent parameters.
Your script would then call mythtranscode.

-v system is all you need for this. --logpath someDirectory will
put the log in that directory.
MTXRooster
Newcomer
Posts: 13
Joined: Sun Apr 22, 2018 9:53 pm
United States of America

Re: Variablies for jobs and job failure

Post by MTXRooster »

I have a brief update.. I copied the command as it wrote it up above and tried using that. I got more infomation! It errors saying it can't find the recording for that channel and @ (time). So then I noticed something..
MYTHTV is for some reason putting in wrong dates in the file names.
Example:
This particular show is Fresh off the Boat. The show was recored (aired) on March 13th, 2018. (aka 0313). Now mythtv passes on this seemingly correct information, as snipped here from above "--chanid 1151 --starttime 20180313193000" (channel 1151 is correct, as is the date code).
BUT...
On the actual drive, the file is named "1151_20180314023000.ts"!!!! It has a file date properly of 03/13/2018, but mythtv is using one day ahead in the actual file name! Because of this, I am certain that's why my jobs are failing.
How can I fix this? Why is the date wrong on them? Looking through, they are ALL wrong, not just this particular show. Never noticed it when I was doing it manually, as I just used the file name as it sat and never really paid attention to the creation date vs file name.. Help?
MTXRooster
Newcomer
Posts: 13
Joined: Sun Apr 22, 2018 9:53 pm
United States of America

Re: Variablies for jobs and job failure

Post by MTXRooster »

bill6502 wrote:
Mon Apr 23, 2018 12:26 am
"%TITLE%" is correct. But you pass that to your own User Job.
If that's the only parameter passed, the it will appear as argument
1 ($1). mythtranscode isn't aware of the percent parameters.
Your script would then call mythtranscode.

-v system is all you need for this. --logpath someDirectory will
put the log in that directory.
I use this in my backend job settings: /sammy/transcoded/mythtranscode --chanid %CHANID% --starttime %STARTTIME% --mpeg2 --honorcutlist --verbose all --logpath /sammy/xcode.log --outfile "%TITLE%_%ORIGINALAIRDATE%_nocomm.mpg"
I don't run a special script, just the one command, so it does properly pass all the variables just fine. Still not sure why it's not making a log since I have it set up, but as my other recent post indicates I think I found the problem, just don't know how to fix it. (the date in files not matching)
User avatar
bill6502
Developer
Posts: 2323
Joined: Fri Feb 07, 2014 5:28 pm
United States of America

Re: Variablies for jobs and job failure

Post by bill6502 »

Filename times are in UTC. I assume you've been reading
https://www.mythtv.org/wiki/User_Jobs#U ... _arguments

Make sure the user asking for the log has write permission in the
chosen directory, which is typically /var/log/mythtv (but can be
wherever you like.)

Note that --logpath is a directory, not a file.
MTXRooster
Newcomer
Posts: 13
Joined: Sun Apr 22, 2018 9:53 pm
United States of America

Re: Variablies for jobs and job failure

Post by MTXRooster »

bill6502 wrote:
Mon Apr 23, 2018 12:38 am
Filename times are in UTC. I assume you've been reading
https://www.mythtv.org/wiki/User_Jobs#U ... _arguments

Make sure the user asking for the log has write permission in the
chosen directory, which is typically /var/log/mythtv (but can be
wherever you like.)

Note that --logpath is a directory, not a file.
Yes, that's the source of my variables :)
As far as UTC.. Is there a setting for mythtranscode to use UTC?
Because as I mentioned, the filename is "1151_20180314023000.ts" but the %STARTTIME% is throwing "20180313193000" in, which is my local time. The shows airs on Tuesdays at 7:30PM (in this case, here, March 13th at 1930 hours, or 0313193000. But it isn't going to find a show by that "filename" because mythtv saved it as 0314023000.
Not sure what to do about that?
I mean, I'm sure for everything up till today, I'm going to have to do them manually, because there is no going back in time fix to correct this, but I'd like to stop it from naming them incorrectly or whatever the issue may be?
User avatar
bill6502
Developer
Posts: 2323
Joined: Fri Feb 07, 2014 5:28 pm
United States of America

Re: Variablies for jobs and job failure

Post by bill6502 »

There's nothing to correct. The filenames are in UTC by
design.

I'd use %STARTTIMEUTC%, here are some examples
for the same recording:

Code: Select all

2018-04-22 08:59:30             STARTTIME = 20180422090000
2018-04-22 08:59:30          STARTTIMEISO = 2018-04-22T09:00:00
2018-04-22 08:59:30       STARTTIMEISOUTC = 2018-04-22T14:00:00Z
2018-04-22 08:59:30          STARTTIMEUTC = 20180422140000
MTXRooster
Newcomer
Posts: 13
Joined: Sun Apr 22, 2018 9:53 pm
United States of America

Re: Variablies for jobs and job failure

Post by MTXRooster »

Think I got it - Partially from a subtle hint about my source of variables.. Noticed there was a starttimeutc on there, rofl :)

Also changed it and moved the path I wanted to save it to the outfile area, as it seemed it wanted to look for mythtranscode at that spot and would tell me it couldn't find that file there. (which ironically it didn't do when it couldn't find the proper file to transcode lol).

This leaves me with one question remaining.. Is there any way to get the %ORIGINALAIRDATE% to work as well? is there another variable I may be missing instead of that one (it doesn't put anything in place of that variable) meaning --outfile "%TITLE%_%ORIGINALAIRDATE%_nocomm.mpg" results in "Fresh off the boat__nocomm.mpg" instead of "Fresh off the boat_03132018_nocomm.mpg".
I suppose I could try using the %STARTTIME% that started my problems, as it DOES use the correct time. I need the date on there so I know when the episode aired so I can edit the name later (after I convert to mkv lower res) and add season and episode to the show name :)

Eh, doesn't matter - Used STARTTIME in the filename, works perfectly fine! 100% as expected, can't thank you enough, bill6502 for your help!
And in case someone is reading this later wondering why I don't just use one of the fancier scripts out there instead of one command-line job, first off it's easier to manage, and more importantly my particular backend is running on an (((OLD))) Core 2 Duo rig I had laying around. It records 2 shows just fine, but would literally (I imagine) take forever and likely bog the system down causing file issues if I were to try running handbrake transcoding a show whilst possibly recording 2 other shows! Someday I'll be able to upgrade it and do it all on one machine (can't wait, honestly), till then the commercial stripped original res files get copied to a much more capable rip for that job, then to a plex server for permanent sitting/future viewing enjoyment!
User avatar
bill6502
Developer
Posts: 2323
Joined: Fri Feb 07, 2014 5:28 pm
United States of America

Re: Variablies for jobs and job failure

Post by bill6502 »

I should have cited this too: https://www.mythtv.org/wiki/UTC

The originalairdate in the database is stored in local time,
no conversion is available.

I wouldn't recommend using %ORIGINALAIRDATE% for part of the
filename. If a single show recorded multiple times on the same day,
the previous files would be overwritten (it's just the date, no time.)

If you're not using a service, then that field is most likely empty. You
can prove that from your favorite browser with:

yourBackendHostNameOrIP:6544/Dvr/GetRecordedList

Look for AirDate.
MTXRooster
Newcomer
Posts: 13
Joined: Sun Apr 22, 2018 9:53 pm
United States of America

Re: [Solved] Variablies for jobs and job failure

Post by MTXRooster »

You're correct, my airdates are all blank

That would absolutely explain why it wasn't putting anything in for %ORIGINALAIRDATE% as you mention EIT data wouldn't grab that.
While the transferring files to another machines and conversion to a different resolution/format still take time, this process has become a breeze getting the commercials stripped out, and works fairly well. Once in awhile a patch remain, which I don't mind (and could edit out later), but so far it's never been the reverse where I've lost a chunk of show. And now with it working as a job, I don't have to go through the annoying task of 'finding' the files.. I used to fire up the client, pull up my recorded shows folder, look at the date of an episode and what channel it was on, then start looking for channelID filenames, then (usually) files dated one day newer than they aired and were recorded, and then type all that into the terminal for mythtranscode.. Every time (well I'd arrow up and backspace edit what I entered previously. It worked, but took so much time!
I'm even thinking of having it do this step automatically after it's recorded a couple times and seeing whether this older system can handle it without upsetting other possible recordings.

Again, thanks so much for helping me out, I cannot thank you enough!
Post Reply