The Official R5000-HD Technical Status Discussion - Page 6

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.

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.

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.

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.

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.

How/where do you set your cookie expiration date?

#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.

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.

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.

The last few days there have been all kinds of glitches on E*. I've seen it on both my 6000 and 811.

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.

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).

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.

Have you:

Tried the card in other pci slots?
Turned PCI Bus Master on in the BIOS?

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.

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

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.

It was the same showing, on November 20.

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.

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

robena stated
I was hoping for a clarification.

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.

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.