[mythtv] Major commflag problems with current CVS

[Chris Pinkham]

> No offense Chris, but, again, is there a reason you didn't use the
> same method that I used for the transcoder?  It deals with all of
> these issues already (use a stack to only process files that are
> specifically asked for, and has built in rate processing.  Plus it
> would make it easier to deal with the cndition where both commercial
> flagging and transcoding are specified.
> 
> It just seems like reinventing the wheel to use seperate code for this.

Deja vu, I think I replied to this question by you before.
I don't think I've reinvented anything because there's no queuing going on
right now.  I still think that the best way is to have some form of job
processor that handles both transcoding and commercial flagging (and maybe
that's just modifications to the current transcoding process to handle
commercial flagging as well.  Whether the two are merged or not, a lot of
the changes I've made recently would have to be made in order to get more
intelligent handling of jobs, so I don't see it as wasted effort on my
part.  I haven't delved into the transcoding queueing code yet so I don't
know what will be involved to reuse/merge code.  If a new merged job processor
job is put into place, then my current code will just queue up jobs there
rather than firing off threads itself.  There's only 250 lines of code in
mythbackend/commercialflag.cpp so I don't see that as too much reinvention.
It's rather simple actually.  I think my recent changes have been more about
trying to get the right jobs started than dealing with an intelligent
queueing system.

-- 

Chris