Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#9152 closed defect (fixed)

Don't Autoflag commercials not honored

Reported by: km@… Owned by: Raymond Wagner
Priority: minor Milestone: 0.25
Component: MythTV - Mythcommflag Version: Master Head
Severity: medium Keywords:
Cc: Ticket locked: no

Description (last modified by Raymond Wagner)

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.

Change History (20)

comment:1 Changed 11 years ago by robertm

Owner: set to cpinkham
Status: newassigned

comment:2 Changed 10 years ago by Raymond Wagner

Owner: changed from cpinkham to Raymond Wagner
Status: assignedaccepted

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

comment:3 Changed 10 years ago by Raymond Wagner

Status: acceptedinfoneeded

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.

comment:4 Changed 10 years ago by 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.

comment:5 Changed 10 years ago by 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?

comment:6 Changed 10 years ago by km@…

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

comment:7 Changed 10 years ago by Raymond Wagner

Description: modified (diff)
Milestone: unknown0.25
Status: infoneededassigned

comment:8 Changed 10 years ago by Raymond Wagner

Component: MythTV - GeneralMythTV - Mythcommflag
Status: assignedaccepted

comment:9 Changed 10 years ago by Github

Resolution: fixed
Status: acceptedclosed

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

comment:10 Changed 10 years ago by 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.

comment:11 Changed 10 years ago by Raymond Wagner

Read the second paragraph in the above commit log.

comment:12 Changed 10 years ago by 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.

comment:13 Changed 10 years ago by 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.

comment:14 Changed 10 years ago by 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.

comment:15 Changed 10 years ago by 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 ' 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.

comment:16 Changed 10 years ago by 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.

comment:17 Changed 10 years ago by Raymond Wagner

Could I see the result from...

SELECT data FROM settings WHERE value='JobQueueCommFlagCommand';

comment:18 Changed 10 years ago by km@…

SELECT data FROM settings WHERE value='JobQueueCommFlagCommand?';



comment:19 Changed 10 years ago by Raymond Wagner

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

comment:20 Changed 10 years ago by km@…

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

Note: See TracTickets for help on using tickets.