User:SredniV

From MythTV Official Wiki
Jump to: navigation, search

I've been using MythTV since late 2003 when I put together my first system using Myth 0.12/0.13. Since then, I've upgraded my frontend and backend a couple of times resulting in the following setup:

Hardware

Frontends

Mac mini (2009 version)

This system works well on it's own, but using the current mythbuntu patches for VDPAU, it's running very nicely. There have been no major problems with this system, and it's been a workhorse for playing back HD content.

Zotac ZBox (ID-41)

This is a new system just introduced. It's running Mythbuntu and was pretty brainless to set up.

Minor Tweaks
Network @ Boot

I did find that I needed to set eth0 to start at boot rather than when the user logged in. It starting at login wasn't working well because it wasn't getting a DHCP response fast enough, and mythfrontend was starting up before the network interface was ready. This got it to think that it was an initial setup and yielded a poor user experience. Starting the interface at boot makes it much happier.

Added to /etc/network/interfaces:

auto eth0
iface eth0 inet dhcp
Prevent 802.11

I also blacklisted the 802.11 wireless modules so they wouldn't load. When the system resumed, there was an annoying popup from Network Manager that the WIFI wasn't connected.

Created /etc/modprobe.d/blacklist-wifi.conf:

blacklist ath9k
blacklist mac80211
blacklist ath9k_common
blacklist ath9k_hw
blacklist ath
blacklist cfg80211
Sound

I output sound over HDMI direct to the TV. I found that ALSA:hdmi:CARD=NVidia,DEV=1 was the sound device I was looking for to make this work.

Suspend/Resume

There was also some amount of wrestling to get suspend/resume working. See the notes below.

AppleTV 1

(Running Mythbuntu 8.04)

This system has been retired. It was never able to play HD content by itself, and even with the added power of the Crystal HD decoder board, it still couldn't live up to expectations. It doesn't even run XBMC very well. The setup was pretty much as described for the atv-bootloader pages.


Backend

The backend is a Mythbuntu virtual machine running under Mac OSX on a Mac mini (2010 version). All of my tuners are network or USB based, so this ends up working very well. I don't do any commercial flagging on the backend, it's reserved only for core backend tasks. Commercial flagging happens on the Mac mini frontend, or on a desktop OSX system that runs MythJobQueue.app. The OSX system is a quad-core Intel Core I7 box with tons of RAM, and commercial flagging happens very, very quickly with no noticeable impact.

Here are some details:

  • ReadyNAS Ultra 6 - 6x 2.0TB drives for storage, configured to with X-RAID2 (dual redundancy) providing approximately 8TB storage.
  • Mac mini has 8GB memory, backend VM has 3GB assigned to it
  • HDHomeRun
  • APC BH500NET for battery backup and remote power port control of DCT-3200, HDHomeRun, and HD-PVR
  • APC SmartUPS 1000 for battery backup of server
  • Added soon will be a HDHomeRun Prime
  • Retired:
* Hauppauge HD-PVR
* Motorola DCT-3200 via FireWire (See notes below for how channel changes are handled)

Notes

Suspend/Resume on ZBox

There were a couple things that needed to be done to make suspend/resume work properly. The information below is gleaned from a variety of web pages spread across time and space...

Allow wakeup events to be received from the remote via the IR sensor

In /etc/rc.local:

echo "USB0" > /proc/acpi/wakeup
echo "USB1" > /proc/acpi/wakeup
echo "USB2" > /proc/acpi/wakeup
echo "USB3" > /proc/acpi/wakeup

IRDEV=`grep -i topseed /sys/bus/usb/devices/*/manufacturer | cut -d/ -f 6`
echo "enabled" > /sys/bus/usb/devices/$IRDEV/power/wakeup

(Yes, it's overkill to allow wakeup events from all the USB[0-3] busses, but I didn't want to figure out which was the right one.)

Create a lirc rule

You need a lirc rule to pass key presses of the power button on the remote to irexec and have it run a script to suspend the system:

~/.lirc/irexec:

begin
	remote = mceusb
	prog = irexec
	button = KEY_POWER
	config = /home/mythuser/scripts/suspend.sh
end

Note that I got hung up for quite a while on this part. You (obviously) need to make sure that you specify the right value for button and remote. Luckily, the output of irw shows you both of these.

Create the script that will suspend the box

~/scripts/suspend.sh:

#!/bin/sh

LOG="/var/log/mythtv/suspend.log"

export DISPLAY=:0.0

size=`ls -l $LOG | awk '{print $5}'`

if [ $size -gt 10240 ]
then
        mv $LOG $LOG.prev
fi

date=`date`

echo "$date : Suspending." >>$LOG
sudo /usr/sbin/pm-suspend

exit 0

This script was adapted from http://www.pcmediacenter.com.au/forum/topic/39679-mythbuntu-frontend-build-xbmc-mythtv-suspendresume-with-remote/

Disable the password lock on XScreenSaver after resuming

Notes for that are in this post: http://ubuntuforums.org/showpost.php?p=8215853&postcount=2

Commenting out everything in /usr/share/acpi-support/screenblank worked fine.


Channel Changing

With the backend setup I have, enabling FireWire control of the cable box was challenging due to issues with how VMware Fusion passed through the FireWire device. Or, rather, it didn't pass it through to the VM. The alternative solution I figured out was to use a channel changer system pref at the OSX level that was developed for EyeTV. ([[1]]) This took care of the FireWire control of the cable box, but I had to determine a way to send messages to it. To do that, I decided on writing a very simple OSX service that would listen for network connections on a specified port, and receive a channel change message that way. On the backend side, I wrote a simple channel change script for the cable box input that sent the appropriate message to the service. Once the service received the message, it would pass the channel change command to ChannelChanger.prefPane via it's message passing interface.

The following is the meat of the service that passes a message over to the ChannelChanger.prefPane. This code was developed from the scant description in the back of the EyeTV documentation.

int deliverChannelNumber (int channelNum) {
	NSMutableDictionary *dict = [[NSMutableDictionary alloc] init];
   
	[dict setValue:[NSNumber numberWithInt:channelNum]	forKey:@"channelNumber"];
	[dict setValue:0 forKey:@"subChannelNumber"];
	[dict setObject:@"Motorola DCT-3200" forKey:@"setTopBoxName"];
								 
	[[NSDistributedNotificationCenter defaultCenter]
	  postNotificationName:@"com.elgato.ExternalChannelChange" object:nil userInfo:dict];	 
	 //postNotificationName:@"com.elgato.ExternalChannelChange" userInfo:dict];
	
	return 0;
}

There's a fair amount of other code around that bit that handles incoming connections, etc.

Here's the channel change script that is used on the backend to send the channel message:

#!/bin/bash

CHANGER_HOST=osxbox
CHANGER_PORT=4833

wget -t 1 http://$CHANGER_HOST:$CHANGER_PORT/changeTo?channel=$1

exit 0

Complex stuff. But, it's worked pretty flawlessly for a couple years now. When the HDHomeRun Prime gets put into production, this will all go away and be lost to the sands of time.

Mac mini Setup

I used the following blog entry as a guide for getting Linux (Mythbuntu 8.10) installed: http://blog.costan.us/2009/03/ubuntu-810-or-904-on-mac-mini.html

Sound & Other Drivers

Sound was relatively easy to get working by specifying the following in /etc/modprobe.d/options:

options snd_hda_intel model=mbp3
<pre>

I also set IPv6 and the Bluetooth driver to not load by modifying <code>/etc/modprobe.d/aliases</code>.  In particular the directives for <code>net-pf-10</code> and <code>net-pf-31</code> were set to <code>off</code>:

<pre>
alias net-pf-10 off
alias net-pf-31 off

VDPAU

This was also close to a no brainer. I used the VDPAU / Ubuntu repository that Jean-Yves Avenard has created at http://www.avenard.org/media/Ubuntu_Repository/Ubuntu_Repository.html. He's also hosting the VDPAU compatible nVidia drivers. I simply uninstalled the original Mythbuntu-provided MythTV packages and installed the ones from the Avenard repository.

Getting the nVidia drivers was a bit more involved. I had to update those separately and I did so from a command line login (not through X). The commands were somewhat similar to the following:

service gdm stop
apt-get install nvidia-glx-180
rmmod nvidia
modprobe nvidia
service gdm start

The following is my xorg.conf, in case it's of use:

Section "Monitor"
	Identifier     "Configured Monitor"
EndSection

Section "Screen"
	Identifier     "Default Screen"
	Device         "Configured Video Device"
	Monitor        "Configured Monitor"
	DefaultDepth    24
	SubSection     "Display"
	Depth            24
	Modes          "nvidia-auto-select" "1920x1080" "1280x720" "1024x768" "720x480" "800x600" "640x480"
	EndSubSection
EndSection

Section "Module"
	Load           "glx"
EndSection

Section "Extensions"
	Option         "Composite" "Disabled"
EndSection

Section "Device"
	Identifier     "Configured Video Device"
	Option         "DPI" "100x100"
	Option         "UseEvents" "1"
	Option         "XvmcUsesTextures" "false"
	Option         "NVAGP" "1"
	Option         "AddARGBVisuals" "1"
	Option         "AddARGBGLXVisuals" "1"
	Driver         "nvidia"
	Option         "NoLogo"	"True"
EndSection

Failed Recordings

I see failures sometimes because of issues with connectivity to the HDHomeRun or to the DCT-3200 via FireWire. It's usually the FireWire system that's fallen down causing the node of the DCT-3200 to change. For these situations, I've written a simple script that looks for the string "Recorder Failed" in the backend logs and emails me information about what died.

From there, I can manually go in to:

  1. Stop mythbackend.
  2. Unload the FireWire modules.
  3. Power cycle the DCT-3200.
  4. Reload the modules and start mythbackend.

I do steps 2 & 3 just to be sure that things are reset right. (In the Aliens sense of "it's the only way to be sure", that is.)

The following is the script I use to recognize a failed recording in the logs. And, yes, Rube Goldberg did assist with design and implementation of this script.

 #!/bin/bash
 
 # Stores a record of what had failed before
 EXISTING_LIST=/var/log/mythtv/failed_recordings.log
 CUR_DATE=`date +%Y%m%d_%H%M%S`
 DIS_DATE=`date +%Y-%m-%d\ %H:%M:%S`
 #NEW_LIST=/tmp/new_failed_$CUR_DATE.log
 NEW_LIST=/tmp/new_failed.log
 
 NOTICE=" Canceled recording (Recorder Failed):"
 MARKER="< "
 
 
 if [ -f $NEW_LIST ]; then
     rm -f $NEW_LIST
 fi
 
 grep "Recorder Failed" /var/log/mythtv/mythbackend.log > $NEW_LIST
 
 if [ -f $EXISTING_LIST ]; then
     FAILED=`diff $NEW_LIST $EXISTING_LIST | grep -v "^>" | grep "^<"`
     FAILED=${FAILED//$NOTICE/}
     FAILED=${FAILED//$MARKER/\\n\\n}
     FAILED=${FAILED//cardid 1, sourceid 6/FireWire}
     FAILED=${FAILED//cardid 2, sourceid 2/HDHomeRun_0}
     FAILED=${FAILED//cardid 3, sourceid 2/HDHomeRun_1}
 fi
 
 #echo "Failed Recordings as of $DIS_DATE:"
 #echo -e $FAILED
 
 ###  Mail function
 
 if [ -n "$FAILED" ]; then
     SENDER="<sender>"
     RECIPIENT="<recipient>"
     MAILER="/usr/sbin/sendmail"
     (
 	echo "From: MythBot (<sender>)"
 	echo "To: Name (<Recipient>)"
 	echo "Subject: MythTV:  Failed recordings"
 	echo " "
 	echo " "
 	echo "As of $DIS_DATE, the following recordings have failed:"
 	echo -e $FAILED
 	echo " "
     ) | $MAILER -f $SENDER $RECIPIENT
 fi
 
 cp $NEW_LIST $EXISTING_LIST
 
 rm -f $NEW_LIST

I'll eventually update this script to use mythtv-status to check when the next recording is. If it's more than 30 minutes away, I'll have it take care of the power cycling and module reloading so that I'll just get notified if something goes wrong. The failures occur on such an infrequent basis that I don't really care much about it yet.

The script is set to run via cron at two minutes past every half-hour (i.e. HH:02 and HH:32).

BH-500NET Control

It's a bit off-topic for MythTV, but since I use the BH-500NET for battery backup and remote power switch control of the HDHomeRun, HD-PVR, and DCT-3200, it's probably useful for the one other person that might be wanting to control one from Linux.

Background: The web-interface of the BH-500NET works from Internet Explorer just fine. Stray away from that and you find that it's an abomination. When I was trying to figure out how I could script it, I noticed that several of the techniques they use violate the Geneva Conventions. (They use NULL characters for string separators, for example.)

I finally came up with some CURL calls that could provide control of the power switches from a script, though.

You'll need the following:

  • CURL installed on your system. It's probably already there.
  • The password and username for the BH-500NET.
    • The default username is admin.
    • For the password, you need to convert the actual password to hyphenated hex ASCII. That is, the password "password" will become "70-61-73-73-77-6F-72-64".

The following script will set the values for the power ports (1 - 3) to "off - on - on".

 #!/bin/bash
 
 PASSWORD="<HEX ASCII PASSWORD>"
 USER="<USER NAME>"
 HOST="<HOST NAME OR IP of BH-500NET>"
 CURL=/usr/bin/curl
 
 $CURL "http://$HOST/Logon.cgi"
 $CURL "http://$HOST/2?n=$USER&T=$PASSWORD"
 $CURL "http://$HOST/3?s=1&a=2&u=3&l=4&o=1&p=0&q=0&S2=Apply"

The request URL in the last CURL call has the interesting bits. "o", "p", "q" represent power ports 1, 2, and 3, respectively. For each of those, values of 0, 1, and 2 are possible, with 0 representing "On", 1 representing "Off", and 2 representing "Reboot/PowerCycle".