We love simple solutions to problems, and this falls into that category.
A Reddit user has posted a pair of scripts to switch between two displays (a monitor and a TV) in Ubuntu 12.04, but these should be usable in many other versions of Linux as well. He writes:
I currently have a 40″ TV on HDMI (we’ll call this HDMI) and a 22″ monitor (DVI). I don’t want to dual screen these, I simply want one on at a time.
After a bit of difficulty at the start, this is what he came up with.
To switch the monitor off and the TV on:
#!/bin/bash
xrandr --output DVI --off
xrandr --output HDMI --auto
exit
To switch the TV off and the monitor on:
#!/bin/bash
xrandr --output HDMI --off
xrandr --output DVI --auto
exit
Be sure to make the scripts executable before running them.
It appears that in July, 2015 and again in January, 2018 some changes were made to the program (and its associated service) mentioned below. Zap2it changed the format and operation of their listings service, forcing some changes in the way zap2xml operates. If you have previously set up zap2xml, you may need to re-download the software and set it up from scratch. See this article for some additional information, and also the page for the software (as linked below) may provide more up-to-date information. Also, I’ve removed a reference to a program that used to be free, but for all practical purposes no longer is.
It seems that if you live in the U.S.A., the MythTV people would really like to entice you to pay for a subscription-based TV listings service, but not everyone will do that. So, if you don’t want to pay, how do you populate your TV schedule grid with program information?
The easiest and most unquestionably legal way to do it is to simply grab the listing from the TV transmitters themselves. Almost all digital TV channels transmit schedule information, and to use it you simply need to make sure that on the MythTV backend, under Video Sources, the Listings grabber is set to Transmitted Guide Only (EIT).
The downside of this is that you will only get schedule information for a limited time, typically 1-3 days out from your current date. So, you won’t be able to schedule a program a week in advance. And another thing that might bother some users is that it will cause MythTV to operate your tuners continuously, because MythTV apparently constantly scans the channels for new EIT data (see this discussion in the HDHomeRun forum).
The other way is to use an external program such as zap2xml (Zap2it TV listings to XMLTV or XTVD .xml). In this case you set the MythTV backend Listings grabber setting to “No grabber” and use the zap2xml software to grab the listings and populate the database. The people who profit by selling the TV listings service don’t much like it if you do that, and therefore their proponents try to spread FUD (Fear-Uncertainty-Doubt) about the legality of doing this, but as a practical matter we highly doubt anyone will ever get in trouble for obtaining TV listings this way, and no one has up to this point, to the best of our knowledge. However, if you choose to use this method just be aware that there might be a cloud over the legality of doing so, at least if you believe the supporters of the commercial service. The larger concern is that someday this service will stop working, but that could happen with the pay service also.
Note that people who live outside the U.S.A. have no choice other than to use either the transmitted guide data or a free service, since the pay service only includes U.S. listings.
Generally it is a two step process: You first run zap2xml to generate the required xmltv.xml file, then run mythfilldatabase (with appropriate options) to import the xmltv.xml file into the MythTV backend.
When you run mythfilldatabase, if you see error messages that include the phrase “Unknown xmltv channel identifier”, this means you need to open the xmltv.xml file in a text viewer or editor and find the channel id for each channel. Then go into the MythTV backend channel editor. For each channel there is an XMLTV ID field. You will need to place the correct channel id from the XML file (the entire string between the quotation marks) into the corresponding XML ID field, then select Next and (on the next screen) Finish, and you will need to do this for each channel. If you do this correctly, the “Unknown xmltv channel identifier” errors should disappear the next time your run mythfilldatabase.
EDIT: After this article was published, we discovered an additional similar program called WebGrab+Plus. It is described as follows: “WebGrab+Plus is a multi-site incremental xmltv epg grabber. It collects tv-program guide data from selected tvguide sites for your favourite channels.” There are some installation hints for WebGrab+Plus here. We have not attempted to install or use WebGrab+Plus, but just wanted to note that this possible alternative exists.
If you know of any other ways to get free TV schedule information for MythTV, please feel free to share in the comments. But if you simply want to debate the legality of the alternatives, please don’t bother – as the title of the blog implies, these are simply technical notes, and not a forum for endless debates over whether something should or should not be done, and we will probably just delete any comments that don’t add to the technical knowledge presented here.
Although many Ubuntu users seem to hate the Unity Launcher in the most recent versions of Ubuntu, some folks are thinking that it might make a great program launcher for use with a LIRC-compatible remote control, if only the remote could actually navigate the launcher. While no one seems to have brought this idea entirely to fruition, there are apparently ways to make it mostly work:
If you are running a RPM-compatible version of Linux that uses YUM to install software, this is for you:
Yesterday, I had a situation where a colleague experienced an issue that caused loss of audio and it seems that one of the updates which had just finished installing may have been the culprit.
Here’s where YUM shines bright and I thought I’d share a feature with you that will definitely be of help at some point. It’s the yum history feature.
It just so happens that yum while performing updates is simultaneously running a journal transaction set recording your update to a transaction id along with all of the excruciatingly painful package update and dependency information you’d ever want to know. Most of the time, you’ll never care about it. In some situations however, you may encounter a post-update problem.
The good news with yum is you have a recourse. If you need to or at the direction of your Distro’s technical support team, you may be called upon to perform a rollback.
See this thread on the PBX in a Flash forum. You may need to be logged in to download the script. It appears it may work with any recent Asterisk installation, not just with PBX in a Flash installations.
There are two ways to enable a SOCKS5 proxy at startup in Ubuntu. For either to work, you must have previously configured ssh public/private key authentication, so make sure that works and that you can do a “normal” ssh login without entering a password. Note that the second method described below is better because it is persistent – if the connection goes down, it will attempt to reconnect automatically.
Method 1 (Ubuntu and similar versions of Linux only):
I’ll briefly show the first method, but keep in mind that if the ssh connection is lost, it will not automatically reconnect.
First install screen from the standard repository if you have not done so already, and change the permissions of /run/screen to 775.
In Ubuntu’s Startup Applications Preferences, add this command, replacing the italicized parts with the correct values:
“tunnel” can be any word you like, “username” is your account name on the remote server, “server_address” is the address of the remote server, and “local_socks_proxy_port” is the port number your local software will use when connecting to the SOCKS proxy (7777 is a frequently-used choice).
Ubuntu users, first go into the Ubuntu Software Center and search for autossh (other Linux users, check your repository for the autossh package):
If you click “More Info” you can read the description:
Go ahead and install it, and after installation it will show you which programs can be run:
Mac OS X users, there is an autossh package for recent versions of OS X among the Rudix packages. Be sure to select your version of OS X in the left-hand sidebar, then download the autossh package for your version of OS X and then click on the downloaded package to run the installer:
Click Continue and you will see an “Important Information” screen, the text of which is copied to the bottom of this article in case you want to review it. Note that you do NOT need to do the build procedure shown there; you just continue the installation as you would any other OS X software you have downloaded.
Whether you are installing in Linux or OS X, after you complete the installation the next thing to do is open a terminal window and run autossh manually one time. Remember, you must have previously configured ssh public/private key authentication for this to work. The reason for running autossh manually the first time is that a window will pop up asking you to approve the connection and accept the RSA key. So open a terminal window and run a line of this form:
Ubuntu: autossh -f -N username@server_address -D local_socks_proxy_port Mac OS X: autossh -M 0 username@server_address -D local_socks_proxy_port
As in the first method, “username” is your account name on the remote server, “server_address” is the address of the remote server, and “local_socks_proxy_port” is the port number your local software will use when connecting to the SOCKS proxy (7777 is a frequently-used choice, but it can be any unused port numbered 1080 or above). If the popup appears asking you to approve the connection, answer “yes”, and that should be the last time you see that dialog (unless, perhaps, some drastic changes are made at the server).
Note that under OS X, we could not get the -f option to work, even though it’s supposed to. When we tried to use it, no ssh connection was opened (as determined by watching Activity Monitor). So, unfortunately, you will need to leave a terminal or iTerm window open with autossh running in it, unless you can figure out some way to make backgrounding it work. This was in OS X Lion; perhaps the -f option works in other versions. Feel free to experiment.
After running autossh from a terminal window, open your browser and make sure the SOCKS proxy works. How you configure it will vary by browser. For example, under Firefox you’d open the Preferences pane, select Advanced, click the Network tab, and then click the Settings button. In the window that opens you’d select Manual Proxy Configuration, then for SOCKS Host you can use localhost, and for Port the local_socks_proxy_port number you set when you started autossh. Select SOCKS v5 as the proxy type. In the “No Proxy for:” window, enter some sane values for your network — generally these will include your local machine and other addresses on your local network. For example (assuming your local network addresses are in the 192.168.x.x range):
localhost, 127.0.0.1, 192.168.0.0/16
In Google Chrome you can use an extension such as Proxy SwitchySharp to configure your proxy settings.
After saving those settings, go to a site that will show you the IP address that it thinks you are coming in from, such as http://ipchicken.com/ – make sure that the address it shows is that of the system you are using for your proxy, and not your local address.
Once you are sure it is working, in Ubuntu you can open Ubuntu’s Startup Applications Preferences and add the same line you typed in the terminal window.
Under OS X it’s a little more complicated. If you use iTerm, you could create a Profile (similar to a bookmark) and for the command use the same command you used in the terminal window, but specify the full path to autossh, e.g.:
Name your profile something meaningful, and make sure that when you click on the profile in the sidebar to runs autossh and opens the connection. The use the AppleScript Editor to build a script that will start iTerm and open the profile. Your script could look something like this:
tell application "iTerm"
activate
tell the current terminal
launch session "Profile_name"
delay 3
tell the last session
set name to "Profile_name - SOCKS proxy using autossh"
end tell
end tell
end tell
Substitute the name you gave the profile for the two occurrences of Profile_name in the sample script. Compile the AppleScript and when it compiles with no errors, save it as an Application. Make sure it works as intended (starts up iTerm and loads the Profile that runs autossh), then simply set that application to run at startup (Under System Preferences | Users & Groups | (select current user) | Login Items).
Now your SOCKS5 proxy should start up each time you reboot your system, and if the tunnel goes down it should reconnect within a few minutes. To learn more about autossh, open a terminal window and type man autossh, or see any of these articles (note that some of them overly complicate the process of setting up the tunnel):
autossh is a program to start a copy of ssh and monitor it, restarting
it as necessary should it die or stop passing traffic.
The original idea and the mechanism were from rstunnel (Reliable SSH
Tunnel). With version 1.2 the method changed: autossh now uses ssh to
construct a loop of ssh forwardings (one from local to remote, one
from remote to local), and then sends test data that it expects to get
back. (The idea is thanks to Terrence Martin.)
With version 1.3, a new method is added (thanks to Ron Yorston): a
port may be specified for a remote echo service that will echo back
the test data. This avoids the congestion and the aggravation of
making sure all the port numbers on the remote machine do not
collide. The loop-of -forwardings method remains available for
situations where using an echo service may not be possible.
autossh has only three arguments of its own:
-M [:echo_port], to specify the base monitoring port to use, or
alternatively, to specify the monitoring port and echo service
port to use.
When no echo service port is specified, this port and the port
immediately above it (port# + 1) should be something nothing
else is using. autossh will send test data on the base monitoring
port, and receive it back on the port above. For example, if you
specify "-M 20000", autossh will set up forwards so that it can
send data on port 20000 and receive it back on 20001.
Alternatively a port for a remote echo service may be
specified. This should be port 7 if you wish to use the
standard inetd echo service. When an echo port is specified,
only the specified monitor port is used, and it carries the
monitor message in both directions.
Many people disable the echo service, or even disable inetd,
so check that this service is available on the remote
machine. Some operating systems allow one to specify that the
service only listen on the localhost (loopback interface),
which would suffice for this use.
The echo service may also be something more complicated:
perhaps a daemon that monitors a group of ssh tunnels.
-M 0 will turn the monitoring off, and autossh will only
restart ssh on ssh exit.
For example, if you are using a recent version of OpenSSH, you
may wish to explore using the ServerAliveInterval and
ServerAliveCountMax options to have the SSH client exit if it
finds itself no longer connected to the server. In many ways
this may be a better solution than the monitoring port.
-f Causes autossh to drop to the background before running ssh. The
-f flag is stripped from arguments passed to ssh. Note that there
is a crucial a difference between the -f with autossh, and -f
with ssh: when used with autossh, ssh will be *unable* to ask for
passwords or passphrases. When -f is used, the "starting gate"
time (see AUTOSSH_GATETIME) will be set to 0.
-V to have autossh display its version and exit.
All other arguments are passed to ssh. There are a number of
other settings, but these are all controlled through environment
variables. ssh seems to be appropriating more and more letters for
options, and this seems the easiest way to avoid collisions.
autossh tries to distinguish the manner of death of the ssh process it
is monitoring and act appropriately. The rules are:
- If the ssh process exited normally (for example, someone typed
"exit" in an interactive session), autossh exits rather than
restarting;
- If autossh itself receives a SIGTERM, SIGINT, or a SIGKILL
signal, it assumes that it was deliberately signalled, and exits
after killing the child ssh process;
- If autossh itself receives a SIGUSR1 signal, it will kill the child
ssh process and start a new one;
- Periodically (by default every 10 minutes), autossh attempts to pass
traffic on the monitor forwarded port. If this fails, autossh will
kill the child ssh process (if it is still running) and start a new
one;
- If the child ssh process dies for any other reason, autossh will
attempt to start a new one.
Startup behaviour:
- If the ssh session fails with an exit status of 1 on the very first
try, autossh will assume that there is some problem with syntax or
the connection setup, and will exit rather than retrying;
- There is now a "starting gate" time. If the first ssh process fails
within the first few seconds of being started, autossh assumes that
it never made it "out of the starting gate", and exits. This is to handle
initial failed authentication, connection, etc. This time is 30 seconds
by default, and can be adjusted (see the AUTOSSH_GATETIME environment
variable below).
- NOTE: If AUTOSSH_GATETIME is set to 0, then BOTH of the above
behaviours are disabled. This is useful for, for example,
having autossh start on boot. The "starting gate" time is
also set to 0 with the -f flag to autossh is used.
Continued failures:
- If the ssh connection fails and attempts to restart it fail in
quick succession, autossh will start delaying its attempts to
restart, gradually backing farther and farther off up to a
maximum interval of the autossh poll time (usually 10 minutes).
autossh can be "prodded" to retry by signalling it, perhaps with
SIGHUP ("kill -HUP").
Connection Setup
----------------
As connections must be established unattended, the use of autossh
requires that some form of automatic authentication be set up. The use
of RSAAuthentication with ssh-agent is the recommended method. The
example wrapper script attempts to check if there is an agent running
for the current environment, and to start one if there isn't.
It cannot be stressed enough that you must make sure ssh works on its
own, that you can set up the session you want before you try to
run it under autossh.
If you are tunnelling and using an older version of ssh that does not
support the -N flag, you should upgrade (your version has security
flaws). If you can't upgrade, you may wish to do as rstunnel does, and
give ssh a command to run, such as "sleep 99999999999".
A monitor port value of "0" ("autossh -M 0") will disable use of
the monitor ports; autossh will then only react to signals and the
death of the ssh process.
Environment Variables
---------------------
The following environment variables can be set:
AUTOSSH_DEBUG - sets logging level to LOG_DEBUG, and if
the operating system supports it, sets
syslog to duplicate log entries to stderr.
AUTOSSH_FIRST_POLL - time to initial poll (default is as
AUTOSSH_POLL below).
AUTOSSH_GATETIME - how long ssh must be up before we consider
it a successful connection. Default is 30
seconds. If set to 0, then this behaviour
is disabled, and as well, autossh will retry
even on failure of first attempt to run ssh.
AUTOSSH_LOGFILE - sets autossh to use the named log file,
rather than syslog.
AUTOSSH_LOGLEVEL - log level, they correspond to the levels
used by syslog; so 0-7 with 7 being the
chattiest.
AUTOSSH_MAXLIFETIME - Sets the maximum number of seconds the process
should live for before killing off the ssh child
and exiting.
AUTOSSH_MAXSTART - specifies how many times ssh should be started.
A negative number means no limit on the number
of times ssh is started. The default value is -1.
AUTOSSH_MESSAGE - append a custom message to the echo string (max 64
bytes).
AUTOSSH_NTSERVICE - when set to "yes" , setup autossh to run as an
NT service under cygrunsrv. This adds the -N flag
for ssh if not already set, sets the log output
to stdout, and changes the behaviour on ssh exit
so that it will restart even on a normal exit.
AUTOSSH_PATH - path to the ssh executable, in case
it is different than that compiled in.
AUTOSSH_PIDFILE - write autossh pid to specified file.
AUTOSSH_POLL - poll time in seconds; default is 600.
If the poll time is less than twice the
network timeouts (default 15 seconds) the
network timeouts will be adjusted downward
to 1/2 the poll time.
AUTOSSH_PORT - set monitor port. Mostly in case ssh
appropriates -M at some time. But because
of this possible use, AUTOSSH_PORT overrides
the -M flag.
Logging and Syslog
------------------
autossh logs to syslog using the LOG_USER facility. Your syslog may
have to be configured to accept messages for this facility. This is
usually done in /etc/syslog.conf.
A page on the Asterisk Wiki entitled Calling using Google contains this bit of information about priorities:
More about Priorities
As many different connections to Google are possible simultaneously via different client mechanisms, it is important to understand the role of priorities in the routing of inbound calls. Proper usage of the priority setting can allow use of a Google account that is not otherwise entirely dedicated to voice services.
With priorities, the higher the setting value, the more any client using that value is preferred as a destination for inbound calls, in deference to any other client with a lower priority value. Known values of commonly used clients include the Gmail chat client, which maintains a priority of 20, and the Windows GTalk client, which uses a priority of 24. The maximum allowable value is 127. Thus, setting one’s priority option for the XMPP peer in res_xmpp.conf to a value higher than 24 will cause inbound calls to flow to Asterisk, even while one is logged into either Gmail or the Windows GTalk client.
Outbound calls are unaffected by the priority setting.
Therefore, if you are not receiving some incoming Google Voice calls, check to make sure that your priority= statement in the configuration is set to at least 25.
Monit is a free open source and very useful tool that automatically monitors and manages server process, files, directories, checksums, permissions, filesystems and services like Apache, Nginx, MySQL, FTP, SSH, Sendmail and so on in a UNIX/Linux based systems and provides an excellent and helpful monitoring functionality to system administrators.
The monit has user friendly web interface where you can directly view the system status and setup up processes using native HTTP(S) web server or via the command line interface. This means you must have web server like Apache or Nginx installed on your system to access and view monit web interface.
Probably the easiest way to get a MythTV installation up and running quickly is to install Mythbuntu or Mythdora, depending on whether you prefer the Ubuntu or Fedora variant of Linux. But if you want a bit more hands-on experience, or additional help with configuration, these links might be helpful:
From a Reddit thread:
I’ve been a fan of MythTV for some time, but found that there were very few comprehensive setup guides out there for new users. So, I decided to write one. It’s split into 4 parts (shown below) and covers not just how to set up a MythTV system, but also makes an effort to explain why certain instructions are given along the way.
Don’t forget about the MythTV Wiki. But be aware that if you live in the United States, much of the “official” MythTV documentation will try to push you into paying for a subscription TV schedule service. If you live elsewhere, they are forced to admit there are other alternatives, which there are for U.S. residents as well — yet for some reason they try really hard to push the subscription service to U.S. users.
Build the ultimate media system with your HTPC using OpenELEC, XBMC and PseudoTV. This manual covers everything from hardware, OpenELEC Installation, File Management, XBMC Scraping, Preparing an awesome channel setup and also covers PseudoTV extensively. This is the definitive guide for HP ProLiant MicroServer owners or anyone who wants to turn their HTPC into a media dream-machine. Easy to understand and scattered with loads of helpful hints and tips.
This guide is a must-have for all PseudoTV users!
Included with the PDF is a wide variety of nifty files and tools that is also explained in the guide.
Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here:
Cookie Policy
Recent Comments