[HH] set top box.

[Tom Metro]

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