View unanswered posts    View active topics

All times are UTC - 6 hours





Post new topic Reply to topic  [ 8 posts ] 
Print view Previous topic   Next topic  
Author Message
Search for:
PostPosted: Wed Jul 25, 2007 10:56 pm 
Offline
Joined: Sun Apr 01, 2007 11:08 am
Posts: 12
I'm running KnoppMyth R5E50 on a Dragon 2 connected via FireWire to a DCT-6200 from Comcast in the Seattle area. I've had a consistently good FireWire connection until the past couple of days. I suspect it's my 6200's new TV Guide firmware...

A few days ago, we had a couple of power brownouts, and it seemed that since then, I'd been unable to get a consistent FireWire connection. The Dragon will record several shows, and then, seemingly for no reason, it will fail to record (only a black screen and no audio) until I do something to fix the FireWire connection (such as run firewire_tester -B or reboot the Dragon). Even then, sometimes I can't get any signal from FireWire at all. I'll get results like this:

Code:
mythtv@domino:~$ plugreport
Host Adapter 0
==============

Node 0 GUID 0x0016b5fffe04d0ec
------------------------------
oMPR n_plugs=1, data_rate=2, bcast_channel=63
oPCR[0] online=1, bcast_connection=0, n_p2p_connections=0
        channel=0, data_rate=1, overhead_id=0, payload=376
iMPR n_plugs=0, data_rate=2

Node 1 GUID 0x0090270001c28316
------------------------------
libiec61883 error: error reading oMPR
libiec61883 error: error reading iMPR

mythtv@domino:~$ firewire_tester -B -P0 -n0
Action: Attempt to fix broadcast connection 1 times, node 0
Broadcast: Testing...Failed (sync failed)
P2P: Testing...Failed
P2P: Testing...Failed
P2P: Testing...Failed (sync failed)
P2P: Testing...Failed (sync failed)
P2P: Testing...Failed
P2P: Testing...Failed (sync failed)
P2P: Testing...Failed (sync failed)
P2P: Testing...Failed (sync failed)
P2P: Testing...Failed
P2P: Testing...Failed (sync failed)
Broadcast Fix: Failed


I thought my DCT-6200 might have been fried during the brownouts, but I asked Comcast to send out a tech with a new one. He hooked it up and we verified its cable signal by looking at its composite video out. After some fiddling with the new box, I managed to get a signal over FireWire and could both watch live TV and record shows. Then, about 24 hours later, the Dragon lost the signal from the new set-top box and stopped recording shows.

The technician's theory was that my first set-top box had not been fried. During the same two or three days that my FireWire connection had been flaky, Comcast in Seattle had been uploading new software to their set-top boxes, replacing their original Microsoft firmware with some from TV Guide. Since we never use the menu system built into the set-top box, we hadn't even noticed the change. He said the old STB had partially overwritten the old software and rebooted itself several times, and this is probably what had caused the outages. The new STB came from the warehouse with the TV Guide firmware already installed, so it wouldn't need to go through that process and probably wouldn't give us any more trouble.

Unfortunately, it is giving us trouble. At this point, my guess is that the new TV Guide firmware has broken FireWire support. Asking for help with FireWire from Comcast is almost pointless; if I believed their line of blarney, I would never have hooked it up in the first place. For example, the tech who came to my apartment told me that Comcast had told him that FireWire ports on Comcast boxes were audio-only.

Does anyone have any other suggestions? Thanks!

Edit:

In the time it took me to write the post above, the FireWire came back. Without rebooting anything or running any other software than firewire_tester, I was able to watch live TV again and presumably record:

Code:
mythtv@domino:~$ firewire_tester -B -P0 -n0
Action: Attempt to fix broadcast connection 1 times, node 0
Broadcast: Testing...Success, 356 packets
Broadcast: Testing...Success, 386 packets
Broadcast: Testing...Success, 340 packets
Broadcast: Testing...Success, 194 packets
Broadcast: Testing...Success, 283 packets
Broadcast Fix: Success (already stable)


There doesn't seem to be any rhyme or reason to it, and I'm sure it will go out again soon. Your help would be appreciated.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 26, 2007 5:05 am 
Offline
Joined: Tue Jan 18, 2005 2:07 am
Posts: 1532
Location: California
I notice that the top of your post shows the output of plugreport; the second shows the output of firewire_tester. If you hadn't run firewire_tester the first time, then that's why you ran into problems. Take a look at this thread http://mysettopbox.tv/phpBB2/viewtopic. ... t=firewire

Also take a look at this -- http://mysettopbox.tv/phpBB2/viewtopic. ... t=firewire

I suspect that you are running into the problems discussed on these threads.

Marc


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jul 26, 2007 10:29 am 
Offline
Joined: Sun Apr 01, 2007 11:08 am
Posts: 12
If you look at the top of my post, you'll see I ran firewire_tester there as well.

After I posted, I cleared out some of the broken recordings from the past few days. I noticed that Myth seemed to have failed to record the same episode of the same show two or three times, so you may be right. Thanks!

I'll keep track of what shows it first chokes on and report back.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 27, 2007 5:39 am 
Offline
Joined: Tue Jan 18, 2005 2:07 am
Posts: 1532
Location: California
You're right -- I missed the reference to firewire_tester at the top of your original post. You are most likely being hit by the copy protection flag.

There is a diagnostic menu you can get into with the dct-6200 that will enable you to get info like signal strength, etc. One of the menus will display the state of the various protection flags, some of which vary by channel, other's of which can vary by which show is playing. I'm not at home right now so I can't double check this, but I think the process is something like this:

1. Tune the dct-6200 to the channel you want info on.

2. Hit the power-off button on the remote.

3. Immediately hit the "select" button. If you wait too long, the sequence will not work.

You will now be in a diagnostic menu that contains many options. I believe the option you want is "d06 - Current Channel Status". There are various flags there that talk about the level of protection -- I think the one that can change by program is called something like "CC" or "CCI"...

Marc


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 27, 2007 12:16 pm 
Offline
Joined: Sun Apr 01, 2007 11:08 am
Posts: 12
Thanks for all your help, Marc!

I'm often not aware of a show's failure to record until several hours after the fact. For example, this morning Myth choked on an episode of "Nova scienceNOW", an educational show Myth was recording on our local PBS affiliate at 6:00 AM, when I was asleep. Now that I'm awake and aware, it's too late to check the live feed. Is there a way to check it in Myth?

There are also some basic things I don't understand here. These are questions for the community. Obviously I don't expect you (Marc) to answer for Myth policy and development decisions, but if you can help, that would be great.

First, which copy protection flag are we talking about? Is it the Broadcast Flag?

http://www.eff.org/IP/broadcastflag/

The Broadcast Flag law was defeated (for the time being), it says here. So why would anyone be using it? Am I being naive here?

Second, why doesn't Myth simply ignore it? Isn't that part of the point of free software? Shouldn't it ignore flags like this, especially if they are being implemented illegally?

Third, why is my set top box being affected? After my setup choked on a show last night, my STB was hung and couldn't even change channels for several hours. When I called Comcast, they re-initialized it and Myth jumped to a new channel and started recording immediately. Please note that not being able to change channels is a well-known symptom of the recent TV Guide firmware rollout in Seattle, so much so that there's an automated FAQ about it when you phone Comcast.

Sigh. So much to learn, so much information people want to keep secret. :?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jul 27, 2007 11:33 pm 
Offline
Joined: Tue Jan 18, 2005 2:07 am
Posts: 1532
Location: California
Some quick answers:

1. The copy protection is enforced by the dct-6200, not mythtv. The dct-6200 attempts a handshake with the box at the other end of the firewire connection. If the handshake does not come back correctly, it stops sending data out the firewire port. In order for mythtv to implement a proper handshake response, the software would have to be certified by cable-labs -- something that won't happen because it is an expensive process and cable-labs will only certify devices that enforce the copy protection. My understanding is that TIVO had to remove the "tivo to go" feature to get their series 3 HD recorded certified (although I don't know for certain that this is true.)

2. I don't know why myth doesn't recover from this situation -- given that firewire_tester can reset the port and get things working again, I would imagine myth could incorporate the same error record logic.

3. If memory serves me correct, the flag is something like "CCI" or "CC" and stand for copy control indicator. I don't know how it relates to the broadcast flag, but I do not believe that there is anything illegal about this flag being set and enforced. Having said this, there are some in the community who feel that it is a violation of an FCC regulation.

Hope this helps answer your questions.

Marc


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 28, 2007 2:42 am 
Offline
Joined: Sun Apr 01, 2007 11:08 am
Posts: 12
Thanks, Marc. That does help.

I guess what I'm wondering is why MythTV doesn't tell my set top box what it wants to hear. For example, if my STB will lock up unless a ComplianTron HD-3000 PVR is recording, when my STB queries what kind of PVR it is, why doesn't MythTV respond, "I'm a ComplianTron HD-3000"? This kind of feature was added to Konqueror, for instance, so Konqueror users could browse websites that required Internet Explorer.

In other news, Seattle area Comcast users are experiencing problems with the new TV Guide firmware such that they can't change channels with the number pads on their remotes. I noticed the last time my STB locked up that I could watch video on the station it was stuck on over the composite connection, but couldn't change the channel with the remote, so I'm wondering if the one problem is related to the other -- is the STB locking up when Myth tries to change channels over FireWire? (The lockup does seem to happen in between shows.) It's kind of a long shot, but I turned "autotune" on on the STB and I'm waiting to see what happens.

I'm keeping a log of what shows Myth is trying to record when the STB freezes, and I don't see any rhyme or reason yet.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Jul 28, 2007 6:49 am 
Offline
Joined: Tue Jan 18, 2005 2:07 am
Posts: 1532
Location: California
My understanding is that only devices that have been certified by cablelabs have the capability of responding properly to the handshake. The handshake is encrypted or protected in some way, and cablelabs will not provide you with the necessary "stuff" (not sure exactly how it works) that enables a proper response to the handshake unless you pass their tests.

Some info on this stuff can be found at the following sites:

1. http://allformp3.com/dvd-faqs/111.htm

2. http://www.avsforum.com/avs-vb/printthr ... =134&pp=30


An extract from the first article:

Quote:
6) Digital Copy Protection System (DCPS)
In order to provide digital connections between components without allowing perfect digital copies, five digital copy protection systems were proposed to the CEA . The frontrunner is DTCP (digital transmission content protection), which focuses on IEEE 1394/FireWire but can be applied to other protocols. The draft proposal (called 5C, for the five companies that developed it) was made by Intel, Sony, Hitachi, Matsushita, and Toshiba in February 1998. Sony released a DTCP chip in mid 1999. Under DTCP, devices that are digitally connected, such as a DVD player and a digital TV or a digital VCR, exchange keys and authentication certificates to establish a secure channel. The DVD player encrypts the encoded audio/video signal as it sends it to the receiving device, which must decrypt it. This keeps other connected but unauthenticated devices from stealing the signal. No encryption is needed for content that is not copy protected. Security can be "renewed" by new content (such as new discs or new broadcasts) and new devices that carry updated keys and revocation lists (to identify unauthorized or compromised devices). A competing proposal, XCA (extended conditional access), from Zenith and Thomson, is similar to DTCP but can work with one-way digital interfaces (such as the EIA-762 RF remodulator standard) and uses smart cards for renewable security. Other proposals have been made by MRJ Technology, NDS, and Philips. In all five proposals, content is marked with CGMS-style flags of "copy freely", "copy once," "don't copy," and sometimes "no more copies". Digital devices that do nothing more than reproduce audio and video will be able to receive all data (as long as they can authenticate that they are playback-only devices). Digital recording devices are only able to receive data that is marked as copyable, and they must change the flag to "don't copy" or "no more copies" if the source is marked "copy once." DCPSes are designed for the next generation of digital TVs, digital receivers, and digital video recorders. They require new DVD players with digital connectors (such as those on DV equipment). These new products began to appear in 2003. Since the encryption is done by the player, no changes are needed to existing discs.


The setting of "copy freely", "copy once", "don't copy", etc., are the possible values of the copy control indicator (CCI), which is set by the original broadcaster. The broadcaster can turn this flag on and off on a per-show basis. The Motorola DCT-6200 chooses to enforce this flag. I suspect that any equipment you obtain from your cable provider will enforce these flags.

Not all of the cable service providers pass on this protection information when they re-transmit the shows over their network, but over the past year many of the cable operators have been upgrading their equipment to make sure this flag is included. My guess is that your local service provider recently made this type of change and that is why you are suddenly having the problem.

Marc


Top
 Profile  
 

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 


All times are UTC - 6 hours




Who is online

Users browsing this forum: No registered users and 17 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group

Theme Created By ceyhansuyu