Opened 18 years ago

Closed 18 years ago

#1237 closed defect (invalid)

commercial flagging does not always occur when it should

Reported by: mythtv.cvs@… Owned by: cpinkham
Priority: minor Milestone: 0.20
Component: mythtv Version: head
Severity: medium Keywords:
Cc: Ticket locked: no

Description

I have recordings that should be commercial flagged, but are not. The flagging simply does not start. When checking in the "upcoming recordings" screen, I can see that it is set to flag commercials as part of the post-recording process, yet it does not. When checking my standard mythbackend logs, I see no mention of the flagging even starting or attempting to start.

After checking the last few days, this has been randomly happening since thge 15th of Jan. at least. It seems to be happening about 1/2 of the time now, and predictably in some cases.

For example, I record back to back MASH recordings at 4pm. In every case, the first recording is never commercial flagged, but the second is. However, back to back showings do not seem to be the only issue, as I have two shows I am recording back to back, with nothing after them.. yet neither are commercial flagged.

Put another way, it seems to be semi-random.

Change History (6)

comment:1 Changed 18 years ago by cpinkham

Milestone: 0.20
Owner: changed from Isaac Richards to cpinkham
Version: head

"semi-random", that's a lot of help....

Maybe you should look at the JobQueue? section of the mythfrontend status page and it might tell you why the jobs haven't run, or if there aren't any jobs, then that might be another clue. If you run mythbackend with "-v jobqueue,commflag" then that would provide even more debugging information. Providing the backend logs as specified above as well as the output of the following SQL command would also be helpful:

select * from jobqueue\G (yes, that's a slash G)

Also indicate which recordings did and did not appear to flag correctly and provide the following SQL output for the mentioned recordings:

select * from recorded where chanid = CHANID and starttime = STARTTIME\G

substituting in the chanid and starttime for the recordings that did and did not work. Perform the query for each recording.

comment:2 Changed 18 years ago by mythtv.cvs@…

The jobqueue via the frontend currently only shows one program, and it was flagged correctly.

In jobqueue via mysql, I only see events that did commercial flag correctly. There is nothing listed there that has not been commercial flagged, put another way, the recordings that didn't flag and should have, are missing from there.

I've run commercial flagging manually on one recording that did not flag, and it flagged correctly. I also did this:

select * from record where autocommflag=0;

and came up with zero matches. I just double checked, and the recording that I just manually ran flagging on, did have it on in scheduled recordings.

I've also upped the logging on my backend, so we'll soon have more information. It will likely be 15+ hours before I can post on this, as I am entering downtime shortly.

comment:3 Changed 18 years ago by anonymous

Here is what I get whenever a recording begins Commercial Flagging, which fails.

2006-02-07 23:01:22.260 Commercial Flagging Starting for Gilmore Girls "A Deep-Fried Korean Thanksgiving" recorded from channel 1017 at Tue Feb 7 16:00:00 2006 2006-02-07 23:01:22.677 Using runtime prefix = /usr/local 2006-02-07 23:01:22.737 New DB connection, total: 1 2006-02-07 23:01:22.761 Connected to database 'mythconverg' at host: localhost 2006-02-07 23:01:22.781 New DB connection, total: 2 2006-02-07 23:01:22.786 Connected to database 'mythconverg' at host: localhost 2006-02-07 23:01:22.794 Could not open 2006-02-07 23:01:23.300 Could not open 2006-02-07 23:01:23.808 Could not open 2006-02-07 23:01:24.316 Could not open 2006-02-07 23:01:24.824 Could not open 2006-02-07 23:01:25.332 Could not open 2006-02-07 23:01:25.840 Could not open 2006-02-07 23:01:26.381 Connecting to backend server: 127.0.0.1:6543 (try 1 of 5) 2006-02-07 23:01:26.401 Using protocol version 26 2006-02-07 23:01:26.412 MainServer::HandleAnnounce? Monitor 2006-02-07 23:01:26.417 adding: dvr.onracine.com as a client (events: 0) 2006-02-07 23:01:26.523 NVP::OpenFile?(): Error, file not found: * glibc detected * /usr/local/bin/mythcommflag: double free or corruption (!prev): 0x09ea2c80 * ======= Backtrace: ========= /lib/libc.so.6[0x14eb124] /lib/libc.so.6(libc_free+0x77)[0x14eb65f] /usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0x5f7b0a9] /usr/local/bin/mythcommflag[0x8054348]

comment:4 Changed 18 years ago by mythtv.cvs@…

Anonymous, this bug is not the same bug I am reporting. Please open a separate bug for this, although Chris on the MythTV dev list posted this for you to check first:

"When was the last time you did a "make distclean" and then recompiled? The only time I've seen something like this is when people haven't recompiled from scratch when they should."

comment:5 Changed 18 years ago by anonymous

This perticular problem (not related to the bug this is listed) was solved by recompiling after distclean, I screwed up. thanks!

comment:6 Changed 18 years ago by mythtv.cvs@…

Resolution: invalid
Status: newclosed

After rebuilding all my database tables, this problem has apparently vanished.

Note: See TracTickets for help on using tickets.