[mythtv-users] remote display from frontend

[Ross Boylan]

Thank you, Mark Boyum, for the tip about the sound.  I'm not sure what I
need to do to make the changes take effect; the configuration file is
called daemon.conf, but I don't see a pulse daemon on /etc/init.d.

On pulse: the system did not have it installed initially--and I didn't get
any sound.  After I installed it I did get sound.  I can think of 3 reasons
this might have happened:
1) installing pulse caused the installation of missing parts of the sound
system, like alsa;
2) VirtualBox needs pulse to make sound available on the host system;
3) Since my host is using pulse, the virtual machine needs to as well.

I know there were a lot of complaints about pulse a few years ago, but I
thought most of the kinks had been worked out.

On the resizing issue, what I was thinking of was being able to grab and
resize the window myth is displaying in.  Does "Use GUI size for playback"
do that?

Some of the argument against specifying settings on the command line seems
to be that myth will then ignore it if you attempt to reset the values.
That seems like very non-standard behavior.  If I specify the geometry for
an application that doesn't prevent me from changing it later in most
applications.

Ross

On Tue, Oct 27, 2015 at 10:58 AM, Michael T. Dean <mtdean at thirdcontact.com>
wrote:

> On 10/27/2015 01:28 PM, Eric Sharkey wrote:
>
>> On Tue, Oct 27, 2015 at 1:03 PM, Michael T. Dean  wrote:
>>
>>> If you really want command-line changes to your settings, you'd actually
>>> be
>>> better off using the services API to change the setting then start
>>> mythfrontend.
>>>
>> In what way would I be better off?  It appears to be working perfectly
>> for me for the last 10 years, and is far far simpler (and thus I
>> consider it to be much more reliable).
>>
>
> You'd be better off because you're not actively disabling/breaking
> MythTV's mechanism for setting the window size.
>
> Overrides are not meant to be used during normal usage.  They're meant to
>>> override broken settings to allow you to get into settings and fix your
>>> system.
>>>
>> Your point of view.
>>
>
> No, this is based on the design of MythTV.  Settings are meant to be
> changeable.  Any override will actively override any changes.  By
> hard-coding in a window size, you will make it very confusing for anyone
> who ever tries to change the window size using the Appearance settings.
>
> Now, if you're the only one using your system or if you forbid you family
> members from ever touching anything in settings, then perhaps no one has
> been confused on your system, yet.  But there have been a /lot/ of threads
> and even bug reports that said that various settings were not working when
> some user had a start command that overrode that setting.
>
> If you really think you're better off using an override, feel free to
> continue, but when you suggest others do so, please make sure you also
> intercept all their future questions about, "Why won't my screen size
> change?" so no one else has to waste time with a lot of back and forth to
> figure out that the answer is due to a hard-coded -geometry override in
> some long-forgotten startup command line got from an e-mail long ago.
>
> By specifying an override, you must know (and remember for as long as
> you're using that override) that the override is in place to understand why
> changes to that setting don't work.  To understand why a command-line
> override that actively ignores settings changes is a bad idea, search
> through the archives (and the Internet in general) to see all the
> discussions about specifying DPI in X and how changes don't work (due, in
> no small part, to some particular distro(s) hard-coding a -dpi override on
> the X server command line and, therefore, ignoring all configuration
> specified in the X config file).
>
> The entire concept that this should be a database setting is broken.
>> It should be a per-window property.
>>
>
> It's not a "database setting."  It's a per-host setting that just happens
> to be stored in the database, rather than storing it in a file on the
> host.  How do you propose we make it a per-window property--and, I assume,
> that MythTV remembers it--without our storing it somewhere?  We simply
> store settings in the database so that they're network accessible--meaning
> you can start up the frontend with that profile identifier on any system on
> your network (also making it easy to resume with the same settings after
> you upgrade your host OS or whatever).
>
> Mike
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20151027/a8605d32/attachment.html>