Morph3ous's Weblog

Please note the last update at the bottom of this post. The issue was once again solved by a firmware update from Toshiba.
—
It took more than a month of back and forth to get the CableCARD working in the first place. Once the CableCARD was set up properly and the firmware for the Toshiba TV had been corrected everything was great… for a little more than 4 years. Then came Tuesday, September 8 2009 and everything changed.

If you’ve read my prior posts about Comcast and using a CableCARD you’ll see that it was a huge ordeal to get the CableCARD working in the first place.

The CableCARD is now not working properly. Many channels are working, but there are a large number that do not. When flipping to one of the channels the is not working the TV shows a black screen, then it goes to channel 3 and a message comes up stating the CableCARD is acquiring the channel information. Then once this information has been acquired, the TV changes to channel 1, but sometimes another channel.

I went through all of the HD channels to note which ones do not work. Here is the list:

• SunSports/FSN HD
• ESPNHD
• ESPN2 HD
• TNT HD
• A&E HD
• Food HD
• HGTV HD
• USA HD
• TBS HD
• History HD
• Discovery HD
• Animal Planet HD
• Sci-Fi HD

These are all channels we received before and are entitled to receive. I did not go through all of the standard definition channels, but I did note that ESPN and ESPN2 standard definition also exhibit the same behavior. This is not just limited to HD.

The problem began occurring on Tuesday, September 8 2009.

The same problems we had before getting this to work are now haunting us again. You would think that in 4 years Comcast would figure out how to get a CableCARD fixed and to properly escalate the issue to an engineer when needed.

I wanted to go through the standard channels rather than crying foul and going to higher levels as I had before. The idea was to give Comcast the benefit of the doubt. That was a mistake. Here’s the sequence of events that so far has not solved the problem:

• Called Comcast on Tuesday, September 8, 2009. We did some basic troubleshooting and they “hit” the card several times to no avail. We then scheduled a technician to come on Saturday, September 12, 2009.

  Saturday came and went and no one showed up. We called and whoever we had spoken to on Tuesday never even scheduled the appointment. We insisted someone be sent on Sunday.

• Sunday, a technician arrived, but he was never told this was a CableCARD issue and did not have one in his van. He had them hit the card several times and replaced some splitters in the house that were not faulty.

  The technician was really trying his best and wanted to do something, but the company had kind of screwed him over. He helped us schedule a technician to come on Tuesday, September 15, 2009.

• The technician, a Technical Operations Supervisor, Ryan came on September 15, 2009. He had a CableCARD, but this was just luck as his notes did not specify this was a CableCARD issue. He tried to get it working by trying a new CableCARD as well as hitting the card several times. This did not work.

  He promised to forward our information to an engineer to have the issue resolved. We were to be called by the supervisor shortly.

It is Saturday, September 26, 2009 and the issue has yet to be resolved and we have not heard a thing. This is unacceptable. Why does our city keep renewing your franchise agreement?

Update – Tuesday, September 28, 2009:
We emailled the technician and the engineer, Lazaro, came today. He tried around 8 CableCARDs. He also spoke with the DAC about our setup and everything checked out. There was a recent channel re-alignment that is likely the genesis of this problem. When we originally tried to get the TV working with a CableCARD years ago, there were firmware issues related to frequency response that had to be fixed. We are now getting in touch with Toshiba to check for an update.

We called Toshiba and new firmware is available and is to be shipped to us. Hopefully this will correct the issue.

Update – Monday, October 5, 2009:
The firmware arrived. It is Seine version 1.6.5. I installed it following the instructions Toshiba sent to the letter. The CableCARD is now working perfectly.

Due to a power failure, my NAS device was powered down. When the connection failed, the icon used to represent the NAS changed.

Normally it looks like a rack-mounted XServe, but when the connection was lost it showed up as an old-school CRT monitor with a Windows blue screen of death (BSOD).

Here’s a screenshot:

This is how the NAS normally appears:

To see how to customize the icon used on Mac OS for a UPNP-advertised device, please read the earlier post: Using MDNS to advertise OpenSolaris NAS to Mac computers

Since I’m using consumer drives that are prone to failure (one already failed within 2 days, but ZFS prevented any data loss).

I am using the script located here:
http://www.sun.com/bigadmin/scripts/submittedScripts/zpadmin.txt.

This will script allows for regular monitoring and scrubs of the pool with email alerting.

These next bunch of steps may not be necessary for everyone. I’m essentially setting up sendmail to use a smarthost. Even if you do need to use a smarthost, there may be an easier way by just modifying one line in the script.

Set smarthost for sendmail email delivery since ATT blocks outgoing port 25 on home DSL connections.

Steps learned from:

• http://www.elandsys.com/resources/sendmail/
• http://wiki.xdroop.com/space/sendmail/smart+host+ports
• http://www.dslreports.com/faq/11247

Edited sendmail.mc
cd /usr/lib/mail/cf
nano sendmail.mc

This line only needed if relay not using port 25:
define(`RELAY_MAILER_ARGS', `TCP $h 587')dnl

Added:
define(`RELAY_MAILER',`esmtp')dnl
define(`SMART_HOST', `relay:[SmartHostAddressGoesHere]')dnl

Commented out by adding # the followng line:
#define(`confFALLBACK_SMARTHOST', `mailhost$?m.$m$.')dnl

Then at the command line:
m4 /usr/lib/mail/m4/cf.m4 sendmail.mc > /etc/mail/sendmail.cf

Restarted sendmail
svcadm restart sendmail

Then I had to get the script working:

Steps taken:

• Created a directory called scripts
• downloaded the script
• renamed it
• set it to be executable
• edited settings
• scheduled with cron

mkdir /scripts
cd /scripts
wget http://www.sun.com/bigadmin/scripts/submittedScripts/zpadmin.txt
mv zpadmin.txt zpadmin.pl
chmod ug+x zpadmin.pl

Edit script. Need to at minimum change:
my $log_path=
Set mine to "/var/log/zpool_adm_log"
my $mailto =
I had to set my $mailhost = "127.0.0.1" might be due to some sort of misconfiguration on my end. This also means that some of the steps above for configuring the smarthost could have been avoided. I still think they are worthwhile because sendmail may be needed to send other sorts of alerts in the future.

Add to cron:
crontab -e

Crontab uses vi, so we need to enter:
G goes to last line of file
o opens new line after line you’re on and gets you into edit mode

Enter the following. Feel free to omit the commented lines if you’d like.
# ZPOOL MONITOR ->
0 * * * * /scripts/zpadmin.pl
# ZPOOL WEEKLY SCRUB ->
0 5 * * 0 /scripts/zpadmin.pl -scrub

Press Esc to get out of edit mode
Then :wq which tells vi to write the file and then quit.

Now your pools will be checked every hour and will be scrubbed once a week on Sunday at 5AM.

See cron on Wikipedia for more information.

This step is not necessary, but it seems like a good idea if you have Mac computers.

Create the XML files that tell MDNS what to advertise. (Found this information from here, here, and here.

Create /etc/avahi/services/smb.service with the following content:

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h</name>
<service>
<type>_device-info._tcp</type>
<port>548</port>
<txt-record>model=RackMac</txt-record>
</service>
<service>
<type>_smb._tcp</type>
<port>139</port>
</service>
</service-group>

The service that contains <txt-record>model=RackMac</txt-record> is only there so that on Mac computers the NAS shows up as an XServe server.

Enable mdns and the avahi-bridge-dsd service:
svcadm enable dns/multicast
svcadm enable avahi-bridge-dsd

I had to reboot the NAS after doing this before MDNS started working and properly advertising.

This is how the NAS appears on the Macs: