Mythdora - Setting up a USB IR-Blaster

Finally got around to ordering an IR-Blaster to use with my Mythdora installation.

The specific one I purchased can be found at www.usbuirt.com. I actually ordered it on-line from NCIX (Vancouver Canada source) on Monday afternoon, and I had it in my hands (Toronto) on Wednesday.

What I wanted to do was to use the IR-Blaster to give me the ability to first; have the Mythtv front-end be controlled by one of my many remote controls, instead of my wireless keyboard; and then to also change the channels on my STB as controlled from MythTV.

So, here's what I had to work with: My MythTV box, the USB IR-Blaster, My STB, the remote for my STB, and for now the remote for my MediaMVP box.

First thing I did was read, read, and read some more, and got myself totally confused ... that is until I read somewhere that the USB-UIRT was directly supported bu lirc 8.2 ... brillaint, because that's exactly what Mythdora comes with.

So I take the first big step; I plug the USB IR-Blaster into the USB port of my MythDora box ... suddenly I see some new device files in my /dev directly, the most important one being /dev/ttyUSB0 which it turns out is the recognized USB IR-Blaster.

Next, as a test I run the "irrecord" command ... first time through it doesn't work, but luckily I make a type on the driver argument, and it obligingly responds with a list of valid drivers, one of them being the "usb_uirt_raw"driver (I was trying to use some other driver, but types it in wrong, which was lucky, as had I typde it in correctly it just would have failed and I would have probably spent hurs more trying to google the reasons and corrections.)

Anyway, after I realize my mistake I correct it and type:

irrecord -H usb_uirt_raw -d /dev/ttyUSB0 myremote.conf

This brings up some information and a few prompts, and asks me to start hitting keys on my remote, which the program starts to recognize. so I know that I am getting somewhere with this little project.

So, let's step back a little bit here now that I've got the basics up and running, and do a quick overview of the steps that are going to be needed in order to accomplish what I want to do.

Step1: Get MythDora to recognize the USB IR-Blaster hardware.

Step 2: Create an lirc configuration file of the remote I want to use so the lirc system can both recognize and simulate these devices.

Step 3: Merge these files into one file and place it in the /etc/lircd.conf file.

Step 4: Configure the lircd to start properly and to start on a reboot.

Step 5: Configure MythTV to recognize the output from the lirc system

Step 6: Configure MythTV to send the proper IR codes out to the IR-Blaster to simulate the STB's remote control.

So, let's put some detail on some of those steps.

Step 1: This step is actually very simple, as mentioned above. Ignore everything you read about setting up other kinds of IR Blasters on other version of lirc, simply make sure you have lirc 8.2 and plug the IR Blaster into your USB port (note: use "rpm -qa |grep lirc" to determine if you have lirc 8.2 ... and if you don't I would assume a command such as "yum install lirc" would quickly fix this problem ... but, as I stated already, MythDora should already come with this software.)

Step 2: This is where the "irrecord" command comes in. You run this command with the proper parameters, and it prompts you to start hitting keys on the remote, gives these keys some names, and it automatically builds the lirc configuration file for you.

For example, to create the lircd configuration file for my Hauppauge MediaMVP remote control I used the following command:

"irrecord -H usb_uirt_raw -d /dev/ttyUSB0 hauppauge"

The program walked me through the process where I hit all the keys on my remote, gave them some names, and it did all the work in creating the following file:

# Please make this file available to others
# by sending it to
#
# this config file was automatically generated
# using lirc-0.8.2-CVS(usb_uirt_raw) on Thu Mar 20 15:55:56 2008
#
# contributed by
#
# brand: hauppauge
# model no. of remote control:
# devices being controlled by this remote:
#

begin remote

name hauppauge
bits 13
flags RC5|CONST_LENGTH
eps 30
aeps 100

one 917 775
zero 917 775
plead 961
gap 109396
min_repeat 1
toggle_bit_mask 0x800

begin codes
1 0x1781
2 0x1782
3 0x1783
4 0x1784
5 0x1785
6 0x1786
7 0x1787
8 0x1788
9 0x1789
0 0x1780
Text 0x178A
Sub/CC 0x178E
Red 0x178B
Green 0x17AE
Yellow 0x17B8
Blue 0x17A9
Skip- 0x17A4
Pause 0x17B0
Skip+ 0x179E
Rewind 0x17B2
Play 0x17B5
Forward 0x17B4
Record 0x17B7
Pause 0x17B6
Vol- 0x1791
Vol+ 0x1790
Mute 0x178F
Previous 0x1792
CH- 0x17A1
Ch+ 0x17A0
Exit 0x179F
Down 0x1795
Menu 0x178D
Left 0x1796
Right 0x1797
Up 0x1794
Guide 0x179B
Radio 0x178C
TV 0x179C
Videos 0x1798
Music 0x1799
Pictures 0x179A
Power 0x17BD
OK 0x17A5
Go 0x17BB
end codes

end remote

Step 3: I also did the same thing with my STB's remote control, merged the two files ("cat file1 >> file2") and copied that merged file to /etc/lircd.conf.

I then had a file that allows the lirc system to both recognize and simulate both of those remote controls.

Note: I have several older remotes, especially a couple of RCA universal remotes, but neither of these remotes were properly recognized by the irrecord program ... so be warned, not all remotes are created euqally, so YMMV.

Step 4: Next we want to set up the licrd program to start properly, and to start up automatically on reboot.

First we need to edit the /etc/sysconfig/licrd file to contain the line:

LIRCD_OPTIONS="--driver=usb_uirt_raw --device=/dev/ttyUSB0"

This will you to start the lircd deamon using the command:

/etc/rc.d/init.d/lircd start

In order to make sure the lircd program starts up after a system reboot you can enter the following command:

chkconfig lircd on

Step 5: Mythtv doesn't actually do the recognizing of the remote control codes ... lircd does that and then looks up what to do with these codes in your /home/mythtv/.mythtv/lircrc file (also "soft linked" to /home/mythtv/.lircrc, so if you edit one of them you actually edit both.)

The lircrc file format (along with other useful information about the lirc system) can be found here.

To understand better what's goin gon here, let's step through a basic key press from my MediaMVP remote control and trace what happens from the actual key press to the action on the screen within MythTV.

OK, so let's say I press the "menu" button on my MediaMVP remote.

The IR-Blaster receives the IR signal "0x178D" and passes it on to the lircd program.

The lircd program checks in the /etc/litcd.conf file and finds the "0x178D" code (see bolded code above) in the hauppauge section of the file, which tells it that this code corresponds to the "menu" button of the hauppauge remote control.

So, now the lircd knows that the "menu" button on the hauppauge remote was pressed .. now what does it do whit it?

First thing the lircd does is to check what program has the "focus" of the system ... in this case since we are supposedly running MythTV, the lircd program finds that "mythtv" has the focus.

Lircd now looks in the /home/mythtv/.mythtv/lircrc file.

It looks through all the file for any entry that refers to the "hauppauge" remote, for a program called "mythtv", and a reference to a "menu" button .

In doing so it finds something like this:

begin
remote=hauppauge
prog = mythtv
button = Menu
repeat = 3
config = M
end

This tells the lircd that as the "mythtv" program has focus, and the "Menu" button was pressed, then send the key-press "M" to the mythtv program.

A key-press of "M", assuming you're watching live TV, will bring up the live tv menu.

The only hard part about this whole process is that you will have to go through each entry in the /home/mythtv/.mythtv/lircrc file and make sure the "button" entry matches what you have listed in the /etc/lircd file (for both "remote" and "button" at least ... also "repeat" and "delay" might need to be adjusted for your particular system needs.)

Step 6: So now we have MythTV recognizing the signals from your remote control, now we need to have Mythtv send out the proper remote codes when it wants to change the channel, so that the STB thinks the codes are coming from it's own remote control.

Again, let's step through a sample case. Let's say you are watching a show on channel 100 and want to change to channel 200 ... so you enter "2-0-0" and hit "ok" on the remote.

Mythtv recognizes these remote control signals just as it would in Step 5 above ... but this time, since it is a string of numbers and an "ok", it interprets this as a request to change the channel (and rightfully so.)

When MythTV recognizes a channel change request it can do one of two things; If you have an internal cable or satellite card installed, it sends that request directly to the card and lets the card handle the channel change process. If you are using an external Set Top Box (STB) then you need to configure MythTV to use an "external channel change command".

You config this in the MythTV setup program under "Input connections".

Run "MythTV Setup", go to the "Input connections" section and select the appropriate connection ... in my case it's the "[MPEG : /dev/video0 ] (Composite 1)" connection as I have my composite output from my STB connected to the composite input of my hauppauge PVR-150 card.

In this Connection I have entered "/usr/local/bin/change_chan.sh" into the filed called "External channel change commands:".

This tells MythTV that when ever a channel change is requested (by entering "###ok" on your remote, or via an automated request from the recording system) to take all the numbers and send them as parameters to a program called change_chan.sh in the /etc/local/bin directory.

So, since as we stated abve we are changing from channel 100 to channel 200 by entering "200ok" on the remote, MythTV automatically runs the Linux command:

"/usr/local/bin/change_chan.sh 200"

Next let's have a look at the /usr/local/bin/change_chan.sh shell script:

#!/bin/sh
REMOTE_NAME=STB-REMOTE
for digit in $(echo $1 | sed -e 's/./& /g'); do
irsend SEND_ONCE $REMOTE_NAME $digit
sleep 0.2 # note, you may have to tweak the interdigit delay up a bit
done
irsend SEND_ONCE $REMOTE_NAME OK

The most important parts of the script are the "irsend" commands. This is the lirc command that tells the ir blaster to send an ir signal out to some other device.

You'll need to understand a little bit of shell scripting to figure out the details of this script, but essentially it takes the channel number passed to it by Mythtv, let's say 200, and takes each individual digit of that number, looks up the proper remote code in the /etc/lircd.conf file, and sends it individually out the ir port of the ir blaster ... repeats for each digit, and then finally sends an "OK" ir signal for that remote.

You will have to modify this script to suit your own remote and the signals it requires:

Change REMOTE_NAME=STB-REMOTE to REMOTE_NAME=

You will find your remote name in the /etc/lircd.conf file in the "name" section of the remote that controls your STB.

You may also have to change the "irsend SEND_ONCE $REMOTE_NAME OK"
line as well to change "OK" to whatever you called the button that your remote uses to signal that you've stopped entering digits and to take whatever number you've entered as the complete channel number you are attempting to change to.


And that should be it .... you may need to restart MythTV, or even reboot your system (I'd recommend a complete reboot to make sure everything starts as it should.


My Mythtv now is controlled by my old MediaMVP remote control, and when I enter a channel number (or Mythtv automatically tries to change channels; for a recording for example) it sends the channel number to the lirc system which emulates the IR Remote of my set top box.

My next little project is to modify the /usr/local/bin/change_chan.sh to look for special numbers, which I will then cause to run other scripts to kick off and send other ir codes that will automatically configure all my A/V equipment ... for example let's say I enter the channel number "99966" (9-9-9-o-n) that could be recognized by the change_chan.sh script, which would then run another script that uses irsend to send ir codes to the TV, HTS, & STB to turn them all on and set them to the proper volumn levels, inputs and outputs. 999644 (9-9-9-o-f-f) could trigger a scrpt that turns everything off.

First though I need to figure out how to get the proper licrd.conf file for my RCA remote that came with y old HTS, as while it is an RCA universal remote, it doesn't seem to be like any official RCA universal remote.


For those attempting this project, I would first look in http://lirc.sourceforge.net/remotes/ to see if your remote already has an lircd.conf file ... if not, then you're going to have to use the lirc tools such as irrecord, mode2, and such to try and build your own ... good luck.

MythDora & Media MVP (rev H3) Configuration

Configuring a MythDora 4.0 standard install to work with a Media MVP rev H3 box.

This article describes the MythDora 4.0 and Media MVP configuration I used to get the Media MVP playing streaming media from my main MythDora Multi-Media system.


Video found on youtube showing basic functions of both MythTV & the Media MVP

---

Update (Oct 11, 2007): Before doing anything, make sure that you have turned off your firewall on the MythDora box.

To see if the MythDora firewall is running or not, open up a terminal session and type:

# /etc/rc.d/init.d/iptables status

If this returns anything but "Firewall is stopped." then you will need to disable the firewall before proceeding. To stop the firewall do the following:

#/etc/rc.d/init.d/iptables stop
# mv /etc/sysconfig/iptables-config /etc/sysconfig/iptables-config.old

It's probably not the best idea to run permanently without a firewall, but at the moment I don't have the details on setting the firewall to include the proper rules to allow the necessary communications (tcp & udp) between the two boxes. When I figure out the proper rules, I will update the post to include a generic addition to the iptables-config file.

---

Basic system information:

My MythDora box is based on an AMD single core 3200+ processor, with 1GB of ram, and an 80GM main drive (I also have a 250 GB secondary drive, which I use to mount at various mount points to best make use of disk space, but that configuration is beyond the scope of this article.) I have "hard coded" this box with an IP Address of 192.168.1.10. MythDora also runs DHCP, two tftp servers, and a special "mvprelay" service (more on these later.)

Additionally, while not relevant to this article, I use a Hauppauge WinTV-PVR-150 for capturing TV, and an Nvidia GeForce 6200 Turbocache video card.

The Media MVP is a "rev H3" and is assigned an IP Address of 192.168.1.100 via DHCP.

The network itself runs a Netgear wireless router (with 4 wired ports. Both the MythDora and Media MVP are connected to the wired ports. Workstations and laptops are a mixture of wired and wireless.) The Netgear router handles the gateway and DNS services, but has had its DHCP service disabled (DHCP runs on the MythDora box as it is more flexible and configurable running there, and depending upon your own router you will likely need to do the same.)

---

Installation Summary:

1. Configure the DHCP server
   
2. Configure two tftp services (on on port 69, and the other on port 16869)
3. Download, compile, and run the mvprelay program
   
4. Download the dongle.bin.mvpmc file
   
5. Create a dongle.bin.ver file
   
6. Create and edit a dongle.bin.config file
7. Set up your MythDora box for NFS shares
8. Install and configure VLC
   
9. Boot the Media MVP box.

Note: The following details are specifically for a MythDora 4.0 installation and an H3 rev (it should also apply to other Hx revisions but I have not tested any other than the H3) of the Media MVP box. If you do not have both of these prerequisites, then these instructions will likely not be accurate (although they may help to give you an idea of what you need to do even if you have some other Linux distro, or rev of the Media MVP box.

For installations with different Linux distros or Media MVP revs, your best bet is to check out the information available on the mvpmc homepage, the mvpmc wiki, or the mvpmc sourceforge forums.

For those of you who are already familiar, or not interested in knowing all the boring details, all the important information is contained in the "quoted" sections . So like for all the parts of this post that look like this:

• Details are in sections that look like this, and all the really important instructions are in RED

---

Configure the DHCP Service:

Summary: I had to disable the DHCP service on my router as it was not capable of providing the bootp (bootstrap protocol) information that is required to run the Media MVP box.

Think of the Media MVP as a Linux server without a disk. This means that the Operating System needs to be stored on a server with a disk, and that we need to be able to boot the Media MVP; give it some basic network information; and tell it where it can find its Operating System. It can then load that Operating System up and perform it's multimedia functions.

On a MythDora 4.0 system, you will find the DHCP configuration file at /etc/dhcpd.conf. Open this file and edit it similar to the following:

ddns-update-style interim;
ignore client-updates;

subnet 192.168.1.0 netmask 255.255.255.0 {

# --- default gateway
option routers 192.168.1.1;
option subnet-mask 255.255.255.0;

option nis-domain "yourdomain.com";
option domain-name "yourdomain.com";
option domain-name-servers 192.168.1.1;

option time-offset -18000; # Eastern Standard Time

range 192.168.1.20 192.168.1.50;

}

group {
next-server 192.168.1.10; # IP address of your TFTP server
#
host mvp {
# NOTE: Change the hardware ethernet to the MAC address of your actual MVP
hardware ethernet 00:00:00:00:00:00;
fixed-address 192.168.1.100;
filename "dongle.bin.mvpmc";
option root-path "/home/mvp,rsize=4096,wsize=4096,nolock";
}

}

Careful of the line wraps that might show up due to web page formatting, they are invalid in a real config file.

Lines highlighted in red should be modified to reflect your own network information.

This DHCPD configuration does the following:

• Sets a range of IP addresses from 192.168.1.20 to 192.168.1.50 to be handed out to any computer that requests an IP address from DHCP.
• Sets a special IP address, 192.168.1.100, for a computer that has a specific hardware address, which in this case will be the Media MVP hardware.
• Not explicit in this configuration, but impled is that all other IP addresses can be used for "static" addressing, which in the case of the main MythDora computer is configured with a "static" ip address of 192.168.1.10. The DHCP is not configured to do anything with that address, so it does not cause any conflicts.
• This configuration also does one more thing. It tells any host in the "group" section (in this case the mvp host) that it should look on the server with the address of 192.168.1.10 (MythDora) for a file called "dongle.bin.mvpmc"; upload it to memory; and attempt to boot using this file.
  

---

Configuring the tftp (trivial file transfer protocol) service:

Summary: In the above DHCPD configuration t was mentioned that the DHCPD config tells the Media MVP box to upload a file called "dongle.bin.mvpmc". Of course files just don't upload themselves, so we will have to configure a service that will allow the Media MVP to do its uploading. This service is called "tftp" (the Trivial File Transfer Protocol.)

It should be noted that the "H revs" of the Media MVP do some sort of "double boot" process, which I've never found a good description of, but apparently uploads the "dongle" file first using tftp on port 69, prepares itself in some mysterious manner, then reboots and uploads the "dongle" file again using tftp but this time on port 16869 (or it may be the other way around, but it essentially means that you need to instances of the tftp service running, one instance on each port.)

The recommended method of enabling a standard tftp service on the MythDora box (which is just a distro of Fedora Core 6 running MythTV) is to edit the /etc/xinetd.d/tftp file and change the "disabled = yes" to "disabled = no". For some reason this did not work for me, but fortunately there is another relatively easy method that works just as well, and works for both the port 69 and port 16869 instance of tftp.

Edit the /etc/rc.d/rc.local file and add the following lines

/usr/sbin/in.tftpd -l -a :16869 -s /tftpboot -v
/usr/sbin/in.tftpd -l -a -s /tftpboot -v

Then save the file.

You will have to reboot the server in order for the rc.local file to take effect, but we will do this later, as there is still one more edit we need to do to this file. After we finish all the other configuration changes, we will reboot the server when all the changes have been made.

---

Downloading, Compiling, and Running the mvprelay service:

Summary: The Media MVP comes with it's own software which runs only on Windows. You load the program on your Windows machine and it starts a "service" which when you boot up the Media MVP harware, responds to a query from the hardware for a "Streaming Media Server". Since you will not be running the Media MVP Windows software on your MythDora machine, you will need to run the "mvprelay" program which serves the same, or similar function on Linux.

The process of getting the mvprelay program goes like this:

Open your browser and browse to this link.
Highlight all the text on that page and click copy.
Open you favourite Linux editor and paste the text into it and save as "mvprelay.c"
Compile the file by typing the command "gcc -o mvprelay mvprelay.c"
Copy the resulting mvprelay file to /usr/local/bin or wherever you think appropiate.
edit the /etc/rc.d/rc.local file and add the line "/usr/local/bin/mvprelay 16881 5906 6337 192.168.1.10 &"

Again, you will have to reboot the MythDora box in order for these changes to take effect, but since there is still one more change we will have to make to the rc.local file, we can wait until that change is made before rebooting.

---

Download the dongle.bin.mvpmc file:

Summary: The dongle.bin.mvpmc file is actually a small specially modified Linux kernel, which is what the Media MVP should run in order to communicate with your MythDora box and stream live TV, recordings and videos.

You should probably get the latest dongle.bin.mvpmc file, which can be done by going browsing to the Sourceforge mvpmc project and selecting the latest version, but in these instructions I will use the one I downloaded at the time of this writing.

You should also be aware that when I used the dongle file as named, it didn't work for me. I've read a few posts on the forums of people having similar problems, so I renamed the file to the more generic "dongle.bin", which should work for everyone. I'd suggest you do the same, just in case you are one of the unlucky ones.

Download the dongle using the command: "wget http://superb-west.dl.sourceforge.net/sourceforge/mvpmc/dongle.bin.mvpmc-0.3.3"

Rename the file to "dongle.bin"

Copy "dongle.bin" to the /tftpboot directory

---

Create a dongle.bin.ver file:

Summary: Supposedly this file is used to determine if there is a need to reload the dongle.bin file. I'm not sure if this is true, or how it works, but it is needed so create it.


To create the bongle.bin .ver file:

Go to the /tftpboot directory
Run the command "dd if=dongle.bin of=dongle.bin.ver bs=1 count=40 skip=52"

You should end up with a 40 byte file named dongle.bin.ver

---

Create and edit a dongle.bin.config file:

Summary: This is the file that the Media MVP reads after it boots, and does all the detailed configuration stuff such as setting the time, running the application that connects to the MythDora system, mounts any NFS mounts that might be needed, and a bunch of other important, ad not so important things.

Here is the dongle.bin.config file that I use:

TZ='EST5EDT4,M4.1.0/02:00:00,M10.5.0/02:00:00' ; export TZ
echo "TZ='EST5EDT4,M4.1.0/02:00:00,M10.5.0/02:00:00'; export TZ" > /etc/shell.config;
rdate -s time-a.nist.gov
echo "192.168.1.10 mythtv.yourdomain.com> mythtv ">>/etc/hosts
mkdir /storage
/etc/nfsmount.sh 192.168.1.10:/storage /storage
mvpmc -f /etc/helvR10.fnt -y 192.168.1.10 -s 192.168.1.10 -r /storage/recordings -t /usr/share/mvpmc/easy.xml --startup mythtv -u mythtv -p mythtv -T mythconverg --vlc 192.168.1.10 &

Of course, the RED parts should be modified to use the information specific to your network.

If you are wondering about the parameters used for the mvpmc command, the complete list with explanations are listed here.

Create this file in your favourite Linux editor and save it as /tftpboot/dongle.bin.config

---

Set up your MythDora box for NFS shares:

Summary: This step configures NFS on your MythDora box to allow the Media MVP box to mount the /storage directory from MythDora box as though it were local to the Media MVP box. This provides to advantages, first it allows access to the MythTV "ring buffer", which means you can pause, and rewind live TV, and in conjunction with VLC allows you to stream other videos from your MythDora box to the Media MVP box. If you do not want to do this, then you will need to read through the documentation and modify the dongle.bin.config as necessary to remove the relevant NFS related parameters from the "mvpmc" command.

Here is what you will need to do in order to allow NFS access.

• Edit or create the /etc/exports file to include the line "/storage 192.168.1.100(ro)" (modify the IP address to be the address of your Media MVP box.)
• Restart the NFS service with the following command "/etc/rc.d/init.d/nfs restart" (This is not totally necessary, except if the NFS service is already started, but by doing this you will be able to make sure the exports file doesn't have any major errors that would make it fail.)
• Set the NFS service to start automatically on reboot by using the command "chkconfig nfs on"

---

Install and configure VLC:

Summary: VLC is a powerful media player and steamer. The Media MVP can be configured to use the LC streaming capability in order to play videos other than simply via the MythTV protocol which would limit the Media MVP to just playing Live and recorded TV. With this configured you can throw all your legal (of course) bittorrent videos and such into your /storage/videos directory on the MythDora box, then using the Media MVP file browser, you can select and stream and play those videos as well.

To install and configure the VLC streamer do the following:

• Install VLC by using the command "yum install vlc"

• Configure VLC to start automatically on reboot by editing the /etc/rc.d/rc.local file and adding the line "su -c "nohup vlc -I Telnet --sout-transcode-audio-sync --sout-transcode-deinterlace &" mythtv" (I run this as the default mythtv user to make sure it have the right permissions and environment. It may work just as well running as root, but I haven't tested it, so if oyu want to, go ahead."

Since you have now made all the necessary configuration changes to the /etc/rc.d/rc.local file, you can, and should, now reboot your computer so that all those changes take effect. If you choose not to do so now, don't forget to do so before booting up the Media MVP box.

---

Boot the Media MVP box:

Summary: Okay, this is where we find out if I've documented everthing correctly, and if you followed the instructions properly .... Good Luck.

Before putting the power to the Media MVP box, make sure you have connected it to the network and plugged it into your television's audio & video jacks (I use the RCA yellow video jack, but if you have an S-Video input that should work just as well, and as far as I can the Media MVP send signal to both at the same time so there should no extra configuration needed ... but I could be wrong, so if the S-Video doesn't work try the RCA jack and then go read the documentation.

If everything goes well when you put the power to the Media MVP you should see something similar to the following:

• A screen comes up with 5 large grey blocks at the bottom. The first four blocks should turn black and the screen should switch
• You might get a message asking to hit "OK" within 3 seconds. You shouldn't have to do anything at this point, but if the rest of the boot doesn't go as described below, reboot and hit OK at this point to see if the Media MVP has detected the "Streaming Video Server" at the MythDora Address.
• The next screen you see should have 10 small blocks at the bottom of the screen. These should step through turning black with the words "loading application" above it. The blocks may cycle through a couple of times, but within 15 seconds or so the screen should flash black.
• The next screen should be black except for a blue "splotch" in the middle of the screen with mvpmv.org. This should show for a few more seconds and then you should see the MythTV menu appear on the screen.
• At this point, you are on your own, browse around and check out all the menu options. Note, some of these options do not work as yet (at least in many cases, and mine in particular.) For instance, the "Live TV" option should work, but the "New Live TV" option may not work and actually cause the mvpmc application to crash and restart (this causes no damage, the application simply restarts and you can continue on.) The crashes seem to be caused by the version of the dongle you are using, although in this case until you go into your mythtv mysql database and configure the database to allow remote access your system may only give you an error message about "sql access" rather than crashing.
  

---

Misc Info:

Summary: I'll add some more stuff here that should make the MythDora box a little more useful for organizing your media. When I get some more time I will document how I installed and configured SAMBA in order to allow my daughter to upload her music to the system ; and how I installed and configured VNC to set up some "virtual X session" where you can do some unattended bittorrent downloading, burning DVD backups, and such on the MythDora box, and control it all from your firefox or IEexplorer browser. Ie. Use your browser as though it were a monitor, keyboard, and mouse attached to your MythDora box, and run applications as though your were sitting in front of the machine. You can also just close the browser and the apps keep on running, and can be reconnected to your browser, password protected, any time you want to monitor progress.