tag:blogger.com,1999:blog-40445215774523793672024-03-13T09:46:42.517-04:00Working with MythTVPerspectives on MythTV from a user, developer, and husband trying to win his wife over from the TiVoRon Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.comBlogger21125tag:blogger.com,1999:blog-4044521577452379367.post-17771948265474482912011-07-22T00:01:00.002-04:002011-07-22T00:05:51.233-04:00Ceton InifiniTV 4 in MythTV 0.24 - Part 3 (Mythbuntu)In <a href="http://mythtvblog.blogspot.com/2011/07/ceton-inifinitv-4-in-mythtv-024-part-2.html">Part 2 of this article</a>, I provided all of the instructions for setting up MythTV 0.24 to use a Ceton InfiniTV 4 cablecard tuner. Today, I'm going to provide a simple step by step that should get a Mythbuntu 11.04 user up and running with Ceton support. However, before continuing, please first read <a href="http://mythtvblog.blogspot.com/2011/07/ceton-inifinitv-4-in-mythtv-024-part-2.html">Part 2</A> to see all of the disclaimers and important info. I'm going to assume you've read it, and thus won't be repeating all of the important details here.<span class="fullpost"><br /><br /><B><BIG>Instructions</BIG></B><br /><br />mkdir /usr/src/mythtv<br />cd /usr/src/mythtv<br /><br />apt-get build-dep mythtv<br />apt-get source mythtv<br />apt-get install devscripts<br /><br />cd mythtv-0.24.0+fixes.20110416.9ba3ece<br /><br />dch -i <br /><br />This will take you to edit a file containing a changelog. At the top of the file, it will have already filled in the framework for you to enter your change info. There will be a line with a single asterisk * about 3-4 lines down. Next to the asterisk, just put a brief summery like "applying ron's ceton patch"<br /><br />For the following, I'm going to assume you've put the patch file (which you can <a href="http://www.ronfrazier.net/mythtv/0.24/index.html#CetonSupport">get here</a>) in your home directory. Also, substitute the XXX in the filename with the appropriate version you've downloaded.<br /><br />cp ~/ceton_mythbuntu_verXXX.patch debian/patches/<br />patch --dry-run -p1 < debian/patches/ceton_mythbuntu_verXXX.patch<br /><br />Make sure you got no error from the above. Also please double check the output to make sure it doesn't say anything about applying the patch with fuzz. Although patching with fuzz will work at this step, when you go to rebuild the package, it won't allow fuzz.<br /><br />pico debian/patches/series<br /><br />Add ceton_mythbuntu_verXXX.patch at the end of the mythtv section.<br /><br />debuild -us -uc -iFFmpeg<br /><br />In the above command -us and -uc are necessary so that we can build the packages even though we aren't setup to sign them. The -iFFmpeg is to tell the packager not to include the FFmpeg stuff in the package. I had to do this because the build process started complaining about the binary file being different. I couldn't find any good explanations on google, but since I didn't modify anything in ffmpeg, we can just leave it out and it will use the old version.<br /><br /><br />Now at this step you are going to need to install the packages to replace the binary files with your new version. First, I want you to run the following command and make note of the timestamps on the existing files (copy the output to a text editor and hold onto it for a few moments).<br /><br />ls -l /usr/bin/mythbackend /usr/bin/mythfrontend* /usr/lib/libmythtv-0.24.so* /usr/bin/mythtv-setup*<br /><br />Now lets install the packages. There are a ton of packages here, and you can try to install them all if you like. However, I only bothered with the following, and everything seemed to work<br /><br />cd ..<br />dpkg -i mythtv_0.24.0+fixes.20110416.9ba3ece-0ubuntu2_all.deb<br />dpkg -i mythtv-common_0.24.0+fixes.20110416.9ba3ece-0ubuntu2_i386.deb<br />dpkg -i libmyth-0.24-0_0.24.0+fixes.20110416.9ba3ece-0ubuntu2_i386.deb<br />dpkg -i mythtv-backend_0.24.0+fixes.20110416.9ba3ece-0ubuntu2_i386.deb<br />dpkg -i mythtv-frontend_0.24.0+fixes.20110416.9ba3ece-0ubuntu2_i386.deb<br /><br /><br />Now, let's once again look at the timestamps on the files:<br /><br />ls -l /usr/bin/mythbackend /usr/bin/mythfrontend* /usr/lib/libmythtv-0.24.so* /usr/bin/mythtv-setup*<br /><br />Everything should have a new timestamp on it<br /><br /><br />At this point, all of the Mythbuntu specific stuff should be setup. Now go to <a href="http://mythtvblog.blogspot.com/2011/07/ceton-inifinitv-4-in-mythtv-024-part-2.html">Part 2 of this article</a> and continue on from step 8.<br /><br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com6tag:blogger.com,1999:blog-4044521577452379367.post-36864596271502716902011-07-21T23:14:00.006-04:002012-01-07T20:54:27.562-05:00Ceton InifiniTV 4 in MythTV 0.24 - Part 2In <a href="http://mythtvblog.blogspot.com/2011/07/ceton-inifinitv-4-in-mythtv-024-part-1.html">Part 1 of this article</a>, I discussed my decision to get a Ceton InfiniTV 4 card instead of a HD Homerun Prime, how it didn't initially go as planned, and how I eventually went through the process to write my own code to utilize the card in MythTV 0.24. Now I'd like to share the fruits of my labor...the necessary code which you can compile into MythTV 0.24-fixes to get Ceton support for yourself. In the upcomming Part 3 (hopefully posted tomorrow), I'll post a patch and instructions for Mythbuntu 11.04 users<span class="fullpost"><br /><br /><br /><B><BIG>Standard disclaimers</BIG></B><br /><br />I'd be absolutely thrilled if you wanted to use my code to get your Ceton card working in MythTV. However, before I unleash all of this on you, I need to be clear about a number of things. I wouldn't want you to not realize what you are getting into and get mad at me if something goes terribly wrong (like you miss a bunch of recordings). So here are a few things you'll need to know before getting started<br /><br />1) This isn't just a distribution you can download and install, or run apt-get on. We are talking about custom compiled code. You will be downloading the mythtv source code from the git tree, applying some patches, and custom compiling it on your own. If you've never done this before, then I'd prefer that you get comfortable with that process before trying to add in my code. So I'd suggest downloading 0.24-fixes from git (see the instructions at <a href="http://code.mythtv.org">code.mythtv.org</a>), compiling it, installing it, and making sure everything works. If that all works fine, only then should you think about proceeding<br /><br />2) This isn't official code by any means. This is something I put together by myself, as a stopgap measure until 0.25 is eventually released with real Ceton support. So far, the only person to test this code is me. If you run into problems, the folks on the MythTV forums aren't gonna help you with this one. You'll be depending on me for help. <br /><br />3) If you have problems with the code, I'll try to help. I take pride in what I do, and I'll be willing to work with you as much as I can to figure out your problems. That said, I've got a full time job and a 1 year old daughter, so don't expect 24 hour support and quick turnaround time. It may take me a while to figure out and get to the bottom of it, but I'll try my best.<br /><br />4) If you do need help from me, then I'm gonna need help from you. I'm gonna ask you for logs, I'll probably send you some custom code, ask you to run it, and send me back the results. I may do this a number of times.<br /><br />5) Realizing that this isn't the official software for running the Ceton card in MythTV (nor will it be the official code in 0.25 or ever), you are going to have to expect things to break when you eventually upgrade to 0.25. You're going to have to delete your tuners and repeat the setup process in 0.25 using the officially supported mechanism.<br /><br />6) When 0.25 comes out, if by some chance it does NOT contain the official support for this card as expected, then this code won't work on 0.25. I may be a bit delayed in upgrading my systems to 0.25, so it may be a little while before I can update the code. That said, I should be able to do it relatively easily, as I already did some preliminary work at getting this working in 0.25 (and had it working in a limited capacity), so I've got a decent part of the code written. And some of the biggest parts (that deal with tuning and getting status info) are actually not tied to myth directly, so I should be able to port them with no problems.<br /><br /><br /><B><BIG>Other important information</BIG></B><br /><br />If the disclaimers didn't scare you off, then here are few of the little quirks you need to know about:<br /><br />Importing QAM channels - I haven't written a channel scanner for this card, so if you want to run it in QAM mode without a cablecard installed, you are going to have to do some work to get your channel data setup properly. I can work with you to get this setup if necessary, and I can probably write some perl scripts to help you with the process. However, hopefully nobody is buying this card just for it's QAM support, so hopefully this won't be such an issue. But if you maybe want to test it in QAM mode before upgrading your cable service and ordering a cable card, then we'll have to setup some channels for you<br /><br />Importing cable card channels - For cable card support, we just use myth's download option and let mythfilldatabase download the data from schedules direct and create the channels. This sets up the channels for the most part, but they are not yet usable by this code. You'll need to run an SQL query to update one of the fields in the database. I'll provide you with instructions below. Also, in the future, if new channels get added to your lineup automatically, they are going to need to be tweaked before they are usable, so you'll need to rerun that query whenever your lineup changes. In the future, I'll try to figure out the most appropriate way to automate this so you don't have to worry about it, but for now it's something you'll need to be aware of<br /><br />Live TV channel changing - Typically this works very well...about 3 to 4 seconds per channel change. However, occasionally a tuning request may fail and the Ceton doesn't properly tune the channel. The good news is that I've got code to detect this condition (as least for every way I've experienced this or I anticipate it could happen) and re-initiate the channel change request automatically. However, when it does happen, it will take 5 seconds for the code to kick in, and then another few seconds for the channel change to occur. When this happens, you'll be staring at a black screen for several seconds. Back on the good news side, I've only had this happen to me once in my testing, so I don't expect it will be very common).<br /><br />Startup error condition - I've started and stopped the mythtv-backend service hundreds of times almost entirely without issue. Once it's running, the code works great. However, one time I rebooted my computer and when it came up, it didn't initialize properly. As a result, the card wasn't usable for recording until I stopped and restarted mythtv-backend. When it happened, it was logging very obvious info to the log file, so this will be easy for you to detect. Sometime next week (after my daughter's 1st birthday party) I intend to take a better look at this, rebooting my system several times to see if I can recreate it. I'm pretty sure it was just a matter of mythtv-backend starting up before the Ceton card was ready. I've modified my card to get its IP through DHCP instead of using the static 192.168.200.1 that it has by default, so this may have been the cause of the problem. <br /><br /><br /><B><BIG>One final disclaimer</BIG></B><br /><br />It's important to know that cablecard support is going to depend on your cable provider. Unfortunately, cable labs has only certified Windows Media Center to support certain modes of DRM. This means in MythTV, you can only watch channels that are marked as Copy Freely, and it's up to your cable provider to decide this. If they mark a channel as Copy Once or Copy Never, you are out of luck and the only thing you can possibly do is complain to them (for all the good it will probably do). You can probably check with others on the MythTV forum to try and figure out what channels are marked Copy Freely for you (either someone that lives in your area may know, or someone may be able to show you how to retrieve that info from your cable box). <br /><br />In general, WOW (wide open west) has said that they mark everything except premium channels (HBO, showtime, etc) and PPV as Copy Freely. This should hold true in all WOW markets. Comcast has the exact same arrangement in most of their markets, but I believe there are some places here and there that are configured differently. With other cable providers, results may vary.<br /><br /><br /><B><BIG>Are you still here? OK, let's get this going</BIG></B><br /><br />If I haven't scared you off with the disclaimers and quirks, then I guess you are serious about this and it's time to get to work. So here's what you need to do<br /><br />1) Download myth 0.24-fixes and make sure you can compile it all fine.<br /><br />2) Download my <a href="http://www.ronfrazier.net/mythtv/0.24/index.html#CetonSupport">ceton patch for 0.24-fixes</a>.<br /><br />3) cd to the mythtv/mythtv folder of the source code. This is the folder that contains the ./configure script<br /><br />4) Clean up any previously compiled code by running: <br /> make dist-clean<br /><br />5) Test the patch first by running the following command:<br /> patch --dry-run -p2 < /path/to/ceton_verXXX.patch<br /><br />6) If the above test was successful and no failures occurred, then apply the patches by running: <br /> patch -p2 < /path/to/ceton_verXXX.patch<br /><br />7) Run ./configure, compile everything, and install it<br /><br />8) Start mythtv-setup and add a Ceton tuner. The default IP address (if you haven't changed it) is 192.168.200.1, and the tuners are numbered 1 to 4. Repeat this process for all 4 tuners (or as many as you want to setup).<br /><br />9) Create a brand new data source exclusively for the Ceton tuners (and don't let any other non-ceton tuners use it).<br /><br />10) Click the button to fetch channel info (I don't recall the exact wording, but it's the next to the scan button in the Input Connections page<br /><br />11) If you have a cablecard installed in your Ceton InfiniTV, perform step 11-A and then go to step 12. If you DO NOT have a cablecard installed (ie: you want to operate the card in QAM mode) perform step 11-B and then go to step 12.<br /><br />11-A) Note: this step is no longer needed as of patch ver 008 (1/7/2012) <del>Do this step ONLY if you are running the Ceton in CableCard mode (ie: you have a cablecard installed):<br />Download <a href="http://www.ronfrazier.net/mythtv/0.24/index.html#CetonSupport">the channel mapping utility</a>. Unzip/untar it and edit the perl script to adjust the config settings at the top of the file. You'll want to verify (and change when necessary) the path to wget, the ip address of your Ceton InfiniTV 4 card, and the mysql info (host/db/user/password). Then simply run the perl script to have it update the channel config.</del><br /><br />11-B) Do this step ONLY if you are running the Ceton in QAM mode (ie: you do NOT have a cablecard installed):<br />Download <a href="http://www.ronfrazier.net/mythtv/0.24/index.html#CetonSupport">the QAM channel mapping utility</a>. Unzip/untar it and edit the perl script to adjust the config settings at the top of the file. You'll want to verify (and change when necessary) the path to wget, the ip address of your Ceton InfiniTV 4 card, and the mysql info (host/db/user/password). Then run the perl script to have it update the channel config. <br /><br />Note: One limitation of this script is that it cannot determine which channels are available in unencrypted QAM. It will simply look at every channel in the videosource that you've assigned to the card in mythtv-setup, and then update the configuration of that channel accordingly. Therefore, in order to eliminate the encrypted channels so that myth doesn't have to tune them, you will need to delete those extra channels or mark them as not visible (either in mythtv-setup or using mythweb).<br /><br />12) Startup the backend and the front end, and you should be good to go if I haven't forgot anything.<br /><br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com32tag:blogger.com,1999:blog-4044521577452379367.post-66518068043014523472011-07-19T22:43:00.003-04:002011-07-19T22:59:06.077-04:00Ceton InifiniTV 4 in MythTV 0.24 - Part 1With the pending release of the SiliconDust HD Homerun Prime, I was getting pretty excited about getting a cablecard tuner for MythTV. However, then something wonderful happened...Ceton decided to drop the price of the InfiniTV 4 card to $300. I hadn't been very interested in the card before simply because it was a bit out of my desired price range. However, at the new price, it was barely more expensive than the Prime, and it gave you a 4th tuner to run off the same cablecard. After thinking about it for a few weeks, I decided to cancel my HDHR Prime preorder and take a chance on the Ceton card.<span class="fullpost"><br /><br />I said take a chance, because I knew that the Ceton card wasn't yet supported in MythTV. However, I had some ideas how I could hack support into myth 0.24, and failing that, I was under the impression that the trunk code of mythtv (which will eventually be 0.25) already had the code necessary to work with the Ceton. So I figured one way or another, I was covered with the caveat that I wouldn't be working with a proven, tested system. <br /><br />It turns out I was wrong on both counts. My plans for hacking support into 0.24 (using the Demo Recorder or Import Recorder) didn't pan out. So I tried the trunk support and couldn't get it working. After a post on the MythTV user forums, I learned that I was mistaken...that the trunk code only contained bits of the needed code, and wasn't at all functional. Oops. Big oops.<br /><br />So here I was with a $300 capture card that didn't work in myth, and a wife who had been anxiously anticipating an upgrade to HD channels. What do I do? Tell her "sorry...you'll have to wait a while...maybe another 6 months"? Or do I sell the Ceton card and buy the Prime? Or is there a 3rd option....can I write my own code to get it working in MythTV 0.24?<br /><br /><br /><BIG><B>Writing the code</B></BIG><br /><br />When I first looked into the code, it was a huge mess of very mysterious things I didn't understand. There was a part of me that said I'd probably never get this all to work. But then I did what I always do...just try to break it down into chunks. I started looking at bits and pieces, figuring out what I did and didn't need. This allowed me to discard large sections of code and focus on a much smaller core set of functionality. <br /><br />It took me only a few days to figure out enough to hack my way through it and get my very first output...video from the Ceton on my TV screen. It was very basic..it didn't include things like channel changing yet, but it was a start. Then I discovered that a whole bunch of stuff wasn't working...seeking, commercial flagging, channel changing was incredibly slow, etc. <br /><br />After looking into it, it turns out that a lot of that "unimportant" code I discarded early actually had important functionality that I didn't yet understand. Yet stripping it out still had value...it allowed me to focus on a smaller bit of functionality and become more familiar with it. I now understood a lot of code, and as I started to work back in those pieces I ripped out, one by one they were making sense, too.<br /><br />Over the next few weeks, I got everything put back in and reworked it. I hit some snags along the way...a bug in the existing myth code, a VDPAU bug in an early release of Debian squeeze, and some peculiar mpeg data streams from my cable provider all simultaneously threw up obstacles and mislead me about why things weren't working. One by one I figured it out, and eventually I ended up with a fully functional recorder for the Ceton card. It could record, flag commercials, do the channel changing on it's own, etc.<br /><br />However, I had a few issues with channel changing. I was changing channels through the Ceton's built in web interface (rather than the DRI UPnP interface), and apparently that isn't the most rock solid way to change channels. I thought I had dealt with the issue and everything seemed fine, so I set up my first big test...recording a dozen programs overnight. When I woke up in the morning, I found that a few of the recordings failed. However, that turned out to be my fault...I had setup the channel data with a channel I didn't actually subscribe to. <br /><br />After fixing that, I ran a bigger test the next night....about 30 programs, using all 4 tuners at a time. When I woke up the next day, I found that several of those didn't record. Looking at my logs, the problem appeared to be that when multiple tuners tried to change the channel in rapid succession, not all of the requests would always succeed. So I spent a few days writing an entire new set of channel changing code, which would do 2 things...first, it would space out the request to ensure too many don't occur at once. Second, it would monitor the change until it saw that it was complete and successful, and if necessary, it would re-initiate the channel change until it finally succeeds.<br /><br />With my new changes in place, I setup my box to run for 12 hours, recording 80 programs, all back to back, and often with 4 new program starting simultaneously. End result...everything worked perfectly. <br /><br />With that final test completely successful, I put it all on the line. I took the Ceton card out of my dev box, put it in my newly-rebuilt production myth server, and set it up as the 4 highest priority tuners. It's been working great for a few days now. <br /><br />I still have some more tweaks I want to make, but it's going to be a little while (I'm getting prepared for my daughters 1st birthday this weekend). However, everything is working well enough now, so I'll be posting my existing code very soon.<br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com4tag:blogger.com,1999:blog-4044521577452379367.post-82725405093921309422010-01-02T15:14:00.004-05:002011-08-07T23:08:25.797-04:00IRWatch version 2 releasedToday, after a MUCH longer delay than anticipated, I've finally made available the newest version of my IRWatch utility. It's been rewritten from scratch for a much cleaner and more modular design. No longer are you required to go into the main perl script and enter all of the logic into the while loop (making sure not to mess any of it up). Now there are much simpler config files for you to edit (ok...technically you are still modifying perl code, but it's MUCH MUCH prettier than before). The special event handling logic has also been exported to a plugin format, which makes it much easier for you to design your own custom event handlers and then share that with other users<br /><br /><span class="fullpost"><B><BIG>Configuration</BIG></B><br />First, you need to download the latest version of <a href="http://www.ronfrazier.net/mythtv/link.php?i=IRWatch">IRWatch</a> and also the <a href="http://www.ronfrazier.net/mythtv/link.php?i=RFLibs">RFLibs</a> libraries.<br /><br />Next, you need to set them up in the right locations. I put both the irwatch and the RFLibs folders into /usr/local/scripts. If you want to place them somewhere else, you will need to modify the first line of irwatch.pl so that the perl include (-I) specifies the appropriate location.<br /><br />Now you need to do some relatively simple configuration. You can probably just wing it by modifying the 000_general file in the config directory, but if you need more help, there is more extensive documentation in the README file. The important parts here are to make sure the values in the settings hash are correct, then define aliases for your remote(s) in the remotes hash, then go through the events hash and define just how you want the remote to behave.<br /><br />You will notice the 500_aquos.disabled file in the config folder. The .disabled extension tells irwatch not to process that config file. For most users, that is what you want (otherwise, the config file will tell irwatch to load the aquos plugin, which will fail becuase it can't connect to the aquosserver, so irwatch will abort). However, if you are running a compatible Sharp Aquos TV with a serial port, and if you have successfully setup my aquosserver script to control the TV, then you will want to enable this functionality. Just rename the file to 500_aquos (ie: remove the .disabled extension) and edit the file to your liking.<br /><br />Once again, check the README file for more details<br /><br /><B><BIG>Writing Plugins</BIG></B><br /><br />Writing plugins is actually relatively easy. Most of the info you need is (once again) in the README file. Simply put, you need to create your plugin in the plugins folder, add a corresponding config file in the config folder, and make sure the config file indicates to load the newly created plugins. When writing a plugin, you want other users to be able to use it without modifying the plugin code at all. So, to that end, make you put configurable option like paths, ip addresses, ports, etc into the config file in the settings hash.<br /><br />If you write any interesting plugins that you think others might find handy, please send me a copy via email. If it looks interesting, I'll include it on my website.<br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com1tag:blogger.com,1999:blog-4044521577452379367.post-37199561463388806972009-12-30T23:21:00.003-05:002009-12-30T23:58:59.580-05:00BluRay updatesWell, in the past month I've had a bit of a chance to play around with bluray playback, as well as doing an upgrade to MythTV 0.22 and a VDPAU capable graphics card.<br /><br /><span class="fullpost"><b><big>The Upgrade</big></b><br /><br />A big incentive for making the upgrade to 0.22 was to take advantage of some of the advancements that make BluRay playback better. At present time, no system is capable of software-based BluRay decoding without multithreading support, and unfortunately ffmpeg's current multithreaded implementation only works on some BluRay discs (a very small subset, based on my experiments). I was sick of having to spend an hour ripping a BluRay movie, only then to have to turn around a spend another several hours (5+ hours) transcoding to something that mythtv can handle in software.<br /><br />With MythTV 0.22 and VDPAU support, I can now play nearly everything without having to do any transcoding. Full bitrate decoding is handled perfectly by the VDPAU card, and DTS-HD audio is handled by MythTV's included libraries. The only problem I've had so far was with a movie that used TrueHD for the master audio track. At present time, that results in unwatchable playback. However, I think that I'll be able to work around this without transcoding by simply extracting the core audio subtrack from within the TrueHD master track. That should work just great without adding to the ripping time. I'll post an update once I get around to testing it (such a small thing to test, but with all the stuff I've got on my MythTV todo list, small things don't necessarily get done more quickly)<br /><br /><br /><b><big>Seektables needed for playback</big></b><br /><br />One thing I forgot to mention before was that playing back an m2ts file doesn't work very well without building a seektable for the file. I wish that weren't the case, but luckily it's not a very difficult thing to do. A simple call to the mythtranscode program (don't worry...you aren't actually doing any transcoding) will generate the seektable for the m2ts file rather quickly. A 2 hour movie takes about 5 minutes to process on my system.<br /><br />mythtranscode --mpeg2 --buildindex --allkeys --showprogress --video --verbose most --infile "$filename"<br /><br />The one downside is that this leaves behind a 0 byte file that you need to delete. To deal with this, and so that I don't have to remember what parameters to use, I've written a shell script to handle this all for me. I simply call the script, pass it the filename, and it does everything. <br /><br /><a href="http://ronfrazier.net/mythtv/0.22/downloads/m2ts_buildindex">Download the m2ts_buildindex shell script</a>.<br /><br /><br /><br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com0tag:blogger.com,1999:blog-4044521577452379367.post-19829037303933874602009-11-28T07:52:00.006-05:002015-08-12T13:34:31.103-04:00BluRay playback in MythTVRecently I decided to see if I could get BluRay playback working in MythTV. I've been putting it off for quite a while because of how problematic the whole process appears to be. Lately I got bored and decided, what the heck...lets see what we can do.<br /><br /><span class="fullpost"><b><big>BluRay player</big></b><br /><br /><div class="amazonlink"><iframe src="http://rcm-na.amazon-adsystem.com/e/cm?lt1=_blank&bc1=000000&IS2=1&bg1=FFFFFF&fc1=000000&lc1=0000FF&t=bloggingabo09-20&o=1&p=8&l=as1&m=amazon&f=ifr&md=10FE9736YVPPT7A0FBG2&asins=B002EE996Q" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe></div>First things first...I needed a BluRay player before doing anything. Amazon has the <a href="http://www.amazon.com/gp/product/B002EE996Q?ie=UTF8&tag=bloggingabo09-20&linkCode=as2&camp=1789&creative=390957&creativeASIN=B002EE996Q">LiteOn iHOS-104-08 for $50 with free shipping</a>, and it has great reviews everywhere I looked. I considered spending more and getting a burner, but at the time I ordered it was $100 more for a BluRay burner, and with BD-R media prices the way they are currently, I figured by the time they become more reasonable I can probably just buy an entire new player/burner for less than $100, and then I'd have a newer player that will hopefully be more mature. I've been burnt enough by buying DVD burners that don't work well with certain media brands or can't burn at their rated speed. I don't want to get stuck with another lemon, so I'll just wait out the burning stuff for right now.<br /><br /><br /><b><big>Ripping Software</big></b><br /><br />The next issue with BluRay playback is that currently there is no linux support for playing it directly off the disc. First you have to rip it to your hard drive and then do something from there. Linux has a program called DumpHD which can rip some BluRay discs, however it appears to be hit-or-miss.<br /><br />I've already had enough annoyance with ripping regular DVDs in linux. Yeah, some will rip fine with one program, but others have bad sectors on disc which cause the ripper to fail. So now you have to use ddrescue to recover the bad sectors, which takes HOURS to rip a single disc. Then when I later decide I want to rip and transcode just the main title, I find that for some reason (which I still haven't figured out) the main track can't be ripped properly by programs like handbrake It comes up all garbled (I suspect it has something to do with not properly/fully removing the CSS encryption). Argh!!! Too much hassle. I want one way to do things, and I want it to work quickly and reliably every time.<br /><br />For this reason, I recent purchased AnyDVD-HD for Windows. Yeah, it's sort of a mental defeat that I can't seem to do it all under linux and have it "just work" every time, but after hassling with this for so long, I don't care. I'd rather just get it working. AnyDVD-HD fits the bill there. Though it's not free, it was worth it for me. DVDs rip successfull every time, and in only about 10 minutes. It doesn't matter which copy protection they have, it handles it for me, and that (to me) is worth the cost (though I am a bit surprised that nothing equivalent has popped up under linux yet, as far as I know).<br /><br />So anyway, I've already got AnyDVD-HD for Windows, and from my reading it appears to work very reliably on ripping and decrypting BluRay discs, so I figure that's my best and simplest course of action.<br /><br /><br /><b><big>Ripping </big></b><br /><br />Ripping the BluRay disc with AnyDVD-HD is quite simple. You insert the disc, wait for the software to analyze the disc and remove the protection, right click on the fox icon in your taskbar icon tray, and choose "Rip Video DVD to Harddisk". A window pops up where you choose the correct drive to rip from, set your output folder, and click the "Copy DVD" button. The rip process begins, and when it's done you've got a folder on the hard disk that contains the entire filesystem from the disc, with all protections removed.<br /><br /><br /><b><big>Extracting the Features</big></b><br /><br />Unfortunately, there's no software in linux (that I am aware of) which understands how to playback a BluRay movie (including all the menu structure and everything). So, in order to do anything, you need to extract each item individually. For some movies, apparently you can just find the largest m2ts file and copy that out, but that doesn't always work well. Many discs actually contain a ton of small m2ts files, and you need to figure out which ones are which and join the appropriate ones together in the correct order. Once again, this seems like another bit of hassle I don't want to deal with. Luckily, there's a program that can deal with this (and this time it's free).<br /><br />ClownBD is a GUI that simplifies the process of extracting tracks from a ripped BluRay disc. You point it at the folder you ripped to, and it runs some backend processes (mostly eac3to), parses the output, and gives you a nice gui for dealing with the results. It's all very easy to use and quite intuitive.<br /><br />So, first step is to install and setup ClownBD. That's quite simple...not much to do there. Mostly, you just need to setup some temporary folders the program can use for demuxing and remuxing the content. Then you point it at the BluRay rip folder and click the "Next" button.<br /><br />Now eac3to will be run in the background, and when it is done (which only takes 5-10 seconds) you will most likely see the "Step 2" window pop up. This window contains a tree control showing each feature on the disc, and for each one it shows the length, which m2ts files it is spread across, how many chapters, which encoding codecs were used, which languages there are, etc. Your job here is to select the one feature you wish to extract. Generally this would be the main movie, and most of the time that would be the longest running feature on the disc. However, that's not always the case. Some movies have a longer feature with directors commentary or something. So in these cases, what you'd want to do is lookup the running length of the movie on the movie case or disc label (if it's not there, check amazon, imdb, or on the netflix sleeve if this is a netflix rental). Then just pick the feature that is closest in length to this figure and click "Next".<br /><br />Note, that I mentioned you will *most likely* see this dialog. However, if your disc only contains a single feature, ClownBD will intelligently skip the step of giving you a dialog with only 1 option to choose from, so you will go straight to step 3.<br /><br />In Step 3, you will now be focusing on a single feature of the film, and it will show you all the info about that feature. This time, you choose which components of that feature you wish to rip. So far, in my experience you only have a single video track, so that's a no brainer. However, the audio and subtitles sections usually give you several options. For each option it will tell you the contents, such as audio type (DTS Master Audio, AC3, etc), language, bitrate, etc.<br /><br />Unfortunately, there is no way to preview the contents of each selection. You just have to rip it and see what you end up with. However, for each section, ClownBD preselects a few options that it thinks you will want, and most of the time it guesses correctly. So, unless you want an alternate language, I'd normally just rip it with the default selections. I've ripped the alternate tracks for a few movies. I tried ripping the AC3 track thinking I'd get AC3 audio, but it just turned out to be a director's commentary audio track. So far in my experience, the defualt track (which is usually DTS Master Audio) is the one you want.<br /><br />Now that you have your selection, you have a few choices to make. First is the output Audio format. I tried leaving it unconverted, but that didn't work for my in mythtv. Instead, I check the AC3 option and that seems to work fine. The FPS and Stream boxes I just leave at default. The Movie Output Format I haven't experimented with. I just set it to m2ts. I'm not sure how that would be different from ts, and I have no idea what output you'd get from BluRay or BluRay+ISO. I just pick m2ts the first time and it worked perfectly, so I've stuck with it.<br /><br />Now that you've chosen all your options, you click next and it will begin a long processes of demuxing and remuxing the content. When it is done, you will have a file in you remuxing temp folder called something like demuxer.m2ts and that is your extracted feature.<br /><br /><br /><b><big>Playing</big></b><br /><br />Ideally, you should just be able to copy that file over to your mythtv system and start playing back, and indeed that does work perfectly in some cases. However, in other's there may be one last gotcha in your way...decoding performance.<br /><br />There are 2 ways to decode...hardware and software. At the moment, the only hardware option in linux is to use a VDPAU capable video card and VDPAU enabled software (mythtv 0.22 can do it, as well as 0.21 if you apply a certain set up backported patches). With this, the video should play back smooth as butter. However, I currently don't have a VDPAU card, so I've no experience with this area yet.<br /><br />The other way to decode is in software, which means using a very fast CPU. If your CPU isn't multi-core, you can forget about it right away. There's no way it will be fast enough. Even if you do have a multi-core processor, it still may not be fast enough if it's a lower end one. Finally, even if it is multi-core and fast enough to play back some movies, there will be a final problem with other movies. MythTV uses ffmpeg to do the decoding, and unfortunately ffmpeg currently has a serious limitation in the multithreading department. It can only multithread h264 video when it is encoded utilizing slices. Not all movies do this. Some do, some don't, and some only do it for some chapters of the movie. If the movie isn't encoded with slices, playback decoding will happen on a single CPU core (while the others sit idle) and you will get pausing every few seconds while the CPU catches up with playback (unless your CPU is fast enough to decode in real time on a single core...however, I'm not sure if any current CPU is fast enough...the only one that MIGHT be able to do it is the very fastest models of the Core i7 chip, and even that it might need overclocking, and even THEN it still might be just a tad too slow).<br /><br />So, the short of it is that software decoding isn't reliable. It will work for some films, and only parts of others (or not at all). So your options now are to upgrade to a VDPAU capable system, wait for better multithreading in ffmpeg (which is under development, but still buggy, and it will be a while before it is finished, and then a while longer until the updates get rolled into mythtv), or transcode to a less demanding file.<br /><br /><b><big>Transcoding</big></b><br /><br />As I just mentioned, if you don't have VDPAU playback, you'll probably want to transcode. Even if you do have it, you still might want to transcode since a BluRay movie takes 15-40GB, and if you are going to keep a copy on your hard drive you might want it to be a bit smaller. Or, if you don't want to keep it on your hard drive but don't want to go through the re-ripping process to play it each time, another option would be to transcode it to something that will fit on a dual layer DVD+R disc.<br /><br />For transcoding I've been using Handbrake under Windows (you can run it under linux too, but since I'm already running AnyDVD and ClownBD in windows, I might as well just finish up the process there, too). Handbrake has a number of option, but I can't explain most of them to you, and I have no idea what they do or which ones are better. I just pick one of the higher quality default profiles (making sure to choose one based on h264) and then tweak it a bit. First, I make sure I'm outputting to mkv format. Then, on the Picture Settings tab I change Anamorphic to "Loose" and set the width to 1280 (which equates to 720p resolution). Then, on the Video tab, you want to set a higher bitrate. For the few I've done, I just tried 6000 kbps. That gave me a file size of about 2.75 GB/hour. However, if you want to go the "burn to DVD+R DL" route, you might want to maximize quality while making sure it still fits on the disc. In that case, rather than setting an explicit bitrate, you'd want to specify a target size of slightly less than the disc can hold. Also, I've read this isn't perfect...it may go over slightly, so you might want to play it safe and just pick something like 8000 MB (disclaimer...I haven't tried this yet, so don't yell at me if you spend hours transcoding and it turns out even that is too big to fit).<br /><br />With these few changes, I then proceed to transcode. This is a long process. For dual pass transcoding, it usually takes me about 2 times the length of the movie to transcode (so a 2 hour movie will transcode in about 4 hours). This is on a Core i7-920, utilizing all 4 cores. Slower processors will obviously take longer.<br /><br />When this is all said and done, hopefully you will have an mkv file that works just fine. However, if you messed up and chose a wrong option, you could have a file that doesn't work (like the first time I tried it and got no sound). So before you go and invest hours of transcoding only to find it doesn't work, what you should do is experiment on transcoding a shorter clip. I'm not sure of a good way to trim down a m2ts file after the fact. Instead, what I did was go all the way back to the ClownBD step, check the box on the first screen that says "Split Output Based on Chapters", run it, and then pick one of the shortest chapter to transcode (usually you can find a 1-2 minute chapter). Just make sure to turn off that option in ClownBD when you are done experimenting.<br /><br /><br />So, in the end I end up with a 720p, 6Mbps, h264 video/AC3 audio file in mkv format. Yeah, it's not quite the quality of BluRay, but honestly I don't see any difference watching the movie, even on my 1080p TV. Maybe if I had them on 2 TVs side by side I might notice a difference, but switching back and forth between the BluRay file and the transcoded file, I see no difference. That's close enough for my satisfaction.<br /><br /><br /><b><big>Conclusion</big></b><br /><br />It's not perfect, but it works. I can't play straight off the BluRay disc, and I need to go through a lengthy process (though there isn't much labor involved...most just start a process, come back in an hour, start another process, etc), and I end up with a slightly lower quality result. However, it's close enough for me, and gets me results that are better than DVD. The damn DRM might not make it easy, but so far it's not an insurmountable obstacle if you are willing to put in a little effort.<br /><br />Maybe in a few weeks, after I get a chance to play with some more options, I'll post an update with what I've found.<br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com2tag:blogger.com,1999:blog-4044521577452379367.post-18585543809608506832009-05-04T09:47:00.005-04:002011-08-08T08:52:57.101-04:00Controlling a Sharp Aquos TV via the serial port interfaceLast year, I replaced my ancient CRT television with an HDTV LCD...a Sharp Aquos. When I got the TV, I was curious to find that it had a RS-232 compliant serial port onboard. I was wondering if I could setup my mythtv frontend to communicate with TV. A quick look through the user manual turned up something I found even more shocking than the existance of the serial port...the communication protocol for the TV's serial port was completely documented in the user manual, including things like port settings, command format, a list of commands, and their accepted parameters. This was exciting...it seemed like it wouldn't be too much trouble to get it all working.
<br />
<br /><span class="fullpost">Indeed, it was quite easy. I installed a Perl module called Device::SerialPort which made it a piece of cake to setup a serial port connection. In no time at all, I quickly issued my first command to the TV and had my response back. From there, it was just a simple matter of turning it into a script.
<br />
<br />At first, I just wrote a simple standalone program to handle what I wanted. It would open a connection, send the command, and give back the response. However, the problem was that I intended to be interfacing with the TV from multiple different scripts and programs, and was concerned about cases where 2 scripts might try writing to the serial port at the same time, which would probably either fail or do something like intermix the 2 commands being written resulting in the TV getting corrupt data.
<br />
<br />Instead, I decided the best way to handle it would be to write a simple server script. This server script would be the only script that interacts with the Aquos via serial port. All other programs would connect to the server, issue a request, and let the server handle the communication and pass back the result. If multiple clients connected to the server, the server would just handle the requests one at time, in the order received.
<br />
<br />The end result of this effort is the Aquos Server, which is a simple perl script that handles requests via tcp/ip connections. You simply start the script running at bootup, connect to a port, issue a text command, and read back a text result. It's a very simple communication protocol. Each request is one line, and it is always responded to with a one line response.
<br />
<br />
<br /><B><BIG>Setting it up</BIG></B>
<br />
<br />First thing you will need to do is download my updated RFLibs (ver 2) library of Perl modules. Also note that even if you downloaded these libs in the last few months (since I posted the updated ones), you'll want to redownload them again. There was one remaining rare bug in the serial port communication that I was able to track down and fix. You can get the current version <a href="http://www.ronfrazier.net/mythtv/link.php?i=RFLibs"> from here</a>.
<br />
<br />Then you need to download the aquosserver script. You can get that <a href="http://www.ronfrazier.net/mythtv/link.php?i=AquosServer"> from here</a>.
<br />
<br />Finally, you need to make sure you have the Device::SerialPort module installed for Perl. Under Debian, you can do this using "apt-get install libdevice-serialport-perl", but the command or package name may be different for your distribution.
<br />
<br />Once you've got it, you'll want to make sure the aquosserver script is in the same directory as the RFLibs directory. Then you may need to edit the aquosserver script and change 2 things:
<br />1)The $listenport variable (set to 4684). This is the port that the aquose server listens for connections on. Change it to whatever you please.
<br />2) The $serialport_device variable (set to '/dev/ttyS2'). This is the device name for the serial port that is connected to your Sharp Aquos TV.
<br />
<br />
<br /><B><BIG>Testing</BIG></B>
<br />
<br />Simply start the script running. Then, to test it out, open another ssh/telnet window and try connecting to it. The easiest program to use is nc:
<br />nc localhost 4684
<br />
<br />Then type "POWER" (without quotes) and hit enter. If everything went as planned, you should get back a response of either 0 or 1 (depending on if the TV is off or on). Next we want to make sure you can turn the TV on via serial port (by default, that capability was disabled on my TV). First, turn the TV on manually. Wait for it to power up completely, and then issue the "SERIALPOWERUP ENABLE" command to the aquosserver, which should give you an "OK" response.
<br />
<br />Now you can try turning it on and off using "POWER ON", "POWER OFF", and "POWER TOGGLE". You can query the current volume with the "VOL" command, and you can adjust the volume using "VOL+" and "VOL-", or you can set it explicitly using "VOL 10". You can query the input using the "INPUT" command (which returns the input number, with input 0 being the tuner), and you can set it to input 2 by issuing "INPUT 2". The commands for muting are "MUTE", "MUTE ON", "MUTE OFF", and "MUTE TOGGLE". Finally, when you are done issuing commands, type "EXIT" and hit enter to disconnect.
<br />
<br />This should cover most of what you want to do with the TV, but if you need to issue a command not listed here, you can issue a raw command code to the aquos server. First look up the command code and parameter in your TV user manual. You can then issue the command using the "CMD" command and pass it both the command code and the parameter value. For instance, to set the AV Mode to Game, you would use "CMD AVMD 3". Note that the parameter (3) does not need to be padded to 4 bytes as the Sharp protocol requires. My library handles the padding for you.
<br />
<br />Also, note that this script was written around the D64U series of Aquos TVs. I've looked at a few other series and they use the same protocol and commands. However, if your TV has different protocol/commands you'll have a problem. If that's the case, let me know and I'll see if maybe I can find a way to handle other TVs in a future version.
<br />
<br />
<br /><B><BIG>Using</BIG></B>
<br />
<br />Now, how do you implement this into something useful? Well, first you need to make sure that the aquosserver script is always running in the background. You'll want to launch it from one of your init scripts. I'll let you figure out how to do that. Once it's running, you'll need to issue commands to it. You can do this from a script. For instance, if you want to power on the TV when your computer boots up, you can run a script (after the aquosserver has started up) which runs the following command:
<br />echo -e 'POWER ON\nEXIT' | nc localhost 4684
<br />
<br />This issues the command to turn on the TV and then disconnects from the aquosserver (without paying attention to the result).
<br />
<br />Another thing you may want to do is issue commands in response to pressing buttons on the remote. I believe there is a way to do that via the lircrc file, but I can't instruct you on how. Myself, I do it using the latest version of my irwatch script. That will be posted about in my next blog entry, so for now, you are on your own. Stay tuned...
<br />
<br />
<br />
<br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com8tag:blogger.com,1999:blog-4044521577452379367.post-37337998335271919942009-03-17T22:57:00.003-04:002009-03-17T23:16:14.994-04:00Updated RFLibs & new scripts coming soonIt's been a while since I posted anything here, but I have been working here and there on getting some work done on mythtv. Over the next few weeks, I'm hoping to post some updates and new scripts. A few things I've got coming include an updated version of irwatch, a new and improved alpha release of the mythimon client, and some stuff for controlling a Sharp Aquos TV via the serial port interface.<br /><br /><span class="fullpost"><br />All of these scripts are based in part around my RFLibs set of perl modules. I posted a release of RFLibs last year. Since then, I've made a lot of changes to those scripts. While some of the modules only experienced minor changes or the addition of new functions only, other modules (especially the imon releated modules) experienced a considerable redesign. <br /><br />As a result of these changes, if you had previously made use of my RFLibs modules in some of your own scripts, you might find that they no longer work with the new versions. I wish I could have avoided doing so, but many of the changes were necessary. I'm hoping things are in a much more stable state now, but still no guarantees.<br /><br />So for now, I'm going to make the new versions of the modules available for download. However, note that if you are currently using the old mythimon (alpha 1) or irwatch (version 1) clients, you cannot use these new versions with those scripts (you need to wait for the upcoming announcment of new versions of those scripts), so don't put these in place just yet.<br /><br /><a href="http://www.ronfrazier.net/mythtv/downloads/RFLibs_v2.tar.gz">Download version 2 of the RFLibs perl module pack here</a><br /><br /><br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com2tag:blogger.com,1999:blog-4044521577452379367.post-50492402237666263962008-05-18T23:26:00.003-04:002008-05-18T23:40:24.239-04:00The TiVo finally diedAs the subtitle of this website mentions, part of my mythtv journey has been getting my wife to give up the TiVo in favor of the mythbox. After several years of resistance, I finally started to really win her over one we got our new HDTV. In the 2 months since then, she stayed pretty clear of the TiVo. She went back briefly on a few occasions when the mythbox failed to record something. However, even that occasional problem has been solved now that she knows she can just get the episode via a torrent.<br /><br /><span class="fullpost">She's been 100% TiVo free for over a month now. Things have been going so good, I was just about getting ready to pull the plug on the TiVo permanently. However, yesterday the issue was forced...the TiVo no longer functions. It's failing to pass through any signal via the coax or ouput anything on the composite output. The system powers up, the drive spins, but nothing happens. I just get a blank screen.<br /><br />The TiVo functioned for a good 4.5 years, so at least I feel I've gotten good use out of it. I'm just glad I was able to get her to make the transition on her own terms, rather than having the thing yanked out from under her. The mythbox was able to win on its merits, rather than by default.</span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com0tag:blogger.com,1999:blog-4044521577452379367.post-48966093756204244872008-04-29T21:57:00.007-04:002008-04-30T14:33:53.556-04:00MythTV iMON server - alpha release 1As I mentioned before, I've been working on an LCD server for mythtv in my spare time with the intention of making full use of the iMON LCD's icons. I'm happy to say that I'm ready to release the first alpha version. Its a little rough around the edges, and very basic in functionality at the moment, but it's a decent start.<br /><br />Note: this application is specifically for the iMON LCD...NOT the VFD. If your display doesn't look like the photos at the bottom of this page, you have the VFD, and this program won't do you a bit of good.<br /><br /><span class="fullpost"><B><BIG>How to get it</BIG></B><br />First, you will need to download 2 separate archives. The first is the application specific archive, and the second is an archive of perl libraries I've written.<br /><br />mythimon: <br /><a href="http://www.ronfrazier.net/mythtv/downloads/mythimon.tar.gz">http://www.ronfrazier.net/mythtv/downloads/mythimon.tar.gz</a><br /><br />RFLibs: <br /><a href="http://www.ronfrazier.net/mythtv/downloads/RFLibs.tar.gz">http://www.ronfrazier.net/mythtv/downloads/RFLibs.tar.gz</a><br /><br />Make sure the RFLibs folder exists as a subdirectory of the folder where you put the mythimon files.<br /><br /><br /><B><BIG>Running it</BIG></B><br /><br />The first thing you want to do is to disable any other software that is outputting to the lcd (including LCDproc). The only thing you want to keep loaded is the lirc imon lcd driver.<br /><br />Next, the simpler test is to try running testAnimations.pl and make sure you get output on the LCD. If you have the older version of the iMON LCD, you will need to edit the code and change '15c2:0038' to '15c2:ffdc'. Also, if your device is setup somewhere besides /dev/lcd0, modify that setting too. If it works, you are good to go for the next test. If not, check for things like perl libraries, and make sure you are using at least perl 5.8 (needed for the thread support).<br /><br />Next, you can try the mythimon.pl application. First you need to open it up and setup a few config variables. Specifically, the port numbers for the lcd server and the network control, the location of the frontend log file, the location of the lcd devices, and the iMON version. <br /><br />If you don't have logging enabled for your frontend, you will need to add logging by adding the necessary paramters to the script that launches mythfrontend (ex "-l /var/log/mythtv/mythfrontend.log"). You will also need to have enabled both the network control port (found under setup->general) and the lcd port (under setup->appearance). You may need to restart the frontend for these changes to take effect.<br /><br />Once that's all setup, you want to kill the existing instance of the mythlcdserver (so you can steal the port from it) and quickly start up the application. You can do this with the command:<br /><br />killall mythlcdserver; ./mythimon.pl<br /><br />You should now be looking at a screen with a clock. Next, you need to wait up to 10 seconds for mythfrontend to connect to the lcdserver port. When it does, you will see the output "FIRST COMMAND RECIEVED FROM MYTHLCDSERVER" appear on the command line (not on the LCD).<br /><br />Now, when you go to watch TV or listen to music, you should get info on the screen and icons lit up. If not, again, check for perl libraries. Make sure you have the mythtv perl bindings installed.<br /><br /><br /><B><BIG>Known Limitations</BIG></B><br /><br />Being a work in progress, there is (by definition) a lot of stuff to be added or improved upon. Here are some of the known limitations, and what I plan to do:<br /><br />Menu Support - This will be added most likely in the next version. I plan to integrate it with the front panel controls of the case via lirc. This way the menu's won't pop up whenever there is a menu change in myth (as mythlcdserver does). Instead, it won't display the menus until you hit the specified button on the front panel to enter menu mode. Then the menu display will override everything else until you hit the specified exit key or you let the menu timeout.<br /><br />Volume Support - This will be added eventually. I plan to add a bit of configurability here...perhaps with plugin modules. One of the things I want to do for my specific setup is to integrate it with my TV, so it controls the volume via the serial port. I prefer this to adjusting the volume within mythtv. However, that's not going to work for most people, so I'll make it work both ways. With a simple plugin architecture, I'm thinking people could customize it to work with their setup (such as controlling an AV receiver).<br /><br />Generic Info - This is info like photo names in the photo gallery, etc. Hopefully this will be in the next verison also.<br /><br />Pausing/Stopping - There are times when myth doesn't send progress updates (like when playing music in the background). As a result, I've taken it upon myself to continuing calculating the progress on the assumption that playback is proceeding as normal. However, since myth sends no pause events, I have no way to track them. Thus, when you pause, my script doesn't know it, and keeps going. A similar problem exists with not knowing when music playback has stopped. I haven't yet figured out an ideal way to handle this. Probably some hack of monitoring the IR codes, cross reference that will the current location as reported by the network control port, etc.<br /><br /><br /><B><BIG>Ideas for future expansion</BIG></B><br /><br />I welcome feedback on ideas for what other types of things to do. There are some things I'm not sure about:<br /><br />Uses for icons/display features - Anything interesting I can do with the top progress bar, other than just duplicating the bottom progress bar? When I add menu support at a later time, I was thinking I could use it to track progress through the menu (like a scrollbar on the side of your browser). How about the spinning disk, and the tray icon right below it? And the vol and time icons (one use is obvious, but also kind of pointless)? How about the source icons? I've taken advantage of TV and HDTV, but not SRC/SRC1/SRC2/FIT (and while we are at it...what the heck is FIT for anyway?).<br /><br />Any good way to get the recording status out of the backend for the rec icon? I could also try monitoring the backend log, but that won't always be available on the remote frontend.<br /><br />Anyone know a way to get codec data out of the music player to light up those icons?<br /><br />How about getting weather data out of mythweather?<br /><br />Is there any easy way to get spectrum analyzer data out of myth or the linux audio system?<br /><br /><br /><B><BIG>Custom Fonts</BIG></B><br /><br />I've created 2 different fonts for the application. The first is a normal font, 16 pixel tall (currently used for the clock). The other is an 8 pixel tall font with small caps instead of lowercase letters. OK...technically I made a 3rd font, but it only consists of 1 charachter (space), and is only meant as a vertical spacer in the display.<br /><br /><br />If you would like to make your own fonts, you can use this utility<br /><a href="http://www.ronfrazier.net/mythtv/imon_fontedit.html">http://www.ronfrazier.net/mythtv/imon_fontedit.html</a><br /><br />If you come up with some good fonts, please feel free to share them with me.<br /><br /><br /><B><BIG>Screenshots</BIG></B><br /><br /><img src="http://www.ronfrazier.net/mythtv/img/lcd/clock.jpg" border="0" width=400/><br><br /><br /><img src="http://www.ronfrazier.net/mythtv/img/lcd/tv1.jpg" border="0" width=400/><br><br /><img src="http://www.ronfrazier.net/mythtv/img/lcd/tv2.jpg" border="0" width=400/><br><br /><img src="http://www.ronfrazier.net/mythtv/img/lcd/tv3.jpg" border="0" width=400/><br><br /><img src="http://www.ronfrazier.net/mythtv/img/lcd/tv4.jpg" border="0" width=400/><br><br /><br /><img src="http://www.ronfrazier.net/mythtv/img/lcd/music1.jpg" border="0" width=400/><br><br /><img src="http://www.ronfrazier.net/mythtv/img/lcd/music2.jpg" border="0" width=400/><br><br /><img src="http://www.ronfrazier.net/mythtv/img/lcd/music3.jpg" border="0" width=400/><br><br /><img src="http://www.ronfrazier.net/mythtv/img/lcd/music4.jpg" border="0" width=400/><br><br /><br /><img src="http://www.ronfrazier.net/mythtv/img/lcd/dvd1.jpg" border="0" width=400/><br><br /><img src="http://www.ronfrazier.net/mythtv/img/lcd/dvd2.jpg" border="0" width=400/><br><br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com12tag:blogger.com,1999:blog-4044521577452379367.post-61847255296112219302008-04-22T06:45:00.000-04:002008-04-22T12:49:55.633-04:00Developng an iMON client for MythTVOver the last few weeks I haven't posted anything here. I've been using whatever time I could to work on developing an iMON client that can interface with MythTV. I've been making some decent process, and although I have a lot of features I still want to implement, I think I might be ready to release a limited-functionality alpha version in a few days. For now, I just want to discuss why I'm developing it and what it has to offer over the standard mythlcdserver.<br /><br /><span class="fullpost"><br /><B><BIG>Why not use mythlcdserver</BIG></B><br /><br />The iMON LCD device has a lot of new capabilities. It's not just a standard 16x2 (or whatever) text display. It goes way beyond that. It's actually a 96x16 pixel display (1-bit each). In addition to displaying text, it can display arbitrary graphics. This gives it a lot of options. You can use custom bitmapped fonts of any size. You can draw symbols on the display. Really, anything you can imagine. The only real limitation (other than size and bit depth) is that, like a lot of inexpensive LCDs, the response time is a bit slow, so animations don't work well (it kind of blurs together).<br /><br />In addition, the iMON also supports custom icons. You can turn on icons for different a/v formats (mp3, divx, dts, etc), icons to represent the number of audio channel, and a bunch of others. <br /><br />These sort of features are completely absent from mythlcdserver. They aren't something that would work with a small tweak. They would require a complete overhaul of the application. It would also require some changes to the way myth itself works, since currently myth doesn't provide any of this data to mythlcdserver. In the end, it would be a huge change, which presents 2 obstacles. First, getting a change that major into myth would be a bit difficult (I've had significantly smaller changes in there for months without anybody accepting/rejecting or even commenting on it). The second is that, even if it were to get included, it would require a myth recompile for people, or would make people wait until the changes made it into the next release of mythtv (or mythbuntu, knoppmyth, etc).<br /><br />In summary, it just seemed to me to be better to do it in a new application.<br /><br /><br /><B><BIG>What cool things can be done?</BIG></B><br /><br />The first obvious thing that can be done is to support the iMON's 40+ icons. The next thing you can do is to use the 4 horizontal lines as progress bars, instead of wasting an entire row of the display on the progress bar. This gives you more space for display info while still having the progress bar visible at all times.<br /><br />As I already mentioned, the bitmapped LCD gives a lot of options for bitmapped fonts. Not only can you do half height text (8 pixel) or full height (16 pixel), but you can do any size you want. Perhaps a slightly bigger 11 pixel font on top and a tiny 5 pixel font on the bottom. Or instead of the 5 pixel font, you can display icons across the bottom for the functionality of the front panel buttons (pause, rewind, etc).<br /><br /><br /><B><BIG>How does it get the data</BIG></B><br /><br />The correct way to get the data would be explicitly from myth. However, as I already stated, this data isn't readily available, and making it available would require a wide range of modifications to mythtv. Instead, I'm going the quick and dirty route. I collect the data from a variety of sources. I pretend to be the mythlcdserver program and monitor port 6545. I scrape data from log files. I gather data from the network control on port 6546. I watch for IR commands. I then weave all of this data together to get a coherent picture of what is going on in myth. It's not 100% perfect, but it works well enough to make me happy.<br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com0tag:blogger.com,1999:blog-4044521577452379367.post-36302263997427498282008-04-05T07:38:00.005-04:002008-04-05T10:17:13.309-04:00Getting iMON 0038 LCD working with LCDprocYesterday I discussed <a href="http://mythtvblog.blogspot.com/2008/04/getting-imon-0038-lcd-working-with-lirc.html">how to get the iMON display working in LIRC</a>. The next step after that is to get the LCD display working. The most popular program for controlling the LCD is probably LCDproc. As it turns out, once you've got LIRC running the LCD properly, it's relatively easy to get LCDproc going too.<br /><br />Once again, these instructions are specific to the 0038 version of the iMON LCD. Other versions may need slightly different instruction. Check over at the codeka.com forums for details.<br /><br /><span class="fullpost"><br /><B><BIG>Step 1 - Making sure your LIRC installation is good</BIG></B><br /><br />LCDproc relies on the lirc_imon driver that is part of LIRC. If that isn't properly configured and installed, you have little hope of getting LCDproc going. Well, I've heard it's possible to have LCDproc control the LCD directly without LIRC, but I haven't tried it so I don't know if it's true, and even if you were to do so you'd lose its IR and front panel button capabilities. For this reason, LIRC is really the right way to go.<br /><br />To test if your LIRC installation is correct, you can run the following command:<br /><br />perl -e 'print pack "H*", "80000000091e0088"' > /dev/lcd0<br /><br />When you run this command you should see the LCD clear itself and then display a clock with the time "AM 09:30" (in an ugly font, where the 4's look like 9's, and are only different by a single pixel, but I digress). If that's what you get, then lirc_imon is configured fine. You can proceed to step 2 after resetting the LCD with the following command:<br /><br />perl -e 'print pack "H*", "4000000000000088"' > /dev/lcd0<br /><br /><br />If you weren't so lucky, then you might have a problem. First thing you want to do is make sure the driver is loaded:<br /><br />lsmod | grep lirc_imon<br /><br />You should get back a few lines of text that contain the lirc_imon driver and some other drivers (lirc_dev, usbcore, etc). If you get back nothing, try loading the driver manually:<br /><br />modprobe lirc_imon<br /><br />Then try running the command to set the clock again. If it works now, you may need to find a way to load the lirc_imon driver automatically (possibly by putting lirc_imon in /etc/modules). After that, you can proceed to step 2 (turn off the clock, first).<br /><br />If it STILL isn't working, go back again and test whether the iMONs IR and/or front panel buttons are still working with LIRC. If not, somehow you don't have LIRC built correctly, with the correct patches, so you need to fix that first. Check out <a href="http://mythtvblog.blogspot.com/2008/04/getting-imon-0038-lcd-working-with-lirc.html">yesterday's post on that topic</a>. However, if it does work, then my best guess is that LIRC thinks you have the VFD rather than the LCD and built the lirc_imon module for that device.<br /><br />If you configured LIRC for only a single device (the Soundgraph iMON IR/LCD), then it should have handled everything for you. However, if you are like me, and have a separate IR receiver that you are using, and thus need to install LIRC with multiple drivers, you probably configured it something like:<br /><br />./configure --with-driver=all<br /><br />As I covered in an update to my post on <a href="http://mythtvblog.blogspot.com/2008/04/setting-up-lirc-with-multiple-devices.html">setting up LIRC with multiple devices</a>, the --with-driver=all option will configure it to use the VFD rather than the LCD. You will need to change config.h so that the line:<br />/* #undef LIRC_IMON_LCD */<br /><br />becomes:<br />#define LIRC_IMON_LCD 1 <br /><br />and then recompile and reinstall LIRC. Then unload and reload the lirc_imon driver. Then once again try the perl command to set the clock. It should now work (once again, be sure to turn off the clock before proceeding). If you still have problems...I have no clue. You are on your own. Try posting over at the codeka.com forums.<br /><br /><B><BIG>Step 2 - Configuring LCDproc</BIG></B><br /><br />This is actually a much simpler process than it was configuring lirc. Once again, you will want to follow the <a href="http://codeka.com/forums/viewtopic.php?f=3&t=22">basic instructions post by Dean</a> at the codeka.com forums. However, you will want to make the following changes.<br /><br />1) Instead of using dean's lcdproc-0.5.2-imonlcd-0.3.patch patch, download <a href="http://www.ronfrazier.net/ronfrazier.net/mythtv/downloads/lcdproc-0.5.2-imonlcd-0.3-v2.patch">my slightly modified version</a>. I've made a few tweaks where he forgot to set an icon flag or set the wrong icon flag.<br /><br />2) After running automake but before running configure, you will want to download <a href="http://www.ronfrazier.net/ronfrazier.net/mythtv/downloads/lcdproc-imon_0038-v2.patch">my slightly modified version</a> of madCoder's patch for the 0038 model, and apply it by running<br /><br />patch -p1 <../lcdproc-imon_0038-v2.patch<br /><br />3) When you get to the part about modifying the /usr/local/etc/LCDd.conf file, rather than changing the file manually, you might want to start by <a href="http://www.ronfrazier.net/ronfrazier.net/mythtv/downloads/LCDd.conf.patch">downloading my patch</a> for the conf file and applying it with:<br /><br />patch /usr/local/etc/LCDd.conf ../LCDd.conf.patch <br /><br />This saves you from the error prone process of modifying it manually, especially since it's easy to leave off the leading or trailing slash on the DriverPath setting (in fact, deans instructions even left off the trailing slash).<br /><br />4) Dean mentions changing the RENDER_FREQ from 8 to 1. You might want to experiment with other values in between (2 to 4). While I found 8 to be too fast, 1 update per second was too slow for my tastes. If you decide to play around with it, you will need to recompile each time (it would be better to move this to the config file, but I didn't find it important enough to waste the effort on). After making a change, you do NOT need to rerun configure or any of the previous commands. Just make and make install.<br /><br /><B><BIG>Step 3 - Testing LCDproc</BIG></B><br /><br />This part is quite easy. Just run the following command:<br /><br />LCDd -f -r 4<br /><br />The display should light up with some text from LCDproc. If not...well, I really don't know what could have went wrong. Just make sure you carefully followed all of the instructions in the proper order (are you sure you ran the command to turn off the clock in step 1)?<br /><br /><br /><B><BIG>Thats it!</BIG></B><br /><br />See, it was quite easy. In fact, if you take a look at my instructions, you'll see that there was more detail involved with debugging your lirc_imon setup than there actually was getting LCDproc going.<br /><br />You can now go on to configure your other applications to interface with LCDproc. Sorry, I have no advice on that part yet. I'm actually working on my own interface program at the moment (it seems I've got more things going on than I have time to write about). I'm sure I'll talk about that at some point.<br /><br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com10tag:blogger.com,1999:blog-4044521577452379367.post-13365261634892362342008-04-04T06:25:00.010-04:002009-04-22T10:14:51.107-04:00Getting iMON 0038 LCD working with LIRCAs I mentioned before, getting the iMON display working was a bit troublesome. However, I managed to get it all working. Since it was so problematic, I'd like to share details of how I did it.<br /><br />Before continuing on, I have to give huge thank you to Dean Harding for setting up the codeka.com forums and for all the work he did with the iMON. Also, thanks to many of the people in those forums who provided followup info and helped troubleshoot/patch things to work with newer versions of the hardware (especially madCoder for his patch for the 0038 model).<br /><br />Also, I just want to say that, while the following instructions may seem a bit long, it really doesn't take that much work. A lot of this will just be verbose text. I'm trying to provide as thorough instructions as possible and describe whats going on, so that if you run into problems (ex: your configuration is a bit different), hopefully you will understand what needs to be done and figure out how to work around it.<br /><br /><span class="fullpost"><br /><B><BIG>Step 1 - Determine which version of the iMON you have</BIG></B><br /><br />First, you need to get the ID of your iMON device. Run the lsusb command and look for a line that says Soundgraph. Before that will be the ID string. In my case, it's 15c2:0038, with the 15c2 being the vendor ID and the 0038 the product ID. If this is the version you have, then the rest of the instructions on this page should hopefully get you up and running. <br /><br />If you have the 15c2:ffdc version, you have the original, and you can probably just follow <a href="http://codeka.com/forums/viewtopic.php?f=3&t=22">Deans instructions from codeka.com</a>. If you have another version number, then that means either Soundgraph has changed the device again, or you don't actually have the LCD (perhaps you have the VFD, which is a very different device). In either case, you can have a look around at the codeka.com forums and see someone has figured it out.<br /><br /><br /><B><BIG>Step 2 - Determine if usbhid is controlling the iMON</BIG></B><br /><br />Originally, the instruction I found for setting up the iMON display didn't work. I followed them to the letter, but had no luck. Well, as it turns out, it seems newer versions of the kernel (I'm running Debian 2.6.24) have support for the iMON in the usbhid driver. That means when the usbhid driver starts, it takes control of the iMON. Later, when the lirc_imon module loads, it's unable to take over the device.<br /><br />So the first step necessary in setting up the iMON is to make sure the usbhid driver hasn't taken control of it. Run "cat /proc/bus/usb/devices". The output of this will be 1 block of info for each USB device in on the system. You want to find the block(s) that has Vendor=152c and ProdID=0038. Then look down a few lines further in the block and look for the line that contains "Driver=". That will tell you what driver is loaded for that device. If the driver is "usbhid", you need to continue on to disable it. If it's "(none)", you can just skip step 3. If you see lirc_imon, then you already have the proper driver loaded. Anything else and you are on your own.<br /><br />---------------------------------------------------<br />Edit: It has come to my attention that /proc/bus/usb/devices doesn't exist on all systems. Apparently not every distribution has usbfs mounted. You can run the command<br /><br />mount -t usbfs none /proc/bus/usb<br /><br />to mount it, and then /proc/bus/usb/devices should exist.<br />---------------------------------------------------<br /><br /><B><BIG>Step 3 - Prevent usbhid from controlling the iMON</BIG></B><br /><br />Assuming the usbhid driver has been loaded, you now need to disable that. You probably don't want to completely disable the usbhid driver, because that can prevent other devices from working properly (such as usb keyboards and mice). Instead, you want to tell the driver to ignore your particular device. The following instruction work for the 2.6.24 kernel under Debian.<br /><br />1) Edit /etc/modprobe.d/usbhid (create it if it doesn't exist) and add the following line. The first hex code is the vendor ID, the second is the product ID, and the 0x0004 means ignore this device.<br /><br />options usbhid quirks=0x15c2:0x0038:0x0004<br /><br />2) Run the command: depmod -ae<br />3) You need to rebuild your initrd. If you are running a typical installation, you can do this by running:<br /><br />update-initramfs -u<br /><br /><br />In my case, I'm doing a diskless boot over NFS, so I had to do it slightly different. Edit /etc/initramfs-tools/initramfs.conf and make sure BOOT is set to nfs. The run "mkinitramfs -o initrd.img.netboot". Finally, copy the new initrd.img.netboot over to the appropriate location on the tftp boot server (and rename it if you are using a different filename in your setup).<br /><br />Once this is all done, a reboot should use the new settings and stop loading usbhid for your iMON. Run the "cat /proc/bus/usb/devices" once again. This time, the driver should be listed as (none). If it is still usbhid, do NOT continue on with these instruction until you've figured out how to deal with it for your particular distribution.<br /><br /><br /><B><BIG>Step 4 - Installing LIRC</BIG></B><br /><br />The basic installation instruction come from <a href="http://codeka.com/forums/viewtopic.php?f=3&t=22">this post in the codeka.com forums</a>. The patches to deal with the 0038 model come courtesy of <a href="http://codeka.com/forums/viewtopic.php?f=3&t=23&st=0&sk=t&sd=a#p150">this post by madCoder</a>. In addition, I've made a few small changes to the patch to deal with the iMON pad remote and the front panel buttons on the Thermaltake DH-101 case. Other cases with front panel buttons likely require this same patch. If you don't have this case, I don't really see any harm in using my patch anyway.<br /><br />You can get detailed info from the above 2 posts, but I'll summarize it below to help you keep things in order between both posts. Also, I'll provide links to actual patch files you can download, because copying and pasting the patch files from the forum are likely to get you "malformed patch" errors because of formatting issues.<br /><br />Also, before beginning, you'll want to make sure you don't already have an installation of LIRC by running "apt-get remove lirc"<br /><br />1) Make sure you have the prerequisites for LIRC installed <a href="http://www.lirc.org/cvs.html">as listed on this page</a>. In my case, I was able to do that through apt-get: <br /><br />apt-get install libtool automake1.9 autoconf<br /><br />2) Download the current version of LIRC from CVS. <br />3) <br /><DIV CLASS='tipbox'><br /><B>UPDATE:</B><br><br />With the latest version of lirc (as of sometime in early 2009) all the necessary patches have been included into the CVS version of lirc. It is now possible to get full iMon support without applying any patches to the CVS branch (at least until SoundGraph decides to create a new iMon device with different control codes :)<br /><br />Anyway, I'm crossing out the info that is no longer needed (but I'm leaving it here in case anyone has any use for it)<br /></DIV><br /><br /><span STYLE='text-decoration: line-through;'>The 0038 version of the iMON hardware requires you to patch the LIRC code first. <a href="http://www.ronfrazier.net/mythtv/downloads/lirc-imon_0038-v2.patch">Download this patch</a> and then install it by running the following command from within your LIRC directory:<br /><br />patch -p1 < lirc-imon_0038-v2.patch<br /></span><br /><br /><DIV CLASS='tipbox' STYLE='text-decoration: line-through;'><br /><B>UPDATE:</B><br><br />The code in CVS has changed slightly, and a critical part of the patch no longer applies automatically. Until I get a chance to update the patch, you will need to do the following AFTER applying the patch:<br><br /><OL><br /><LI>Edit drivers/lirc_imon/lirc_imon.c</LI><br /><LI>Find this line:<br><br />{ USB_DEVICE(0x15c2, 0xffdc) },</LI><br /><LI>Add this line after it:<br><br />{ USB_DEVICE(0x15c2, 0x0038) }, /* IR & LCD */</LI><br /></OL><br /><br />Then you can continue with the next step<br /><br /><B>UPDATE 2:</B><br><br />It looks like cvs has been updated to handle the new version of the imon. However, from what I've heard, it appears that the patch applied to cvs wasn't as comprehensive as the patch I applied, and some of the buttons on the pad remote as well as some of the case front panel buttons might not work.<br /><br />I haven't yet had a chance to look at the new version to see what it takes to get it going. In the mean time, if you would like to try with the old version from CVS, you can download the version I used from:<br /><a href="http://ronfrazier.net/mythtv/downloads/lirc-cvs.tar.gzip">http://ronfrazier.net/mythtv/downloads/lirc-cvs.tar.gzip</a><br /></DIV><br /><br /><br />4) Run autogen.sh and setup.sh. This will give you the configuration dialog. Choose the following sequence:<br /><br />Driver Configuration -> USB Devices -> Soundgraph iMON IR/LCD<br /><br />Save configuration & run configure<br /><br />5) Run make, make install, and then modprobe lirc_imon.<br /><br />With the 0038 version, you should have devices setup for /dev/lcd0, /dev/lcd1, /dev/lirc0, and /dev/lirc1. In addition, you are also going to have a device for /dev/lirc, but thats not really important. The actual devices we need are lirc0 and lirc1. <br /><br /><B>Notice to Ubuntu users:</B> I received an email from Sascha Zucca who said that after following these instructions, he did not get all of the appropriate devices showing up under /dev. After working through the problem with him, he discovered that Ubuntu was loading its modules from a different directory than the lirc installer was putting the compiled files in. As a result, even after installing the new modules, lirc was loading the old version without the iMON fixes. Here is how he told me he fixed it:<br /><br /><blockquote>i had to<br />mv /lib/modules/2.6.24-16-generic/ubuntu/media/lirc/lirc_imon/lirc_imon.ko{,.OLD}<br />and<br />ln -s /lib/modules/2.6.24-16-generic/misc/lirc_imon.ko /lib/modules/2.6.24-16-generic/ubuntu/media/lirc/lirc_imon/<br /></blockquote><br /><br />I've since received a half dozen emails from other users who encountered the same problem. Performing the same fix worked for each of them (taking into account that the path will be slightly different for different versions of Ubuntu). Also, take note of the line wrapping. Those are actually only 2 commands.<br /><br /><br /><B><BIG>FYI - Why are there 2 LIRC devices?</BIG></B><br /><br />The iMON pad remote acts like a mouse/keyboard in addition to a remote. In the old version, it was my understanding that this was all handled through one LIRC device. However, the 0038 version splits it into 2 devices. All of the mouse/keyboard related keys come through the lirc0 device (the directional pad, left click, enter, the number button, ect....however NOT including the Mouse/Keyboard toggle button). Everything else comes through the lirc1 device (play, eject, colored buttons, zoom, etc...plus the Mouse/Keyboard toggle button). Finally, if you have front panel button, they will also come through the lirc1 device (at least they do on the DH-101).<br /><br />If you have no plans to use the included remote, and plan to use a separate LIRC receiver with a different remote, you might think you can just skip the lirc0 part and use lirc1 for the front panel buttons. However, that may not work. Even if you don't use the iMON's IR receiver, it will still pick up some of the IR signals from certain remotes. When it does you will run into a problem. The iMON buffers up the inputs from each device separately, but maintains the sequence of events between the 2 buffers. If you only run the lirc1 device, everything will work fine until the iMON picks up an IR signal that it decides to put in the lirc0 buffer. When that happens, the lirc1 buffer will appear to have locked up and will not generate any more events. In reality, it's just maintaining the event sequence, and the next event is waiting to be removed from the lirc0 device. Until you do that, you will see no more events coming from the lirc1 device.<br /><br />Now, on to the testing. <br /><br /><br /><B><BIG>Step 5 - Testing and using LIRC</BIG></B><br /><br />First you are going to need a lircd.conf file. For the pad remote, you can download <a href="http://www.ronfrazier.net/mythtv/downloads/lircd-pad.conf">this file</a>. For the Thermaltake DH-101, you can download <a href="http://www.ronfrazier.net/mythtv/downloads/lircd-dh101.conf">this file</a>. If you want to use them both, you can just combine them into the same file. Whichever file you use (or both files combined), you will need to put that file in /etc/lircd.conf.<br /><br />Once lircd.conf is in place, you can do the actual testing of LIRC. You need to get both devices up and running. The way to do this it to run 2 copies of lircd. The first one needs to listen to a socket and output its events there. The second one connects to the remote socket, gets events from there, and combines those with its own events. Each of the 2 processes will be listening to a different iMON device. Run the following 2 commands:<br /><br />/usr/local/sbin/lircd --driver=default --device=/dev/lirc0 --pidfile=/var/run/lirc0.pid --listen=8765<br />/usr/local/sbin/lircd --driver=default --device=/dev/lirc1 --pidfile=/var/run/lirc1.pid --output=/dev/lircd --connect=localhost:8765<br /><br />Now you can run the irw program and start pressing buttons on the remote and/or front panel, and you should see the event output on the screen. If you have a different case and don't get output from the front panel buttons, you will need to record a custom configuration file for it using irrecord.<br /><br />First, you need to kill off the lircd processes (kill `pidof lircd`). Then you need to run irrecrd, but you need to point it at the right LIRC device:<br /><br />irrecord --device=/dev/lirc1 frontpanel-lircd.conf<br /><br />Follow the instructions to create your config file. When it's done, you will want to add the contents of frontpanel-lircd.conf to your /etc/lircd.conf file. Then restart both lircd processes and try irw again. Everything should be fine (hopefully)<br /><br /><br /><br /><B><BIG>Congratulations</BIG></B><br /><br />If you made it this far, then you must have got everything working. Now you probably want to do something useful with the LCD. The most common program to control it is LCDproc. I've covered getting LCDproc setup with the iMON <a href="http://mythtvblog.blogspot.com/2008/04/getting-imon-0038-lcd-working-with.html">in this post</a>.<br /><br />If you have any questions or problems, be sure to leave a post in the comments below, or email me (you can find my email address through the "My MythTV Patches & Add-ons" link at the top of the right hand column). Or you can post about it in the iMON forum over at codeka.com<br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com32tag:blogger.com,1999:blog-4044521577452379367.post-43156465621669700552008-04-02T21:22:00.003-04:002008-04-04T21:29:21.969-04:00Setting up LIRC with multiple devicesIn the process of building my latest mythbox, I've been doing a lot of adhoc experiments with a various things over the last few weeks. I thought it was time I start putting some of them together to start moving towards a working system. One of those things I needed to do was get all 3 of my lirc devices working together. The process turned out to be a bit trickier than I expected, but I got it done, and thought I'd share the details of a couple of the trickier spots<br /><br /><br /><span class="fullpost"><B><BIG>Why three lirc devices?</BIG></B><br /><br />I wish I could say I only needs one device, but unfortunately that's not the case. First of all, my new Thermaltake DH-101 case has a set of front panel buttons, and the driver handles those buttons by treating them like IR codes and sending them through LIRC. I certainly would like those buttons to work, so that's one device. <br /><br />In addition, as I discovered in my driver writing experiment, the iMON (which handles the front panel buttons) will block the input queue if it receives certain IR signals. The only way to unblock it is to remove those signal events from the queue, and the way that gets done is by exposing a second lirc interface. So, I need to have that interface working if I want my front panel buttons to continue working.<br /><br />Finally, since the iMON can only receive a very limited subset of IR signals, it is pretty much worthless as a general purpose IR receiver. Therefore, I have a separate receiver...the IRA-3 (which appears to lirc as an Irman).<br /><br /><br /><B><BIG>Compiling LIRC to support both drivers</BIG></B><br /><br />The 2 iMON interfaces use the lirc_imon kernel driver (via the lirc default driver), while the IRA-3 uses the irman driver. Therefor, I need to get both drivers installed. However, thats one are where lirc is a bit troublesome.<br /><br />The suggested approach is to configure/make/install lirc once for each individual driver, and then configure again with the --with-driver=all flag. This will configure lirc to make and install every supported lirc driver available. That's not exactly ideal, but it works. However, when I tried that, I got errors during the build complaining the the necessary bttv libraries were not installed and it couldn't continue. Now, it seemed silly to have to install dependancies for drivers I never even planned to use, so I was determined to find a better way.<br /><br />I tried every way I could think of to run configure: with individual --with-driver parameters (one for each driver), as well as using a single flag and specifying both drivers (space separated, comma separated, quoted, etc). Nothing I could come up with would work. After searching and finding no resolution, I started trying to hack the configure script (which got me nowhere). However, I eventually found a trick that worked...hack the generated makefile.<br /><br />The trick here was to configure it with --with-driver=all, and then edit the drivers/Makefile script. In here, there are 3 parameters to be edited. Each parameter contains a list of all the lirc drivers. You want to remove any drivers from that list you aren't interested in. The three parameters in that file you want to edit are: lirc_driver, DIST_SUBDIRS, and SUBDIRS. Once you've modified those lines to remove the extra drivers, just run the make and make install.<br /><br />-----------------------------------------------<br />Edit: Well, a few days later, I get to work trying to setup my lcd display and realize it's not working. It seems that compiling lirc for all drivers makes it pick and choose between some mutually exclusive settings. One of those setting was whether the lirc_imon driver is built for the LCD or the VFD. It picks the VFD. In order to fix this for the iMON LCD, after running configure you need to edit the config.h file (in addition to the drivers/Makefile). Change config.h so that the line:<br />/* #undef LIRC_IMON_LCD */<br /><br />becomes:<br />#define LIRC_IMON_LCD 1 <br /><br />Then continue on with the make and install. You may find a similar issue occurs with some of the other hardware.<br />-----------------------------------------------<br /><br /><B><BIG>Getting all 3 devices working</BIG></B><br /><br />Now that I had lirc installed with all the drivers, I needed to get the 3 lirc devices functions. First steps was to test them out individually using irw and then merge them together. Unfortunately, I had an odd bug which I was able to resolve, but can't explain. My lircd.conf file has definitions for 4 remotes (my hauppauge remote, my wife's tivo remote, the iMON Pad's IR codes, and the case's front panel butons). For some reason, the Tivo/Hauppauge remotes would work no matter which order they were in, but the, but the other 2 wouldn't work with the TiVo and hauppage remotes defined first. I had to switch the order to get all 4 to work. <br /><br />As far as I can tell, they are all valid definitions, and they all work. I was able to pinpoint the problem more specifically. If the earlier definition had the post_data_bits attribute definited, the iMON and front panel button definitions failed to work. Commenting it out fixed the problem with the lower definition (though it broke that one). Curiously enough, each of the 4 definitions has a post_data_bits attribute set, yet they all work fine when in the correct order. I can't seem to make sense of it.<br /><br /><br /><B><BIG>Getting them working together</BIG></B><br /><br />Now that I had each one working individually, I needed to get them working together through a single interface. I found documentation specifying how to use the listen and connect parameters to connect multiple lircd instances together. I tested, and that worked well enough for 2. However, as soon as I added the third, only one of the 3 would work.<br /><br />It turns out that lircd has its client/server model a bit different that what I'd expect and would believe is the normal way to do it. Normally, when you have multiple processes connected together by sockets, you have one server that listens on the port and then multiple clients that connect to the one socket. And indeed, if you attempt this with lirc, it works perfectly. The one server will happily establish connections with multiple clients, but it won't actually do anything.<br /><br />Instead, what you need to do is have all but 1 instance of lircd running as a server (ie: listening), and then have a single client connect to all of the servers, aggregate their data, and output it all on the single interface. Once I figured that out, it worked like a charm.<br /><br />Just for reference, in case you'd like to see the actual commands I used:<br /><br />lircd --driver=irman --device=/dev/lirc --pidfile=/var/run/lirc.pid --listen=9988<br /><br />lircd --driver=default --device=/dev/lirc1 --pidfile=/var/run/lirc1.pid --listen=9987<br /><br />lircd --driver=default --device=/dev/lirc0 --output=/dev/lircd --pidfile=/var/run/lirc0.pid --connect=localhost:9988 --connect=localhost:9987<br /><br /><br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com1tag:blogger.com,1999:blog-4044521577452379367.post-63572722336554675232008-03-30T07:54:00.006-04:002008-03-30T09:28:10.409-04:00Writing my first linux driver - Part 1I've always wanted to write a driver for a piece of hardware, but hadn't the slightest clue how to go about it. It seems like such a complex process...interfacing with the system at the kernel level, dealing with the necessary subsystems (ex: USB), reverse engineering the device's communication protocol. Where does a driver writing noob even begin?<br /><br /><span class="fullpost"><B><BIG>Getting my inspiration</BIG></B><br /><br />Luckily, I found a very insightful and well written series of articles by Greg Kroah-Hartman, who is the official maintainer of (among other things) the linux USB subsystem code. In his series, he covers all kinds of topics dealing with driver writing. Theres a lot of content, and it's not exactly laid out in step-by-step tutorial form. Still, it is by far the best resource out there that I've seen so far.<br /><br />A list of the articles is <a href="http://www.linuxjournal.com/user/800887/track">located here</a>. Lots of those articles are useful, but the most enlightening for someone getting started were the articles on <a href="http://www.linuxjournal.com/article/4786">writng usb drivers</a>, writing your first <a href="http://www.linuxjournal.com/article/7353">kernel space driver</a>, then rewriting the driver as <a href="http://www.linuxjournal.com/print/7466">a user space driver</a>. In addition, the article on <a href="http://www.linuxjournal.com/article/7582">snooping the usb stream</a> was helpful in figuring out how to reverse engineer a devices protocol from the working Windows driver that almost every usb device has.<br /><br /><br /><B><BIG>Choosing a device for my first driver</BIG></B><br /><br />So now that the series of articles had inspired me, I needed a piece of hardware to serve as my first driver. I quickly figured out a way to kill 2 birds with one stone.<br /><br />I've been having some success getting my LCD working, but I've been having some trouble with the IR part of it. It seems that when the IR sensor receives certain signals, it locks up and stops responding. However, it works fine under Windows, so theres some issue in the current linux driver for this device. <br /><br />The device seemed to be simple enough. I didn't envision a lot of back and forth communication. I envision a one way stream of incoming data for the IR sensor, and another of outgoing data to write to the LCD. The hardware didn't appear to have a lot of conditional states built into it. That meant there probably woulnd't be a lot of tricky reverse engineering such as "this command does X if the device is doing A, but Y if it's doing C, or Z if it's doing C or D" etc. Nope...it appeared it would (hopefully) be fairly straight forward.<br /><br /><br /><B><BIG>Reverse engineering the protocol</BIG></B><br /><br />If I needed to, I could always try to strip some protocol information out of the existing partially working driver. However, I figured it would be best to start out from scratch (that would be the most rewarding experience for my learning process).<br /><br />I downloaded a copy the Snoopy program for Windows, hooked the LCD up to my Windows system, installed the drivers, and started monitoring the stream with Snoopy. Snoopy has it's pluses and minuses. It's very simple to use, but it doesn't let you monitor the stream in real time. It records it all to a log file, which you can later look through. The entries are all timestamped (relative to the start of the log), so you can tell what happened and when.<br /><br />So first thing I did way was start up the log and watch the event counter grow. After a couple seconds, the counter stopped. I waited 10 second and the count remained steady. Great...that means I can look at that bunch and treat it as the initialization code. I then pressed a single button, waited for the event counter to stabilize, and then waited another 10. Then I started doing the same with other things (turn the volume knob, hit the menu key, switch the driver into graphic eq mode, etc). <br /><br />At the same time I was doing this, I was writing down on paper a list of what actions I took at each step, and what type of feedback I got for each action (text on the LCD changed, an icon blinked, etc). After doing this for about a dozen different actions, I stopped and saved the log file.<br /><br />Now, all I had to do was go through the list and start picking out some common things. I saw that every event had one pair of command codes in common. Looking at my notes, the one thing that every event had in common was that it blinked a particular icon. I now figured out the first code was to turn the icon on, and the other to turn it off. <br /><br />Comparing them, they were very similar codes. Almost all zeros, except for the last byte (which was identical), and one of the other bytes had a single bit set in one of the codes but not the other. I quickly figured out that the last byte indicated that we were toggling the icons, and which bits were set in the other bytes indicated which icons to turn on. <br /><br />I then looked at my written list. One of the other action had toggled a different icon. I suspected that If I looked in the corresponding series of events, I'd find an event where the command code had the same last byte, but a different set of bits turned on in the other bytes. Indeed, there was. I had now figured out how to toggle the icons. All that was left was to determine which bits handle which icons...a trivial task.<br /><br /><br /><B><BIG>Comming Attractions!</BIG></B><br /><br />Before I got much further in the debugging, I decided I needed to test my theory about the icon command. It was time to start writing a very basic driver. In my next post, I'll cover writing the first bits of driver code and putting my theories about the protocol to the test.<br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com0tag:blogger.com,1999:blog-4044521577452379367.post-37669536928649570752008-03-26T22:55:00.003-04:002015-08-12T13:36:11.264-04:00Got my Thermaltake DH-101 case with iMon LCDI'm currently in the process of building a dedicated frontend box for my living room. Choosing most of the hardware was easy, since I'm modeling this after my other myth boxes. However, for the case, I wanted something that would blend into the entertainment center a bit better. <br /><br />After looking for options for several weeks, trying to decide which HTPC case I like, I finally settled on the Thermaltake DH-101 case. It arrived yesterday, and I quickly began putting it together. Once it was up and running, my first task was to figure out how to get the new hardware features (the LCD and front panel control buttons) working. It's been tough, but I'm making progress.<br /><br /><br /><span class="fullpost"><B><BIG>iMon hardware is not linux friendly</BIG></B><br /><br />Not that it was any surprise, but Soundgraph (makers of the iMon hardware) have been less than helpful with using the iMon hardware on linux. They refuse to release a linux driver for the hardware, and that's really not such a big deal. There are plenty of people willing to write the drivers for them (as is usually the case for hardware under linux). However, they also refuse to release the protocol for the hardware. Thats not such a big deal either. Again, plenty of hardware hackers out there enjoy reverse engineering this stuff. <br /><br />The thing that is most annoying is that, after people went through the processes of reverse engineering the protocol and writing the driver for it, Soundgraph decided to suddenly change the hardware's protocol, thus breaking a lot of the work that had been done. Luckily (as can be expected) people have already gotten underway figuring things out again. <br /><br />The forums over at codeka.com have been filled with discussion about the iMon hardware, with lots of helpful advice on getting the hardware working. There's even info and patches that explain how to get the new iMon hardware (denoted by the hardware ID 15c2:0038). I wasn't having any luck at first, but I'm starting to make some progress here. I'll post more details in the coming days as I come up with a more concrete description of just what it takes.<br /><br /><br /><B><BIG>Initial impressions on the case</BIG></B><br /><br /><div class='amazonlink'><iframe src="http://rcm-na.amazon-adsystem.com/e/cm?t=bloggingabo09-20&o=1&p=8&l=as1&asins=B0011UDQYA&fc1=000000&IS2=1<1=_blank&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe></div>The case is very nicely constructed, and looks even better in person that what I had thought from the photos. Assembly was nice and easy, organization of the case was very good. However, I do have a few complaint. First, the stock fans are quite loud. I'm going to have to replace them with something else if this is to go in the living room. Second I'm a bit disappointed with the LCD. Besides the fact that I ended up with the new "redesigned, for more difficult linux compatibility" model, I'm also disappoint by which LCD color they used. <br /><br />The photos on the Thermaltake website all show the system used with the Soundgraph negative white LCD. However, the one I got is using the negative blue. Negative white has a dark, unlit background, so all you really see is the lit up elements (text and symbols). The negative blue, however, has the whole display backlight with a dimmer blue light. That has 2 downsides. First, it gives off more light. When you are in a datk room watching a movie, the fewer sources of bright light, the better. But more so than that, having the whole background lit up means less contrast for the characters being displayed. <br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com2tag:blogger.com,1999:blog-4044521577452379367.post-90111485159376923762008-03-25T06:27:00.003-04:002015-08-12T13:35:35.337-04:00Enabling Quality of Service for the HDHomeRunA few times recently, I've had problems where I was generating a large amount of bandwidth at the same time mythtv was recording a few HD programs from my HDHomeRun. The HDHomeRun transmits its data over the network via UDP instead of TCP, so when it ends up on the losing end of an oversaturated network, it's packets just get dropped and the data is never retransmitted. The end result is a lot of packet loss, and the recording will be full of skips and other corruption. Having damaged recordings is an unacceptable situation, and was something that I needed to resolve. Simply scheduling any heavy network activity around the recording schedule was not acceptable, either. I needed a better solution.<br /><br /><span class="fullpost"><br /><B><BIG>Upgrading the network</BIG></B><br /><DIV CLASS='amazonlink'><iframe src="http://rcm-na.amazon-adsystem.com/e/cm?t=bloggingabo09-20&o=1&p=8&l=as1&asins=B000FITKK8&fc1=000000&IS2=1<1=_blank&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe></DIV> As it just so happens, I also had another problem at the same time. My home network had grown considerably, and I was now out of ports on my router and switch. I needed to add another switch to the network. In looking around, I found the D-Link DGS-2208 and it seemed to be both inexpensive and had very good reviews. It also had something else I found interesting...support for 802.1p Quality of Service delivery. <br /><br /><br /><B><BIG>QoS on the HDHomeRun</BIG></B><br /><br />When I saw 802.1p support in the feature list, something clicked in my mind. I remember reading once that the HDHomeRun could enable Quality of Service flagging on its packets. I figured that would be a great feature to enable, to ensure that the HDHomeRun got priority over other devices when the network starts getting saturated. <br /><br />I figured it would be as simple as changing a setting in the HDHomeRun, and all data would be streamed with a QoS flag. Do that once, and it would be transparent to everything else. I promptly opened up a support ticket with Silicon Dust to find out how to do it. I got a prompt response back indicating how it could be done.<br /><br />As I expected, the solution was quite simple. Simply pass an extra flag to hdhomerun_config when you tell it where to stream the data to. Instead of<br /><br />hdhomerun_config FFFFFFFF set /tuner0/target "udp://192.168.0.10:5555"<br /><br />it would be<br /><br />hdhomerun_config FFFFFFFF set /tuner0/target "udp://192.168.0.10:5555 qos"<br /><br />(note...the quotes in the parameter list are important so that the qos string doesn't get treated as a separate parmaeter).<br /><br />I gave it a try and it worked. That was a very easy solution. However, there was a slight problem here. The way this was enabled meant that a patch would need to be applied to mythtv to enable this to happen each time it opened up the stream.<br /><br /><br /><B><BIG>Patching MythTV</BIG></B><br /><br />The patch to make this happen wasn't very difficult. There were only a few tiny changes that needed to take place. A single line of code could be used to accomplish this, except for the fact that 802.1p tagging is applied as part of the 802.1q standard for virtual LANs. This meant in order to QoS tag the packet, the packet had to be destined for a VLAN (the HDHomeRun uses VLAN 0). <br /><br />By default, linux will ignore packets that are received for a VLAN unless it has been explicitly configured to do otherwise. This means that a quick and dirty patch to mythtv would break HDHomeRun functionality for anyone who doesn't have VLANs configured, as the packets from the HDHomeRun would never be handled. Obviously, this needed to be a feature that could be toggled on/off in the capture card setup of mythtv-setup. This made the patch just a tiny bit more complex, because it requires a schema change to the database so you have somewhere to store this flag. Regardless, I was quickly able to code up the patch. I'll release it soon, but I first need to run a few things by the mythtv-dev mailing list.<br /><br /><br /><B><BIG>Enabling VLAN support under Debian</BIG></B><br /><br />As I mentioned, linux ignores packets destined for VLANs unless explicitly configured to do otherwise. It turns out that configuring Debian to handle a VLAN wasn't all that difficult.<br /><br />The first step was to install the vlan package ( apt-get install vlan ). Once that was done, you needed load the 8021q module ( modprobe 8021q ). Finally, you just needed to tell linux to accept packets for VLAN 0 on your adapter ( vconfig add eth0 0 ). Your network is now accepting VLAN 0 packets. This created an entry for eth0.0 under /proc/net/vlan/. If you view its contents ( cat /proc/net/vlan/eth0.0 ), it will give you network usage statistics for that VLAN.<br /><br />That last thing you need to do is make sure your VLAN configuration survives a reboot. Simply create a script called /etc/init.d/vlan that runs your modprobe and vconfig commands. This script can then be run automatically when your eth0 interface comes up by adding the line "up /etc/init.d/vlan" to your /etc/network/interfaces file in the section for "iface eth0".<br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com1tag:blogger.com,1999:blog-4044521577452379367.post-82649098675417598362008-03-20T20:23:00.003-04:002008-03-25T15:12:54.744-04:00Patch to configure mythmusic exit actionI released a tiny new patch today. This patch is for the mythmusic plugin. It allows you to configure the action you want mythtv to take when exiting the mythmusic plugin while music is playing back.<br /><br /><span class="fullpost">Currently, when you are use the mythmusic pluging and are playing some music, if you try to exit the plugin (perhaps to do other things in myth), you get prompted whether you want to stop playback or contiue playback. For myself, if I didn't want the music to keep playing, I'd hit the stop key first, so getting prompted every time gets a bit annoying. In addition, if I hit a jumppoint key (perhaps to jump into the photo gallery), music playback stops instantly with no option to exit.<br /><br />This patch gives you the option to configure the action to take when exiting. By default, it maintains the current behavior. However, you can also set it to always stop playing or to always continue playing. In either case, you can exit myth without being prompted. In addition, if you set it to always continue playing, it will do so even if you exit the plugin by using a jumppoint.<br /><br />This patch will work with either myth 0.21-fixes or trunk.<br /><br />You can download the patch file from <a href="http://cvs.mythtv.org/trac/ticket/5008">Ticket #5008</a>.<br /><br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com0tag:blogger.com,1999:blog-4044521577452379367.post-50666749804987156722008-03-19T20:55:00.001-04:002008-03-25T15:14:44.377-04:00My USB-UIRT failed on meJust when my wife was REALLY starting to take a liking to mythtv (she's been rejecting the mythbox for years, all the while desperately holding onto the TiVo), I suffered a tiny setback to my progress. I had to experience a hardware failure...my USB-UIRT died on me. Luckily my wife is pretty understanding of stuff like that, and I was able to get things back up and running quickly enough, so she really hardly noticed:<br /><br /><span class="fullpost"><B><BIG>My previous IR experience</BIG></B><br /><br />For several years, I had been using a IRA-3 serial port IR receiver from <a href="http://www.home-electro.com">http://www.home-electro.com</a>. I was very pleased with the device, and it served me quite well. However, when I decided to rebuild my entire mythtv system late last year, I decided I had a few additional needs. One, I wanted something that could transmit as well as receive. Second, I wanted a USB device that I could use to wake the machine up from suspend-to-ram when I pressed the power button on the remote. After searching around, the USB-UIRT seemed to be the device that best suited my needs and had some happy users.<br /><br /><B><BIG>Unhappy with the USB-UIRT</BIG></B><br /><br />My experiences with the device, however, had been less than satisfactory. First, there had been some code reverted in the latest kernels, and the device no longer functioned without patching and rebuilding a kernel driver. After spending a lot of time figuring that out, and then finally successfully getting it all working, the next release of the kernel seemed to fix the problem, so all of my work accomplished little. However, being that linux isn't an officially supported platform for the USB-UIRT, I could hardly blame the manufacturer (well...I guess I COULD blame them for not caring to support linux).<br /><br />Once the device was up and running, my next task was to program the device. I immediately had trouble, as irrecord kept telling me there was an error reading the signal. After much trial and error, I was able to brute force my way through the errors and get it to record my lircd.conf file. By contrast, my IRA-3 worked perfectly every time in this regard.<br /><br />Once that was working, the next thing I noticed was that the device was VERY finicky about the remote being pointed directly at it. If I pointed it just a tad too high, low, or to the side, it would only pick up the IR signal intermittently. A little more that that and it wouldn't see it at all. By contrast, with my IRA-3, I could point the remote at the ceiling, the opposite wall, or even stand in an adjacent room and it would still pick up the remote.<br /><br />Next came the task of getting the device to wake the machine from suspend. I was able to program it with my remote's power button signal and get it to wake the machine successfully. However, I then ran into the discovery that, as soon lirc tried to use the USB-UIRT, the device's state would somehow get corrupted and it would no longer wake the machine up. I would have to physically unplug the device before it would wake the system again. Thus I had my choice of using it for lirc, or using it to wake the machine, but not both.<br /><br />The final straw came this weekend. The USB-UIRT was working perfectly. I left the room, came back 30 minutes later, and the red light was stuck on. The device was no longer responding to IR signals, and nothing could get it to work again (rebooting or unplugging it didn't help). There were other posting of the same problem in the support forum, but no response was ever posted by the manufacturer. Now it looks like I'll need to send it back.<br /><br /><B><BIG>Final outcome</BIG></B><br /><br />Overall, I was quite disappointed in the device. It's performance was inferior to the IRA-3 in almost every respect. The one aspect where the USB-UIRT actually didn't disappoint me was with the IR emitter. I was able to get the IR emitter working successfully with little effort. However, I never got a chance to actually implement that aspect of it on my system, so I never got to put it through its paces.<br /><br />For now, luckily my IRA-3 was still sitting around, unused and functional. I was able reconfigure my myth frontend (drivers, config files, and scripts) and get it working in relatively short order. My wife barely noticed downtime. <br /><br />The only downside to the IRA-3...I've only got one serial port, and now I'm using it. I was just about set to start controlling my TV via the RS-232 serial port, but now I have to put that plan on hold. I've ordered a PCI serial port card and am waiting for it to arrive before I can continue. I've also still got to find a solution for waking the machine from suspend, and I may need to come up with another device to do the IR transmit functionality.<br /></span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com0tag:blogger.com,1999:blog-4044521577452379367.post-36628371515957802042008-03-19T20:50:00.003-04:002008-03-20T20:59:31.909-04:00Blog spam is a PITAI'm a few days later than expected in getting this blog started. It seems that google suspected my blog was blog spam (for reasons unknown) and locked it, so I had to wait for them to fix it. So, now it's time to get started...<br /><br /><br /><span class="fullpost">Don't bother to click this link</span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com0tag:blogger.com,1999:blog-4044521577452379367.post-47019168166012857062008-03-16T20:45:00.003-04:002008-03-20T20:58:53.651-04:00First PostI thought it would be useful to have a place where I can put some of my daily thought on using and developing mythtv. Somewhere to talk about features I'm working on, patches I release, problems I run into, things I discover, etc.<br /><br /><br /><span class="nofullpost">Don't bother to click this link</span>Ron Frazierhttp://www.blogger.com/profile/00837119718002987952noreply@blogger.com0