The Official R5000-HD Technical Status Discussion - Page 6 - AVS Forum | Home Theater Discussions And Reviews
Forum Jump: 
 3Likes
Reply
 
Thread Tools
post #151 of 2827 Old 11-25-2004, 03:35 AM
Senior Member
 
dcarl's Avatar
 
Join Date: Feb 2001
Posts: 301
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I'm also being driven crazy by Zap2it's overly strict time-out.
It's like an Evelyn Wood speed-reading exercise to scan the
schedule and choose a recording before it kicks me out.

With heavy traffic in the evening, I can't get to the
interactive schedule at all.

Zap2it's great otherwise.

It seems they have two different schedule pages we can view.
One is interactive (with the "record" button) and the other isn't.

I can peruse the latter all day long without ever having to re-login.
dcarl is offline  
Sponsored Links
Advertisement
 
post #152 of 2827 Old 11-25-2004, 08:49 PM
AVS Forum Special Member
 
mkerdman's Avatar
 
Join Date: Sep 2000
Location: Santa Barbara, CA
Posts: 3,048
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 2 Post(s)
Liked: 11
Quote:


Originally posted by dcarl
I'm also being driven crazy by Zap2it's overly strict time-out.
It's like an Evelyn Wood speed-reading exercise to scan the
schedule and choose a recording before it kicks me out.

With heavy traffic in the evening, I can't get to the
interactive schedule at all.

Zap2it's great otherwise.

It seems they have two different schedule pages we can view.
One is interactive (with the "record" button) and the other isn't.

I can peruse the latter all day long without ever having to re-login.


Try using RoboForm and it's AutoFill feature- for the most part, it seems to do the trick.

Evelyn Wood speed-reading, boy that brings back memories.

Murray Kerdman
mkerdman is offline  
post #153 of 2827 Old 11-26-2004, 01:26 PM
Senior Member
 
HookedOnTV's Avatar
 
Join Date: Nov 2003
Location: Oregon
Posts: 454
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


Originally posted by Ron Tobin
Thanks. I assume you're using Roku's Streamplayer. I'll have to give it a try sometime.

Actually I use the player I wrote, TStream (which you can grab a copy of from my website). It's not perfect but does have a few more abilities like skip forward/back.

I use HDTVtoMPEG2 v 1.10.5 and it works perfectly. Some of the older versions have problems with 720p material.
HookedOnTV is offline  
Sponsored Links
Advertisement
 
post #154 of 2827 Old 11-28-2004, 12:40 AM
 
HDTVFanAtic's Avatar
 
Join Date: Mar 2004
Location: 3rd Rock from the Sun
Posts: 8,246
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Forgive me for not cutting and pasting, but its just too late to do so and respond to that many points.

As for the zap2it website, besides making sure there are no limitations on the site that might force the continued login (which others have stated they have as well) I have added the zap2it address to the trusted sites section of IE and allowed cookies from everywhere in an attempt to make it work properly. No go. We are not talking about autocomplete and remembering passwords. .All these efforts are for naught - clearly from the post above there are 2 groups - one that nothing works to keep you logged in - the other group works fine.

If you accept cookies and have it listed as a trusted site, there isnt much more one can humanly do to keep the info available within the confines of IE.

As stated, there is plenty of software made for sites such as ebay that you enter your name and password into the program and you get directly sent to the appropiate page when needed without the additional 10 steps in between. The R5000 should have this - no ifs ands or buts.

Every few minutes if you are in the have not group, you must 1) wait for the logon page to reappear instead of where you thought you were going 2) begin to re-enter your name and with autocomplete make sure that goes into place - thus adding your password. 3) Then you must click on ok to get back to the 4) page for personal setup which has to load so you can click 5) to see the TV Grid.

That is a nightmare - especially when Zap2it is slower than mudd in primetime as someone stated above and I highly agree with.

There is also another issue in the PVR section which if you manually edit a program (say to move the start time and end time up 2-3 minutes as I would always do on any caps), you will find that all the sudden you find multiple instances of that capture in the PVR. If you click on those multiple instances to edit them, you will also find they aren't what they are labelled but are other items you had in place that are now mislabeled on the front interface.

The only work around is to save to a DEFAULT.PVR file (and btw, thats what it should load upon startup) and then reload it. The problem with this is if you are recording, sometimes reloading this file will stop and start your recording.

Even if you don't think a DEFAULT.PVR should load on startup, atleast give the user that option. Many do.

The MPEG errors in the capped streams have grown a 100 fold with the latest release of software. You stated the newer release would record more errors instead of blowing up the capture. Perhaps it has a little more error induciton as well???

You can dismiss the program documenting the error (Mpeg2Repair) where the repair log file has gone from an average 1kb for a capture to 500kb of errors since the new software upgrade - or even mprobe. But the errors are clearly there and multiplied at a high rate.

I have made some initial contact with some users of the other system to capture the same movies at the same time and run the same program on each capture. From the intial indications that these people have given me, the errors are nowhere near what they are with the R5000 with the latest software release - thus I don't buy that this is a Dish induced error. If this was the case, it should happen on both systems. Not being an Electronics Engineer, I can only assume you both get your mpeg stream at the same point in the STB. If one has 100x errors than the other at this point, then it's hard to blame the supplier.

As for the comment about someone recording 200GB off E* with the R5000HD and not cap blow up - or maybe just one - as the average movie runs 13-16 Gig at 19.2, I am not sure you have given your unit enough use to really see the restarts

I have run through close to a terrabyte of captures this week alone - and as I stated, its usually 1 out of 10 movies having a restart. Simple math would tell you that at your 200 GB, you might have only seen this once in your capping.

Don't get me wrong. I think the R5000 is a wonderful device in many ways. However, all the inital posts starting last June about error free capping out of the box is not exactly the case. Maybe the comments were made in light of the 169time issues - where it appears that many have the same results - some have no issues - others have massive issues. I just wasn't expecting the number of problems I have witnessed given the massive build up by people on AVS to this system.
HDTVFanAtic is offline  
post #155 of 2827 Old 11-28-2004, 09:03 AM
Senior Member
 
HookedOnTV's Avatar
 
Join Date: Nov 2003
Location: Oregon
Posts: 454
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
How's the Directshow source filter coming? It should allow the community to address some of the issues mentioned above.

ps - I have found that with almost absolute certainty you can cause a new file to be created during recording by doing anything that accesses the hard drive like deleting a file.
HookedOnTV is offline  
post #156 of 2827 Old 11-28-2004, 09:38 AM
 
HDTVFanAtic's Avatar
 
Join Date: Mar 2004
Location: 3rd Rock from the Sun
Posts: 8,246
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I should not that the computer being used for this has a 2.4G Intel Processor and 512 Megs of Ram with Windows XP SP2.

The machine has no other use, thus, it should not be conflicting programs.

According to the R5000 specs, that machine should have plenty of headroom.


BTW, in a perfect world, when you click on zap2it record button and the capture is set, the program should grab the run time from IMDB and compare, noting the IMDB time and the Channel Supplier's time alloted. You could then adjust manually. Thus you clearly would not loose the beginning or end of a movie.

It also would be very nice to have a user defined time option (say an adjustable 1 to 5 minutes) that IF THERE WAS NO CONFLICTING PROGRAM, the unit would start 1-5 min early and run 1-5 min late. It could adjust accordingly if you specified 5 minutes and supposedly ended at :30 and the next started at :35. From what I have seen in my captures for years, the end time is usually fudged more when needed than the start time (which usually always happens with 90 seconds of the correct time). A simple check of the IMDB database under Runtime should also give a clear indication to the program how tight the sequencing is going to be.

i realize there is a 60 second feature already, but the above would give more control and is very easy to code.

Both of these are very easy to do with software code - for a person who writes code - of which i am not one. However the former would be much harder to do than the later. But still very doable.

Regardless, all this means nothing if the other issues are not corrected.
HDTVFanAtic is offline  
post #157 of 2827 Old 11-28-2004, 10:22 AM
AVS Forum Special Member
 
mkerdman's Avatar
 
Join Date: Sep 2000
Location: Santa Barbara, CA
Posts: 3,048
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 2 Post(s)
Liked: 11
Quote:
Originally posted by MichaelZ
The Zap2it cookie on my computer shows an expiration date of 12/31/2013 what date does your cookie show?

How/where do you set your cookie expiration date?

Murray Kerdman
mkerdman is offline  
post #158 of 2827 Old 11-28-2004, 11:06 AM
 
HDTVFanAtic's Avatar
 
Join Date: Mar 2004
Location: 3rd Rock from the Sun
Posts: 8,246
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally posted by MichaelZ
I've only had two restarts out of 70+ hours recording (DTC-100) and both of those occured when MyHD was recording at the same time and I think it is when it started up. I have a 2400AMD chip ASUS motherboard with one 80gig maxtor attached.
Also, I left Zap2it in my browser for over an hour today and it still never timed out and it was inactive the whole time (minimized on the desktop). I am not sure what your problem is but it is a browser problem and not an R5000 problem. The Zap2it cookie on my computer shows an expiration date of 12/31/2013 what date does your cookie show?


#1 Stating the obvious, a DTC-100 is not on the Dish Network. As Directv doesn't put out the same bandwidth or signal as Dish, it is somewhat of an apple to oranges comparison. However, 70 hours of recording could be viewed as about 35 movies - thus instead of 1 in 10 you are hitting about 1 in 20.

Over the past 3 days I have probably seen 1 in 20 with Dish.

However, the error rate in the files is horrible.

Again, different delivery methods, but I would be interested in having you record several movies from SHO, HBO and HDNET at same time as DISH users do. Then use an mpeg analyzer program (mpeg2repair/mprobe etc) to compare the errors. This is what I have stated is being done dish to dish with some 169time users.

#2 As for the Zap2it login, If you read above, you will see I agree that Zap2it it is not entirely a R5000 problem. It has to do with something else. YOU WILL ALSO READ OTHERS HAVING THE SAME ISSUE. I have taken more actions than any normal user would - including adding zap2it in the trusted zones BECAUSE I DO NOT TRUST IT.

Regardless I simply suggested an option that should be included in the software that would get you to the original page first time - everytime - one that is very doable.

There is an issue between the regular Zap2it and the program guide that the R5000 uses. If you that there is no interaction between the R5000 and Zap2it perhaps you can explain why the record button doesnt show up on the same url when you enter the address manually. Zap2it clearly has an interaction with the R5000 software.

If you will clear out your cookies (delete them all) from internet options and delete all files for good measure, first go to zap2it by regular web browser. Then examine your cookies. You will see the cookie it places.

Then open up the PVR, click on the legalease, put in your password etc and go to show my listings. Then check your cookies. You will notice that there is another new cookie for the interactive program guide as well as the Zap2it url and the ad server.

Now on my system, I then closed out IE.

Then I reopned IE and went to zap2it with the url in question and went straight in with no prompting.

Then I closed IE again and did the same thing with the R5000 PVR. BINGO -login and password required - etc etc etc.

Thus something between the PVR and Zap2it is not functioning properly.

I am not at all uncovinced that this has something to do with a combination of 1) Operating System (XP on mine) 2) Service Pack installed (SP2 on mine) 3) IE Update installed and (latest Critical Updates on Mine) and 4) User name on computer (ie Administrator).

Regardless, the login failure is a reality for many of those that have posted above. As Zap2it takes 60 seconds or more to load a page during primetime (in some instances) and going through the procedure every 10 minutes makes it a very unworkable solution for me, my brothers and apparently others users.

Again, a software rewrite containing the logon and password info for the PVR to submit automatically at the initial request would eliminate this entirely.

Now, for the other question about where to find cookies, go here:

X:\\Documents and Settings\\USERNAME\\Cookies

Where X: is the letter of the drive your Windows Installation is on (usually c:\\) and USERNAME is your logon name.


Do not delete cookies there. Instead go to Internet Explorer - Tools - Internet Options - General Tab and click on delete temporary files there - both cookies and files to clear out your system.
HDTVFanAtic is offline  
post #159 of 2827 Old 11-28-2004, 11:41 AM
 
HDTVFanAtic's Avatar
 
Join Date: Mar 2004
Location: 3rd Rock from the Sun
Posts: 8,246
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
lol...posted too soon.

After 10 minutes the regular IE entry will not automatically go to listings either.

However, I did just try an interesting experiment.

AVS Forum uses cookies for automatic logon as well. So I went to AVS Forum on the R5000 Computer. Logged in - got the cookie. Now when I come back to AVS Forum, I do not have to log on.

Cookies and Automatic log on either work or they don't.

It's working on AVS Forum on the R5000 computer. It will be interesting to see if this stops working on the R5000 computer in 10 minutes or 10 days or 10 years.

And I have gone so far as to give Zap2it trusted site status - something I would much rather give to AVS Forum instead of Zap2it.

So clearly, there is a difference and as noted above - it works for some - not for others...your mileage may vary...member FDIC....not available in Alaska and Hawaii....must be 18 to apply.
HDTVFanAtic is offline  
post #160 of 2827 Old 11-28-2004, 01:32 PM
Senior Member
 
HookedOnTV's Avatar
 
Join Date: Nov 2003
Location: Oregon
Posts: 454
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Zap2it doesn't want you to be able to log in programitically. If you could someone would probably write an app that would log in and "scrape" all of the listing information therefore eliminating the need to browse their site and read their ads.
HookedOnTV is offline  
post #161 of 2827 Old 11-28-2004, 03:04 PM - Thread Starter
Senior Member
 
R5000-HD's Avatar
 
Join Date: Jun 2004
Posts: 226
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
It seems there is more and more chatter out there wrt E* transmission errors:


http://www.dbstalk.com/showthread.php?t=35457&page=1

Whatever the cause (uplink or muxers), the best any recording option can do is to capture it exactly as it comes in. Garbage in = garbage out. With these problems being increasingly frequent as of late it is no wonder that any error analysis of the streams would jump exponentially in number.

-R
R5000-HD is offline  
post #162 of 2827 Old 11-29-2004, 06:23 AM
Senior Member
 
HookedOnTV's Avatar
 
Join Date: Nov 2003
Location: Oregon
Posts: 454
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
The last few days there have been all kinds of glitches on E*. I've seen it on both my 6000 and 811.
HookedOnTV is offline  
post #163 of 2827 Old 11-29-2004, 07:48 AM
Senior Member
 
HookedOnTV's Avatar
 
Join Date: Nov 2003
Location: Oregon
Posts: 454
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I'm not terribly fond of using the zap2it web page for scheduling. Often it is very slow. So...

Found an existing application that uses the xmltv data and made the necessary modifications to make it generate the file the R5000 app needs to schedule a recording. You will need to have the .NET framework installed.

1. Sign up for data from zap2it labs. Use code TGYM-ZKOC-BUTV.

http://labs.zap2it.com/ztvws/ztvws_l...MS01-1,00.html

Configure your channel lineup etc. I have it just bringing down the few HD channels that I might record from.

2. Download xmltv and extract it to somewhere like the root of the c: drive. I renamed the folder to just xmltv to make things easier.

http://sourceforge.net/project/showf...group_id=39046

3. Configure xmltv. From a command prompt in the zmltv folder do:

xmltv.exe tv_grab_na_dd --configure

4. Download listings to make sure everything is set up correctly. From the same command prompt do something like:

xmltv.exe tv_grab_na_dd --days 7 --output listings.xml

5. Download and install my modified version of TVGuide from my website

http://www.hookedontv.com/TVGuide.zip

6. Configure TVGuide (data location, xmltv.exe location if you want to do the data load from within the app, etc.) to your liking.

7. Double click a program to create a recording.

It's simple but it works. You can schedule a download of data using the Windows Scheduled Tasks.
HookedOnTV is offline  
post #164 of 2827 Old 11-29-2004, 10:41 PM
Senior Member
 
jamesmil's Avatar
 
Join Date: Jan 2000
Location: USA
Posts: 402
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 105 Post(s)
Liked: 82
Hey Hooked, thanks a lot! This is a nice alternative. Note that the program appearently hardcodes the schedule file to be saved in "C:\\xmltv" so it will crash if you don't make a folder called "xmltv" at the root of C:\\. Also, it doesn't support the *_dd form of config files if you want to try and run xmltv from within the guide program (no big deal).
jamesmil is offline  
post #165 of 2827 Old 11-30-2004, 03:23 AM
Newbie
 
CherieK's Avatar
 
Join Date: May 2003
Location: Nicasio, CA
Posts: 10
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Help! We have been unable to get an R5000-HD to work _AT ALL_ in our HTPC system since we received the unit over a month ago. We have exchanged email back and forth between us and customer support at Nextcom many times. Basically, they have been unable or unwilling to specify a combination of USB controller and drivers that is known to work.

Is there any successful user of the R5000-HD that can specify the manufacturer and model number of a known-good USB controller and the exact names and revision numbers of all the associated drivers?

Is there any successful user who is using the R5000-HD with an Asus A8V Deluxe motherboard and an Athlon 64 3800 running Windows 2000? Better yet, is there anyone who has been able to use the motherboard USB controller as well?


We have tried three different USB controllers and followed all of the suggestions from Nextcom customer support without success.

The embedded USB controller on the Asus A8V Deluxe motherboard will only receive 6 or 7 seconds before the HDVR program reports an error and restarts the recording. Moreover, the files that are produced are garbage when played.

We disabled the embedded controller and installed a Belkin F5U220 PCI USB controller, which uses an NEC chip. Just to make sure, we were able to change the channel on the satellite receiver using the HDVR program. However, as soon as we pressed the record button, we got the Windows "blue screen of death". The error message was "DRIVER_IRQL_NOT_LESS_OR_EQUAL in ousbehci.sys". This was with the latest drivers for the Belkin board downloaded from their website.

We next purchased and installed a Compaq UC-160 (Rev 1.2) USB controller card. This card also uses an NEC chip as per the recommendation of customer support. We got the same "blue screen of death" results as with the Belkin controller.

The following is a list of things that we have already checked:
-We are only recording HD content.
-Our HTPC machine has 2 Gigabytes of RAM.
-There are no USB hubs or external USB drives connected to the USB controller.
-The R5000-HD is set for Dish Network, which is the proper service.
-The bitrate is set to "Constant 19.392Mb/s".
-The USB controllers are 2.0.
-We replaced the supplied USB cable with a "2.0" one.
-We have used the PCI slot closest to the AGP slot.
-We have downloaded and tried the latest drivers from both the manufacturers and Microsoft.
-We are using the latest 1.5a drivers from Nextcom.
CherieK is offline  
post #166 of 2827 Old 11-30-2004, 06:17 AM
Senior Member
 
HookedOnTV's Avatar
 
Join Date: Nov 2003
Location: Oregon
Posts: 454
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Have you:

Tried the card in other pci slots?
Turned PCI Bus Master on in the BIOS?
HookedOnTV is offline  
post #167 of 2827 Old 11-30-2004, 11:17 AM - Thread Starter
Senior Member
 
R5000-HD's Avatar
 
Join Date: Jun 2004
Posts: 226
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


Originally posted by CherieK
Help! We have been unable to get an R5000-HD to work _AT ALL_ in our HTPC system since we received the unit over a month ago. We have exchanged email back and forth between us and customer support at Nextcom many times. Basically, they have been unable or unwilling to specify a combination of USB controller and drivers that is known to work.

I think you are still missing the point in this issue. As reported to you, we have tested out the exact make and model Belkin card that you are using this morning and so far it has been recording perfectly for the last ~4 hours. So, as far as we are concerned that card would be part of a list of "USB controller and drivers that is known to work" but it clearly doesn't work for you. That is why providing a list of this sort is just about meaningless. There are numerous issues that can exist between the various MB manufacturers & PCI cards that we cannot have any knowledge of (unless we were to purchase every PC/motherboard combo available!)

Our recommendation still stands at this point to open up a support dialog with Belkin and/or Asus to see if there are any known issues with their PCI card and various MB models. Otherwise, the other alternative is to look for another card that works. I believe we supplied you with 4-5 different models. I don't hold out much hope any of the NEC-based cards since even though they are from different manufactureres they are for the most part going to be electrically identical.

BTW, the R5000-HD driver has never been updated in any of the software releases to date and there are no known issues or anticipated updates.

-R
R5000-HD is offline  
post #168 of 2827 Old 12-05-2004, 11:33 PM
 
HDTVFanAtic's Avatar
 
Join Date: Mar 2004
Location: 3rd Rock from the Sun
Posts: 8,246
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
I agree that the problem appears to be something strange.

As a test, 2 R5000HD users recorded Dangerous Lives of the Altar Boys on Showtime at 9:35pm Eastern Tuesday 11/29/2004 off the 110 Bird. (If you have this a capture from this time and wish to play along). All captures were edited to start at the same place and end at the same place with HDTVtoMPEG2 (though some were off up to 3 seconds as you will see).

All were then examined using MPEG2Repair with the expanded verbose error reporting.

All programs had the exact same 333k error log. They all showed the same errors at the same place - some a little more severe than others, but the consistency is clear.

For example:
Log #1

Sequence Frame 150671(710-P) / Time 1:44:20 :
Error: Motion vector going out of range at MBA=1200(0,160)
Error: Missing 1 picture slices at MBA=1200(0,160)
FileInfo: Last errors span 1120 bytes at file offset 15176910945
Error: Motion vector going out of range at MBA=1680(0,224)
Error: Missing 1 picture slices at MBA=1680(0,224)
FileInfo: Last errors span 592 bytes at file offset 15176922511
Error: Motion vector going out of range at MBA=2640(0,352)
Error: Missing 1 picture slices at MBA=2640(0,352)
FileInfo: Last errors span 578 bytes at file offset 15176939681
Error: Motion vector going out of range at MBA=4080(0,544)
Error: Missing 1 picture slices at MBA=4080(0,544)
FileInfo: Last errors span 946 bytes at file offset 15176969337
Error: Motion vector going out of range at MBA=4561(16,608)
Error: Missing 1 picture slices at MBA=4560(0,608)
FileInfo: Last errors span 726 bytes at file offset 15176978523

Sequence Frame 150739(778-P) / Time 1:44:23 :
Error: Motion vector going out of range at MBA=7560(0,1008)
Error: Missing 1 picture slices at MBA=7560(0,1008)
FileInfo: Last errors span 222 bytes at file offset 15183850121

Sequence Frame 150755(794-P) / Time 1:44:24 :
Error: Motion vector going out of range at MBA=6840(0,912)
Error: Missing 1 picture slices at MBA=6840(0,912)
FileInfo: Last errors span 130 bytes at file offset 15185468067

Sequence Frame 150961(997-B) / Time 1:44:32 :

Info: End of sequence: 1920 x 1080, 29.97 fps (with telecine flags), 18.00 Mbps.
Info: Found 150961 frames/fields since start of sequence.
Info: 766 frames/fields found with errors.
Info: 773346 corrupted bytes in file.

End of Log


Log #2

Sequence Frame 150743(710-P) / Time 1:44:23 :
Error: Motion vector going out of range at MBA=1200(0,160)
Error: Missing 1 picture slices at MBA=1200(0,160)
FileInfo: Last errors span 1120 bytes at file offset 15182411073
Error: Motion vector going out of range at MBA=1680(0,224)
Error: Missing 1 picture slices at MBA=1680(0,224)
FileInfo: Last errors span 592 bytes at file offset 15182422639
Error: Motion vector going out of range at MBA=2640(0,352)
Error: Missing 1 picture slices at MBA=2640(0,352)
FileInfo: Last errors span 578 bytes at file offset 15182439997
Error: Motion vector going out of range at MBA=4080(0,544)
Error: Missing 1 picture slices at MBA=4080(0,544)
FileInfo: Last errors span 946 bytes at file offset 15182469465
Error: Motion vector going out of range at MBA=4561(16,608)
Error: Missing 1 picture slices at MBA=4560(0,608)
FileInfo: Last errors span 726 bytes at file offset 15182478839

Sequence Frame 150811(778-P) / Time 1:44:26 :
Error: Motion vector going out of range at MBA=7560(0,1008)
Error: Missing 1 picture slices at MBA=7560(0,1008)
FileInfo: Last errors span 222 bytes at file offset 15189350437

Sequence Frame 150827(794-P) / Time 1:44:26 :
Error: Motion vector going out of range at MBA=6840(0,912)
Error: Missing 1 picture slices at MBA=6840(0,912)
FileInfo: Last errors span 130 bytes at file offset 15190968195

Sequence Frame 151047(1011-B) / Time 1:44:35 :

Info: End of sequence: 1920 x 1080, 29.97 fps (with telecine flags), 18.00 Mbps.
Info: Found 151047 frames/fields since start of sequence.
Info: 766 frames/fields found with errors.
Info: 773346 corrupted bytes in file.

End of Log

Same number of frames/fields with errors, same number of corrupted bytes - virtually identical.

Thus, it is not a SINGLE Dish Receivers. It either has to be originating out of R5000 Dish 6000 units or out of the Dish chain

A test was set up with several 169time users and a C Band user and even someone with an open cable box not on Dish for reference over this past weekend, however.....guess what happened?

The cap of The Postman was error free for the 3 hours it was on. Same with the first 8pm Saturday showing of The Last Samurai.

As no R5000HD software was changed, it does seem suspicious that this was the case. You would think if it were the software, it would be consistent in errors.

Now, Antone Fisher caused a file restart every showing in mid-November over the course of a week. Yet a week later, no issues.

It would seem that the same input should cause the R5000 to behave the same way every time. Yet it seems that the problem exists and other times it doesnt.

BTW, as a side note, as Dish allows you to view the same PPV all day for the same $5.95 price, Passion of The Christ was capped every showing for a day.The bit rate was significantly better for the first 2 showings (at 10am and 1pm) than later on in the day/evening (starting with a 5pm showing). Thus Dish does play around with these things.

This, quite simply, is why an apples to apples comparison will only work off the same capture at the same time, though the post about this being a 110 satellite issue is interesting.

Again, the final and conclusive test will be off Dish via 169time and R5000HD when the problem occurs again - most likely during the next week.

But it is looking less and less as its the new R5000HD software causing all the errors in the captures.

As for the R5000 not starting - always deciding to do this on 1 time showings or limited scheduled items, usually waiting for drive or other error messages thats a different issue.

And finally, does anyone know how to add recording time to a capture in progress? You can do this with MyHD, but when you hit OTR on the R5000HD to more time, it stops the current recording and restarts it - thus ruining your cap.

Thus, if HDNET only shows The Wall once every 6 months and it starts 30 minutes late as it did Sunday Night, you are hosed trying to add more time to the capture.
HDTVFanAtic is offline  
post #169 of 2827 Old 12-06-2004, 11:35 AM
 
HDTVFanAtic's Avatar
 
Join Date: Mar 2004
Location: 3rd Rock from the Sun
Posts: 8,246
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
As I suspected, it was too good to last.

After a weekend of 0 Error caps, every cap since the overnight Silence of the Lambs has produced an error resulting in a new file. 5 for 5.

This included Silence of The Lambs, The Life And Death of Peter Sellers, Shattered Glass and Moscow on the Hudson just blew up so badly it shut the Recorder down and wanted to send an error report to Microsoft.

Something is clearly very strange here.
HDTVFanAtic is offline  
post #170 of 2827 Old 12-06-2004, 11:56 AM
AVS Forum Special Member
 
mkerdman's Avatar
 
Join Date: Sep 2000
Location: Santa Barbara, CA
Posts: 3,048
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 2 Post(s)
Liked: 11
Quote:


Originally posted by HDTVFanAtic
A test was set up with several 169time users and a C Band user and even someone with an open cable box not on Dish for reference over this past weekend, however.....guess what happened?

The cap of The Postman was error free for the 3 hours it was on. Same with the first 8pm Saturday showing of The Last Samurai.

HDTVFanAtic

Are you saying a 169Time AVX-1 in a Dish 6000 was error free?

Or, was only the 169time and a C Band error free?

Murray Kerdman
mkerdman is offline  
post #171 of 2827 Old 12-06-2004, 12:22 PM
 
HDTVFanAtic's Avatar
 
Join Date: Mar 2004
Location: 3rd Rock from the Sun
Posts: 8,246
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


Originally posted by mkerdman
HDTVFanAtic

Are you saying a 169Time AVX-1 in a Dish 6000 was error free?

Or, was only the 169time and a C Band error free?

I am saying that as for The Postman and BOTH showings of The Last Samarui on Saturday Night and Sunday morning, as well as most other things, there were no errors with the R5000HD and other units.

My only concern was why was the R5000 showing a tremendous amount of errors in the last several weeks after a pretty flawless start.

The expansion of the tests to include some 169time, CBand and Cable users was to see if they had clean copies when the R5000 was producing errors. Nothing more, nothing less.

As the R5000 produced no errors this weekend on these caps (nor did the others mentioned), you cannot say that the R5000 produced problems where the others DID NOT.

It is HIGHLY UNLIKELY, in my estimation, that the R5000 would produce perfect caps all weekend and then go south during the week. If it were software doing this in the R5000, it shouldn't produce error free caps for days and then go south like a light switch was turned on.

Now with everything going down the tubes on HBO and Showtime this morning, it is the time to determine how different the errors are between the R5000 and the other units. Unfortunately, the week is also harder to coordinate the apples to apples test.

If you are interested, someone else did this comparison recently of the different systems for bandwidth. It was only a 160 second clip - and no guarantee it was the same showing either of Once Upon A Time in Mexico, but:

Once Upon a Time in Mexico - 160 seconds clip

Satellite System.............File length........Actual BR......Manzanita BR

HDD200 C Band AVX1....257927352.....12.896 Mb/s...14.827 Mb/s
DTC100 DirectTV AVX1..195734696.......9.787 Mb/s....9.056 Mb/s
6000 Dish AVX1............254408368.....12.720 Mb/s...13.28 Mb/s
6000 Dish R5000...........278318208.....13.916 Mb/s...14.59 Mb/s

Pitty the DirecTV user who wanted HDTV.
HDTVFanAtic is offline  
post #172 of 2827 Old 12-06-2004, 02:16 PM
AVS Forum Special Member
 
robena's Avatar
 
Join Date: Aug 2000
Posts: 1,927
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 175 Post(s)
Liked: 75
Quote:


Originally posted by HDTVFanAtic
If you are interested, someone else did this comparison recently of the different systems for bandwidth. It was only a 160 second clip - and no guarantee it was the same showing either of Once Upon A Time in Mexico,

It was the same showing, on November 20.

Robert
robena is offline  
post #173 of 2827 Old 12-06-2004, 02:58 PM
Advanced Member
 
stjr's Avatar
 
Join Date: Feb 2002
Location: San Francisco
Posts: 953
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
It's interesting that two simultaneous recordings of the same film on E* with 169time and R5000 yield different bit rates. IMO, this is a further indication that the two systems will also handle errors differently once they are detected.

Steve
stjr is offline  
post #174 of 2827 Old 12-06-2004, 04:00 PM - Thread Starter
Senior Member
 
R5000-HD's Avatar
 
Join Date: Jun 2004
Posts: 226
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


Originally posted by HDTVFanAtic

It is HIGHLY UNLIKELY, in my estimation, that the R5000 would produce perfect caps all weekend and then go south during the week. If it were software doing this in the R5000, it shouldn't produce error free caps for days and then go south like a light switch was turned on.

Now with everything going down the tubes on HBO and Showtime this morning, it is the time to determine how different the errors are between the R5000 and the other units.



E* is screwing up their source stream. This will effect all recording systems in different ways. We have analyzed hundreds of hours of recordings made on various systems and locations. Through careful test setups, analyzing data collected at exactly the same time, we have collected a series of test samples that point to corruption of data at the E* source. One of my favorite examples is a glitch in a hdnet movie where Andy Garcia is cross examining a cop on the stand, captured during a 20 hour recording run. The movie played twice during the 20 hour recording and the glitch in the video occurs at exactly the same place on both showings.

If anyone can put us in touch with the "right people" at E*, we can provide detailed examples of how they are corrupting their data stream

Sadly most of the "glitch" problems in the dish system have been due to E* conversion to re-compression. It started in late summer, about the time we were introducing the R5000-HD


BTW one of the reasons r5000-HD users are seeing more of these glitches is because they do more recoding in a shorter period of time. Recording six 2 hour movies unattended via dvhs would be quite difficult. The glitches seem to come in bursts. We typically need to record about 20 consecutive hours to capture one or two glitch events.

Quote:


Originally posted by HDTVFanAtic

If you are interested, someone else did this comparison recently of the different systems for bandwidth. It was only a 160 second clip - and no guarantee it was the same showing either of Once Upon A Time in Mexico, but:

Once Upon a Time in Mexico - 160 seconds clip

Satellite System.............File length........Actual BR......Manzanita BR

HDD200 C Band AVX1....257927352.....12.896 Mb/s...14.827 Mb/s
DTC100 DirectTV AVX1..195734696.......9.787 Mb/s....9.056 Mb/s
6000 Dish AVX1............254408368.....12.720 Mb/s...13.28 Mb/s
6000 Dish R5000...........278318208.....13.916 Mb/s...14.59 Mb/s



YOU CANNOT COMPARE BIT RATES OF NON TIME ALIGNED SAMPLES.
the mpeg-2 video is variable rate so if the samples are not from an identical section of the movie, the bit rates will not be the same!

If the same clip is extracted from both dish systems, the bit rate will be the same, because both the r5000 and the avx1 do not touch the underlying mpeg-2 stream, they just repackage it into a transport stream.

Quote:


Originally posted by HDTVFanAtic
Pitty the DirecTV user who wanted HDTV.

Not exactly. I compared a side by side capture of D* and E* clip of Empire Records from HDNMV. Both clips came from the same source because the film scratches from the master were identical. IIRC the D* average bit rate was ~10Mb and the E* was closer to 15Mb. I played back both clips on a myhd100 to a Hitachi HDTV CRT reference monitor. The results were indistinguishable. (at one point both samples were available on kevin's site)

Analysis of the extracted mpeg-2 elementary stream showed that D* was using telecine mode and E* was not. In layman's terms, D* was encoding the movie as 24 frames per second and then using 3:2 pull down on the decode to convert the image back to an interlaced 30 fps image. E* on the other hand, encoded all frames as interlaced at 30fps. Since the source master was film, the actual source rate was 24 fps, so the E* encoder was encoding more frames than necessary.

The empire records test sample was recorded before E* started re-compressing and before D* started downresing 1280x1080i


Lastly, please be very meticulous about your test set ups and the conclusions you draw. If you record the same E* program at two different locations using two different recording systems, it is difficult to draw any conclusions because the test set ups are different. On the other hand if the extracted mpeg-2 data shows exactly the same errors (mpegrepair) on both systems, then it would be reasonable to assume that the locations and recording systems were not damaging the data, therefore the mpeg-2 errors must have originated from the source stream.


-R
R5000-HD is offline  
post #175 of 2827 Old 12-06-2004, 04:17 PM - Thread Starter
Senior Member
 
R5000-HD's Avatar
 
Join Date: Jun 2004
Posts: 226
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


Originally posted by stjr
It's interesting that two simultaneous recordings of the same film on E* with 169time and R5000 yield different bit rates. IMO, this is a further indication that the two systems will also handle errors differently once they are detected.

Steve,
The recordings were not simultaneous! See the following
Quote:


Originally posted by HDTVFanAtic

If you are interested, someone else did this comparison recently of the different systems for bandwidth. It was only a 160 second clip - and no guarantee it was the same showing either of Once Upon A Time in Mexico,



Unless the files are from the exact same clip recorded at exacly the same time, the bitrates will be different. Both systems repackage(remultiplex) the existing mpeg-2 stream into a transport stream. They do not change the elementary stream bit rate. The average elementary stream bit rate is set by the encoder/recompressor not the remultiplexer. Therefore, identical clips extracted from both systems will have the same average bit rate.



-R
R5000-HD is offline  
post #176 of 2827 Old 12-06-2004, 04:24 PM
AVS Forum Club Gold
 
dahester's Avatar
 
Join Date: Sep 1999
Location: Austin, TX
Posts: 998
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 2 Post(s)
Liked: 11
Quote:


Originally posted by HDTVFanAtic

Thus, if HDNET only shows The Wall once every 6 months and it starts 30 minutes late as it did Sunday Night, you are hosed trying to add more time to the capture.

So funny you mentioned that. My first recording of The Wall got hosed because of the time delay and the fact that CapDVHS won't let you add time to a scheduled recording in progress either. But I got it the second time around.

-Dylan

Displays: Sony VPL-HW40ES | 110" SI Motorized Slate screen | Pioneer PRO-150FD
Sources: Sony BDP-S5000ES | Dune HD Smart D1 | Roku HD | LG LST-3410A HD-DVR
Speakers: Nearfield Pipedreams 18 (L,R,Sub1,Sub2), Pipedreams 15 (C)
| Magnepan MC-1 (WL, WR, SL, SR, SBL, SBR)
Audio: Denon AVR-4311CI | Bryston 6B-SST | Bryston 14B-SST
Control: Control4 home automation
dahester is offline  
post #177 of 2827 Old 12-06-2004, 04:52 PM
Advanced Member
 
stjr's Avatar
 
Join Date: Feb 2002
Location: San Francisco
Posts: 953
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 11
Quote:


Originally posted by R5000-HD
Steve,
The recordings were not simultaneous! See the following

robena stated
Quote:


It was the same showing, on November 20.

I was hoping for a clarification.

Steve
stjr is offline  
post #178 of 2827 Old 12-06-2004, 07:59 PM
 
HDTVFanAtic's Avatar
 
Join Date: Mar 2004
Location: 3rd Rock from the Sun
Posts: 8,246
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Robena had all 4 samples. I did not. He knows better than me if they were from same 160 seconds. As he is very anal about quality, I assume they would be the same 160 second clips - but do not know that for sure - thus I qualified it as best I could.

That is why I was comparing movies as a whole - not clips. Easier to get same info without sending movie half way across planet.

While I agree with R- statement that it does not appear that the R5000 is producing these errors from the evidence thus far, I DO NOT understand how they could not have errors for 3 days (all weekend) and they start back up in force on Monday.

If it is recompression, it is happening 24/7/365.
HDTVFanAtic is offline  
post #179 of 2827 Old 12-06-2004, 11:23 PM - Thread Starter
Senior Member
 
R5000-HD's Avatar
 
Join Date: Jun 2004
Posts: 226
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:


Originally posted by HDTVFanAtic
...
While I agree with R- statement that it does not appear that the R5000 is producing these errors from the evidence thus far, I DO NOT understand how they could not have errors for 3 days (all weekend) and they start back up in force on Monday.

If it is recompression, it is happening 24/7/365.

My comment wrt recompression is that once E*switched it on, weird things started happening on the dish 6000 receivers. There were reports of never before seen gray blocks, glitches even with 95 receive level, etc.

This is because E* is actually transmitting bad data. This is truly sad because even if you buy a 30" dish, you're still going to see glitches.

As to the error free weekend, that's consistent with what we've seen during testing. Sometimes it takes a couple of 20hr recordings to get one that has the glitch were looking for. One nasty glitch that E* was transmitting, took almost a week to capture.

Anyway... My belief is that E*'s new recompressors have an intermittent bug that is causing these problems. If anyone knows who makes the re-compressors, please PM me so I can contact the manufacturer directly. I've got lots of data to document the problem.

-R
R5000-HD is offline  
post #180 of 2827 Old 12-07-2004, 12:07 AM
AVS Forum Special Member
 
robena's Avatar
 
Join Date: Aug 2000
Posts: 1,927
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 175 Post(s)
Liked: 75
Yes, the 4 160 seconds clips are exactly at the same location in the movie, at least as exactly as HDTVtoMPEG2 allows it. The error must be +-1 frame at the beginning and at the end, less than 1%.

The first 3 samples were recorded by a friend located in NJ, and the fourth (the R5000 recording) by another friend in Florida.

The first bit-rate indication is simply the length of the file divided by 160, and the second one is computed by the Manzanita stream analyzer after removing the NULLs.

Before NULL removal, the bit-rate was exactly 19.3 Mb/s for each stream.

I have no idea why the R5000 recording shows more bit-rate, that seems indeed very strange. Before NULL removal, all files had almost exactly the same size.

Robert
robena is offline  
Sponsored Links
Advertisement
 
Reply HDTV Recorders

Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off