Don't Autoflag commercials not honored

[km@…]

I'm running the trunk. My default behavior is to have recordings automatically commflagged, and to not run on certain commercial free channels, which works properly. When mythcommflag is run with no options, to pick up any missed recordings, it ignores the commercial free tag for channels.

[Raymond Wagner]

This will be taken care of as part of #7990.

[Raymond Wagner]

Can you confirm this is still a problem? I just attempted to, and was unable to reproduce it.

Please open up mysql and run:

select recordid,title,subtitle,autocommflag from record where autocommflag=0;

to ensure the rule you did not want to run commercial detection was in fact disabled.

[km@…]

It's probably my misunderstanding. Left to its own myth does not flag the programs I've designated for it not to flag. However, if I run mythcommflag with no arguments it does flag them. I guess thats by design, that mythcommflag flags everything not just whats queued.

However, the reality is that when mythcommflag runs the queue it doesn't take much for it to fail on some recording and not run the rest of the queue.

I need some way to run mythcommflag by hand on just the programs queued.

[Raymond Wagner]

So the automatic commercial flagging when something records works properly, but this ticket is reference to the mythcommflag behavior where when given no recording, it blindly operates on all recordings and ignoring that setting?

[km@…]

Yes, thats correct. When I submitted the ticket I expected mythcommflag to honor the setting.

[Github]

Rework ordering of command line processing in mythcommflag. Inputs are no longer processed and stored to temporary variables, as required by the previous command line parser, but are now pulled out of the parser object as needed. The --skipdb parameter now behaves properly.

Fixes #9515

Use with no options is no longer permitted. The old behavior of running all recordings directly is no longer supported. If the --queue parameter is specified alone, it will queue a commercial detection job for any recording that has not been previously flagged, and is not on a commercial free channel. The --force parameter will queue jobs for all recordings, and the --rebuild will queue jobs to instead rebuild the seektables.

Fixes #9152

Branch: master Changeset: baf6105331ffac50f720e57006223486f8071b72

[km@…]

This fix seems to have broken the backends ability to run the queue. It tries to run mythcommflag with no arguments which aborts with a usage message.

[Raymond Wagner]

Read the second paragraph in the above commit log.

[km@…]

"Use with no options is no longer permitted"

Yes, I understand. But that is apparently what the backend is doing, running mythcommflag without options. I'm not running it manually a this point, its the backend periodically running the queue and failing.

[Raymond Wagner]

Do you know what is triggering this? The only time the backend should ever be running mythcommflag is when triggered by the jobqueue. When mythcommflag is run through the jobqueue, it should pass along a jobid with the '-j <id>' parameter.

[km@…]

Right now I go to System Status -> Job Queue. What I see is all recent recordings in RED. I pick one and select re-queue from the gui. It momentarily goes blue but when I refresh its red. Mean time what shows in the log is

2011-07-12 11:00:17.048991 E [16024/26116] Commflag_22241 jobqueue.cpp:2335 (DoFlagCommercialsThread) - JobQueue: Commercial Detection Errored: "The Daily Show With Jon Stewart":"Denis Leary" recorded from channel 3868 at 2011-07-11T23:00:00 (Failed with exit status 132)

I can tell mythcommflag is being called with no args since as a test I briefly put a frontend shell script in front of mythcommflag which prints outs the arguments before execing the binary with those arguments. There are no arguments.

[Raymond Wagner]

The string 'mythcommflag' has special behavior with the jobqueue, in which if you have that defined as your commercial flagger, it will automatically add the proper command line arguments to make it work properly. If instead you specified 'yourscript.sh mythcommflag' as your flagger, you would run exactly that.

If you want to see specifically what command is being run, use the 'system' verbose mode when running mythbackend or mythjobqueue.

[km@…]

I have not changed the commercial flagger string in that experiment. I just renamed /usr/local/bin/mythcommflag to /usr/local/bin/mythcommflag.bin and put a small shell script called /usr/local/bin/mythcommflag that records the args and invokes mythcommflag.bin with them. The backend is unaware of a change.

At any rate even without the script I can tell mythcommflag is being invoked without arguments. In the terminal that started the backend the usage message comes out every time I do a requeue.

[Raymond Wagner]

Could I see the result from...

SELECT data FROM settings WHERE value='JobQueueCommFlagCommand';

[km@…]

SELECT data FROM settings WHERE value='JobQueueCommFlagCommand';

returns

/usr/local/bin/mythcommflag

[Raymond Wagner]

There's the problem, it must be exactly 'mythcommflag', blank, or undefined.

[km@…]

Yes, that was it. I've always had the full path in, but I guess the new mythcommflag parsing showed the issue.