I would open up the DTC and see if there's anything obvious, like a lose connection. If not, send it back.

Sending back isnt really an option, I've had it a year or so.

Well I've got the DTC-100 open and I see no loose wires from the HDVR board. Also see no burn marks or anything to indicate a blown component on the board.

Now I am also getting errors like this:

ohci1394.o: Error in reception of SelfID packet [0x0005001c/0x000615fe] (count:0)
ohci1394.o: Error in reception of SelfID packet [0x0001001c/0x0003d36d] (count:0)

Kirby-

ohci1394.o: SelfID received outside of bus reset sequence

That error indicates your HDVR is not working but it does not mean that the connections are bad or a failed HDVR.

Two things to check- I have had both be the source of this error and
DTC-100 Unplug the DTC-100 for 5 minutes. Plug it back in and tune to an OTA channel that is an ATSC with HDTV on the -1 as -2 will fail on the 169Time hardware. Now connect 1394 your JVC VCR and wait for the I list to sense the connection. You should also see the power button flash. ( I have ver 1.6 so power button flashing may be different in newer board versions. Once that is ready, I'd test a recording to be sure or with the JVC, just look at the JVC output to see if signal is coming through. Oh, forgot, if you have version pror to 1.8 HDVR then you will not see a JVC I list identifier for the JVC 40K, That is why you check the video output on the Componet from the deck. Now plug in the AVX-1 tune to the sat channel and it should begin to interpret the data. If you still get the error as you stated. I have had some issues with my AVX and its 1394 board not making good connections to the MB. I reseated the board and then checked again and got results.

That's the order I would follow based on what you told me. It does sound like you have 1394 connection but the digital data flow is not there.
remedied it as follows-

In my 6000, which is still problematic, Richard and I are scratching our heads on this one as it definitly seems to be an HDVR failure of the connection. It will be going back for the 4th time after I do one more test here to check for HDVR connectivity. (Waithig for a female to female adapter to plug the 6000 into the AVX for his test. This is the third board so far. Last one was tested by him for 3 days and when it arrived here it was DOA! I get the same error message of Looking for HDVR and then stopping and then repeat. I don't get the ohci message so that is why I think your error is in the HDVR board with video and audio signal out, not the basic HDVR to AVX OHCI connection. Yours, in my opinion is a 169Time boot up issue.

Note that the older DTC-100 and HDVR often would lose data connection, sometimes in under a week and the simple way was to just unplug the 1394 cable for a second and reconnect it again (Mitsubishi 2000U standrd procedure.) This usually refreshes it but some times you need to do a Power cord 5 minute reboot to fire it up again. This is especially true if you decided to try another VCR or change anything in the 1394 network. This also could be an issue with the AVX but the most recent version is self correcting and reboot should now be only required when the AVX exceeds its buffer and stops. That takes about 8-10 days according to my records on it.

Hope all this helps.

Don, thanks, I will have to go find some coax to run an OTA signal to the DTC. I'll post results later. Thanks.

Originally posted by Don Landis
Kirby-

ohci1394.o: SelfID received outside of bus reset sequence

That error indicates your HDVR is not working but it does not mean that the connections are bad or a failed HDVR.

Two things to check- I have had both be the source of this error and
DTC-100 Unplug the DTC-100 for 5 minutes. Plug it back in and tune to an OTA channel that is an ATSC with HDTV on the -1 as -2 will fail on the 169Time hardware. Now connect 1394 your JVC VCR and wait for the I list to sense the connection. You should also see the power button flash. ( I have ver 1.6 so power button flashing may be different in newer board versions. Once that is ready, I'd test a recording to be sure or with the JVC, just look at the JVC output to see if signal is coming through. Oh, forgot, if you have version pror to 1.8 HDVR then you will not see a JVC I list identifier for the JVC 40K, That is why you check the video output on the Componet from the deck. Now plug in the AVX-1 tune to the sat channel and it should begin to interpret the data. If you still get the error as you stated. I have had some issues with my AVX and its 1394 board not making good connections to the MB. I reseated the board and then checked again and got results.

Ok, got an antenna signal to the DTC now. So I disconnected power from DTC100, and JVC-30k. also disconnected both ends of the 1394 cable between them, and antenna input and sat input on DTC100. Let it sit for 5 minutes. plugged antenna and sat back in, turned on DTC and JVC. Tuned to 30-1 with 76% signal strength. Hooked up the 1394 to JVC, and turned to I-, and nothing. Doesnt find the I- number for the DTC. Doesnt blink the power light. HDVR version is 1.7.

So no real need to try the sat signal to AVX, because something is obviously wrong with what I just did. Have any ideas? I should get a I- number on the JVC with just the DTC and JVC connected right?

Well I've been resetting this thing all afternoon, and cant get the JVC to sync an I- number with just the DTC at all. It syncs with my PC fine, and gives an I- number for the AVX fine. So my guess is that the HDVR is dead. But maybe I am wrong. I do know that in my normal setup, AVX - DTC - JVC (using both DTC ports) the JVC can still sync an I-link to the AVX, so the HDVR is at least operating enough to pass through the firewire from JVC to AVX.

If I have to replace/repair the HDVR, anyone know what Richard charges?

Is there any way to get the transport stream from the 169Time unit into a PC, exactly as the model 6000 receiver outputs it?

I understand that AVX1-remuxed output doesn't play correctly on all hardware decoders. I've written software that does offline remuxing, producing output that seems to play fine in every hardware decoder that I've tried. But I might need to get the transport stream from before the AVX1 messes with it to make use of it.

Can anyone tell me exactly what the AVX1 does to the stream?

balazar,

Your remuxing proposal sounds really interesting. I don't believe that avx-1 processing has ever been explained and it is the proprietary knowledge of 169time.

I was able to capture a stream from my DTC-100 HDVR directly to my PC with DVHSTool, but the PC lost the connection after about 3 minutes and the resulting files could not be played at all with the MyHD card. I would guess that the Dish 6000 could achieve similar results.

My method is encouraging in particular because it works with all of the channels on BEV. I understand that some of the BEV HD channels are not recordable at all by the 169time mod. (not that BEV channels are important, but this points to the "correctness" of my approach)

Kirby-

The connection time should be within a minute or so. Therefore I am beginning to agree with you but there is one other problem and I think you need to talk to Richard about this or maby Dave. You need to ask someone with a 30K and DTC-100. When I spoke to Richard, he told me that the JVC would not get an I number assigned on versions prior to 1.8. You have 1.7. I have 1.6 and I don't get an I-# for the DTC-100 HDVR. However, I am using the 40K and I'm thinking that WHAT Richard was saying was in reference to the 40K only. As far as the HDVR 169Time stuff is concerned, I understand these 40K's and 30K's react quite differently.

You're at a point where I think you need to really talk to Richard and see if he can give you some other tests to run.

If your AVX shows up on the 30K with an I number that that box seems to be OK as well as the 30K VCR. The DTC/HDVR is showing up at the AVX but it's I address is out of range error message on the AVX. That's how I would sum up your situation.

I can't wait until the 1394 coupler arrives here next week so I can complete my testing on the 6000. It should show up on the 40K because it is version 1.8. Actually it did one time for a moment on board #2 but then I lost audio and the 6000 was at fault. Very frustrating for me too.

balazer This has been posted here before but what I understand is that it converts the packet size of the modified MPEG2 for sat transmission to a standard MPEG2 required by the recorder in the case of DirecTV but I don't know what they are doing in the 6000. I would have always thought that a 6000 would not have non-standard MPEG2 packet size. It must be doing something else. I have yet to see a 6000 AVX working.

Kirby,

My JVC30k always shows an I-channel number for every firewire device on my home network, including the HDVR, the avx-1 and every PC. As Don suggested, if you can't get an I-channel for the HDVR, I think this is an question for Richard.

balazar,

Getting the avx-1 streams to be compatible with all the decoders has been the holy grail for many in this thread, including me. The A5 software was an improvement IMO, but there still seems to be a little more work to be done. Please keep us posted on your progress.

Does anyone know if the 169time firewire-modified STB's can function with a Macintosh-based HD HTPC? In other words, can the functions of the AVX-1 be duplicated on a Mac? Thanks, David

I don't think anyone has been able to record 169time sat chans without the help of the AVX1. Theoretically someone could write software to run on another OS (e.g.: Windows or OS-X), but apparently no one has done that yet.

Does anyone know if AVX recordings can be processed to remove null packets? Anyone doing it with success?

Kirby,

Your experience sounds exactly like mine. The JVC senses and recognizes the AVX, but will not recognize the DTC100 anymore. I contacted 169time and they suggested it was the JVC at fault. I then borrowed one JVC 3000 from a neighbor and it also could not recognize the DTC.

I will be sending in for repair after the Super Bowl as I have people coming over and a blank screen doesn't work too well.

By the way, Don, maybe I don't understand your post, but the JVC 3000 has always assigned an I-# to the HDVR from the first version. I probably missed what you were getting at.

Jeff

It is most definitely not my JVC 30k. It still plays nicely with the AVX and my PC. Its the HDVR thats dead. I had everything (JVC, DTC, AVX) disconnected from AC and all 1394 calbes removed overnight, reinstalled the DTC and JVC again, and still cant sync to the HDVR. I'll have to call Richard, but not today. Hopefully he will be willing to just swap out HDVR boards, so I dont have to pay shipping on the whole DTC back and forth (assuming of course that Richard doesnt have a trick up his sleeve to make it work again).

Originally posted by Kirby Baker
Does anyone know if AVX recordings can be processed to remove null packets? Anyone doing it with success?

Yes, you can use NullPacketStipper. It's a handy Java-based utility which does two very useful things. You can remove packets automatically or any PIDs you choose, and it will re-parse sequentially numbered .ts files to a new file length, or merge the files together.

http://www.hometheatersoftware.com/stuff/NullPacketStripper/

-Dylan

Is it possible to record OTAHD signal with 169time modded DST3000 to the 30K?

I'll try again, Is anyone recording OTA HD with the modded DST3000 & the AVX1? I tried on the LSU game a while back and the recording came out looking awful. It did record but the aspect ratio looked off and the quality was awful. From reading the 169time webpage it looks like it should work OK.

Jeff-

There are subtle differences in the 30K and 40K in the way it recognizes firewire on the HDVR. The latest firmware fixed that problem and both the HDVR and the AVX are listed in the 40K I kist. The down side of this is that the latest HDVR version no longner supports the Mitsubishi. Richard has assured me that if someone wants to use a Mits VCR he will supply an older firmware on the HDVR but then it will not display the 40K I-information. The 40K still works with the older firmware, however.

Update on my 6000/ HDVR testing. The 1394 couplers arrived today but unfortunately that test still failed. As a final thought before packing this 6000 up and shipping it back to Richard, I decided to peer inside the case with a flashlight. Very strange sighting. It is pretty hard for the HDVR to work if it is not even plugged in! I opened up the case and plugged it in and bingo! Within 2 minutes everything was sensed and I made a successful recording with the 40K for a few minutes. Now it's back in the rack and I have DishNetwork archiving to tape along with the 921 for time shifting. Happy days are here again!

Originally posted by Don Landis
Jeff-

There are subtle differences in the 30K and 40K in the way it recognizes firewire on the HDVR. The latest firmware fixed that problem and both the HDVR and the AVX are listed in the 40K I kist. The down side of this is that the latest HDVR version no longner supports the Mitsubishi. Richard has assured me that if someone wants to use a Mits VCR he will supply an older firmware on the HDVR but then it will not display the 40K I-information. The 40K still works with the older firmware, however.

Update on my 6000/ HDVR testing. The 1394 couplers arrived today but unfortunately that test still failed. As a final thought before packing this 6000 up and shipping it back to Richard, I decided to peer inside the case with a flashlight. Very strange sighting. It is pretty hard for the HDVR to work if it is not even plugged in! I opened up the case and plugged it in and bingo! Within 2 minutes everything was sensed and I made a successful recording with the 40K for a few minutes. Now it's back in the rack and I have DishNetwork archiving to tape along with the 921 for time shifting. Happy days are here again!

Don,

D-Theater and HDVR firmware version aside, what are the arguments for the JVC 30K/40K vs. the Mits D-VHS decks in a D* or E* 169Time implementation?

D* & E* themselves aside, do you have a preference as to the RCA DTC-100/AVX-1/D-VHS vs. the Dish 6000AVX-1/D-VHS in a 169Time implementation?

FYI


5C does not work as described above. It cannot be "added to the MPEG2 stream" to stop 169time upgrades.

5C WILL stop 5C compliant equipment from allowing copying, but it cannot control 169time equipment. Just like 169time upgrades, most computer
firewire are not 5C compliant 5C cannot control computers nor 169time
upgrades.

5C would only be effective in a factory installed firewire output. No consumer satellite box available in the USA today has a working 5C firewire outputs.

169time upgrades cannot be turned off by program providers. If you can watch the program, then the 169time upgrade will output the recordable digital signal to the connected recording equipment, i.e. computer or tape deck. They can't turn it off without turning off the receiver's usual video outputs.

Generally speaking, no matter how good the technical wizards claim their copy protection is (Macrovision, 5C, DVI), the truest fact is that the entertainment industry is, and should be very skeptical of any claimed copy protection technology. Yes, even DVI can be copied. It's simply too expensive to record from DVI today, since 169time sells a more economical method with their AVX1.

The entertainment industry knows quite well from actual working experience that copy protection technology is not effective. It merely creates a market for devices to remove copy protection.

Since there is no copy protection that is "perfect," obviously the best approach that the entetainment industry can take is to completely eliminate recordable digital outputs on all HDTV set top boxes, and they have.

5C is really not the issue. If entertainment industry had even the smallest spark of an idea to allow firewire outputs, all boxes would have 5C firewire outputs. Instead none of the boxes have a firewire output except for the 921, and it's is turned off.

Dish Network is only a middleman, in the same position of signal
distribution as DirecTV, Cable HDTV, Voom, BellExpress, etc. Dish Network
will not be able to allow digital copying of HDTV any sooner than the entertainment industry will allow all the other signal distributors to output a recordable digital signal, and this is probably never.

I heard from an AVS member that at Charley Chat, it was announced that firewire would never be activated in the 921, but might in some future model.

IMHO, it was a marketing blunder to put those firewire outputs on the 921 at all. Perhaps Dish / JVC had been overly optimistic and had the idea they'd be able to get the 921's firewire approved in time to replace the 5000's modulator.

Dish network knows quite well that most anyone still running a 5000 for HDTV does this for the recording output, which is claimed to soon be defunct.

Unless the entertainment industry believes they can make money from allowing consumers to record HDTV, the 921's firewire outputs will remain off.

Of course the 921's firewire might someday be enabled for OTA recording, but that would be inferior to the 169time upgrades that are already working and allow recording from OTA and satellite.

With the example of the terrible effect digital copying and the internet has already had on the music industry, the entertainment industry will likley never allow recordable digital outputs for any subscription based HDTV signals.

Bottom line- only 169time upgrades allow recording satellite HDTV outside of the built in hard drive. This will remain true for the foreseeable future.


fyi

Dave

Dave,

So, why us it that Cablevision is today delivering HDTV, OTA channels and Premium Channels like HBOHD, over cable with an activated FireWire to D-VHS output?

And the answer is...?

I tried recording an OTA signal again tonight on Gladiator. I was getting a signal for audio & video. When I play back the tape I get sound with a black screen. If I fast foward then I can see the picture but the picture has blocky lines through it. I can see the picture well enough to recognize where in the movie it is and it is an HD picture. If I restart the Play,then the last picture that was left from the FF remains on the screen I'm getting mostly perfect recordings from the satellite stations through the DST3000 & JVC30K w AVX1. What am I doing wrong?

http://www.avsforum.com/avs-vb/showthread.php?s=&threadid=358090

"D-Theater and HDVR firmware version aside, what are the arguments for the JVC 30K/40K vs. the Mits D-VHS decks in a D* or E* 169Time implementation?"

Please understand that I have far less experience with the JVC40K as I do with the Mits 2000U.

In the nut shell- The JVC40K with the latest HDVR firmware, seems to be a faster setup, and 1394 connect, easier to use with respect to not having to refresh the 1394 connection and simply make a recording from power off mode. By comparison, the MIts2000U with the older firmware that is known to support the MIts VCR, the connection is a real kludge. It takes quite a bit of procedure to get working from power up. Not at all intuitive and many of the steps are not even visible. But once connected it just plain works.
Performance- After both are connected (handshaked) the performance of the Mits2000U has a proven track record of producing near flawless recordings consistently with even mediocre tape quality. It is featureless and requires another device to view the tapes since the Mits does not have any way to connect to a standard analog monitor. The JVC40K, in my brief experience has been shown to be extremely tape quality sensitive. It will pixelate out far more often (people often call this a glitch as well) than I have ever seen in the MIts. Tapes recorded with the 40K will play back on the 40K with pixelated and glitches that do not show up when the same tape is played back on the Mits2000U. Tapes made on the old Panny PVHS1000 also play with more glitches on the 40K when played on the Panny or the Mits. These are all subjective observations and not based on statistical studies.

I think the track record with the JVC has been well defined over the past 2 years. It is a good machine with nice features but has a fragile design when it comes to tape quality. Perfect tape quality = perfect playback. Slight imperfection in the tape and you will see it in the output. Mits- very forgiving on imperfections with the tape and the recording. Dare I hint better error correction, in VCR lingo- "DOC" or Drop Out Compensator.

Dave- I respectfully disagree with your assessment in your editorial of the 5C encryption process. At one time I wasn't sure but after reading the way it works, it appears that the only way the program MPEG2 stream encrypted with 5C code will be passed over the 1394 connection is if both the source device and the sink device are 5C compliant. This is true even for copy many flag set in the encryption data. Consequently, once 5C encryption has been added by the program creator, 1394 devices that are not compliant will not pass the MPEG2 stream over the 1394 connection. The only way around this would be to decode the MPEG2 stream, strip off the 5C encryption code before the data sees the first instance of non-1394 5C compliant hardware, and then allow the stripped file to be sent via the non- 5C compliant hardware, source and sink. This process has been made quite clear in the literature.

addendum- opinion: Just to be clear, I wish, as in "dream", that I am wrong and you are right. That 5C is as ineffective as you believe because that would be of great benefit to all of us recording enthusiasts. But unfortunately for us 5C is a far more robust form of encryption than Macrovision ALC, which was a joke on their own customers, copy protection ever was.

Whether the 5C encryption will ever be compromised is an entirely different issue. I happen to think that it will based on history. But, in the meantime, the transport of any 5C encrypted MPEG2 data stream will be foiled by non-compliant hardware.

I agree with you that 5C will not stop 169Time from developing its product line but this has more to do with legal issues than technical. There is nothing that MPAA or the industry can do to prevent 169Time from making it's products short of hostile business tacticts and big money. Whether they will work with the encrypted signals is different issue. I also believe that it may be possible for 169Time to develop a way to achieve signals via another high speed data connection to a computer where the owner could "hack" the code and strip the 5C out of the files and then dump that stripped file back to the DVHS tape, 5C free. This has possibilities using USB2.0 which is not part of the 5C encryption process. eg. build a new HDVR board with USB2.0 output. Send this MPEG2 data to the computer hard drive via USB2.0 complete with 5C encryption. Now once in the computer either play it as is(5C will be inert as it doesn't go to work until it sees 1394 source and sink hardware) or strip the 5c using a hacking method (which is most likely a violation of DMCA) and then transport that file back out to DVHS tape via 1394 for archival or duplication purposes.

Don,

Did you catch the projected street price and availability of the JVC HM-DH40000's upcoming replacement model w/DVI & ATSC Tuner at CES?

Don,
Have you tried the VU-V13U head cleaning tape? I think this tape has solved most of my glitch problems at least for now. Seems like many others have also had success using this tape.

No info available on that model, Murray.

I have been reading about the latest snake oil of cleaning tapes. :D , I'm in the habit of manual cleaning with proper solvent but the 40K here is so new, I'd be really worried if one needed to use a head cleaner before the first tape was used. I think my 40K has less than 20 hours to date.

Don,

Have you had any experience with the JVC 40K and the popular Fuji S-VHS T120's and 160's?

Originally posted by Don Landis
Dave- I respectfully disagree with your assessment in your editorial of the 5C encryption process. At one time I wasn't sure but after reading the way it works, it appears that the only way the program MPEG2 stream encrypted with 5C code will be passed over the 1394 connection is if both the source device and the sink device are 5C compliant. This is true even for copy many flag set in the encryption data. Consequently, once 5C encryption has been added by the program creator, 1394 devices that are not compliant will not pass the MPEG2 stream over the 1394 connection. The only way around this would be to decode the MPEG2 stream, strip off the 5C encryption code before the data sees the first instance of non-1394 5C compliant hardware, and then allow the stripped file to be sent via the non- 5C compliant hardware, source and sink. This process has been made quite clear in the literature.


Don, the last few weeks I've been doing tons of research trying to figure out the feasibility of adding firewire to a box using publicly available 1394 link layer chip-sets. I wasn't optimistic, but I went at it anyways. Long story short, it wouldn't be worth it and it's beyond me, and even if I could get it to work, it would be useless once 5C flags are on, which brings me to point out that I think you're incorrect and that Dave is right.

The 5C encryption process takes place within the 1394 link layer, not beforehand. The DTC100, for example, is totally incapable of encrypting or decrypting any video signal with 5C protection, nor is the signal encrypted from the broadcast source (it's only flagged). The firewire aspect of a legitimate firewire box is what does the encrypting. This is also how HDCP works I believe, the encryption takes place within the DVI transmitter itself.

There are two types of legitimate 5C compliant 1394 chipsets. Both are exactly the same except one is publicly available, and the other is not because it has encryption/decryption capability.

For the public kind, you can go to arrow.com or wherever and buy everything you need. These are most likely what's found in the DVHS decks. If someone knew how to program these, had the means to make a PCB, and knew how to interface it with a particular box, it would work. However, because it's 5C complaint, it won't pass through any flagged material. ATSC stuff would probably still work though.

Then there's the second type of chipset, which is available to DTCP licensees only. This is how the signal is encrypted, through these chips. They encrypt on one end (hypothetical legal firewire D* receiver) and the same chip is used to decrypt on the other end (hypothetical legal firewire D* DVR). This is the only instance of encryption- when the signal is actually on the firewire bus. The idea behind it is to protect against people plugging the firewire port into a PC or whatever and hacking it. But before it reaches the link layer, it's totally exposed.

The 169time HDVR is clearly neither of the above. If it were, there would be no need for an AVX1, and it would have always worked flawlessly w/o hiccups from the beginning, but of course it wouldn't pass flagged material. It could be a custom FPGA or possibly a hacked/modded "legitimate" chipset. If I had to guess, I would say that it's a 1394 chipset not meant video, and that Richard has programmed it to pass along packets anyways. I really don't know what it is cause I don't have one. But whatever it is, logic suggests that it's perfectly capable of ignoring the flags and passing the stream along.

Originally posted by Don Landis
At one time I wasn't sure but after reading the way it works, it appears that the only way the program MPEG2 stream encrypted with 5C code will be passed over the 1394 connection is if both the source device and the sink device are 5C compliant. This is true even for copy many flag set in the encryption data. Consequently, once 5C encryption has been added by the program creator, 1394 devices that are not compliant will not pass the MPEG2 stream over the 1394 connection. ...

First, remember that 5c encryption only applies on the FireWire link. Outside of that, the only thing 5c can do is put its descriptor in the stream, and enforce some kind of 5c compliance in 5c devices.


*** The program creator cannot add 5c encryption. *** All they can do is send the descriptor. It's up to the 5c-compliant device to look at the descriptor and decide if the content needs to be encrypted on the FireWire link, or otherwise restricted.


The question: what happens when a non-5c source device is connected to a 5c-compliant recorder, and the source program has the 5c copy-once or copy-never descriptor in it?

A clever person (not myself) has tested for this, and found that it depends on the recorder: the JVC recorder refuses to record. The Mitsubishi records just fine. I don't know if the 5c spec allows for that variability. Perhaps the Mitsubishi recorder is not fully 5c compliant. Both recorders happily recorded copy-freely content.

Regardless, the very fact that the source device is willing to deliver copy-once or copy-never content over a non-5c link means that the content has already been compromised. All you'd need to do is hook up a non-5c recorder (like a PC). Once you get the data into a PC, you can remove the 5c descriptor completely, if you want.

Another important point: it is not necessarily the case that if DISH or whoever puts a 5c descriptor in the satellite signal, the 169Time unit will pass that descriptor through to the FireWire output. The descriptor is not embedded in the video; it's in one of the program tables. The program tables are not necessarily passed through by the 169Time unit. It's entirely likely that new tables are generated by the HDVR or the AVX1.

The thing I'm having trouble with, is that it doesn't sound like 5C would be good for anything if it's so easy for anybody to evade it? If you can put unsecure firewire nodes in a link-up and they can recieve 5C flaged material, then what's the point? Isn't 5C *only* supposed to work when all of the components in a chain are compliant?

That's what I can't wrap my head around. Is it true then that this was just another nonworkable DRM scheme that hawkers managed to sell to content owners?

If the sending end is 5c-compliant and the content is flagged copy-never, then the receiving end needs to be 5c-compliant also.

I don't understand what you don't understand. 5c is only as good as the devices that are using it. If you make a new device that doesn't use 5c (e.g. 169Time), then of course it is not bound by any 5c restriction. 5c is copy protection, not access control.

The idea was that every satellite receiver with a FireWire output would be 5c-compliant. Under that scenario, 5c does exactly what it is supposed to. But the reality is that there are ways to avoid that scenario, including what 169Time did.

Rumors are floating around that D* is going to do some brash things this year including swapping out lots of old receivers with new SD PVRs (non TiVo) that can receive 8PSK signals.

Imagine if they also swap out all the existing DTC100s with some new 8PSK compatable HD receivers. Lots more channels, but no more D* 169time...

The way I understand it, and I could be 100% wrong is:

If a 5c compliant device – let’s just say it is a 921 (I wish!) is going to connect to a non-5c device it won’t send anything other than ‘Copy As Much As You Like’ video. If it marked as copy once or copy never then it won’t send the data to a non-5c device. So to be able to archive something from the 921 to tape you would need a 5c compliant tape device because if they ever do enable the fire wire I’m sure everything will be at least ‘copy once’ if not ‘copy never’.

I think the reason that 169time stuff may still work even after 5c is because they just tap the mpeg stream and send the data out their non-5c fire wire. Because the 6000 doesn’t know about the 169time device snooping the bus all is well. On the other side of the coin I don’t see what would stop Dish Network from changing something in the 6000 to stop the 169time device from working. I’m sure this would only happen if there were enough of the 6000s around that people were installing the 169time modification and if Dish had pressure from providers to stop it. It is ironic in that the better the 169time mod gets, the more they sell, the more likely it is to be killed by Dish Network.

Again this is simply my understanding and I could be completely wrong.

More power to 169time – I may need one of their modifications to my 6000!

Originally posted by shah8
The thing I'm having trouble with, is that it doesn't sound like 5C would be good for anything if it's so easy for anybody to evade it? If you can put unsecure firewire nodes in a link-up and they can recieve 5C flaged material, then what's the point? Isn't 5C *only* supposed to work when all of the components in a chain are compliant?

That's what I can't wrap my head around. Is it true then that this was just another nonworkable DRM scheme that hawkers managed to sell to content owners?

Being flagged and being encrypted are two completely different things.

The flag tells the link layer to encrypt the signal, among other things. Once that happens, you cannot do anything with it until it's decrypted by a similar device. This pretty much eliminates people from hacking the thing without a soldering iron, which is the primary goal.

Using a non-5C device to convert the parallel MPEG stream into serial (firewire), which is what the 169time HDVR is, then the flags do nothing.

In other words, 5C "triggers" the the commands and the firewire device (if it's 5C compliant) reacts accordingly. Either by encrypting and passing along (5C chipsets with encrytpion/decryption capability), or by ignoring it and not passing it along (5C compliant devices that do not have encryption capability).

You can find more information here in these links. This is the encrytion/decrytion enabled device, only available to DTCP licensees:
http://focus.ti.com/docs/prod/folders/print/tsb42aa4.html

And this is the same thing but with no encryption/decryption. But because it's still 5C compliant it will refuse to accept streams that contain the flags:
http://focus.ti.com/docs/prod/folders/print/tsb42ab4.html

Those are just the basic link layer controllers. TI also makes an integrated chipset with everything you need and here is a link to a company that already manufactures a complete PCB solution for it:
http://www.mindready.com/pdf/rts/Mindready_SedNet_1394_AV_Board.pdf

Mike Greer, your explanation was the clearest.

I was sorta asking for what the general role is, which balazar and lifter has given, and why it was so, which hasn't quite been answered...

but I know now why 169time might still work.

It's still a stupid system, though...access control and encryption should not be two seperate beasts if you expect the entire system to remain secure.

"A clever person (not myself) has tested for this, and found that it depends on the recorder: the JVC recorder refuses to record. The Mitsubishi records just fine. I don't know if the 5c spec allows for that variability. Perhaps the Mitsubishi recorder is not fully 5c compliant. Both recorders happily recorded copy-freely content."

Who did this?

I don't see how this could be but if it is true it pretty much means that the Mitsubishi will not work with the 921 or any new 5c compliant device. This would amount to the destruction of 5c and the prices for the Mitsubishi would sky rocket!

Most of you all are examining the sending end only. I was told that the system of 5C protection requires 5C compliancy at both ends or the flagged signal will not pass. Given that 169Time HDVR is not compliant. Connect it to a 5C complaint VCR. Now send a program along with 5C flag, any of the three. The 5C compliant VCR will refuse to accept the signal for recording. I don't think it gets any simpler than that!

Now if one of you all can produce a VCR that is not 5C compliant, then we can debate whether that will work or not until such time as we can prove it one way or the other.

Don,
What you're saying about 5c only working for a flagged stream when both ends are compliant presumes that the source is compliant. As soon as you have a non-5c source, the copy protection scheme has already failed. There may not be any non-5c D-VHS recorders, but every Windows XP machine with FireWire is a non-5c recorder.

It's the sender's job to establish a secure connection, or refuse to send if the receiver is incapable of making a secure connection. If the sender is willing to send the data over an insecure link, then it doesn't really matter what the receiver does, because there are receivers out there that are non-5c and perfectly willing to accept the data.

The person who did the test wishes to remain anonymous. But it's not a hard thing to test yourself. Just add the 5c descriptor to a stream on your PC, and then send it to a D-VHS recorder and see what happens.

For any copy protection scheme to work, it requires compliance on the part of every device that handles the stream.


I must again stress that we don't know that the 169Time unit would even pass the 5c descriptor, if it were present in the satellite stream.


Mike,
Just because the Mitsubishi is willing to receive data from a non-5c source even with copy-never flags present DOESN'T mean it is not capable of making a secure connection to a 5c source.

Don, the easiest example of a non-5c VCR is a computer running DVHStool. I know that there are also a few early Panasonics that don't have the 5c firmware.

It may be true that a 5c compliant 'sender' won't talk at all to a non-5c receiver but I don't see the connection to 169time.

The Dish 6000 receiver doesn't know what 5c is so it can't listen to it.

If I understand, and I may not, 5c works with 1394 not with an MPEG stream. The 5c flags are only in firewire not in an MPEG stream. In other words if the 921 does get enabled it will be the job of the 921 to receive the flag of 'Copy once' and then tell the DVHS 'This information can only be recorded this time'. Because the 6000/169time solution doesn't watch for the flag it never tells the receiver to only allow 'this one recording'.

Am I missing something?

-Mike

Sorry about the restating some of the same info - posted a few seconds after you.

I don't understand what you mean by:

"Mike, Just because the Mitsubishi is willing to receive data from a non-5c source even with copy-never flags present DOESN'T mean it is not capable of making a secure connection to a 5c source."

It's getting late - I may be loosing it!

"Snake Oil" or not, the cleaning tape is working for me. I couldn't even get a watchable recording on a Fuji 160 SVHS tape before using the cleaning tape. Although I still may get one or two glitches on a 2plus hour movie on the 160, the glitch level is now very acceptable even on these tapes. When I first got the 40K it worked well with few glitches but after a period of time it got much worse. With DVHS tapes I am now getting more perfect(or near perfect) recordings. I'm not really worried about destroying the heads. I have never had a head on any recording device I have ever owned wear out before I quit using it anyway. I would hope that in 5 years from now we will have better source material and these tapes I'm recording now will be obsolete. I don't watch my Lasers anymore ever.
Anyway if I wear mine out in the near future I will probably buy one of the new ones either JVC HM-DH5U or JVC HM-DT100U.

Guys I have a question about 169time file playback. Assuming you have a TV thats HDTV ready but you have to use an external set top box to receive HDTV and you have a D-VHS of a 169time recorded 720p program you want to play back on it.... can the JVC 30k's built in decoder up convert it or are you out of luck?

Originally posted by Don Landis
Most of you all are examining the sending end only. I was told that the system of 5C protection requires 5C compliancy at both ends or the flagged signal will not pass. Given that 169Time HDVR is not compliant. Connect it to a 5C complaint VCR. Now send a program along with 5C flag, any of the three. The 5C compliant VCR will refuse to accept the signal for recording. I don't think it gets any simpler than that!

Now if one of you all can produce a VCR that is not 5C compliant, then we can debate whether that will work or not until such time as we can prove it one way or the other.

I read (somewhere here) that the AVX 1 strips the flags.

I found this http://www.dtcp.com/data/wp_spec.pdf for everything you ever wanted to know about 5c. In reading this it looks to me in my non-engineering mind that if the sending device is 5c and the receiving device is not – you will only be able to transfer ‘copy freely’. If the sending device is not 5c as in 169time I don’t see anything in these specs (I could have missed it) that says it won’t communicate.

Maybe you engineer types could read this and answer this: If a non-5c source tries to communicate with a 5c tape device like the JVC DVHS and the mpeg has embedded CCI that says ‘copy never’ what will happen at the JVC?

I don’t think any of this matters with 169time because I think the 169time mod taps the mpeg after it is decrypted and processed – just before it hits the DAC. I would think that any CCI flag information is already gone by this time in the 6000 receiver – no need for encryption or any flags to be sent to the DAC because the receiver has already decided that the content should be shown. If the 169time mode does strip CCI information then it would be considered illegal and would not be an option for the main stream – it would take an army of attorneys to keep them in business. Can anyone with technical knowledge of the 169time mod confirm this?

If this is the way the 169time mod works it is a non-issue. If on the other hand the CCI flag information is sent out through the firewire then there is the possibility that a 5c compliant device would not record a ‘copy never’ MPEG stream. I don’t believe it would take much of a computer program on a PC to strip the CCI information from the stream from a non-5c source. A 5c source would not send the stream to a PC unless it was marked as ‘copy freely’ so it would be quite the undertaking to trick a 5c compliant source to send anything but ‘copy freely’ MPEG to a computer.

I think we may already have the answer now – if it is true that the 921 beta testers are using firewire then the Dish Network stream must already be providing the flags. If the stream is currently flagged it must still work with the 169time mods because people can still record PPV HD with their 169time/6000 combo.

Originally posted by mike greer

I don’t think any of this matters with 169time because I think the 169time mod taps the mpeg after it is decrypted and processed – just before it hits the DAC. I would think that any CCI flag information is already gone by this time in the 6000 receiver – no need for encryption or any flags to be sent to the DAC because the receiver has already decided that the content should be shown.


I've been trying to explain this but it's difficult, so I apologize if I repeat some things. The receiver itself does not do any 5C encryption or decryption whatsoever. None. That job is for the firewire controller chipset. If a receiver does not come with a firewire port then it has no firewire controller chip, therefore it does not encrypt or decrypt any MPEG streams whether they contain flags or not.

The flags are part of the stream and they are meant to trigger protection schemes within firewire devices- nothing more. The flags by themselves do absolutely nothing.

Example A: A 5C compliant firewire chipset on a future sat STB is about to pass along the MPEG stream. But it sees there is a flag. This particular chipset has encryption/decryption capability, so it will encrypt the stream and pass it along. On the receiving end, there is a future DVR that is also 5C compliant w/ an encrypt/decrypt capable firewire chipset. It decrypts the signal and does whatever with it. Furthermore, it has other hardware or software within it (non-firewire devices) that can read the flag and knows what to do with it (copy once, copy never, etc.)

Example B: Same as above, but in this case the STB is a legal import from Korea or something. Let's just pretend that it's some kind of universal DVB receiver and it has a slot for a Dish Network access card. It also has a firewire port. However, they either chose not pay for or did not get approved for a DTCP license. Because of this, they must use the "public" firewire chipset, which is also 5C compliant but does not have the ability to encrypt or decrypt. If this chipset sees a flag in a stream, it will refuse to pass it along the firewire bus.

If the same chipset is in a DVR or DVHS deck, and it somehow recieves a flagged stream that has not been encrypted, I'm not sure what it does. It is quite possible that it just doesn't do anything. The flags could possible be used only for parallel to serial conversion (converting it to firwire packets and encrypting it) and therefore only apply on the sending unit. Since all "source" firewire ports are supposed to be 5C compliant, there would be no reason to implement this. Why bother to protect recording devices in this manner when the signal has already been compromised? Who cares if a DVHS deck would not refuse it? A person could just copy it to a PC anyways, which is what they're worried about (Internet piracy). It wouldn't be worth implementing if it increases cost or complexity.

Originally posted by mike greer

If the 169time mode does strip CCI information then it would be considered illegal and would not be an option for the main stream – it would take an army of attorneys to keep them in business. Can anyone with technical knowledge of the 169time mod confirm this?


I don't think it's illegal. Obviously there are many who would like things like that to be illegal but I'm pretty sure it isn't. It's like removing Macrovision. Since no encryption is being broken, it's not specifically illegal according to the DMCA. But I'm not a lawyer so I couldn't say for sure.

I'm not an engineer but there seems to be a lot of confusion about how 5C works. Most of this is over my head. If 169time is not affected by 5C then why couldn't you use 169time to record a Dtheater tape to another recorder or computer?

I think the JVC deck disables any firewire output when a Dtheater tape is played.

Marc.

Lifter – I think I am following you. My question is that in the case of a 6000 with 169time added are they not grabbing the audio and video just before it hits the DACs? The audio and video has already been descrambled by the 6000 using the smart card and Dish Networks security system. I understand that the encryption that Dish uses has nothing to do with 5c. Then are they not then transferring this raw nonstandard mpeg audio/video to the AVX1 where it is assembled into a standard mpeg stream over non-5c firewire? If this correct it wouldn’t make any difference what 1394 chipset they use – there wouldn’t be any flags to instruct the firewire chipset to do anything. If they are not grabbing the raw audio and video on the way to the DAC what does the AVX1 do? If the output was just plain and simple MPEG over 1394 they wouldn’t need an AVX1 to process the output.

If the process works like I think it does – 169time could also have used USB2 (rather than 1394) to get the information out of the 6000 to the AVX1 where it could be ‘converted’ to firewire for use with DVHS and computers.

Example B: Same as above, but in this case the STB is a legal import from Korea or something. Let's just pretend that it's some kind of universal DVB receiver and it has a slot for a Dish Network access card. It also has a firewire port. However, they either chose not pay for or did not get approved for a DTCP license. Because of this, they must use the "public" firewire chipset, which is also 5C compliant but does not have the ability to encrypt or decrypt. If this chipset sees a flag in a stream, it will refuse to pass it along the firewire bus.

Your description is very good for devices that where designed with an awareness of 5c but what about devices created before 5c? What if a manufacturer makes their own firewire chipset and chooses to ignore 5c? As far as 5c compliance and chipsets go there were plenty of 1394 devices before 5c was even a thought. These devices would not know they were not supposed to pass the signal along. What happens with these?

Your are obviously a very knowledgeable person and I am not questioning your 5c knowledge I am just trying to understand how it works with 169time’s add on.

Thanks for your patients!

-Mike

Lifter- IMO, you have presented a 90% clear and concise explanation. It is real close to the way it was explained to me by someone in the know.

I do believe I juxtaposed the words encryption for flag that may have confused others and maybe myself too. Originally, my understanding is that the _flags_ are set in the program by the program provider according to the license agreement rules. The 1394 hardware (chipsets) see the flag and encrypt based on that data in the program stream.

I think where I get lost from your explanation is where you site some scenarios, scenarios that don't exactly conform to present day reality so let me, venture some real life scenarios that will present itself when 5C flags begin to appear-

Given- That ALL DVHS VCR's are 5C compliant and contained licensed Chipsets. I know this as I have researched this with Panny PVHD1000, Mitsubishi 1000 and 2000, as well as the JVC 30K and 40K and the industrial equivalents. For the moment, let's hold on the issue of DVR inputs either STB's or home built computers and stick to DVHS VCR's

Given- that the current source tuners for satellite are all supplied by 169Time and use HDVR hardware retrofit technology that uses an unlicensed 1394 chipset. I believe you refer to this as the one that is in the public domain. Earlier references links point out that both available chipsets are 5C compliant but only the one with the license allows licensed code to be programmed into the chip to execute the encryption. Here is where it gets fuzzy for me. If the chip is of the unlicensed variety in the HDVR from 169Time, then it seems to me that it will recognize the flags and stop the 1394 transmission whether the flag is copy many or copy one. I believe this, in part is what the engineers tried to explain to me a year ago.

In addition, there was one more part to their explanation. The 5C process allows that each end of the 1394 connection can halt the flow based on licensed compliance. i.e. if one part of the system is not licensed 5C then there will be no signal flow either. I don't believe you addresses this unless your comment about: " "and it somehow receives a flagged stream that has not been encrypted, I'm not sure what it does. It is quite possible that it just doesn't do anything. "

Again, all the above is strictly pertaining to 169time source connected to a DVHS VCR that is licensed 5C 1394.


Now, the second scenario is where we have the 169Time HDVR output connected to a simple OHCI 1394 card in a computer for receive and process of a flagged datastream. If the chipset in the 169Time is 5C but unlicensed and connected to a 5C unlicensed chip on the computer card, would the signal flow or would it be stopped. The experts say it would be halted and no signal flow.

If we have the same situation and a NON-5C chipset, (is there such a thing?) the I think the data file can be streamed over the firewire without issues, containing the 5C flags and these flags would be inert until they see a 5C compliant 1394 chipset. The question in all this is what is the chip set in the HDVR. I suppose I could look as I have the HDVR, latest version here but it may be the one with the sticker on it. I don't know whether the number of the chip has been rubbed off underneath. Never bothered to look. The other chips are numbered.
If someone who is knowledgeable and wants to do some additional research, I'm game to uncover the chip number if it is still there. Send me a PM and we can discuss further, in the interest of science. :)

Originally posted by Randall Morton
I'm not an engineer but there seems to be a lot of confusion about how 5C works. Most of this is over my head. If 169time is not affected by 5C then why couldn't you use 169time to record a Dtheater tape to another recorder or computer?

Marc is correct - when you play D-Theater tape it can only be view over the analog outputs.

I too am trying to understand how 5c and 169time work or don't work together.

The biggest plus I can see for it to continue working is that if they really are testing the 921 with firewire then the 'flags' are still allowing the 169time devices to work today.

Mike- Please, lets not confues this further. It is already known that no current program has 5C flags yet. Also, DTheater is supposed to use two forms of copy protection. 5C flags for copy none PLUS Dtheater and this is from the people at JVC. DTHeater tapes with known 5C copy none flags can't be used to test 169Time because it is not a satellite signal, it is a tape.

So the Dtheater tape being 5C has nothing to do with not being able to record it?

Originally posted by Don Landis
Mike- Please, lets not confues this further. It is already known that no current program has 5C flags yet. Also, DTheater is supposed to use two forms of copy protection. 5C flags for copy none PLUS Dtheater and this is from the people at JVC. DTHeater tapes with known 5C copy none flags can't be used to test 169Time because it is not a satellite signal, it is a tape.

Sorry Don - I shouldn't have gone the DTHeater route.. I really just meant there is more to DTHeater than just 5c.

But...

If there are no 5c flags how can Dish Network be 'testing' the 921's fire wire ports? Until there are 5c flags coming from Dish I guess we won't know the status of 169time for sure but it seems to me that the 'Dishwire' is a little further in the future than I had hoped.

If there are no 5c flags how can Dish Network be 'testing' the 921's fire wire ports?

One of the major problems with the way E* developed the 921 was to use all laboratory conditions in England. Not only did the developers NOT have 5C flags in a sat signal to test, they didn't even have the sat signal. They used l;aboratory signal generators.
Now, when the tests are done in the states, what makesyou think Dish has no way to build a sat signal for test purposes open to their internal people? Dish is a license holder for 5C. They can build their own program put it on the bird, add their 5C flags and run a test. They don't need your permission to do that and they don't need to open their testing for public scrutiny. I don't know whether they did this but it would be silly to assume that anything you don't see doesn't exist.

Originally posted by Don Landis
If there are no 5c flags how can Dish Network be 'testing' the 921's fire wire ports?

One of the major problems with the way E* developed the 921 was to use all laboratory conditions in England. Not only did the developers NOT have 5C flags in a sat signal to test, they didn't even have the sat signal. They used l;aboratory signal generators.
Now, when the tests are done in the states, what makesyou think Dish has no way to build a sat signal for test purposes open to their internal people? Dish is a license holder for 5C. They can build their own program put it on the bird, add their 5C flags and run a test. They don't need your permission to do that and they don't need to open their testing for public scrutiny. I don't know whether they did this but it would be silly to assume that anything you don't see doesn't exist.

Don – I wasn’t suggesting they need my permission. Damn, I thought I was hostile!

<<Defensive Blast Mode On>>
If dish isn’t going to do ‘real’ testing that’s their problem. Don’t they have at least 1 or 2 people using 921’s to test in the real world? If not – I wouldn’t be surprised – they don’t need to test anything – their hardware is world famous for being rock solid and reliable, you don’t hear any complaints about their hardware. The 501, 508, 510, 721, 811, and 921 are all working wonderfully – God forbid they test something before the release it. It would be silly to think that dish does anything that makes sense. What are they going to do when they do flip the switch on 5c and works great on the 921 but kills all 6000s ability to receive HD? Sounds insane right? What about when the came up with “SuperDish” idea, started implementing it only to find out they couldn’t do it?

“They don't need your permission to do that and they don't need to open their testing for public scrutiny.”

They don’t open their testing for public scrutiny probably because they don’t have any ‘testing’ going on. The 921 was under development for how long? Did they test it before the sent it out?
<<Defensive Blast Mode Off>>

Back to the subject at hand…

Will 169time still work with 5c?

I don’t know. If Dish ever does enable the fire-wire we will see then if the 169time stuff still works.

Random stuff I think:

#1: Since DVHStools can record a PC file to a D-VHS VCR, then the D-VHS VCR will accept a non-5C negotiated stream and record it.
#2: I am not sure how/where 5C flags are sent, but MPEG2 has different types of streams. So (for instance), if someone were to tap off the 'program stream', then they wouldn't be getting any flags that were part of the 'transport stream'.
#3: I think JVC DVHS D-VCRs do send data out the IEEE1394 when you play a D-Theater tape - but it is 5C encrypted with the "copy never" bit set... So only a 5C compliant display device would be able to view it.
#4: 5C is really dependent on the sending device. If the sending device doesn't know how to speak 5C protocol then most receiving devices will just happily accept the data and allow you to view or record it.
( I think that is one of the big misconceptions here... Some people think that a 5C capable receiving device should refuse to record if the sender doesn't negotiate 5C... I think it most cases it just hapily records as if it was "copy freely" )

But I could be wrong about any or all of this - I am just guessing based on what I have been reading on this forum.

Originally posted by mike greer
Lifter – I think I am following you. My question is that in the case of a 6000 with 169time added are they not grabbing the audio and video just before it hits the DACs? The audio and video has already been descrambled by the 6000 using the smart card and Dish Networks security system. I understand that the encryption that Dish uses has nothing to do with 5c. Then are they not then transferring this raw nonstandard mpeg audio/video to the AVX1 where it is assembled into a standard mpeg stream over non-5c firewire? If this correct it wouldn’t make any difference what 1394 chipset they use – there wouldn’t be any flags to instruct the firewire chipset to do anything. If they are not grabbing the raw audio and video on the way to the DAC what does the AVX1 do? If the output was just plain and simple MPEG over 1394 they wouldn’t need an AVX1 to process the output.

Let me first clear up that I'm not an engineer, just a video editor. My "theories" are based on a LOT of reading I did last week in an attempt to detirmine what it would take to recreate what 169time does. Most of what I read are in the links I posted above and I knew nothing about this stuff until recently.

What you're saying is pretty much what I believe. I have no idea how the HDVR interfaces with a STB because I could not find any datasheets or schematics on any HD sat boxes (they are probably kept secret to protect against signal theft). I only have a Hughes HTL-HD and I had access to a Zenith SAT520. Both have LG motherboards with most of the same ICs on them. I couldn't find ANY useful information like a datasheet on almost any of the chips (which could be why 169time does not support them). The only info I found was for this chip:
http://sic.lge.com/products/AdvancedVSBReceiver.htm
It wouldn't suprise me if much more info could be found on an older STB like the DTC100, but I don't have one.

I do know that the "legit" firewire chips interface through what is referred to as HSDI (High Speed Data Interface). Think of HDSI as the input, and firewire as the output. The chips advertise multiple HSDI ports, so they could theoretically accept ATSC on one port, DVB on another, etc. The 169time HDVR must also have multiple "inputs" because I know the DTC100 will transmit ATSC w/o the AVX1 hooked up.

As far as the AVX1, it probably does more than convert the MPEG stream. It tricks Windows and the DVHS devices into thinking it is a DVHS device, thus eliminating the need for a custom AV/C driver. This also makes it compatible with the JVC decks without using a user's regular PC since the AVX1 takes over that task. With DirecTV, the MPEG streams are not standard (130 byte packets) so it makes sense that the AVX1 is needed for that, but Dish Network uses DVB which is standard 188-byte packet MPEG2. Somebody on this forum (not sure who) used a firewire analyzer and figured out what it was. I'm sure whoever it was knows a lot more. Anyone with the smarts (not me) could do the same.
Originally posted by mike greer

If the process works like I think it does – 169time could also have used USB2 (rather than 1394) to get the information out of the 6000 to the AVX1 where it could be ‘converted’ to firewire for use with DVHS and computers.

Yes, you're probably right. Technically it could be anything- any type of serial interface that's fast enough. Of course this would have been 10 times more difficult to make because firewire chipsets similar to the HDVR already exist, like the chipset in a DVHS deck.
Originally posted by mike greer

Your description is very good for devices that where designed with an awareness of 5c but what about devices created before 5c? What if a manufacturer makes their own firewire chipset and chooses to ignore 5c? As far as 5c compliance and chipsets go there were plenty of 1394 devices before 5c was even a thought. These devices would not know they were not supposed to pass the signal along. What happens with these?

Other than the 169time HDVR, I don't think there are any. You see, the two types of 5C compliant devices I described (with and without encryption capability) are designed to accept a multitude of AV signals, including DVB and DirecTV transport streams. Some even accept DVD Audio. Regular firewire devices like external disk drives and PCI adapters do not have this capability to inherently understand multimedia- particularly satellite formats. These are actual chips that Texas Insturments, Indigita, LSI, and several other IC companies make for the purpose of being integrated into STBs and DVRs, and are most likely found in the DVHS decks. An FPGA (which I just learned last week) is a customizable chip which can be programmed to do unique tasks to replace the need for pre-designed chips. Instead of using a "legit" 1394 chip, one could theoretically take the information from one and make a custom FPGA. It's quite possible this is what Richard did to develop the HDVR.

Originally posted by Don Landis
Lifter- IMO, you have presented a 90% clear and concise explanation. It is real close to the way it was explained to me by someone in the know.

I do believe I juxtaposed the words encryption for flag that may have confused others and maybe myself too. Originally, my understanding is that the _flags_ are set in the program by the program provider according to the license agreement rules. The 1394 hardware (chipsets) see the flag and encrypt based on that data in the program stream.

I think where I get lost from your explanation is where you site some scenarios, scenarios that don't exactly conform to present day reality so let me, venture some real life scenarios that will present itself when 5C flags begin to appear-

Given- That ALL DVHS VCR's are 5C compliant and contained licensed Chipsets. I know this as I have researched this with Panny PVHD1000, Mitsubishi 1000 and 2000, as well as the JVC 30K and 40K and the industrial equivalents. For the moment, let's hold on the issue of DVR inputs either STB's or home built computers and stick to DVHS VCR's

I don't own a DVHS deck and have done little research into them. I only know they're 5C compliant because you said they were in another thread :). The made up scenarios are kind of necessary because I don't own a STB with firewire on it. I forgot about the 921 (I'm stuck w/ D* myself). My main point is that the chips are the same. The firewire chipset in a DVHS deck could easilly be the same exact chipset found in a non-encryption capable firewire satellite STB (which doesn't exist so I made one up). Actually, this just dawned on me. I would be willing to bet that ATSC-only STBs with firewire use the "public" chips (what the DVHS decks use), and that these chips can accept a non-flagged DVB or DirecTV streams. I wonder how much different the Samsung TIR-165 and TIR-151 really are.
Originally posted by Don Landis

Given- that the current source tuners for satellite are all supplied by 169Time and use HDVR hardware retrofit technology that uses an unlicensed 1394 chipset. I believe you refer to this as the one that is in the public domain. Earlier references links point out that both available chipsets are 5C compliant but only the one with the license allows licensed code to be programmed into the chip to execute the encryption. Here is where it gets fuzzy for me. If the chip is of the unlicensed variety in the HDVR from 169Time, then it seems to me that it will recognize the flags and stop the 1394 transmission whether the flag is copy many or copy one. I believe this, in part is what the engineers tried to explain to me a year ago.

What I'm saying is that there are not two, but three types:
1) 5C compliant AV/C 1394 link layer chips w/ encryption/decryption (what the 921 must have).
2) 5C compliant AV/C 1394 link layer chips without encryption/decryption (what the DVHS decks and the Mitsubishi TVs probably have). This is what I refered to as the "public" chipset.
3) Everything else including the 169time HDVR, IDE to 1394 "adapters", 1394 to PCI "adapters", customizable FPGAs, etc., etc.- chips not designed for AV/C. Not designed to accept and convert MPEG streams (or at least D*& DVB MPEG streams). 5C doesn't apply.

So the 169time HDVR is clearly #3, not #2. If it were #2, there would be no need for an AVX1. However, it would also refuse any content with the decripters. Since the 169time system fits into #3, I personally believe 5C will not affect it.
Originally posted by Don Landis

In addition, there was one more part to their explanation. The 5C process allows that each end of the 1394 connection can halt the flow based on licensed compliance. i.e. if one part of the system is not licensed 5C then there will be no signal flow either. I don't believe you addresses this unless your comment about: [i]" "and it somehow receives a flagged stream that has not been encrypted, I'm not sure what it does. It is quite possible that it just doesn't do anything.


According to that exact language, it is false. You can of course interface a DVHS deck with a PC. According to what that says, you couldn't- flags or no flags. Maybe I should read the whole pdf. I really don't know, but if a DVHS deck would refuse a flagged signal, then it's just a matter of running it through a "cleaner" first, something that the AVX1 is totally capable of performing (if it doesn't already). This is why I suggested that implementing this is almost totally useless if their goal is to prevent internet piracy. You could end up with seeing a bunch of flagged transport streams floating around in pirate channels that anyone can playback on their PCs. Preventing them from copying to a DVHS deck (without hacking the stream first) isn't very useful.
EDIT: I don't know why this paragraph is italicised, heh.

Originally posted by Don Landis

Now, the second scenario is where we have the 169Time HDVR output connected to a simple OHCI 1394 card in a computer for receive and process of a flagged datastream. If the chipset in the 169Time is 5C but unlicensed and connected to a 5C unlicensed chip on the computer card, would the signal flow or would it be stopped. The experts say it would be halted and no signal flow.

Absoultely right. According to everything I've read, it wouldn't work. But again, there isn't a chance in hell that the HDVR is 5C complaint (it's part of the #3 group above). If it were, no AVX1 would be needed.
Originally posted by Don Landis

If we have the same situation and a NON-5C chipset, (is there such a thing?) the I think the data file can be streamed over the firewire without issues, containing the 5C flags and these flags would be inert until they see a 5C compliant 1394 chipset. The question in all this is what is the chip set in the HDVR. I suppose I could look as I have the HDVR, latest version here but it may be the one with the sticker on it. I don't know whether the number of the chip has been rubbed off underneath. Never bothered to look. The other chips are numbered.
If someone who is knowledgeable and wants to do some additional research, I'm game to uncover the chip number if it is still there. Send me a PM and we can discuss further, in the interest of science. :)
That would be awesome. I would love that information, for educational purposes only. After going on my "crusade", I've clearly realized that the 169time system is a massive work of intellectual property, and could not be recreated with merely a soldering iron and an account with Arrow or Digikey. A similar (and more reliable) system could be made, but it would not work with 5C protected content. Knowing what the chips he used would be very interesting, but by itself I don't think it could lead to anything that would harm his business. I thought it was just a custom FPGA, but why would it be taped over then? I'm dying to know.

Originally posted by Lifter
... The 169time HDVR must also have multiple "inputs" because I know the DTC100 will transmit ATSC w/o the AVX1 hooked up....


I have no idea how you arrived at this bit of logic.


I thought Mike's point about some FireWire chips being designed without any notion of 5c was pretty clear, but maybe you didn't.

A FireWire chip designed with absolutely no consideration of 5c is still quite capable of passing AV data and being hooked up to a D-VHS recorder. (e.g., probably any PC with FireWire now, and certainly any FireWire adapter released before 5c) FireWire is just one kind of networking technology atop which you can carry any kind of data. It only needs to be "customized" when you want to do something tricky like add encryption at the link level. (which is what 5c does(?) )

Originally posted by Lifter
What I'm saying is that there are not two, but three types:
1) 5C compliant AV/C 1394 link layer chips w/ encryption/decryption (what the 921 must have).
2) 5C compliant AV/C 1394 link layer chips without encryption/decryption (what the DVHS decks and the Mitsubishi TVs probably have). This is what I refered to as the "public" chipset.
3) Everything else including the 169time HDVR, IDE to 1394 "adapters", 1394 to PCI "adapters", customizable FPGAs, etc., etc.- chips not designed for AV/C. Not designed to accept and convert MPEG streams (or at least D*& DVB MPEG streams). 5C doesn't apply.

So the 169time HDVR is clearly #3, not #2. If it were #2, there would be no need for an AVX1. However, it would also refuse any content with the decripters. Since the 169time system fits into #3, I personally believe 5C will not affect it.


How did you arrive at the conclusion that the HDVR is #3?

Originally posted by balazer
I have no idea how you arrived at this bit of logic.


I thought Mike's point about some FireWire chips being designed without any notion of 5c was pretty clear, but maybe you didn't.

I don't have a clue what you're talking about. I think Mike was agreeing with me. Read more than a line from my posts and you'll see that I totally believe that the HDVR is a custom, non 5C compliant device. I don't remember if I mentioned this first or Mike did- doesn't matter to me.

Regardless, none of that has anything to do with the fact that the HDVR can probably accept more than one HSDI source- something I thought was interesting and has absolutely nothing to do with what Mike said.

Originally posted by balazer
How did you arrive at the conclusion that the HDVR is #3?

Originally posted by Lifter

If it were #2, there would be no need for an AVX1.

I still don't see the connection. Please enlighten me.

As for the other issue, you can go back and re-read your own post. Mike said "Your description is very good for devices that where designed with an awareness of 5c but what about devices created before 5c.", and you responded "Other than the 169time HDVR, I don't think there are any."

You seem to think that only an AV FireWire chip can do AV. I'm trying to tell you that any FireWire chip can do AV.

"Do AV" is an oversimplification. To my knowledge, there is no non-C compliant 1394 controller chip that by itself can convert parallel DVB & D* MPEG packets into serial 1394 packets and vice-versa. The DVHS decks' controllers are 5C compliant. Those are about as old as it gets. What else is there?

I'm not talking about "#3" like I described. Obviously a firewire bus can be used for whatever someone programs it to do. Theoretically, someone could drive an LCD panel with a SCSI controller.

What I'm talking about are chipsets specifically designed for AV/C- which are all 5C compliant. The 169time HDVR is not one of these, but can perform the same task because a whole lotta work went into customizing a non-AV/C chip (I'm assuming) to do the same thing (in combination with the AVX1). Or it could be a "legit" 5C device that's been massively hacked. If Don tells us what the IC is then we can find out for sure.

Sorry I keep editing this.

The chip doesn't need to do everything by itself. You can have whatever kinds of hardware and software you want running behind that chip.

What's older than a D-VHS recorder? FireWire.

Anyway, what's a parallel packet and a serial packet?

I never said the chip needed to do everything itself. The 169time system obviously proves that. What I'm saying is that all 5C compliant AV/C devices HAVE chips that do everything themselves. That's how it works.

Like I said I'm not an engineer. This is how I understand it. The MPEG streams move around the STB's motherboard on some kind of parallel bus. A serial bus, like firewire or USB, is designed to streamline data across a cable. That's about as technical of an explaination I can give you.

chi lan sin! hahahaha

^^^ Am I missing something? What's the deal with this guy?

Correct me or stay out of it. I don't think anyone cares to hear your sarcasm. I'm trying to learn some things and I would be happy to wager that I'm at least 90% right about everything I've said, despite my lack of knowledge of the fundementals. You can write a page on what the difference is between serial and parallel busses are, and it isn't going to help anyone determine if the 169time system has a future.

Has anyone seen this error? It is a new one for me:

Video1394_UNTALK_CHANNEL: Bad Address


I was getting the typical invalid selfID error and started adjusting my
1394 cables. Now I am just getting this new error.

I rebooted the AVX-1 and the message disappeared. It would still be nice to know what happened though.

At the moment, everything is working fine again.

Like I said I'm not an engineer. This is how I understand it. The MPEG streams move around the STB's motherboard on some kind of parallel bus. A serial bus, like firewire or USB, is designed to streamline data across a cable. That's about as technical of an explaination I can give you.


I haven't been following this discussion, but you could have a single chip solution that decodes encrypted data, does MPEG2 (or whatever) decoding, and provides DACs and/or Firewire/DVI/HDMI digital outputs.
So such a single chip solution doesn't have to move the MPEG2 data around on an external bus. You'd have access to encrypted data coming in, and on the other end analog component or RGB, and only some other digital format if the signal tells the chip to do so. If the signal says not to make digital outputs available, there wouldn't be much you could do, since it's all inside the chip.

which is what I thought firewire already did...not saying that's right, though...just my earlier perception...

Darius

Yeah, but it would be encrypted. Anyways, I don't think that's the case with any STBs except possibly new ones coming out in the future. I know that's not the case with the LSS3200A/HD300/HDL-HD models, which are the newest D* boxes.

Originally posted by Dean Roddey
I haven't been following this discussion, but you could have a single chip solution that decodes encrypted data, does MPEG2 (or whatever) decoding, and provides DACs and/or Firewire/DVI/HDMI digital outputs.
So such a single chip solution doesn't have to move the MPEG2 data around on an external bus. You'd have access to encrypted data coming in, and on the other end analog component or RGB, and only some other digital format if the signal tells the chip to do so. If the signal says not to make digital outputs available, there wouldn't be much you could do, since it's all inside the chip.

I don't doubt that future receivers will most likely do this - but on the 6000 the unencrypted MPEG stream must be 'alive' somewhere on the board or the 169time mod wouldn't be able to get to it.

Hopefully 5c firewire will become the 'normal' digital output so that people can continue to time shift and archive for personal use just as they always could with analog signals.

This thread is becomming very difficult to read because there are about 99% theories being presented as facts. Let me try to clarify with just some facts that I have confirmed-

1. There is no 5C flags currently being sent in the public E* channels. Therefore any observation of "5C" in the window of your VCR is likely du to 1394 connection malfunction and not that the program has 5C copy protection added.
2. The 921 is 5C compliant and follows the special rules for 5C DVR applications.
3. The 921 was originally tested in laboratory conditions, not with public open sat signals. It now is being beta tested in the open public sat channels as well. The Dishwire is still not in public beta but only in internal beta/alpha mode testing. It is not known if E* is testing using laboratory generated sat signals with 5C flags or if testing with closed test channels over the bird. They have done so in the past but I have no direct information they are doing this for 5C testing presently.

4. HDVR board- is using a chiop set that is not listed in the Ti references as being 5C compliant. No mention of DTCP or 5C or any content protection is made in the specs of the 1395 controllers in the HDVR.

5. The 5C content protection management system executes a series of tests performed sequentially between the source and sink (HDVR and DVHS VCR) The sink device is the one that initiates a request for authentication key from the source based on seeing the 5C flags in the MPEG2 stream. These are not stripped out by normal process nor are the flags generated in the 1394 source controller. The source must answer the request and perform certain encryption to the Mpeg2 stream before any program data will flow. Once all the exchange between source and sink is cleared an encrypted signal is sent to the sink and is decrypted via the sink for recording based on the rules set by the flags. If the handshake Q&A fails, there is no program transmission flow because the sink which is 5C compliant will refuse it. A non-5C source will continue trying to send but can't respond to the 5C Q&A properly.

It is because of how the Q&A process is executed before the actual data flow of the program happens that is the reason those who fully understand 5C system all say that given two devices, source and sink, that is, the source is not able to answer the requests made by a compliant 5C sink then no copy will be allowed, even with a 5C flag set for copy many.


This also speaks to the very fact that these same people state that IF there were a DVHS VCR to be made that does not have 5C hardware then it would ignore the 5C flags and would be able to record. A good reason for Richard and 169Time company to continue to investigate computer DVR as it may be the way to record, legally, any 5C content protected program. There are no non-5C DVHS VCR's but virtually all PC's 1394 boards are 5C inert.

As I stated earlier, I would check the HDVR board and I have a list of the chips used in the latest version. Since this is a bit out of my area to interpret, I trust the engineer who is very familiar with chip set specs and the 5C technology.

Oh, one more thing, I made an offer for anyone really interested in the this to contact me about the HDVR and to date no one has asked. LOL! that tells me something. So I just posted it here.

Sorry but it looks like the 5C flagged program will not record to DVHS VCR's and may record to PC's just fine. Now once you have the file in the PC, I suppose you will be able to hack all you want if it is that important. This is also likey the reason Hollywood is more concerned now abut 5C integrity over the internet. Seems this IS the 5C hole. Works for DVHS but not PC's. This last part is my speculation.

For those of you with multiple FireWire HDTV sources and D-VHS and PC's, what is the best FireWire Hub that allows for 1394 A/V signal routing without un/re-plugging and possibly also has X In- X Out switching as well that is suitable for use with 169Time/HDTV STB's/D-VHS decks/PC's?

Don – you are correct, this and all other threads here are based mostly on theories. This would also include many of your posts. How do you know these are facts?

“1. There is no 5C flags currently being sent in the public E* channels. Therefore any observation of "5C" in the window of your VCR is likely du to 1394 connection malfunction and not that the program has 5C copy protection added.”

Where do you get these ‘insider’ facts? Or are they based on theories like everyone else?

“2. The 921 is 5C compliant and follows the special rules for 5C DVR applications.”

The 921 is NOT currently 5c compliant – it doesn’t even have active fire wire.

“3. The 921 was originally tested in laboratory conditions, not with public open sat signals. It now is being beta tested in the open public sat channels as well. The Dishwire is still not in public beta but only in internal beta/alpha mode testing. It is not known if E* is testing using laboratory generated sat signals with 5C flags or if testing with closed test channels over the bird. They have done so in the past but I have no direct information they are doing this for 5C testing presently.”

Again - Where do you get these ‘insider’ facts? Or are they based on theories like everyone else?

“There are no non-5C DVHS VCR's but virtually all PC's 1394 boards are 5C inert.”

Is this fact, fiction or a theory? What about the original Panasonic DVHS VCRs? I know someone with 3 of them that were supposedly built without 5c? How about Macintosh computers that came with fire wire before 5c even existed?

When I read these forums I assume unless someone has someway to back up what they say that it is ‘to the best of their knowledge’. I don’t think anyone is trying to mislead other people.

I have read about five pages of these theories, and my head almost exploded; if I understood any more about what was said, it probably would have. All I wanted to find out, was: If the JVC30K has 5-C built in, and the DTC100, and AVX-1 do not see the flags (or encryption?), will a 'handshake' be made and a recording from DirecTV take place when (and if) 5-C is in place? If this has been answered in a language that I can understand, please link me to it.

"All I wanted to find out, was: If the JVC30K has 5-C built in, and the DTC100, and AVX-1 do not see the flags (or encryption?), will a 'handshake' be made and a recording from DirecTV take place when (and if) 5-C is in place? If this has been answered in a language that I can understand, please link me to it."

It hasn't been answered in it's simplest form. Therefore I'll do it-


No. :)

But then there are those who have all the theories as to why I'm wrong. To understand that you will need to push your head to the explosion point.

Mike- I began to answer your questions but when I got to the one about the Macintosh, I decided you were just playing a game of acting like a cross examiner during an expert witness testimony and I don't need to waste my time with that. You have a simple choice. You can believe any of the information you want. That is the beauty of the forum and freedom to post ones theories as fact, to post " a smart feller I know said..., and to post my insider contact at E* or Eldon says... And then you can decide to believe the smart feller, the theories, or the insider contact. All the time knowing that anyone of them could be right or wrong.

Originally posted by mkerdman
For those of you with multiple FireWire HDTV sources and D-VHS and PC's, what is the best FireWire Hub that allows for 1394 A/V signal routing without un/re-plugging and possibly also has X In- X Out switching as well that is suitable for use with 169Time/HDTV STB's/D-VHS decks/PC'sI have used hubs, mechanical switchers and extender cables to connect my various components, and there is no ideal solution. I think the problem is that the software/hardware capabilities of all the components are not robust enough work properly while being continuously plugged in. I still have to physically plug and unplug the firewire cables when I switch configurations. The hubs do help to extend the cable lengths or make the firewire ports more accessable. For what it's worth, here (http://www.zeehoo.com/miva/merchant.mv?Screen=PROD&Store_Code=Zeehoo&Product_Code=fwhub&Category_Code=fwaccs) is the hub I bought.

Originally posted by Don Landis
Mike- I began to answer your questions but when I got to the one about the Macintosh, I decided you were just playing a game of acting like a cross examiner during an expert witness testimony and I don't need to waste my time with that. You have a simple choice. You can believe any of the information you want. That is the beauty of the forum and freedom to post ones theories as fact, to post " a smart feller I know said..., and to post my insider contact at E* or Eldon says... And then you can decide to believe the smart feller, the theories, or the insider contact. All the time knowing that anyone of them could be right or wrong.

Don- My apologies, I was being an ass this morning when I left that post.

My point was that no one should take any of the information here as the absolute truth. Much of it is just educated and sometimes not so educated guessing.

I didn't know that the 5c flags are not currently being sent down by Dish. I am genuinely surprised that if the fire wire is going to be enabled soon that they have not started to flag the content. I'm just curious how you know this to be fact. Did I miss it somewhere in this thread? I am really interested in this because as soon as I see that the 169time will still work after 5c is sent I will be getting one and starting up my Dish sub again. I also would like to know what you think about the first release of Panasonic DVHS machines that supposedly don't do 5c. Do you have any info on them? As far as the Mac statement I really do have an old Mac at work somewhere in storage that has 1394 on it. That is unless someone chucked it in the dumpster I haven't noticed yet. I'll have to see if I can find it.

On many of my posts I try to make it clear that I don't know. The entire discussion on 169time falls under the category of I don't know. Fact is I want to know, that's why I am posting here.

Again I am sorry about my previous 'attack'.

-Mike

While recording HBOHD off DirecTV, does the 169Time>AVX-1>JVC 40K setup always pass along Dolby D 5.1 if available, or, only Dolby D 2-Channel as the JVC 40K user manual seems to imply?

Murray- The DVHS VCR's all record the MPEG2 stream and there is no way for a VCR to switch the Dolby encoded in that MPEG2 stream. What they send is what you record is what is played back and then, if your receiver is DD2,0 only, the Dolby AC3 spec allows it to default to DD2.0. That is in the case of 1394 I/O.. In the case of the JVC using it's own decoder, you still get DD5.1 if the recording has DD5.1. In the case of the JVC40K, if the tape had DTS audio embedded it will allow DTS playback as well. Basically, it does all you need! :)

Thanks MIke for your clarification- We all get a bit over the top sometimes, even me! :)

Opinion- I think you may have your stories mixed up on the Panasonic non5C question. It was the first few weeks of production on the Tuner DST50 that was not 5C compliant. The PVHD1000 always was 5C compliant. Source, Panasonic. I could look up the guy's name but it would take awhile since his card in in a stack of about 3000 business cards I have in a box unorganized. He was also the one who showed me the letter from the MPAA suggesting it would be a nice gesture if they cease making the PVHD1000 and in exchange would continue to support the Panasonic broadcast division.

One more thing, Mike, Dish doesn't execute the flags except if they produce their own content. The flags are inserted by the program providers such as HBO, Showtime, HDNet etc. and the providers decide how and when to add the flags. The signal DBS providers are not permitted to insert the flags into others content, only their own. That is in the 5C license agreement. Does that help also clarify it. I'm not sure who inserts the flags in the PPV content. It may be a contractual thing, I just don't know. Maybe Glimmie or Mike Most could answer that one as they are closer to the source than I am. I remember the few PPV productions I worked on we had very little control over anything.

Since the 5C flags are set by the content providers, and we have as an AVS member, Richard Southard from Showtime HD, why don't you try to contact him and ask him when Showtime is planning to execute the flags? I'm sure he would give you a straight answer. We haven't seen him around lately but if you're interested why not track him down and ask. It's what I would do if I were as concerned about it as you seem to be. :) There I gave you a source for some real direct info if you want to do something.

Time to go and watch some CBSHD on one hour delay!

Originally posted by mkerdman
While recording HBOHD off DirecTV, does the 169Time>AVX-1>JVC 40K setup always pass along Dolby D 5.1 if available, or, only Dolby D 2-Channel as the JVC 40K user manual seems to imply?

I have answered my own question here as earlier testing was being done with DD 2.0 progams, and, now a DD 5.1 movie is on HBOHD.

HBO's online lisitngs do not say if films are DD 2.0, 5.1.

Originally posted by Don Landis

One more thing, Mike, Dish doesn't execute the flags except if they produce their own content. The flags are inserted by the program providers such as HBO, Showtime, HDNet etc. and the providers decide how and when to add the flags.

That may be what 5c says, but it's not necessarily how the equipment works now. The descriptor doesn't go in the video stream - it goes in the program tables.

I'd speculate that most transport stream multiplexers don't bother preserving descriptors from the input to the output. I also speculate that at least in the beginning, DISH will send no descriptors even if HBO and Showtime are. And after that, I bet DISH will just set the descriptor and leave it.

I wonder if 5C flag passing works sortof like DD5.1 passing.

When a source provider uplinks the show via national sat (say C band for instance), then another provider (say local OTA or DBS company) receives it, then (with DD5.1) I think they have to decode the DD5.1, then re-encode it using boxes external to their HD MPEG2 encoder.

It gets kindof tricky, and they can mess up the cabling or settings such that rear channels disappear or the subwoofer output is reduced. Sometimes the lipsync gets thrown off.

I wonder if 5C is the same way - such that an intermediate provider could '"goof" and forget to passthrough the 5C or even pass along a different flag than was being sent in (for instance to make everything become copy once).

Originally posted by Don Landis

But then there are those who have all the theories as to why I'm wrong. To understand that you will need to push your head to the explosion point.

I'm sure you're right. I hadn't read the entire 5C pdf like you so I just pointed out that it's possible the DVHS decks would work, because as you pointed out, it's kind of pointless at that point since the protection is already compromised and can be recorded to a PC.

Originally posted by Don Landis

Oh, one more thing, I made an offer for anyone really interested in the this to contact me about the HDVR and to date no one has asked. LOL! that tells me something. So I just posted it here.


Sorry, I must have missed something. What did you offer and what did you post?

I asked 169Time for their take on whether our ability to record directly to D-VHS from a 169Time HDVR/AVX1 device will be affected if and when copy-protection flags are added to the program stream. Their reply (in full):


My well considered opinion based on a detailed analysis of the actual design of the various pieces of equipment is that there is no provision or requirement that the signal coming out of the 169time HDVR firewire adapter will ever be encrypted from the STB units that are currently compatible with the HDTV recording upgrade. In order to prevent recording, they'd have to turn off reception. This means that they'd have to disable the STB. Rumors are that dish is about to do this with the 5000. But the reason as I understand it is not because of recording but instead is to more efficiently use their satellite bandwidth, i.e. it costs DishNetwork less to transmit HDTV that is received by the newer 8PSK setup.

I personally don't believe that existence of 169time equipment will cause Dish or Direct to turn off STB equipment. Instead when technology improves so that users can record HDTV economically from analog outputs or even DVI-HDCP outputs (5 to 10 years), and if the entertainment industry is still in a position to want to control this, they might replace STBs with newer ones. There may be other factors involved such as subscription piracy for box replacement. What if Dish and Direct someday merge? The cable industry replaces boxes and amortizes the cost of this within the subscription price, for example and the satellite industry could do this.

With all of these *IFs* it doesn't seem worth worrying about the long term future. The fact is that 169time is the only way to get to tape or other computer media today. Users that understand the benefit of doing this realize why 169time.com is a valuable solution.

Ron, that post quote sounds like a politician talking. I don't think Richard or whoever wrote that understood your question, which I thought was plain enough. I have great respect for what Richaerd has done with the HDVR and the AVX-1 but that answer is not very flattering of his knowledge as it skirted around and around and around the question several revolutions without ever addressing what you asked. Makes me wonder if he really understands how 5C works and that it is the VCR that will refuse to accept the signal if proper 4 step handshaking process is not validated by the source and sink. His answer disappointed me! I assumed it did come from Richard as he is the only one speaking for 169Time in technical matters. Even Dave was always speaking to the issues of PR and user operation stuff, not the tech details on how it works.

Lifter- Didn't you just PM me on this? I sent you the information I offered.

To summarize the theories:
...My well considered opinion based on a detailed analysis of the actual design of the various pieces of equipment is that there is no provision or requirement that the signal coming out of the 169time HDVR firewire adapter will ever be encrypted from the STB units that are currently compatible with the HDTV recording upgrade (Quote)
... If the JVC30K has 5-C built in, and the DTC100, and AVX-1 do not see the flags (or encryption?), will a 'handshake' be made and a recording from DirecTV take place when (and if) 5-C is in place? (Answer: No)
It seems as if the JVC will become 'obsolete' when 5-C becomes a reality. The earlier Mits don't have the built-in 5-C ( Model #)? Any other resources?

I don't know what Mits that is. I'm only aware of the 2000 and the 1000 and both are 5C compliant. As I said earlier there are no DVHS VCR's sold that are not 5C compliant. (Based on specs as no one has really consumer tested the 5C on any of this stuff)

Will the JVC become obsolete with the addition of 5C flags? By some opinions it is now since some feel that there are no receivers that offer 1394 output. OTA doesn't count either because they want sat receivers with 1394. They don't consider any 169Time a real product because the company is not big, like Panasonic and it only sells modifications these same people call "hack jobs" Just another opinion and not based in reality, however.

Will the JVC become obsolete with the addition of 5C flags?
We, who use the JVC to record, do not accept that it is now; but may have to accept that it could be later. So, what would 169 time do to stay in the business of "hacking"? It has made a successful recording device that could be around for years, based upon the licensing agreements made by the "big guys".

I honestly don't think there's anything to worry about based on the way the system works. The worst case scenario would be that an update to the AVX1 is required.

there are stations now on expressvu that the avx1 cannot record since before Christmas. Richard can't or hasn't taken the time to fix the avx1 software for them channels so if dishnetwork starts doing whatever expressvu is on the ppv there will be nothing the 169time setup can record. So we may not even have to wait for 5C. This whole system is held together by a thread and it may not take long for it not to work at all if it doesn't go open source.

Originally posted by wildchild22
there are stations now on expressvu that the avx1 cannot record since before Christmas. Richard can't or hasn't taken the time to fix the avx1 software for them channels so if dishnetwork starts doing whatever expressvu is on the ppv there will be nothing the 169time setup can record. So we may not even have to wait for 5C. This whole system is held together by a thread and it may not take long for it not to work at all if it doesn't go open source.

Does anyone know why these channels don't work? Could it be that 5c is present on those two channels?

Originally posted by wildchild22
there are stations now on expressvu that the avx1 cannot record ...
Originally posted by mike greer
Does anyone know why these channels don't work? Could it be that 5c is present on those two channels?
Doubtful. These channels don't pass through the 5000's 8VSB modulator either.

Time to get a good analysis on those e-vu channels. Peter.

as for the 5000/HDTV mod- that could be they are 8PSK channels. easy enough to analyze. Use a 6000 that you can quickly pull the 8PSK module and see if they still come thru.

The second part is that those channels, suspect of being 8PSK are also carrying 5C flags. This could be the field proof that supports what the engineers have told me.

wildchild-
I believe the future for 169Time recording will be to use a PC as the recorder and the support for DVHS VCR's will be gone from the 169TRime specification, when 5C becomes a reality on all programing. Being a small company, 169Time has a way of just dropping support for a feature without immediate protest. Few people know or care that the MItsubishi DVHS VCR is no longer supported by 169Time 's current and latest HDVR firmware, ver. 1.85.
I don't believe 169Time is in a position to apply and pay for a 5C annual license. It would take a $100 price increase and selling 100 units a year to break even on the 5C license. Then he would need to rebuild the hardware to support the proper licensed 1394 chipset. Finally, it is not known how the AVX-1 would affect the handshaking function of the 5C flag test between source and sink. 5C limits the 1394 network to just 2 devices, not 3, so this adds a final gotcha in the saga of 169Time and 5C. We could speculate, though, that the AVX-1 may appear invisible to that HDVR-DVHS connection.

Therefore, I believe the future for 169Time is PC recorder, not DVHS.

Don,

Your speculations are overlooking so many facts that they are no better than chance.

I will say just two more things to counter your speculation: there is no 5c on the BEV PPV channels - I've checked. They are not 8PSK.

There is no need for 169Time to transition to a PC-only solution, because it already has a PC as part of the chain that can do anything necessary (the AVX1).

Don't anyone try unplugging your 8PSK module with the receiver plugged into wall power. I don't know if the thing is hot-swappable, but if it isn't you risk damaging things.

There is nothing on bell that is 8psk my receiver does not have a module. There are dvb cards that can capture the stream perfect. Another about bell is most if not all their hdtv programming is 720P not 1080i. I have checked the streams using mpegvcr and it shows them as 720

Could those channels be running at a datarate incompatible with the 5000 modulator? Say something higher than ATSC 19.3?

They aren't.

balazer- What firmware version of the HDVR do you have? Which DVHS VCR are you using?

I don't have an HDVR or a D-VHS recorder.

Word is EVU is doing something unique to the non-recordable HD channels; not 5C & not 8PSK.

Originally posted by Ken H
Word is EVU is doing something unique to the non-recordable HD channels; not 5C & not 8PSK.

It's probably still DVB-compliant, however, as many on another forum are able to record with their DVB-S PC cards.

thats correct dvbs cards work great

I have just hooked up an RCA DTC-100 with a 169Time FireWire Mod. and firmware v1.60 > a small PC running AVX-1 v08A5 > and a JVC 40K.

The AVX-1 is 14 feet from the DTC-100 and the JVC 40K and the RCA reciver are connected with ferrite coiled 1394 cables used from a Panasonic Combo.

I get glitches that are visible while viewing the staellite HDTV stream out the JVC 40K as well as on playback if I record them.

The DTC-100 alone displays no glitches when viewing without the AVX-1/JVC40K.

The glitches are typical momentary loss of digital information and occur every-12 minutes or so.

Any ideas how to rid myself of the glitches for trouble free viewing, recording and playback?

Try a shorter cable. I saw pictures of the thing and there is some cable length going from the actual HDVR to the ports on the back of the STB. Add that to your 14 feet and it may exceed 4.5 meters, the maximum for firewire.

mkerdman,

You are the second person that I recall reporting glitches with the JVC 40k and A5 software. I wonder if there is a difference between the 30k and 40k decoders that causes this. I have 2 JVC 30K's and they both work fine. I wish someone with both decks would comment.

I do not seem to have any problems with extended cable lengths, and I use several firewire extension cables with my avx-1 setup at times.

Originally posted by Lifter
Try a shorter cable. I saw pictures of the thing and there is some cable length going from the actual HDVR to the ports on the back of the STB. Add that to your 14 feet and it may exceed 4.5 meters, the maximum for firewire.

Lifter

Actually, I was using 6 foot cables and had the same problem and was hoping to get greater isolation from the RF etc. in the PC by getting out to 14 feet.

The results are the same, maybe slightly better at 14' rather than 6'.

Has anyone had better results avoiding glitches by using a repeater and going even farther away with the AVX-1?

Any other suggestions?

Originally posted by stjr
mkerdman,

You are the second person that I recall reporting glitches with the JVC 40k and A5 software. I wonder if there is a difference between the 30k and 40k decoders that causes this. I have 2 JVC 30K's and they both work fine. I wish someone with both decks would comment.

I do not seem to have any problems with extended cable lengths, and I use several firewire extension cables with my avx-1 setup at times.

All:

Is there any consensus as to whether the 30K or 40K match up better with the 169Time RCA DTC-100-HDVR-AVX-1?

There is an issue with the DTC100 when it is modified; sometimes there are glitches. Call Richard. He has a fix for this ( you have to send the DTC to him).

Originally posted by Don Landis
Few people know or care that the MItsubishi DVHS VCR is no longer supported by 169Time 's current and latest HDVR firmware, ver. 1.85.


Maybe more people would know about the Mits no longer working with 169time if you updated your webpage

http://www.scubatech.com/MitsMan714.htm

Which talks about using the Mits with 169time and is linked to from the 169time website.

Mark

True, unfortunately, volunteer efforts, like this are pushed to the bottom of the pile with work, family, and HT enjoymant taking priority. Probably just easier to remove it, Thanks.

Don

There are a lot of people not using the latest build software. I still use the Mits and love it. Its a very stable deck.
You put a lot of time into your on-line instructions and I and others find it very useful and appreciate it. Instead of pulling it you should just add a disclaimer letting people know the Mits no longer works with the latest version.

Just my opinion., thanks.

Alan- There is now a notice on the home page. That was quick and easy. Once I get into the manual there are other updates that also need to be made. As with the FAQ on the TV3 I posted, sometimes when notices and disclaimers aren't enough for some people it is easier just to pull volunteer efforts. Not everyone appreciates these efforts and certainly it has been shown that some are outright combative when it comes to 169Time's contribution to recording HDTV and anyone associated or supporting it. As with the TV3, those who are genuinely sincere in a quest for information have come to me privately and I have taken the time to give what I know. A formal document open to the public is a different level of information and Mark is correct. I need to keep it updated or remove it until it is. Misleading information is not good for anyone.

There's another thread about recording directly to a Windows XP PC without using a JVC deck at:

http://www.avsforum.com/avs-vb/showthread.php?s=&threadid=370904

We're making some progress but I thought I would ask some of you 169time veterans about some issues that I'm still encountering. I don't think they are related to PC Recording although I don't have a JVC to verify my findings.

I'm seeing periodic resync messages whenever I'm recording. They occur on an almost constant frequency, like every 460 seconds. Because the resyncs are not random, it seems like some sort of buffer overflow rather than random noise/glitches. Are people with JVC decks also seeing them?

When playing back the recordings using Elecard software decoder, I don't see anything unusual at the resync points. When using any other decoder (Intervideo, Nvidia, etc.) I get 1 second pauses at those points. Since I would prefer not to buy/use Elecard, I'm wondering if there's anything I can do to fix the resyncs. Does anyone know what they represent? Is it a transmission problem between the AVX and HDVR or HDVR and XP-PC?

I'm using a Dish 6000 HDVR that I got about 2 weeks ago.

Please reply in the other thread to keep things organized.

Thanks.

-Mark

Please test your playback with Videolan (www.videolan.org).

The more data we collect the closer we will get to the bottom of the problems.

Originally posted by bwooster
Please test your playback with Videolan (www.videolan.org).

The more data we collect the closer we will get to the bottom of the problems.

Please see my reply in the other thread.

Thanks.

I'm curious if anyone using 169time is not getting any (or very few) resync messages during their recordings. The best I've been able to do is a resync about every 460 seconds. The weird thing is that it does seem to be affected by your equipment since I went from every 195 seconds to every 460 seconds simply by swapping the AVX firewire card from a TI one to an Agere/Lucent one. I'm wondering if there's any other changes worth trying (cables, computer speed, etc.). Just need to know what's the best possible scenario anyone has encountered so far.

Thanks.

-Mark

Edit: I'm using the latest 0.8A5 software. Anyone know where I can get 0.8A4 to compare?

Mark- I posted it here for you- Have fun!

http://www.tv-shopper.com/TV3/AVX08A4.zip

It's a 41Mb file.

Advisory-
Richard has informed me that he has purchased a Mits 2000 for testing. I believe he may be planning to resurect the Mits compatibility with the latest 169Time hardware. Time will tell...

Also, I have updated the Mits Manual on my http://www.scubatech.com website with my latest knowledge and methods.

Where did you buy the Agere card?

What do you guys use to watch the 169Time HDVR-AVX-1 files you record to the PC without a JVC deck?

Plan to order a 6000 mod, AVX-1 and 40K within a week. Questions first:

1. Are 40K owners able to confirm that it contains upgrades that fix
problems in the 30 K that caused so many complaints?

2. Is this setup likely to allow reasonable reliability with the present software? Given the slow upgrade progress, would you do this again?

Hal

Originally posted by Don Landis
Mark- I posted it here for you- Have fun!

http://www.tv-shopper.com/TV3/AVX08A4.zip

It's a 41Mb file.

Thanks Don. As you might be able to tell from the other threads, I love tinkering with this stuff. :-)

Regarding the Agere card, it was purchased at Fry's. It a Que!/QPS Brand. It looks like it's also available on outpost.com (see the thread I mentioned a few posts ago for the link). Keep in mind that I'm doing recordings from Dish 6000 directly to an XP PC (no JVC deck) so your results may vary. I also built my own AVX.

-Mark

I already have several STB's with component video output.

I also have a DLP front projector viewed on a large Stewart FireHawk screen.

I am looking into whether I am likely to see a measurable increased benefit on OTA HD when viewed live over the Samsung T165's DVI connection, and, more on point for this thread, whether I will also be able to satisfactorily playback JVC D-VHS tapes over the Samsung T165 FireWire inputs and output them from DVI to my DLP projector.

I believe I read that D-Theater and OTA Samsung/JVC recorded tapes will work fine, but, not those made with the 169Time solution.

Anybody have any experience using these pieces together?

I believe D-Theater will only be passed through component outputs since it is encrypted.

Originally posted by EJ
I believe D-Theater will only be passed through component outputs since it is encrypted.


EJ

Well, I thought I recalled reading that D-Theater does pass through DVI because it presents no risk as DVI is HDCP protected.

Murry


You can indeed feed the Sammy via firewire from the JVC deck and DVI from the Sammy to your projectors dvi input if your projector is HDCP compliant.

Originally posted by Alan Gouger
Murry


You can indeed feed the Sammy via firewire from the JVC deck and DVI from the Sammy to your projectors dvi input if your projector is HDCP compliant.

Alan,

Is the JVC Deck's 1394 output compatible with all three of the following over FireWire to my Infocus 7200's DVI-HDCP input:

A. OTA tapes made from the T165 (obviously the answer here is yes)

B. D-Theater pre-recorded tapes

C. 169Time AVX-1 recordings made on the JVC 30K/40K deck

Sorry if I gave wrong information. I will defer to those who know more than I do!

Just remember that some OTA HDTV is 1920 x 1080i.

You're infocus projector will rescale this to 1280 x 720 since it can't display the "higher" resolution. Also, some DVI connections cannot pass through higher resolutions so you might not even get to 1280 x 720.

Good luck and please let us know what your results are.

Originally posted by bwooster
Just remember that some OTA HDTV is 1920 x 1080i.

You're infocus projector will rescale this to 1280 x 720 since it can't display the "higher" resolution. Also, some DVI connections cannot pass through higher resolutions so you might not even get to 1280 x 720.

Good luck and please let us know what your results are.


My Infocus can lock onto my Samsung HD931 DVD players 1080i output just fine over DVI.

Since the T165 forces you to select one of 480P/720P/1080i with a back panel switch, I need to decide whether to allow the T165 to scale all the 1080i content to the 720P native rate of the Infocus projector by selecting 720P on the T165, or, set the T65 to 1080i and allow the Infocus to do the scaling as needed.

I wonder however, if the T165 would then take 720P up to 1080i, only to have the Infocus knock it back down to 720P- all of which cannot be good for the signal.

Native rate output, like the Panasonic TU-DST50 has, is the very best way.

Murray

Yes to A/B

I have passed A/B to my Samsung HDCP DLP RPTV using the JVC/Samsung 165 combo.

The 165 does not like the AVX decoder so it results in mini glitches through out the movie.

I still get some glitches with my DCT100>AVX-1>JVC40K, so, I want to try different cables.

Which brand and type of 4X4, 4X6, 6X6 FireWire Cables for HDVR>AVX-1>JVC>PC do you use?

What length are they, and, are they toroidal or some other form of exotica?

I have found the Video Line Noise Suppressor for 1/4" HDTV cables at www.ebaystores.com/hdtvsupply work with my DTC-100/AVX1/30K combo

Originally posted by Jim Christian
I have found the Video Line Noise Suppressor for 1/4" HDTV cables at www.ebaystores.com/hdtvsupply work with my DTC-100/AVX1/30K combo

Jim,

Did they get rid of A & V glitching, blocking and pixelation you had on your 169Time system prior to buying them?

You can get those at Radio Shack for a lot less.

Quite a few people said they helped. I've got them on mine, power cable too.

Originally posted by mrwilson
You can get those at Radio Shack for a lot less.

Quite a few people said they helped. I've got them on mine, power cable too.

mrwilson

Sure, now you tell me.

I had the opportunity over the last week to test both the JVC 30K and 40K with a very recently 169 Time modified RCA DTC100 and an Fry’s bought off-the-shelf AVX-1 PC with CPU: VIA C3 Samuel2 GigaPro 800MHz Processor Front Side Bus: 133MHz Chipset: SIS 630E Memory: 128MB SDRAM running AVX-1 software v08A5.

The JVC refurbished 30K immediately recognized both the HDVR and the AVX-1 and assigned them “I” link numbers 1 & 2 respectively. The 30K respected those “I” link numbers and allowed me to hot-swap around the FireWire cables into various configurations whereby the HDR and JVC 30K were each the “hub”. It never required powering down to re-establish communications.

The tapes made with the 30K were flawless.

The factory-sealed new 40K also immediately recognized both the HDVR and the AVX-1 and assigned them “I” link numbers 1 & 2 respectively. The 40K respected those “I” link numbers, but, did not allowed me to hot-swap around the FireWire cables into various configurations whereby the HDR and JVC 30K were the “hub”, and, several times it did require powering down either just the 40K, and sometimes the HDVR as well, to re-establish communications when configurations were changed.

The tapes made with the 40K exhibited video “glitching” and audio dropouts at regular intervals. The video anomalies occurred about every 8-12 minutes as a burst of pixilation and the audio drop outs were more random.

Because the FireWire communications was imperfect during the record session with the 40K, the live monitoring of the recording as well as the tape itself contained the same glithces/dropouts.

Therefore just viewing Satellite HD through the AVX-1>HDVR>JVC 40K presents video glithces and audio dropouts.

I used no Video Line Noise Suppressors with either deck.

I only did some preliminary tests to record and play back to the PC hard drive, but, found that having the 30K, more so than the 40K, in the Fire Wire chain greatly improved DHVSTool’s ability to communicate and write files to the HDD.

It’s odd that JVC changed something that makes the 30K more compatible that the 40K with the TS data that comes out of the 169Time AVX-1 firewire ports.

Regrettably, or, for some possibly thankfully, the JVC 30K is no longer widely available.

Yet, the best explanation for this phenomenon is that Richard probably designed the current 169Time-AVX-1 software based on tests he conducted with the JVC 30K’s decoders as his primary baseline.

I am fairly confident from other user reports that the JVC 40K or the Mits 1100/2000 do not demonstrate the above REC/PLAY anomalies with the FireWire enabled signals of STB’s from major cable suppliers like S/A or Motorola, or, OTA STB’s like the Samsung SIR-T165.

Accordingly, we must look forward with anticipation to 169Time AVX-1 streams becoming more widely compatible with the other decoders to be encountered in new D-VHS decks like the JVC 40K/Marantz MV 8300P as well as to-be introduced JVC HM-DH5U & HM-DT100U, Terralogic-Janus HDTV PCI cards like MyHD, HiPix and accessDTV, the Roku HD1000, as well as software based solutions like DVHSTool, the Fusion & ATI HDTV PCI cards and various PC software-Video Card Accelerated player/filter/decoder combinations.

Does the 40K recording play back with glitches in the 30K?

Originally posted by mrwilson
Does the 40K recording play back with glitches in the 30K?

mrwilson

Yes it does, because the FireWire communications was imperfect during the record session with the 40K, the monitoring of the recording as well as the tape itself contained the same glithces/dropouts.

Playback on the 30K does not heal the glithces/dropouts.

I am trying to get high quality end to end all digital AVX-1 processed HD Sat streams both live and on tape sent directly to my 1280X720P DLP projector over DVI.

In furtherance of that, I was able to successfully hook up the AVX-1>HDVR >JVC 30K>Samsung SIR-T165 STB--- and, I can play back tape, or, monitor AVX-1>HDVR live Sat HD signal from the JVC 30K through the Samsung SIR-T165 component outputs (I haven’t checked the DVI yet, but, it should work too).

The Samsung in this configuration is glitch-free when playing back HD Sat AVX-1 tape files and Live HD Sat TV fed by AVX-1>HDVR >JVC 30K>Samsung SIR-T165 STB.

The extended the daisy chain may also allow for PC REC/PLAY as well, so, I will next try this configuration: AVX-1>HDVR >JVC 30K>PC>Samsung SIR-T165 STB.

Murray

Myself and many others on the forum have had bad luck with the 165 and avx files. It has the video glitches, cant handle the AVX files.

Are you using Dish or DTC100?

Thanks!

Originally posted by Alan Gouger
Murray

Myself and many others on the forum have had bad luck with the 165 and avx files. It has the video glitches, cant handle the AVX files.

Are you using Dish or DTC100?

Thanks!


Alan

It's a DTC100 with a recent Mod.

The Samsung was manufactured in Nov. 2003, but, Samsung tells me that it is electrically identical to an early production model with the firmware update added.

Yet, luck is probably the right word for it.

Since posting I have seen some motion artifacts.

However, after disconnecting and re-connecting they went away.

I had even better luck playing a 169Time tape from the JVC 30K directly into the T165 without the HDVR/AVX-1 connected.

Still, the T165 is more willing to allow the 30K's HDVR/AVX-1 incoming streams to be viewed/monitored than from tape as I did develop some problems as I tried several different tapes.

I will continue to test it under different conditions and post back.

I am only interested in a consistently reproducible installation and not one that requires the re-patching of cables and the rebooting of devices, and...luck.

My only reason to add the T165 to the mix is the pursuit of an end to end all digital AVX-1 processed HD Sat stream/tape played over DVI.

I do wonder how much can/will be gained with DVI from the T165 over Component Video out the JVC 30K when viewed on a DLP PJ on a 130" diag. FireHawk?

I certainly have had solid performance from the AVX-1/HDVR/JVC 30K Component Outputs.

Again, not so the 40K.

I have only used the 165 for AVX tape playback. The movie starts out fine and after 20 minutes you get your first drop out then few more minutes and a few more, toward the end of the movie your getting them all the time as if something has run out of buffer.

I did not try the 165 for monitoring. Ill give it a try.

I have the AVX,DTC100 and JVC30K. Murray what hook up sequence do you recommend I try so I can monitor the AVX streams.
Do you have to be recording in order to monitor the stream, if not how do you activate the firewire input.

By the way I have tried the DVI and it does make a difference. I think you will be impressed. It lifts another layer of grunge.

Thanks Murray.

Originally posted by Alan Gouger
I have only used the 165 for AVX tape playback. The movie starts out fine and after 20 minutes you get your first drop out then few more minutes and a few more, toward the end of the movie your getting them all the time as if something has run out of buffer.

I did not try the 165 for monitoring. Ill give it a try.

I have the AVX,DTC100 and JVC30K. Murray what hook up sequence do you recommend I try so I can monitor the AVX streams.
Do you have to be recording in order to monitor the stream, if not how do you activate the firewire input.

By the way I have tried the DVI and it does make a difference. I think you will be impressed. It lifts another layer of grunge.

Thanks Murray.

Alan

I just watched a 169Time/JVC30K-made tape of The Soprano's via direct component output from the JVC 30K to the projector, and, it was absolutely flawless from beginning to end- not one audio dropout or video glitch.

With that as a baseline I will hook up the following configuration:

AVX-1>HDVR>JVC 30K> Samsung SIR-T165, and, replay the tape.

If I see anything untoward at all, I will rewind it and hook up just the JVC 30K directly to the T165 and run it again to see if there is any dropouts/glitches in the 1394 chain that is creating some latency that manifest themselves in the T165 output when the HDVR & AVX-1 are present but is not there when they are removed.

I was able to monitor the HD Sat stream from the T165 outputs with the following configuration:

AVX-1>HDVR>JVC 30K>Samsung SIR-T165

This is also the config. I use to record. It allows you to also playback from either the 30K or the T165.

I brought up the FireWire menu and played 20 seconds of a DVHS tape, and then, pressed STOP through the T165's DVHS menu.

The T165 then shows an OSD indicating an OTA channel, but, in actuality monitors the "I-1" stream of the 30K, which must be the AVX-1.

The JVC must be configured whereby the I-1 is the AVX-1, I-2 is the HDVR, and the I-3 address is the T165. You can accomplish this by deleting all the iLinks in MENU and first plugging in the AVX-1 directly to the 30K, then remove that cable and attach it to the HDVR, attach another cable from the HDVR to the JVC 30K, and yet another from the 30K to the T165.

Murray

In the past I was using the JVC400 with the 165 and avx and had those darn drop outs. Using the 30k I had great luck last night. Reading your thread kept me up half the night experimenting:)

Ill have more time later on tonoght to continue testing.

Thanks for posting your results:)

Maybe this is a dumb question, but without going through 121 pages of posts, and extensive use of the search function, what is the output data format on firewire? It can't be DV like SDI, is it Mpeg2 with audio mixed somehow? If it can go directly into a DVHS deck, does the deck do subsequent compression. I wouldn't think it to be SDI as it would take 1.5 Gbps and FW400 can't possibly handle that.

Thanks for any quick answers.

IEEE1394 is a network layer that can pass different types of data. You can use it to send 5:1 compressed DV from a DV or digital-8 camcorder.

It can also be used to send along MPEG2 transport streams (with multiplexed audio and video) intact between devices (such as D-VHS decks).

IEEE1394 can be used to send HAVI commands, encapsulate TCP/IP ethernet, or hard disk read & write commands.

For example, lets say E* is sending an MPEG2 HD channel - it can be broadcast from them in 4PSK, received by a Dish 5000, modulated to 8VSB (ATSC), received by a HiPix card, sent via IEEE1394 to a DVHS deck and recorded. The MPEG2 video and audio "bits" are still IDENTICAL to what E* transmitted. There is no recompression done. The MPEG2 decoding isn't done until you actually watch it.

Hope this helps.

(I have no idea what an AVX1 does to data passing through it)

Actually I was actually looking for something more AVX specific to try to understand the data formats. What are the data file formats from the AVX to the PC or STB? However, I think you sort of answered the question.

In your fourth paragraph you discuss the HiPix card, and mention that it sends Mpeg2 and audio. Would it be a good assumption then at the AVX does this as well?

The dish 5000 solution no longer exists, however, your discussion must be analogous to AVX otherwise the JVC HD30K wouldn't work on both. What is the data rate of an Mpeg2 compressed full HD signal? It must be less than 400 Mbps.

The front of my JVC 30K has a firewire port that says "DV in". The manual for the JVC 30K shows on page 62. a camcorder with the words "DV output" going to the "DV in" connector on the back of the VCR.

I ran a tool called "AVBrowser" on my Powerbook hooked up to my setup and found that the AVX showed up as a "Camera".

The output of the AVX appears to be "DV" (Camcorder output).

Is "DV output" the same as the ieee standard for MPEG2 transmission over firewire?

Originally posted by Compromise
What are the data file formats from the AVX to the PC or STB? However, I think you sort of answered the question.

I assume it is encapsulated MPEG2 all the way through.
I seriously doubt the AVX1 does MPEG2 recompression, so it is really just a matter of muxing different streams, and sizes of data packets.
There are also multiple types of timestamps that different systems use to keep the audio and video streams in sync.


In your fourth paragraph you discuss the HiPix card, and mention that it sends Mpeg2 and audio. Would it be a good assumption then at the AVX does this as well?

The HiPix is an ATSC (8VSB) tuner card, a scaler, and an HD MPEG2 decoder.
If you captured MPEG2 transport streams from an 8VSB source (like OTA, or a Dish 5000 modulator), then you could pass the data to a DVHS VCR using a program like DVHStools. The AVX1 can also send data directly to a DVHS for recording... So I suspect that the data from either (coming out of an AVX1 or spooled from a HiPix recording) is basically the same sort of thing.


The dish 5000 solution no longer exists, however, your discussion must be analogous to AVX otherwise the JVC HD30K wouldn't work on both.

Right...

What is the data rate of an Mpeg2 compressed full HD signal? It must be less than 400 Mbps.

Uncompressed HD is something like 1500MBit/sec.
They often use some light compression when recording to tape in the editing room... Bringing it down around 500MBps
Once the MPEG2 encoders get involved it is often then encoded down to a range of 15-45Mbit/sec.

Many consumer playback devices (MPEG2 decoders) can only handle up to around 30Mbit/sec (if that), so we (as consumers) end up with things like:
~25Mbit/sec: D-Theater pre-recorded tapes
~22Mbit/sec: Japan BS sat broadcasts
~19Mbit/sec: Full bit rate ATSC OTA
~15Mbit/sec: Typical multicast OTA, or sat chan like HBO-HD or SHO-HD

Originally posted by Alan Gouger
Murray

In the past I was using the JVC400 with the 165 and avx and had those darn drop outs. Using the 30k I had great luck last night. Reading your thread kept me up half the night experimenting:)

Ill have more time later on tonoght to continue testing.

Thanks for posting your results:)


Alan,

As we discussed, my further testing as well as yours has revealed that digital video glitches do occur during extended viewing with the 30K/T165 combo making the recordings not of archival quality and while somewhat watchable ultimately annoying.

Improvement to the AVX-1 code to establish broad compatibility with SW and HW decoders is required as the 30K is no longer readily available and in many cases compatible authorized DHVS HD taping is becoming widely available from cable companies around the country.

Absent any 5C restriction that may be present, the prime advantage that 169Time will then have is the possible opportunity to archive HD recordings for later transfer to Blue-Ray/HD-DVD.

Do the glitches still appear even when a PC is decoding the D-VHS files? I've been waiting such a long time for a stable recording solution where I can archive to my PC, unfortunately the 921 does not allow this nor does the Hughes HDTivo, a big dissapointment :( so I'm looking at 169time again.

Phire

Yes you will get the glitches even when the PC decodes the stream.

Playing back the tape or files through the JVC 30k is "the" only method until 169 gives us a new software drop with improved decoders.

The 30k is now discontinued making this updated more important for the survival of the AVX.

Please contact 169 company and let them know your considering their product but the decoder compatibility issue is keeping you on the bench.
Give them a nudge.

Alan,

Your view on 169time/avx-1 compatibility conforms precisely with mine. Until the the avx-1 software improves, I believe that the JVC 30k is an essential piece of the puzzle.

The JVC 30k provides connection robustness (even for PC recording). It also has the best decoder I have found for avx-1 recordings either on D-VHS tape or the PC.

I gave up tweaking my various PC software decoders once the A5 avx-1 software was introduced, because recording on my PC with DVHSTool and playing back with DVHSTool through the JVC 30k decoder gave me the better results than any software decoder.

I second the thought...or is that simply chime in?

The JVC 30K may have a wonderful decoder however I would like to simply play the tapes on my other Panny machines or even on a Mits and feed it through my MYHD Card. The image running component out from the JVC is nowhere near as clean...general picture wise...... as what I get from files or tape from the MYHD card and from any DVHS playback deck.

I have a 6000 ready and waiting for a mod job if and when the signals are more standard.

I emailed Richard about this a couple months ago and got no real reply on the issue.

Larry

I know I am preaching to the choir when I say that Alan and Steve's comments represent the unviersaly held belief of the entire 169Time user community insofar as there is an undeniable need to have new AVX-1 software delivered that is fully compatible with the vast majority of all SW & HW decoders, and, not just the now long discontinued JVC 30K.

That said, I have some guarded optimism that while it may have been long delayed in coming, there may well be a new rev to the AVX-1 code late in Q1 or early in Q2 that directly addresses this issue.

I think169Time understands believes that this is in their best business interest, as well as those of their users.

Originally posted by Alan Gouger
...The 30k is now discontinued making this updated more important for the survival of the AVX...

Alan,

Are you sure that the 30K is officially discontinued??? I went into my local Circuit City a week or so ago and they had a store display model of a JVC 30K. I asked a manager about buying it off the shelf and they said they can't sell their display model unless it has been discontinued, and accoding to them, it isn't yet:confused:

Originally posted by videohot
The image running component out from the JVC is nowhere near as clean...general picture wise...... as what I get from files or tape from the MYHD card and from any DVHS playback deck.

I have a 6000 ready and waiting for a mod job if and when the signals are more standard.

Larry

Larry

Since I own a digital projector and, have sampled stunning DVHS playback over DVI from the Samsung T165, I totally agree that broad decoder compatibility for 169Time AVX-1 streams would open up vast new markets for 169Time from those users who want to play files and tapes through decoders and devices other that the JVC 30K.

I also have a 6000 ready to me modified.

videohot - mkerdman

I have the 169 Time mod for the Dish 6000 and the 30K. Had the setup now for the last 6 months. I was hesitant to have it modified due to reports of instabilities. With the last software update, the recordings have been pretty much flawless. I don't take any extra precautions on wire lengths, chokes, or how far away the AX1 is. The thing I like the most is you can do unattended timed recordings using the 6000 internal timers to force HD to the 30K. Makes it nice for the late night recordings or when you are at work.

I don't think you could go wrong with getting the mod done now. The next software update should make it even better. I'm glad I didn't wait. I have many great movies recorded.

Steve

Originally posted by xsrsmithx
videohot - mkerdman

I have the 169 Time mod for the Dish 6000 and the 30K. Had the setup now for the last 6 months. I was hesitant to have it modified due to reports of instabilities. With the last software update, the recordings have been pretty much flawless. I don't take any extra precautions on wire lengths, chokes, or how far away the AX1 is. The thing I like the most is you can do unattended timed recordings using the 6000 internal timers to force HD to the 30K. Makes it nice for the late night recordings or when you are at work.

I don't think you could go wrong with getting the mod done now. The next software update should make it even better. I'm glad I didn't wait. I have many great movies recorded.

Steve

Steve

I am subbed to both E* and D* and have an active 169Time mod. DTC100.

I also am able to REC/PLAY flawless DVHS recordings, but ONLY with and from the JVC 30K over it's component outputs.

However, I want to play back my DVHS tapes over a digital DVI connection which requires either a Samsung T165 or LG 3410 to accomplish.

The decoders built into these STB's DO NOT decode 169Time streams glitch-free. Only the JVC 30K does that and it is no longer in production, has it's own set of flaws and does not have DVI outputs.

Also, I would like to record and play back 169Time STB files on a PC, however, no PC based SW or HW decoder can record/play 169Time streams glitch-free.

Again, you can REC/PLAY PC files glitch-free ONLY if you play the PC files through a JVC 30K.

So, if the AVX-1 streams were more portable across other HW & SW decoders, I would modify the 6000 and probably drop D*.

xsrsmithx,

Well, great movies recorded, that can only be played back with only ONE device means to me:

I will have have lots of tape and hard drives tied up with material that takes ONE discontinued electronic device to play them back on and, in my case, not that well. I believe there is also some thread that shows the JVC decoder tends to clip the highest frequencies via the component out. So while it may look great on some setups, on mine the JVC doesn't compare to the same tape being played via firewire and a MYHD card. If some third party came up with a piece of software that would modify the files to play properly, that might be enough to make me invest not only in the 169time gear but the time and the backup materials.

Reel to reel, audio cassettes, elcasette, betamax, quad videotape, wire audio recordings from the 40's, and hordes of other formats could be played using multiple pieces of equipment and still can.

It sounds like none of what you have can be used on anything but the JVC, ever. When the AVX software is working well enough that it does produce a more standard stream of data I will buy it. If 169time has committed to to software to reprocess streams previously recorded, I'm certainly not aware of it.

Most of what we record will be available at some point on HD-DVD. We don't really own any of what we may record anyway.

Larry

I have made many recordings using my AVX-1 and my JVC 30K.

I have lent the tapes to my buddy who has the JVC 40K and they play back without any problem from his unit.

I can also record from the AVX to my Powerbook and play the transport stream files back through the JVC 30K or 40K using VirtualDVHS.

So far I have not seen any problems other than minor sound dropouts.

Originally posted by bwooster
I have made many recordings using my AVX-1 and my JVC 30K.

I have lent the tapes to my buddy who has the JVC 40K and they play back without any problem from his unit.




The key point here is that you could not RECORD the same glitch-free tape with your buddy's 40K because it does not accurately capture the AVX-1 streams to start with the ay the 30K does.

Murray

If the AVX decoder update ever does happen I wonder if theres a way to re record our current library to tape through the AVX to gain use of the new decoder so we can play our current library using other decoders. Did that make sense:)

Originally posted by Alan Gouger
Murray


If the AVX decoder update ever does happen I wonder if theres a way to re record our current library to tape through the AVX to gain use of the new decoder so we can play our current library using other decoders. Did that make sense:)

Alan,

If you have tapes that you recorded that are perfect when played on a 30K, but nothing else, you might be able to "Restore" them to HDD with DVHSTool using the To-be-Released Updated AVX-1 code, and, then (re-record) archive them back to DVHS, or, hopefully HD-DVD, which "may" result in a more perfect Tape/Disc.

However, there have been some reports that when DVHSTool Restores a DVHS tape to HDD it can add glitches that were not present on the tape itself.

Fun huh.

If you have a playback device you like better than the mechanics of the JVC 30K, say a Mits DVHS, you can play your 30K tapes in it through the 30K acting only as an expensive decoder with perfect results.

It doesn't make sense that the 30k can play files glitch-free, yet on a PC it shows glitches? Are you guys sure that the 30k isn't simply dropping these frames entirely during playback and you might not notice?

VLC on my Dual G5 mac plays back the AVX recored files perfectly.

I seem to remember that my Elecard MPEG playback software also played the AVX files perfectly.

I wonder if the ATI HDTV recording add on card can also play these files back perfectly. Does anyone have one of these cards? Are they out yet?

Originally posted by bwooster
I wonder if the ATI HDTV recording add on card can also play these files back perfectly. Does anyone have one of these cards? Are they out yet?

bwooster

Betting that ATI will deliver compatibility to a third party product like 169Time is a risky proposition.

Originally posted by bwooster
VLC on my Dual G5 mac plays back the AVX recored files perfectly.

VLC is no longer able to play DD5.1 on a Mac.

mkerdman:

I don't think ATI would care about 169time at all....but they are the first really big company that I know of that is getting involved in the PC-HDTV recording market.

I would hope that there card would playback the AVX streams properly but we won't know until someone can try it.

Someone in another thread I read just recently mentioned he tried the Elecard MPEG playback software and was happy. I asked if it played the AVX files perfect and he said no. I dont have high hopes for ATI unless they are doing something different. I think all we can do is hope for decoder improvement to come from 169time side. Once that happens it should open the door to a variety of options.

Originally posted by Alan Gouger
I think all we can do is hope for decoder improvement to come from 169time side. Once that happens it should open the door to a variety of options.

Alan:

Did you abandon the thought of Dish 6000/169 and the Roku? It's working great here.

Originally posted by Ron Tobin
Alan:

Did you abandon the thought of Dish 6000/169 and the Roku? It's working great here.

It's disappointing that the Roku HD1000 does not have a DVI output.

Still, at the new $299 MSRP, it's a lot more interesting than before.

Originally posted by mkerdman
It's disappointing that the Roku HD1000 does not have a DVI output.

Still, at the new $299 MSRP, it's a lot more interesting than before.

I agree with you, but am quite impressed with the Roku's component output. The video is spectacular, and equal to that of the JVC's component output.

If you followed our thread on 169time and Roku, you will have seen that we tried all kinds of tests with D*/169/AVX material through the Roku, and concluded that, for whatever the reason, E* works almost flawlessly yet D* has severe audio drops.

Ron

I am a week or so away from my Dish 6k arriving. Once I get it Ill be back on the
AVX Roku wagon:)

Got my 6000 today, and will be sending it to Richard on monday. Should be in the land of happy recordings by next friday! :D Its too bad I wasnt able to get an already modded 6000 though......

Kirby

Glad to see you came across a 6k.
We should be up and running right around the same time.

I don't know if anyone is looking at the "LG LST-3410A Review" thread but a few of us new 3410a owners have questions concerning whether the AVX-1 will work with the LST-3410a. Early indications are that it will not.

Any help over in that thread would be really appreciated.

Originally posted by Alan Gouger
Glad to see you came across a 6k.
We should be up and running right around the same time.

Congratulations!!

I currently use the JVC 30K IR dongle connected to the RCA DTC-100's IR Extender jack to perform scheduled recordings of HD programs on my RCA DTC100-169Time-JVC 30K combo.

To have the Dish 6000 similarly control a Dish 6000-169Time-JVC 30K Combo to perform scheduled recordings, do the IR signals come from the 6000's Rear Accessory Jack's IR Extender connected to a dongle emitter, or, only from the 6000's Front mounted built in IR Blaster?

Originally posted by Alan Gouger
Kirby

Glad to see you came across a 6k.
We should be up and running right around the same time.

Alan,

Are you hoping the E* 6000 w/169Time Mod. will yield better results than the D* RCA DTC100 when played back with decoders other than the JVC 30K?

What are expecting to gain with the 6000 over the DTC100?

Hi Murray

I may be done with dish and Direct all together.

Looks like Ill be joining all the other lucky ones with digital cable using the new cable boxes with firewire output.
April first all cable companies have to offer this. My company will have the boxes next week.
Ive been reading all the posts and everyone seams to be having great luck recording to the JVC/ Mits/PCs and playing back with the MYHD card ect.

I have TW in my area and they have more HD channels than Dish & Direct combined.

Ill be joining the others in the other thread. I dont want to drag this thread off topic but I do look forward to trying a new recording media.

If for what ever reason I have bad luck theres always the AVX:)

Originally posted by Alan Gouger
Hi Murray

I may be done with dish and Direct all together.

Looks like Ill be joining all the other lucky ones with digital cable using the new cable boxes with firewire output.
April first all cable companies have to offer this. My company will have the boxes next week.
Ive been reading all the posts and everyone seams to be having great luck recording to the JVC/ Mits/PCs and playing back with the MYHD card ect.

I have TW in my area and they have more HD channels than Dish & Direct combined.

Ill be joining the others in the other thread. I dont want to drag this thread off topic but I do look forward to trying a new recording media.

If for what ever reason I have bad luck theres always the AVX:)

Alan,

When you say you look forward to trying a new recording media I take it you mean to DVHS record the Cable STB output- correct?

The only thing to keep in mind going forward is that any DVHS copies you make from Cable/Satellite FireWire outputs will have 5C flags and will not be able to be re-recorded to HD-DVD/Blu-Ray, as it is reputed to conceivably be possible to do with 169Time recordings.

So, are you putting a hold on getting a 6000 modified?

Alan,

Even without 5C, there is currently no way to record directly to a Windows PC from a cable STB, until the firebus software is fixed and released. You must record first to tape and then capture the transport stream from tape to a PC, a process that I am not convinced is bug free.

Hi Murray and Steve

I was talking to someone tonight who uses the MYHD card for playback and he said it works great.

I should not get to excited about anything until I try it myself. Ive learned that lesson the hard way many times.

I have no intentions of giving up the AVX at this point. My sat receiver is still being converted and I will have it next week. Im still looking forward to getting it and comparing the Dish files to Direct.

I dont think Ill have the Cablebox for few weeks anyway and when I do I will still keep both for awhile unless I am having extraordinary luck with the cable box.

If Richard does offer a new software drop with improved decoders I think there could be no better time than now considering other options are finally becoming reality. Maybe he will surprise us soon.

Thanks!

Originally posted by Alan Gouger
I have no intentions of giving up the AVX at this point. My sat receiver is still being converted and I will have it next week. Im still looking forward to getting it and comparing the Dish files to Direct.



Alan,

Were you specifically motivated to get a 169Time E* 6000 because of the reports that it worked better than your D* DTC100 to record PC files and play them back from the Roku HD1000, and, may also have fewer audio dropouts as well?

Murray

Yes. Based on the testing by those in the Roku thread started by Marc. Files recorded from Dish via the AVX played fine through the Roku but anything from Direct through the Roku produced bad audio drop outs.

By the way my Roku has a bad case of chroma delay. On the big sreen it is clearly visable and mkes for a blurry image. Others note they do not see this.
I need to get my hands on another unit to see I have a faulty unit or if its common to all of them.

Originally posted by mkerdman
I currently use the JVC 30K IR dongle connected to the RCA DTC-100's IR Extender jack to perform scheduled recordings of HD programs on my RCA DTC100-169Time-JVC 30K combo.

To have the Dish 6000 similarly control a Dish 6000-169Time-JVC 30K Combo to perform scheduled recordings, do the IR signals come from the 6000's Rear Accessory Jack's IR Extender connected to a dongle emitter, or, only from the 6000's Front mounted built in IR Blaster?

Can anyone answer this one?

Question for anyone out there with a Dish 6000 setup and ability to read your AVX output. Can you tell me if you are getting very widely ranging VRATE's on Discovery HD Theater? My HDNet channels and ESPN all stay between 2,0xx,xxx and 2,2xx,xxx. Discovery drops well below, sometimes as low as 1,2xx,xxx and on some scene changes into 6 and 5 digit numbers.

These seem to be corresponding with audio glitches on playback of the files through a Roku, and I am curious as to what DISH is doing differently to DiscoveryHD.

Originally posted by Kirby Baker
Question for anyone out there with a Dish 6000 setup and ability to read your AVX output. Can you tell me if you are getting very widely ranging VRATE's on Discovery HD Theater? My HDNet channels and ESPN all stay between 2,0xx,xxx and 2,2xx,xxx. Discovery drops well below, sometimes as low as 1,2xx,xxx and on some scene changes into 6 and 5 digit numbers.

These seem to be corresponding with audio glitches on playback of the files through a Roku, and I am curious as to what DISH is doing differently to DiscoveryHD.

At the time of this post (11:19 PT, 3/19/04) I'm getting a constant 2122288 while recording Insectia. So either they stopped testing or it's something specific to your setup.

On a related note, I noticed when recording Star Trek Nemesis on SHO that it was running at 9-10 Mbps (after null packet stripping). I could have sworn that this channel was 13-14 Mbps a couple months ago when using the 5000 Mod. At this rate, we'll be at sub-DVD quality in no time. :-(

-Mark

Edit: Okay, during commercial breaks I do see it going down to the rates you described. Not sure if this is something new or if it's always been like this.

I am sorry to report that I was able to test the LG LST-3410A DVI-1394 DVR-STB with DTC100-169Time-JVC 30K tapes, and, it does not work properly as it produces glitches and freezing over the course of 30-45 minutes of viewing.

We still need 169Time to publish a new multiple decoder-friendly revision to the AVX-1 software.

Originally posted by Wizziwig
At the time of this post (11:19 PT, 3/19/04) I'm getting a constant 2122288 while recording Insectia. So either they stopped testing or it's something specific to your setup.

On a related note, I noticed when recording Star Trek Nemesis on SHO that it was running at 9-10 Mbps (after null packet stripping). I could have sworn that this channel was 13-14 Mbps a couple months ago when using the 5000 Mod. At this rate, we'll be at sub-DVD quality in no time. :-(

-Mark

Edit: Okay, during commercial breaks I do see it going down to the rates you described. Not sure if this is something new or if it's always been like this.

Thanks for looking. One interesting thing I discovered late last night, when looking at the captures from DiscoveryHD with HDTVtoMPEG2, the resolution was reported as 1920x1088i, 29.97 fps, and 17Mb/s. However on HDNet, the resolution reported was 1920x1080i, 29..97fps, and 45Mb/s.

Would this indicate that Discovery is being re-encoded/compressed? I thought I had read somewhere that when the resolution went from 1080i to 1088i that it was from being re-encoded, but I could be way off on that. But the data rate of 17 vs. 45 seems a bit alarming.

When you say you had a constant rate, you mean it never varied even a little? Mine always changes depending on the screen, and only is the same on a still shot.

Keep in mind that those 17Mb/s and 45Mb/s values you are seeing are the "encoder hint" values. They are really just a comment field in the stream. The actual datarate is very different.

Originally posted by mkerdman
I currently use the JVC 30K IR dongle connected to the RCA DTC-100's IR Extender jack to perform scheduled recordings of HD programs on my RCA DTC100-169Time-JVC 30K combo.

To have the Dish 6000 similarly control a Dish 6000-169Time-JVC 30K Combo to perform scheduled recordings, do the IR signals come from the 6000's Rear Accessory Jack's IR Extender connected to a dongle emitter, or, only from the 6000's Front mounted built in IR Blaster?

Hi Murray:

I didn't see that anyone answered this, so let me respond.

I just converted from the D* to the E* setup with the 169time mod. I just used the dongle from the DTC100 and plugged into the accessory jack of the Dish6000. Only thing is you have to modify the plug. The Dish6000 uses a power type of a plug. You can find it in Radio Shack. You must set the accessory jack on the Dish6000, in the setup screen, to act as IR Extender.

Another thing. The commands from the Dish6000 do not power on and power off the JVC30K. It only sends the record and stop commands. So you must leave the JVC30K on, at the I link that bridges the Dish6000 HDVR and the AVX1 (usually I-2).

Hope this helps.

Ron

Originally posted by Ron Tobin
Hi Murray:

I didn't see that anyone answered this, so let me respond.

I just converted from the D* to the E* setup with the 169time mod. I just used the dongle from the DTC100 and plugged into the accessory jack of the Dish6000. Only thing is you have to modify the plug. The Dish6000 uses a power type of a plug. You can find it in Radio Shack. You must set the accessory jack on the Dish6000, in the setup screen, to act as IR Extender.

Another thing. The commands from the Dish6000 do not power on and power off the JVC30K. It only sends the record and stop commands. So you must leave the JVC30K on, at the I link that bridges the Dish6000 HDVR and the AVX1 (usually I-2).

Hope this helps.

Ron

Ron

Thanks, that's exactly what I needed to know.

By not powering the JVC 30K ON/OFF, the E* setup is actually more reliable.

Did Radio Shack have a female-male adapter, or, did you have to cut off the mini-plug and solder on the power type plug?


Why did you switch to E* from D*?

Originally posted by mkerdman
Ron

Thanks, that's exactly what I needed to know.

By not powering the JVC 30K ON/OFF, the E* setup is actually more reliable.

Did Radio Shack have a female-male adapter, or, did you have to cut off the mini-plug and solder on the power type plug?


Why did you switch to E* from D*?

Murray:

No, Radio Shack did not have the adaptor, but I happened to have a female mini jack in my "junk box", so I made an adaptor cable. If you don't do that, then yes, you have to cut off the mini-plug and solder on the power type plug. The other trick is to figure out the correct power plug to buy at Radio Shack. I guessed, & guessed correctly. Sorry, I can't tell you the part number, because I disgarded the packaging. But it's a larger size power plug. And it's one that you have to solder. If in doubt, just buy all the sizes they have, and return what you don't need.

Oh, I switched from D* to E* for the same reasons Kirby did. Severe audio glitches when recording 169/AVX to the PC and playing back through the Roku. We had a robust thread on it, started by Marc Carra., "A new option for 169time File Playback!!!"

Ron

Originally posted by Ron Tobin
Murray:

Oh, I switched from D* to E* for the same reasons Kirby did. Severe audio glitches when recording 169/AVX to the PC and playing back through the Roku. We had a robust thread on it, started by Marc Carra., "A new option for 169time File Playback!!!"

Ron

Ron

I have a DTC100/169Time 1394 STB and I like it very much for DVHS taping.

I also have a 2TB three tuner-PC accessDTV network for all OTA REC/PLAY.

While I have an unmodified Dish 6000, I am waiting to see what happens with E* & D* HDTV programming, the 921 and the HD-Tivo before committing further to E* by modding the 6000.

Does the Roku HD1000 give you glitch/dropout free playback of PC HD 169Time files?

What programming are you recording to PC and what programming to DVHS, if any?

Originally posted by mkerdman
Does the Roku HD1000 give you glitch/dropout free playback of PC HD 169Time files?

What programming are you recording to PC and what programming to DVHS, if any?

Murray:

I just returned from vacation, and prior to that, only had the Dish6000 for about a week. It's not glitch free playback through the Roku, but acceptable. Discovery HD seems to be the one that has some problems. They're more annoying than anything else. It was reported in the original Roku thread (which I referred to) that E* was audio glitch free, while we were all having big time problems with D*. So one by one, several of us made the jump. I still have my D* 169 modded receiver, which I will probably sell. The audio was so bad, that you could not watch anything. While E* was reported as audio glitch free, and we tried some samples, unfortunately, the file size only allows 2-3 minutes to be available on an FTP site. I'm not disappointed that I switched, because the PC recordings are certainly watchable through the Roku. Hopefully, the next AVX1 software drop will yield improvements. If so, it will be by accident, because I know Richard does not have the Roku HD1000, and even if he did, there is the PC recording software, i.e., DVHSTools or DVHSCap, both of which I know he won't support. Too many pieces here in the mix, by too many developers/companies.

As for what I'm recording where, I've only been playing around, but plan to use the PC for time shifting and for keeping documentaries and other interesting pieces which I might want to share with company or view again myself. The DVHS will be used for movies and material I don't want to waste disk space on.

Originally posted by HDHTPC
Keep in mind that those 17Mb/s and 45Mb/s values you are seeing are the "encoder hint" values. They are really just a comment field in the stream. The actual datarate is very different.

Ok. Makes sense. But I would like to add, that it does seem that Dish is re-encoding Discovery HD. Or doing something odd to it.

So far, both HD Net's and the HD PPV are reporting 1920x1080i. Notice 1080i. Discovery is at 1088i. What does this mean? Is it being re-encoded somehow? And the "encoder hints" seem to all be 45Mb/s except for the DiscoveryHD. Any ideas what is going on with that channel?

I noticed also that the data rates from the AVX screen for every channel except Discovery are always above 2 million. Discovery fluctuates a lot, sometimes dropping as low as 1,0xx,xxx in the program, and as low as 45000 on a commercial change over. While I understand why it would do this (black frame between show and commercial needs little data) why is it only on Discovery? HDNet changeovers dont do this. I really hope that Dish isnt going to move to the encoder settings used on Discovery for everything!

Originally posted by Kirby Baker
Ok. Makes sense. But I would like to add, that it does seem that Dish is re-encoding Discovery HD. Or doing something odd to it.

So far, both HD Net's and the HD PPV are reporting 1920x1080i. Notice 1080i. Discovery is at 1088i. What does this mean? Is it being re-encoded somehow? And the "encoder hints" seem to all be 45Mb/s except for the DiscoveryHD. Any ideas what is going on with that channel?

I noticed also that the data rates from the AVX screen for every channel except Discovery are always above 2 million. Discovery fluctuates a lot, sometimes dropping as low as 1,0xx,xxx in the program, and as low as 45000 on a commercial change over. While I understand why it would do this (black frame between show and commercial needs little data) why is it only on Discovery? HDNet changeovers dont do this. I really hope that Dish isnt going to move to the encoder settings used on Discovery for everything!

I just checked again and I'm still getting pretty constant (above 2 million) video rate on DHD. It fluctuates a little but no more than the other channels. I only see the huge changes during breaks.

I never rely on the bitrate reported in those programs. TSReader seems to give more reliable numbers by actually analyzing the stream in real-time. There is a free "lite" version that should show you the real numbers so you can compare for yourself. Just make sure you're looking at the video PID (usually 0x11).

The 1080 vs 1088 thing is really just a "clue" that a different encoder may be involved.

Personally, I think the days of DBS HD getting "passed through" without being re-encoded are gone. I bet E* and D* are re-encoding most all of their HD channels now so that they can stat-mux them and share as many chans per transponder as possible.

Just for reference, about 2 years ago, I noted the following from a Dish 5000 + modulator:

Chan: HxV Encoder Hint
HBO: 1920x1080i 14.200Mbps 29.97fps
SHO: 1920x1088i 14.200Mbps 29.97fps
DSC: 1920x1088i 17.000Mbps 29.97fps
PPV: 1920x1080i 17.048Mbps 29.97fps

A little while later, I noticed that HBO changed to
HBO: 1920x1088i 14.250Mbps 29.97fps

Now, as I look at D*, basically everything shows:
1920x1088i 45Mbps 29.97fps

In summary,
DSC-HD was showing 1088i even when first launched on E* a while ago.

Many chans show an encoder hint of 45Mbps even though the actual rate is < 19Mbps.

Some chans have vertical encoding of 1080, other 1088... They even change back and forth from time to time.

Basically all the "1080i" chans seem to always be 29.97fps.
The only time I have seen other FPS is from 720p sources.

---

So - I wouldn't put too much into tracking the Mbps (encoder hint), or the vertical res... Studying the picture quality is what really matters.

I just think the AVX has a flaw in it's basic design concept.

If the capture of the stream were correct, why would it matter what kind of proccessor the AVX software runs on, and what do timings have to do with a byte stream? 169time must not be marking off the bits properly.

They've reverse-engineered something based on one decoder, came up with an answer that's not quite right, and when it doesn't work with other decoders they blame the other decoders.

But it's the only way I know of to record NFL Sunday Ticket football games in high definition, so that I can watch last year's playoff games this year.

Originally posted by HDHTPC
In summary,
DSC-HD was showing 1088i even when first launched on E* a while ago.


A question for you. While I dont think I mentioned it, all the recordings I am making are fine on the JVC for playback. But I am trying to play through my Roku. So with that being said:

Is it at all possible that the streamplayer app (on the Roku) is seeing the encoder flags and messing up on some of them? Its a stretch I assume, but here is what I discovered. On all channels, excluding ESPN and Discovery, the resolution flag on my captures from Dish are 1920x1080i. This includes both HDNet's, HBO, Showtime, PPV. Discovery recordings I have made in the past few days are all 1920x1088i. In every case, the captures from non-Discovery channels play perfect.

Discovery programs are hit or miss with audio glitches only. Video is always fine. Some 5.1 programs play perfect, some have glitches, and the same goes for 2.0 shows. But it does seem to be show dependent. A recording earlier today had the preview stuff in 2.0 with glitches, then a show started that was also 2.0, but had perfect audio.

Any idea what can be causing this sort of behavior? I seriously doubt its the AVX/169time unit itself, since all other channels work great. Could it be the way that Discovery has encoded the source material? I wouldnt imagine that Dish is doing anything to the signal on a show by show basis. Any ideas?

I have played a few of my avx-1, D* recordings through the DTC-100 decoder as a comparison to the recordings played through the JVC 30k decoder. While I do get occasional minor video glitches on playback through the DTC-100, I believe that I get fewer glitches on recordings that have more null packets. I can usually gauge the volume of null packets by the amount of compression that I get archiving a recording to DDS tape; more compression indicates higher null packet content.

HBO, Showtime (especially 2.35:1 OAR-HD broadcasts) and many SD broadcasts (on the HD channels) have high null packet content. I have not archived any Discovery-HD content, but I suspect many of these broadcasts have low null packet content. Therefore, my guess is that the Roku might have trouble with low null packet content recordings in a similar manner to the DTC-100 decoder. In the case of Roku, the glitches are with the audio rather than the video.

Originally posted by stjr
In the case of Roku, the glitches are with the audio rather than the video.

Steve:

Does that make sense that video, which is the majority of the file, would play perfectly through the Roku, yet audio, which takes up considerably less file size, is prone to glitches?

Ron

Originally posted by stjr
Therefore, my guess is that the Roku might have trouble with low null packet content recordings in a similar manner to the DTC-100 decoder. In the case of Roku, the glitches are with the audio rather than the video.

All my recordings are processed with nullpacketstripper. So I dont think this is the case. I believe that Marc's large library of files are also stripped files..

Ron,

It appears that every decoder deals with irregular transport streams in different ways. That is why we get different glitch patterns with avx-1 streams using different decoders and different capture/rendering software. The JVC 30k decoder seems to be very good at handling these streams.

I cannot explain why some decoders would have audio glitches and others have video glitches. As I alluded to above, I even get audio glitches playing avx-1 - DVHSTool captured files through the JVC 30k decoder when I use the MyHD software, even though playback with DVHSTool is virtually glitch free.

Oh well.... I guess we'll just keep pioneering, and someone will figure out the cause and the cure. For the moment, I'm still quite satisfied with the difference, while not perfect, between captures played through the Roku now made from Dish vs. Direct.

Originally posted by Ron Tobin
Oh well.... I guess we'll just keep pioneering, and someone will figure out the cause and the cure. For the moment, I'm still quite satisfied with the difference, while not perfect, between captures played through the Roku now made from Dish vs. Direct.

Yeah its night and day between the two, at least in terms of using the Roku for playback.

Originally posted by Kirby Baker
A question for you. While I dont think I mentioned it, all the recordings I am making are fine on the JVC for playback. But I am trying to play through my Roku. So with that being said:

Is it at all possible that the streamplayer app (on the Roku) is seeing the encoder flags and messing up on some of them? Its a stretch I assume, but here is what I discovered. On all channels, excluding ESPN and Discovery, the resolution flag on my captures from Dish are 1920x1080i. This includes both HDNet's, HBO, Showtime, PPV. Discovery recordings I have made in the past few days are all 1920x1088i. In every case, the captures from non-Discovery channels play perfect.

Discovery programs are hit or miss with audio glitches only. Video is always fine. Some 5.1 programs play perfect, some have glitches, and the same goes for 2.0 shows. But it does seem to be show dependent. A recording earlier today had the preview stuff in 2.0 with glitches, then a show started that was also 2.0, but had perfect audio.

Any idea what can be causing this sort of behavior? I seriously doubt its the AVX/169time unit itself, since all other channels work great. Could it be the way that Discovery has encoded the source material? I wouldnt imagine that Dish is doing anything to the signal on a show by show basis. Any ideas?

I don't think E* does anything show by show either.

I can't explain your inconsistencies. I don't know why DSC would be problematic, but the others not.

At first I thought maybe it was datarate related
(where DSC is likely higher than SHO-HD or HBO-HD), but then
you mentioned that your HDnet and PPV are fine, so I am back
to scratching my head.

Is HDNet a pay channel now? I can't seem to get 199 on D* any longer.

It's not on 199 any longer, it's on 79, however, you can only get it as part of the HD Pack, which also includes HDNet Movies, Discovery HD and ESPN HD, along with HDNet, for about $11.00 a month.

It's been that way for quite a few months.

I finally got a transcoder for connecting my JVC 30K to my projector. Bypassing the DTC-100 for playback makes a HUGE difference. I have not seen any video dropouts so far. The Key Digital KDCTC3A is definitely worth the additional $100 over the Audio Authority 9A60; although the AA does work just fine with my Panasonic RP-91.

Does anyone have a small 169time recorded stream they can put up? I would like to see how they actually play back and would like to mess around with different decoders.

Originally posted by Phire
Does anyone have a small 169time recorded stream they can put up? I would like to see how they actually play back and would like to mess around with different decoders.

Send Kevin Yee a PM and ask him to give you the address of his FTP site. There's lots of 169time recorded streams there. I just don't want to publically give out the site address.

Just an off the wall random thought.

Firewire and DVHS were developed at about the same time to the point where D-VHS bit formatting is supposed to match the packet structure for firewire. (I read that somewhere).

We don't know what the AVX is doing when it transfers the transport stream to firewire,

but when the tape stream is transferred to a PC (or I am guessing the Roku), the driver in the PC has to treat the packet structure like a file system. (Not having used it, I can only imagine).

Perhaps the packet structure isn't representing the data correctly in all cases. When the JVC decodes the stream, it can go straight to the stream and read directly. But when the stream is transferred to another device, there may be other headers or summary information that he tape recorder cares nothing about but that other devices need to know. Or maybe the JVC doesn't care about something like nulls and skips over it, but to other devices, (and maybe according to the firewire standard) the 0's mean something and have to be interpreted as something in the other devices.

How about this..

Couldn't we take an OTA recording with a PCI card like a HiPix or MyHD and then try to record that exact show using the 169time on it's Satellite HD counterpart and then compare the .ts structure between the two? Or is OTA and Satelite .ts totally different?

OTA and SAT ts are basically the same type of signal, but the local broadcaster and the sat provider each re-encode using their own encoders.

Their encoders may be different brands, and almost certainly are using different settings, so the bits would not "line up" at all.

Forgot that they pass through to their own encoders, so yeah.. I guess that's not going to work.. BUT, I think I might have made some progress..

I downloaded a clip from Kevin Yee called Discoveries Ireland, when just playing back the transport stream file I noticed about 3 glitches in the video of 1-2 second pauses. I managed to get rid of the glitches completely I think, however I need to confirm that these glitches were there in the first place and that my system is not causing those glitches to show up. If anyone can confirm that these glitches are in the Discoveries Ireland clip than I can confirm I got rid of the glitches.

Phire:

I reported perfect playback of this clip, through the Roku HD1000 on the following post in a different thread.

http://www.avsforum.com/avs-vb/showthread.php?postid=3453055#post3453055

You may also want to try some of the other files which are on Kevin's site, including some that I uploaded.

Ron

Ok I'm going to read through that thread, there's alot of messages in it so it's going to take me a while. The good news (I think) is that I got it to play without glitches on the PC, I don't have a Roku right now. I'm assuming the file does not play without glitches except when using the Roku. If I have it working on the PC without glitches that means you could probably just transfer the reconstructed file back to D-VHS without the glitches, I'm still testing though.. I downloaded a few clips and it seems the Discoveries Ireland one had the most frequent glitches when viewing them on my PC without reconstruction. There are a few clips on Kevin's site, is there one in particular that you can suggest that I can test with.

Phire:

I can't really remember, but if you go to the thread and scan through the messages around the same date as the one on the link I sent you, you will find what the reports were as to perfect recordings and others that were not. Forgive me, but I don't have the link handy to Kevin's FTP site, otherwise if I saw the files, I might remember more.

I seem to recall that Marc Carra's first upload, which was all by itself, had some glitches that we all confirmed were in the same spots. But just read through the thread where we were all testing, and you'll see our comments. Keep in mind though, that we were all testing on the Roku decoder. Some of those files might have, and probably did, give different results on different decoders. This stuff is real finnicky, and very source capture specific as well as decoder specific. That's what's driving us a little nuts.

Originally posted by Phire
The good news (I think) is that I got it to play without glitches on the PC, I don't have a Roku right now. Phire, could you please elaborate on how you got avx-1 files to play without glitches on the PC? Many software decoders can play avx-1 files more smoothly than the Hipix or MyHD decoders. I'm assuming that you remuxed the files. Is this correct?

Here is a clip I found under ron's folder on Kevin's site that I redid, not sure whether he had a problem with this clip or not. I can't seem to find Marc's files on his site, I think I downloaded everything except the files in his root folder which give me an Access Denied when I try to download them.

ftp site: 216.46.65.138 port 21 l/p: temp

This is not going to be up very long. Keep in mind the file wasn't encoded for quality, just for size, it was encoded with VP6 so you're going to need to get that codec from www.on2.com (it's free).

stjr, yeah I am using some editing software that works sometimes and sometimes not. Sometimes when I open the files I just get black frames and sometimes it opens the files fine. After opening the frame rate information is corrupted, it seems to think the streams are at 0.97fps, so I have to give it the right frame rate information and then I check the audio to see if it matches up properly with the video. Then I output the file into a lossless format such as HuffYUV. When opening the original .ts video using a commercial decoder such as WinDVD I am able to see pausing glitches.

Any rumors on when the next release comes as my BEV 6000 unit still has monster problems. Richard says they are working on it but won't commit.

Richard from 169time has indicated that he might release software that would clean up previous avx-1 recordings, but this would have a lower priority than improving the current avx-1 software.

Jim Christian Richard says they are working on it but won't commit.

stjr but this would have a lower priority than improving the current avx-1 software.

I am on the fence with this product. What keeps me from buying are the problems I keep reading about and the lack of upgrades.
I find it frustrating the company itself feels they owe no commitment to their current customers and more important potential customer like myself who would buy now if I knew software improvements were going to happen on a timely schedule as needed.
I have not read this thread throughly but from what I have read the promises are there but no delivery.
When I call they are not very friendly and do not want to tell you anything.
How can they survive in a customer service oriented world?

Did anyone get a chance to take a look at the clip?

Ron was that original .ts clip problematic for you?

Phire:
Which clip are you questioning? The one I uploaded or the Discovery Ireland?

The redone one I put up on my ftp site is from Discovery HD and seems to be about martial arts.

Originally posted by Phire
The redone one I put up on my ftp site is from Discovery HD and seems to be about martial arts.

Phire:

I just viewed the martial arts clip that I put up on Kevin's site. There are two short glithches. One almost at the beginning and another about 25 seconds in. Are those the ones you see? If so, how do you clean then up. That's the problem we're having with Discovery HD captures on Dish Network, and it seems to be limited only to Discovery HD, as best as we can tell.

As far as I can see I think I have eliminated the glitches but I need you to confirm. Please download the VP6 clip on my ftp site, the info is:

216.46.65.138 port 21 l/p: temp

If you don't have the VP6 codec you can download it from www.on2.com. If the glitches are indeed gone then I think I may be getting my own 169time setup :) I will give a detailed explination as soon as things are confirmed.

Phire:
I cannot get into your site at the address you gave. Please give me the EXACT link. If you want, you can PM me.

Ron

Originally posted by Ron Tobin
Phire:
I cannot get into your site at the address you gave. Please give me the EXACT link. If you want, you can PM me.

Ron

Worked ok for me. Try this link:

ftp://temp:temp@216.46.65.138

The sample looked fine to me. The original .ts file did pause in a few places on most PC decoders.

I usually play the 169time .TS files with either CyberLink decoders (ATI version from their site) or MainConcept decoders. Just make sure that both run with no hardware acceleration. Anything with hardware mpeg2 acceleration seems to introduce the pauses. Unfortunately, this solution is no good for Discovery/Hdnet because both of those channels require de-interlacing which doesn't work well without hardware support.

-Mark

Originally posted by Wizziwig
Worked ok for me. Try this link:

ftp://temp:temp@216.46.65.138

The sample looked fine to me. The original .ts file did pause in a few places on most PC decoders.

I usually play the 169time .TS files with either CyberLink decoders (ATI version from their site) or MainConcept decoders. Just make sure that both run with no hardware acceleration. Anything with hardware mpeg2 acceleration seems to introduce the pauses. Unfortunately, this solution is no good for Discovery/Hdnet because both of those channels require de-interlacing which doesn't work well without hardware support.

-Mark

Mark:

FINALLY - it's copying now. I'm going to try to play it through the Roku, and change the extension to .ts, which is what the Roku requires. I'll post my results when I've viewed the file.

Ron