Opened 13 years ago
Closed 13 years ago
Last modified 13 years ago
#9152 closed defect (fixed)
Don't Autoflag commercials not honored
Reported by: | 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 )
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 13 years ago by
Owner: | set to cpinkham |
---|---|
Status: | new → assigned |
comment:2 Changed 13 years ago by
Owner: | changed from cpinkham to Raymond Wagner |
---|---|
Status: | assigned → accepted |
comment:3 Changed 13 years ago by
Status: | accepted → infoneeded |
---|
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 13 years ago by
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 13 years ago by
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 13 years ago by
Yes, thats correct. When I submitted the ticket I expected mythcommflag to honor the setting.
comment:7 Changed 13 years ago by
Description: | modified (diff) |
---|---|
Milestone: | unknown → 0.25 |
Status: | infoneeded → assigned |
comment:8 Changed 13 years ago by
Component: | MythTV - General → MythTV - Mythcommflag |
---|---|
Status: | assigned → accepted |
comment:9 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
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 13 years ago by
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:12 Changed 13 years ago by
"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 13 years ago by
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 13 years ago by
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 13 years ago by
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.
comment:16 Changed 13 years ago by
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 13 years ago by
Could I see the result from...
SELECT data FROM settings WHERE value='JobQueueCommFlagCommand';
comment:18 Changed 13 years ago by
SELECT data FROM settings WHERE value='JobQueueCommFlagCommand?';
returns
/usr/local/bin/mythcommflag
comment:19 Changed 13 years ago by
There's the problem, it must be exactly 'mythcommflag', blank, or undefined.
comment:20 Changed 13 years ago by
Yes, that was it. I've always had the full path in, but I guess the new mythcommflag parsing showed the issue.
This will be taken care of as part of #7990.