[mythtv-users] Question on channel record removal

David Engel david at istwok.net
Wed Dec 4 20:46:06 UTC 2013


On Wed, Dec 04, 2013 at 03:23:48PM -0500, Tom Dexter wrote:
> I'm currently on 0.25.3 and will have to upgrade soon, as the Gentoo
> ebuilds for 0.25.3 are scheduled for removal.
> 
> Until today I wasn't aware of the removal of the channel record option
> and it's replacement with a filter in 0.27.  I use almost nothing but

Don't believe everything you read/hear here.  There are a lot of
low-information users out there.  Hint, it's still easy to create
rules that only record on a single channel.

> channel record for this reason:  I live between New York and Philly
> and can get both areas if I turn my antenna.  I watch New York almost
> exclusively, but do occasionally turn the antenna to see an NFL game
> out of Philly for example.  As a result I have all the Philly network
> channels in my database, but they under normal circumstances they of
> course won't come in.  For that reason I've always used he channel
> record on the New York stations.
> 
> I leave those Philly channels set with "visible" off.  Is that visible
> flag used in scheduling in any way?  My guess is that it isn't, and
> I'll have to use filters.

Only "visible" channles can be recorded.

> Another unrelated question:  I'm still deciding as to whether I want
> to upgrade to 0.26 or 0.27 right now.  I have a lot of concerns about
> things I've seen in passing about mythlogserver issues.  First of all
> I wanted to be clear on where all that stands.  Also, when the release
> notes talk about mythlogserver being "optional", what exactly does
> that mean?  If you don't run mythlogserver do you get any logging at
> all, and if so, is it just to the console?

mythlogserver was(is) a separate daemon that got spawne automatically
to collect log entries from the various MythTV processes and write
them to disk, save them to the database, or whatever.  The benefit of
having the logs handled in a separate process was you wouldn't lose
the last, possibly important, log messages from a process that dies
suddenly.  For most users, having a separate mythlogserver process was
more trouble than it was worth, so the logging was changed to be done
"in-process" by default.

David
-- 
David Engel
david at istwok.net


More information about the mythtv-users mailing list