Bill Bogstad wrote: > Tom Metro wrote: >> If you're curious, you can see a picture of the type of remotes in >> question and the device they control here: >> http://mvpmc.wikispaces.com/Mediamvp > > You are still using a MediaMVP?
Sadly, yes. The problem is that it is still working, which lets me perpetually defer committing to a replacement. Maybe I'm holding out for something that's too perfect, but I haven't been enthused with the available options. On the one hand I want something cheap and appliance-like, like the MVP. On the other hand, having learned the lessons of the MVP, I want something that doesn't lock me into 1. only one firmware choice, and 2. an inability to use software codecs, as they are a constantly moving target. The firmware and dependency on hardware acceleration (and proprietary drivers) rules out almost all appliance devices, from WD Live boxes to Rukus to lesser known Chinese media players. A mini-ITX or other x86 small form factor PC is the obvious choice. Nvidia ION was hot for a while. Now its the AMD Fusion. This option is always more expensive, more D-I-Y, and almost always requires a fan (and thus more noise and power). But you can't beat the flexibility. About the most promising thing I've seen lately are platforms running Android, like the Pivos XIOS-DS, OUYA, or the more D-I-Y Odroid-x. These can run XBMC, and potentially an mvpmc port, and may have enough hardware horsepower to do some software video decoding. > Is that paired with PVR-150s as well? Yes. It had been paired to a PVR-500, and then also to an HDHR. Then Comcast killed unencrypted QAM, making the HDHR near useless. Then they killed analog channels, making the PVR-500 useless. So now I'm using a pair of PVR-150s (the PVR-500 has only one RF input) with a pair of DTA. I had the setup working pretty well with a simple channel changer script (like a 10-line Perl program found on the MythTV wiki, and slightly tweaked). One of the modifications I made was to have it call LIRC's irsend only once per channel change, passing it all the digits in one invocation. Only problem is that tuning to channel 11 or 33 would cause the repeated digit to drop or tuning to 217 would send you to 21. Apparently the timing in the config file didn't match the key debounce threshold on the DTA. I posted to the LIRC list about this, but didn't get any helpful guidance. I tried a bunch of semi-informed adjustments to the config, and was not able to resolve the problem. (Short of hooking up a scope to compare the real remote to the synthetic one and spending many hours.) Eventually I gave up and switched to a much more elaborate channel changer script that injects application-layer delays between calls to irsend for each digit. Coincident with this change, my setup developed a cross-talk problem. About 40% of the time, tuning tuner #1 results in tuner #2 seeing one or both digits sent to tuner #1. Some additional electrical tape later, I'm leaning away from it being optical leakage. Which leaves me really puzzled how it would have developed electrical cross-talk all of a sudden. (The IguanaIR sender I'm using has a known cross-talk issue, but it should be way down near the noise floor, and if it applied to my arrangement of emitters, it should have been a problem before.) I need to run some experiments, like unplugging the 2nd emitter, to definitively prove it is an electrically transmitted signal going to the 2nd DTA. I was just thinking that another possibility is that the channel changer script calls might be getting overlapped when both tuners are being tuned at the same time. (A real possibility when tuning consists first of a command to set the IR channel, then separate commands for each digit, all separated by delays, making a "wide" target for overlap.) My old channel changer script did nothing to address this (but it only invoked irsend twice, without delays). The new script actively combats this problem using SysV semaphores. While testing it, I ran it as my normal user ID, then deployed it and it failed when running as the mythtv user, due to a permission denial when accessing the semaphore. (I then ran a command line tool to delete the semaphore and all was well.) That seemed to suggest that the semaphore was working, but I didn't actually test it with two processes running as the same user. Maybe it's broken? The other issue I've ran into is that the PVR-150's seem to have a much lower default volume, and each time MythTV accesses a tuner, it resets the volume to the default. I've had to counter act that with a cron job that calls an ivtv command on the half hour. I migrated that to code that gets called as part of the channel changing process, but the timing isn't quite right yet. It seems if you correct the volume immediately after MythTV activates the tuner, it doesn't take. You have to delay a few seconds. If I stick with Comcast, and upgrade my front-end (and back-end), maybe I'll throw all of this out and switch to an HDHR Prime with a CableCard. -Tom _______________________________________________ Hardwarehacking mailing list [email protected] http://lists.blu.org/mailman/listinfo/hardwarehacking
