or Connect
AVS › AVS Forum › HDTV › HDTV Recorders › The Official AVS Dish DTVPal DVR Topic!
New Posts  All Forums:Forum Nav:

The Official AVS Dish DTVPal DVR Topic! - Page 421

post #12601 of 18096
Quote:
Originally Posted by golinux View Post

Last 24 hours the clock has been acceptable. I can live with this. Maybe the new hardware installation at KVUE 'fixed' things . . . more or less . . .

Absolutely! If the clock stays as-is, I'm perfectly happy. The problem is that if bandwidth is tight enough at KVUE to cause ANY clock skew then there's a good chance that at some point it will cause SIGNIFICANT clock skew. Remember that >95% of users report ZERO clock skew from TVGOS.

If memory serves, MABUTTRA and P SMITH reported null packets of 3 - 4 Mbps for the TVGOS carriers in Wichita and San Francisco. Maybe that's what it takes to get this flaky ROVI boxes to fly straight and level...
post #12602 of 18096
If the time difference still stable, I would contact the station and ask for fix it, IMO it would be much simple then we saw before (in hope the station's engineers are more friendly and goal oriented ).
post #12603 of 18096
Quote:
Originally Posted by P Smith View Post

If the time difference still stable, I would contact the station and ask for fix it, IMO it would be much simple then we saw before (in hope the station's engineers are more friendly and goal oriented ).

If you are implying that the K-EYE engineer didn't do his best, you'd be mistaken. Dusty has always been right on top of any little thing that I ever brought to his attention. ROVI's lack of responsiveness drove him to the end of his patience.
post #12604 of 18096
That's why I mentioned "goal oriented", not cutting corners.
post #12605 of 18096
Quote:
Originally Posted by J-D-H View Post

After swinging the antenna to Wash DC as well as changing the zip code to Wash DC, the clock became almost instantly off by 5 minutes or so (fast). I made the changes at 6:30 PM last night, presumably around the best time. After observing the bad clock, I tried several soft-resets via the 4 sec on-off button push on the remote. This caused some minor clock changes, but certainly not a fix, not a return to an accurate clock.

There are quite a number of variables here (antenna bearing, zip code, which of two CBS stations are allowed in the channel listing, soft-reset or not, how long to wait between changes, etc.). And when doing tests, the order in which the changes are made matters as well as the time of day when they are done (at least for some of the changes). This leads to a test matrix which is large and rather intimidating... I'd love to hear what they are....

I had a similar experience on 4/5/11. The results were very clear when I toggled my CM-PAL from DC to Baltimore then to DC and then to Baltimore--all before 6pm. The clock read: -5½ minutes; correct; -5½; correct. But by the time I tried the same routine on my 3rd PAL, it was roughly between 6:10pm and 6:40pm. That clock read: -5½; correct; -3½; correct; -1½; and the final change to Baltimore: -1½, until the clock corrected much later. My guess was, (at around 6:30pm), either the Pal had been smoothing the clock data (unlikely because the CM-PAL didn't) or the DC clock was realigning towards correct. That's why I chose 7:10pm to restore my DC zip code. I imagine you chose 6:30pm on the basis of its success in Austin.

The fact that I successfully replicated the results of my CM-PAL fix two weeks later on my Dish-PAL, is a good indication this fix is credible.

You've accumulated quite a few empirical observations and you might have been closer to locking on to the correct DC time than you think. Maybe initiating the change 20 to 40 minutes later would have actually workedin spite of all the other variables. But, the question remains: Is your Pal locking onto the TV Guide or not? If you can't populate 7 days of the applicable TV Guide listings, there's something else going on here. If neither zip is populating a proper Guide, it might be time to unplug the Pal and wait a minute before plugging it in again (the old hard reset). This was SOP with the Sony and LG dvrs. In most cases the Guides populate listings in less than 24 hourssometimes considerably less. Finding a solution to acquiring the TV Guide would be my first priority.
post #12606 of 18096
Quote:
Originally Posted by AV Empiricist View Post

I had a similar experience on 4/5/11. The results were very clear when I toggled my CM-PAL from DC to Baltimore then to DC and then to Baltimore--all before 6pm. The clock read: -5½ minutes; correct; -5½; correct. But by the time I tried the same routine on my 3rd PAL, it was roughly between 6:10pm and 6:40pm. That clock read: -5½; correct; -3½; correct; -1½; and the final change to Baltimore: -1½, until the clock corrected much later. My guess was, (at around 6:30pm), either the Pal had been smoothing the clock data (unlikely because the CM-PAL didn't) or the DC clock was realigning towards correct. That's why I chose 7:10pm to restore my DC zip code. I imagine you chose 6:30pm on the basis of its success in Austin.

The fact that I successfully replicated the results of my CM-PAL fix two weeks later on my Dish-PAL, is a good indication this fix is credible.

You've accumulated quite a few empirical observations and you might have been closer to locking on to the correct DC time than you think. Maybe initiating the change 20 to 40 minutes later would have actually workedin spite of all the other variables. But, the question remains: Is your Pal locking onto the TV Guide or not? If you can't populate 7 days of the applicable TV Guide listings, there's something else going on here. If neither zip is populating a proper Guide, it might be time to unplug the Pal and wait a minute before plugging it in again (the old hard reset). This was SOP with the Sony and LG dvrs. In most cases the Guides populate listings in less than 24 hourssometimes considerably less. Finding a solution to acquiring the TV Guide would be my first priority.

On TVGOS or not, what throws me is the clock setting screen always saying it has derived the time from TV Guide. Depending on whether I have a Wash DC or a Baltimore zip code, my clock has been more or less like yours, that is, all over the place. However when I delete both town's CBS stations from the channel listing, presumably forcing PSIP, the clock almost instantly changes to being with 5-10 seconds of accurate. So when one or both of the CBS stations are available to the box, I presume I must be getting TVG clock setting data (wrong though it may be). However it looks like it's possible to get TVG clock setting data without advance TVG TV show description data.

My first priority isn't TV Guide, it's the clock. The reason for this is that the family records many shows, frequently two at a time and several shows back to back. Since this means both tuners are often in use simultaneously for sequential shows, the time padding feature is NOT always a universal fix for a bad clock here.

Many weeks ago I tried cold reboots by killing the power. As you suggest, maybe I'll do this again -- after trying so many other things, why not this?

There are a few recent messages here about changes which have happened in another city, and what sounded like a semi-fix for the TVGOS problem (in that town anyway). It's nice to hear that someone somewhere may actually be working the problem. I hope the same happens here!
post #12607 of 18096
Quote:
Originally Posted by J-D-H View Post

On TVGOS or not, what throws me is the clock setting screen always saying it has derived the time from TV Guide.

Once the DVR has extablished a TVGOS lock on a local channel it maintains that "lock" status for at least 6 days after that channel ceases to transmit the TVGOS datastream. We have that proof in Austin where we had a full week of "no info" showing in the guide indicating that KEYE had discontinued the TVGOS feed one week earlier. The clock set screen still showed "Time acquired from TV Guide" at that point. So the DVR may eventually relinquish its TVGOS time-lock when it ceases to receive the PID, but it certainly will take more than a week for this to happen. I tried zipcode and time zone changes and still the clock set screen was locked. Then I resorted to factory defaults and voila, clock set released, 5-min time skew gone, presumably PSIP derived clock. A day or two later, the TVGOS lock re-appeared from the new station (KVUE rather than KEYE) and things have been pretty good to date. So bottom line, the only ways to tell whether you're actually getting a real-time TVGOS time lock are to do a factory reset or to delete the TVGOS supplying channel from your lineup.
post #12608 of 18096
This is the third day since KVUE took over TVGOS and I 'd like to report, so far so good. If it remains stable for a week, I'm gonna start removing all that extra padding . . .
post #12609 of 18096
Quote:
Originally Posted by golinux View Post

This is the third day since KVUE took over TVGOS and I 'd like to report, so far so good. If it remains stable for a week, I'm gonna start removing all that extra padding . . .

Is the time correct, or is it still off by 2 minutes, as reported a couple of days ago?

Mark
post #12610 of 18096
Quote:
Originally Posted by mabuttra View Post

Is the time correct, or is it still off by 2 minutes, as reported a couple of days ago?

I can't really tell 'exactly'. The two other clocks in that room are 2-3 minutes apart depending when the new minute starts - I'm too lazy to reset them. All I can say is that the KVUE clock is in that range. It has never gone outside either of those clocks, slow or fast. Recording have been consistent in start times so everything seems pretty stable.
post #12611 of 18096
I have two, used DTVPAL DVRs that I'm listing on EBAY today, for $179.99 each. The DVRs work just fine and are in great shape. Both have the F208 firmware installed. I'm selling them simply because I decided to build my own home media server, with integrated DVR functionality.
post #12612 of 18096
Quote:
Originally Posted by jrpastore View Post

Once the DVR has extablished a TVGOS lock on a local channel it maintains that "lock" status for at least 6 days after that channel ceases to transmit the TVGOS datastream. We have that proof in Austin where we had a full week of "no info" showing in the guide indicating that KEYE had discontinued the TVGOS feed one week earlier. The clock set screen still showed "Time acquired from TV Guide" at that point. So the DVR may eventually relinquish its TVGOS time-lock when it ceases to receive the PID, but it certainly will take more than a week for this to happen. I tried zipcode and time zone changes and still the clock set screen was locked. Then I resorted to factory defaults and voila, clock set released, 5-min time skew gone, presumably PSIP derived clock. A day or two later, the TVGOS lock re-appeared from the new station (KVUE rather than KEYE) and things have been pretty good to date. So bottom line, the only ways to tell whether you're actually getting a real-time TVGOS time lock are to do a factory reset or to delete the TVGOS supplying channel from your lineup.

Thanks. That's very useful information. J-D-H has confirmed that deleting DC's 9-x and Baltimore's 13-1 unlocked the time set and reported the resulting PSIP clock was very accurate. I thought that would be the case. When I set up my 1st Dish-PAL, I checked the PSIP data pages and about 20 stations were within 30 seconds of the Atomic Time. Of course, 1 station that was displaying the wrong time was also displaying the wrong date and year.

For now the safest fix in DC is to switch to a Baltimore zip code. But my temporary fix has functioned perfectly so far. My first Dish-PAL has continued to display correct DC clock data since October 2009. The two that skewed were set to a Baltimore zip on 4/5/11. Three weeks ago today, I simply restored the DC zip at 7:10pm to my CM-PAL and it has operated perfectly ever since. So, I repeated the experiment with my Dish-PAL #2 one week ago today with the same result.

The upside is that I get the full DC TV Guide which includes the full Baltimore listings. The downside is J-D-H has confirmed a forward skew now exits in the morning and even at 6:30 pm. The implication is: If a power outage exceeds my back-up battery capacity before around 7pm, I'm back to skewed time. Also any reboot or full channel scan done before 7pm would probably have the same result.

So for now, I'll be on the lookout for any blinking oven clocks!
post #12613 of 18096
If someone has broken pal DVR(s), PM me please.
post #12614 of 18096
Quote:
Originally Posted by mabuttra View Post

Is the time correct, or is it still off by 2 minutes, as reported a couple of days ago?

No longer a 2 minute lag. Since last night with KVUE as the new king of TVGOS in Austin the clock sync is within a couple of seconds of NIST and the program guide fills out nicely like the good ol' days... prayers answered, or a tease? The skeptical me just changed to another local zip code and did a hard reset and watched the time sync just to make sure.
post #12615 of 18096
Two units already sold.
post #12616 of 18096
Quote:
Originally Posted by jrpastore View Post

Once the DVR has extablished a TVGOS lock on a local channel it maintains that "lock" status for at least 6 days after that channel ceases to transmit the TVGOS datastream. We have that proof in Austin where we had a full week of "no info" showing in the guide indicating that KEYE had discontinued the TVGOS feed one week earlier. The clock set screen still showed "Time acquired from TV Guide" at that point. So the DVR may eventually relinquish its TVGOS time-lock when it ceases to receive the PID, but it certainly will take more than a week for this to happen. I tried zipcode and time zone changes and still the clock set screen was locked. Then I resorted to factory defaults and voila, clock set released, 5-min time skew gone, presumably PSIP derived clock. A day or two later, the TVGOS lock re-appeared from the new station (KVUE rather than KEYE) and things have been pretty good to date. So bottom line, the only ways to tell whether you're actually getting a real-time TVGOS time lock are to do a factory reset or to delete the TVGOS supplying channel from your lineup.

Thanks for the heads-up on the 6 day lock. This will definitely change how I do tests from here on out.

To that end, I'm confused about the several kinds of resets/reboots and especially how they differ in effect. There seem to be at least three ways to "reset" the CM-7000PAL:

1) cold-reboot by pulling the plug, waiting, plugging it in again

2) soft-reset by pressing the remote control on-off button for 4 sec.s

3) factory reset done via that menu option

I've very rarely tried number 1, number 2 far more often, and never number 3.
Presumably there are significant differences between them -- can someone give the specifics on these, what each does, etc.?
post #12617 of 18096
Quote:
Originally Posted by AV Empiricist View Post

Thanks. That's very useful information. J-D-H has confirmed that deleting DC's 9-x and Baltimore's 13-1 unlocked the time set and reported the resulting PSIP clock was very accurate. I thought that would be the case. When I set up my 1st Dish-PAL, I checked the PSIP data pages and about 20 stations were within 30 seconds of the Atomic Time. Of course, 1 station that was displaying the wrong time was also displaying the wrong date and year.

For now the safest fix in DC is to switch to a Baltimore zip code. But my temporary fix has functioned perfectly so far. My first Dish-PAL has continued to display correct DC clock data since October 2009. The two that skewed were set to a Baltimore zip on 4/5/11. Three weeks ago today, I simply restored the DC zip at 7:10pm to my CM-PAL and it has operated perfectly ever since. So, I repeated the experiment with my Dish-PAL #2 one week ago today with the same result.

The upside is that I get the full DC TV Guide which includes the full Baltimore listings. The downside is J-D-H has confirmed a forward skew now exits in the morning and even at 6:30 pm. The implication is: If a power outage exceeds my back-up battery capacity before around 7pm, I'm back to skewed time. Also any reboot or full channel scan done before 7pm would probably have the same result.

So for now, I'll be on the lookout for any blinking oven clocks!

With all the juggling I've done between having ch 9.x and/or ch 13 in the channel listing, changing antenna bearings giving signal strength preference to one station or the other, changing zip codes, etc., I frequently (but not always) did intervening resets. My most recent change sequence regained a near-perfect clock. However, in light of the 6 day lock info, I'm going to have to re-do these tests once I understand the differences between the several ways of resetting.
post #12618 of 18096
Quote:
Originally Posted by J-D-H View Post

Thanks for the heads-up on the 6 day lock. This will definitely change how I do tests from here on out.

To that end, I'm confused about the several kinds of resets/reboots and especially how they differ in effect. There seem to be at least three ways to "reset" the CM-7000PAL:

1) cold-reboot by pulling the plug, waiting, plugging it in again

2) soft-reset by pressing the remote control on-off button for 4 sec.s

3) factory reset done via that menu option

I've very rarely tried number 1, number 2 far more often, and never number 3.
Presumably there are significant differences between them -- can someone give the specifics on these, what each does, etc.?

I'm not sure that there is "lock", more likely, the PAL "holds onto the TVGOS time as long as it can", or until some sort of reboot, where it attempts to recover it and repopulate the TVGUIDE. I'm fairly sure all three of your ways above will accomplish that same thing - that is clear the clock and TVGOS data.
post #12619 of 18096
Yesterday (FRI) early, I reset the zipcode on the PAL to B'More (21075). As of Friday evening, clock was still off. Twice I did a soft reboot (via holding down pwr button), once around 6:30pm and once around 7:30pm. Clock and data still appears to be coming from CH 9/DC station.

Put Pal on Ch 13 (Baltimore CBS TVGOS provider), soft reset, and went out for a few hours. Came home, and clock was spot on, but TVGUIDE data was populated for both DC stations and B'more stations, indicating I had Baltimore clock, but DC TVGOS data!

Got up this morning, and no longer have DC guide data, only PSIP data up to a couple days on the DC stations and full 8 day guide for the B'more stations. And clock is still spot on!

For all I know, I could have eaten a bowl of ice cream and end result could have been the same once I changed the zip code. But for now, I have the accurate clock from B'more, day or so of guide data for DC stations (and full guide for B'more stations) and am going to leave it that way until I hear the DC clock is accurate. (FYI, I only record on the DC stations, as the B'more stations are much weaker).
post #12620 of 18096
Quote:
Originally Posted by J-D-H View Post

Thanks for the heads-up on the 6 day lock. This will definitely change how I do tests from here on out.

To that end, I'm confused about the several kinds of resets/reboots and especially how they differ in effect. There seem to be at least three ways to "reset" the CM-7000PAL:

1) cold-reboot by pulling the plug, waiting, plugging it in again

2) soft-reset by pressing the remote control on-off button for 4 sec.s

3) factory reset done via that menu option

I've very rarely tried number 1, number 2 far more often, and never number 3.
Presumably there are significant differences between them -- can someone give the specifics on these, what each does, etc.?

First I think it's important to separate out the various things that one might be trying to accomplish:

A) Re-sync TVGOS clock with no change in TVGOS supplier. This would be useful only if you believe that your TVGOS supplier provides un-skewed timestamps only during certain hours of the day (and the only way to really know that for sure would be to use TSREADER and a tuner card). At any rate, this objective can be accomplished with any of your methods 1, 2, 3 above.

B) Confirm that you are indeed receiving the TVGOS datastream. The best way to do this is with TSREADER and a tuner card, but if all you have is the DVR guide and clock-set screens to look at then only your method #3 will work. The reason is that the DVR retains the TVGuide contents and TVGOS supplier channel info in NVM. So when you use your #1 or #2 methods above, the DVR will reboot but will not release the clock-set screen and within a few minutes will re-populate the guide display with the retained "image" from NVM while awaiting the next download from TVGOS.

C) Change or eliminate your TVGOS supplier. In order to do this you have to break the "lock" that the DVR wants to maintain with whatever TVGOS supplier it has found. Your methods #1 and #2 will not do this. It can only be done by your method #3 or by deleting the channel that the DVR is currently using for TVGOS supply from your lineup. The details of the algorithm that the DVR uses to pick between multiple available TVGOS suppliers is a mystery. Certainly it depends on zip code, but apparently also on signal strength.

EDIT: So as you can see the only real difference between your 3 methods is what happens to the Non-Volatile Memory in the DVR. AFAIK there is no functional difference between #1 and #2, they are identical and neither of them affects the contents of the DVR's NVM. #3 obviously wipes out the dynamic contents of the NVM (preference settings, channel lineup, TVGOS supplier and all your timers unfortunately!), so it accomplishes a lot of things that #1 and #2 will not.
post #12621 of 18096
Just a small technical note (perhaps very technical ): the DVRs - CM and Pal doesn't have separate NVM (usually small serial EEPROM) for current settings;
all static [bootstrap, serial number,etc], semi-static [FW] and dynamic data [channels, etc] are storing in one type of memory - in one big flash chip (by Spansion).
post #12622 of 18096
Quote:
Originally Posted by ss_sea_ya View Post
Yesterday (FRI) early, I reset the zipcode on the PAL to B'More (21075). As of Friday evening, clock was still off. Twice I did a soft reboot (via holding down pwr button), once around 6:30pm and once around 7:30pm. Clock and data still appears to be coming from CH 9/DC station.

Put Pal on Ch 13 (Baltimore CBS TVGOS provider), soft reset, and went out for a few hours. Came home, and clock was spot on, but TVGUIDE data was populated for both DC stations and B'more stations, indicating I had Baltimore clock, but DC TVGOS data!

Got up this morning, and no longer have DC guide data, only PSIP data up to a couple days on the DC stations and full 8 day guide for the B'more stations. And clock is still spot on!

For all I know, I could have eaten a bowl of ice cream and end result could have been the same once I changed the zip code. But for now, I have the accurate clock from B'more, day or so of guide data for DC stations (and full guide for B'more stations) and am going to leave it that way until I hear the DC clock is accurate. (FYI, I only record on the DC stations, as the B'more stations are much weaker).
Baltimore seems a long way for you. Given the air traffic and wind gusts, I'm wondering if your reception for 13-1 can be flaky. J-D-H reported that he couldn't lock onto Baltimore when his reception was marginal. The Sonys give signal strength as well as signal quality and the two don't always correlate. On the PALs, I have to confirm a 98 is solid almost as often as a 70. That's one of the factors making the pieces to this puzzle hard to put together. But even with solid reception the quickness of the clock reset changes: from almost instantaneous to unknown. When I restored my DC zip at 7:10pm there was no discernible change because it went from correct to correct (but when it went from Baltimore correct to DC correct is a mystery). The Baltimore Guide remained until almost 2am when, magically, the full DC Guide appeared.

Anyway, when you get tired of the pathetic Baltimore Guide, give the old 7:10pm DC zip change a try. So far, it's two for two.
post #12623 of 18096
Quote:
Originally Posted by ss_sea_ya View Post
Yesterday (FRI) early, I reset the zipcode on the PAL to B'More (21075). As of Friday evening, clock was still off. Twice I did a soft reboot (via holding down pwr button), once around 6:30pm and once around 7:30pm. Clock and data still appears to be coming from CH 9/DC station.

Put Pal on Ch 13 (Baltimore CBS TVGOS provider), soft reset, and went out for a few hours. Came home, and clock was spot on, but TVGUIDE data was populated for both DC stations and B'more stations, indicating I had Baltimore clock, but DC TVGOS data!

Got up this morning, and no longer have DC guide data, only PSIP data up to a couple days on the DC stations and full 8 day guide for the B'more stations. And clock is still spot on!

For all I know, I could have eaten a bowl of ice cream and end result could have been the same once I changed the zip code. But for now, I have the accurate clock from B'more, day or so of guide data for DC stations (and full guide for B'more stations) and am going to leave it that way until I hear the DC clock is accurate. (FYI, I only record on the DC stations, as the B'more stations are much weaker).
Baltimore seems a long way for you. Given the air traffic and wind gusts, I'm wondering if your reception for 13-1 can be flaky. J-D-H reported that he couldn't lock onto Baltimore when his reception was marginal. The Sonys give signal strength as well as signal quality and the two don't always correlate. On the PALs, I have to confirm a 98 is solid almost as often as a 70. That's one of the factors making the pieces to this puzzle hard to put together. But even with solid reception the quickness of the clock reset changes: from almost instantaneous to unknown. When I restored my DC zip at 7:10pm, there was no discernible change because it went from correct to correct (but when it went from Baltimore correct to DC correct is a mystery). The Baltimore Guide remained until almost 2am when, magically, the full DC Guide appeared.

Anyway, when you get tired of the pathetic Baltimore Guide, give the old 7:10pm DC zip change a try. So far, it's two for two.
post #12624 of 18096
Quote:
Originally Posted by ss_sea_ya View Post

I'm not sure that there is "lock", more likely, the PAL "holds onto the TVGOS time as long as it can", or until some sort of reboot, where it attempts to recover it and repopulate the TVGUIDE. I'm fairly sure all three of your ways above will accomplish that same thing - that is clear the clock and TVGOS data.

The concept of "locking onto a TVGOS source" has been mentioned several times in this thread, so maybe someone will jump in and explain how it works (or even if it's the case).

The same goes for the three resets. Before I begin another round of tedious changes (it's a big test matrix), I want to be sure about how to do things properly this time. Maybe doing any of the three resets between tests would do fine as you implied -- just want to be sure.....
post #12625 of 18096
I don't know if it is relevant to the clock issue or not but my TVGOS enabled analog recorder worked fine when in the shop but did not work at all right for me. The only difference is that I am OTA and he had it connected to cable. The only theory that we could come up with was that the fact that there were two TVGOS signals being received may be confusing it. This may mean nothing since it was analog and it was real TVGOS code but I notice that the people with clock problems seem to have more than one station that is sending the TVGOS data.
post #12626 of 18096
Quote:
Originally Posted by J-D-H View Post

The concept of "locking onto a TVGOS source" has been mentioned several times in this thread, so maybe someone will jump in and explain how it works (or even if it's the case).

The same goes for the three resets. Before I begin another round of tedious changes (it's a big test matrix), I want to be sure about how to do things properly this time. Maybe doing any of the three resets between tests would do fine as you implied -- just want to be sure.....

No one but the firmware authors at Echostar can definitively explain how this DVR manages its TVGOS supplier. But we can infer quite a bit from the observations posted in this thread:

1) If you have a full 7 days of guide info and you do a hard or soft reset (not a factory default reset), your full 7 days of guide info will re-populate within minutes regardless of what time of day you do the reset. Since we know that TVGOS guide data only gets transmitted 8 times/day this is proof that the guide data is retained in NVM during the reset.

2) If you live in a market that is subject to predictably variable clock skew (like Austin used to be) and you do a hard or soft reset during a period of zero clock skew, the clock will instantly correct itself. This is proof that when the DVR "wakes up" from a reset, it grabs the next timestamp it sees and sets the clock based on that timestamp.

The recent results from D.C. where correct DVR clock can be maintained even with a faulty TVGOS supplier (WUSA) provided that a reset is done at the critical hour suggest that maybe the clock smoothing algorithm in the DVR is a pretty simple one where it grabs a timestamp once per day (every 86,400 secs) based on its internal clock ticker. If all those timestamp grabs occur in the "clean zone" with zero clock skew you get a good clock all day long. Those results contradict what we saw in Austin however. We were resetting our DVRs shortly after the clean zone started and that fixed our clocks for that evening, but by the next morning the clocks would be slow again. The difference in results is probably due to differences in exactly what is going on at WUSA. We have logs showing exactly what was coming out of KEYE, but until somebody generates some for WUSA I'm afraid you guys will continue to struggle with each new observation poking a hole in the latest theory of explanation.

EDIT: In terms of how and whether the DVR "locks on" to a specific TVGOS supplier, we have the recent Austin results where the guide data and the clock-set screens both indicated a TVGOS lock on KEYE despite that fact that KEYE had ceased transmitting the TVGOS datastream several days earlier. Time Zone and non-local ZIPCODE changes did not break this "lock", but factory default reset did, PSIP guide and unlocked clock-set screen proved that.
post #12627 of 18096
Quote:
Originally Posted by jrpastore View Post

First I think it's important to separate out the various things that one might be trying to accomplish:

A) Re-sync TVGOS clock with no change in TVGOS supplier. This would be useful only if you believe that your TVGOS supplier provides un-skewed timestamps only during certain hours of the day (and the only way to really know that for sure would be to use TSREADER and a tuner card). At any rate, this objective can be accomplished with any of your methods 1, 2, 3 above.

B) Confirm that you are indeed receiving the TVGOS datastream. The best way to do this is with TSREADER and a tuner card, but if all you have is the DVR guide and clock-set screens to look at then only your method #3 will work. The reason is that the DVR retains the TVGuide contents and TVGOS supplier channel info in NVM. So when you use your #1 or #2 methods above, the DVR will reboot but will not release the clock-set screen and within a few minutes will re-populate the guide display with the retained "image" from NVM while awaiting the next download from TVGOS.

C) Change or eliminate your TVGOS supplier. In order to do this you have to break the "lock" that the DVR wants to maintain with whatever TVGOS supplier it has found. Your methods #1 and #2 will not do this. It can only be done by your method #3 or by deleting the channel that the DVR is currently using for TVGOS supply from your lineup. The details of the algorithm that the DVR uses to pick between multiple available TVGOS suppliers is a mystery. Certainly it depends on zip code, but apparently also on signal strength.

EDIT: So as you can see the only real difference between your 3 methods is what happens to the Non-Volatile Memory in the DVR. AFAIK there is no functional difference between #1 and #2, they are identical and neither of them affects the contents of the DVR's NVM. #3 obviously wipes out the dynamic contents of the NVM (preference settings, channel lineup, TVGOS supplier and all your timers unfortunately!), so it accomplishes a lot of things that #1 and #2 will not.

Thanks for the very helpful summary!

While I've never tried doing "method #3", it sounds like the fact that I've frequently juggled which of the two CBS stations were in the channel listing was good enough (at least those tests might not have been a waste of time, as I feared).

This "lock" concept is interesting (and maybe controversial too). All this business of stale data, over-allocation by some CBS stations, etc., seems to have caused the DVR designers to create a data acquisition algorithm that's far more complex than I would ever have guessed.

While on that subject, the over-allocation thing is still mysterious. I asked once before here about what advantage the CBS stations get from it. In other words, why over-allocate? Since digital broadcasting employs a form of MPEG, could it be that those CBS stations push their throughput/bandwidth limit so as to allow the use of less compression and thereby enhance their picture quality? This doesn't make much sense to me since I'd assume the improvement would be quite subtle, but there has to be SOME reason why they're doing what they're doing. And why only CBS? Strange.
post #12628 of 18096
Quote:
Originally Posted by AV Empiricist View Post

Baltimore seems a long way for you. Given the air traffic and wind gusts, I'm wondering if your reception for 13-1 can be flaky. J-D-H reported that he couldn't lock onto Baltimore when his reception was marginal. The Sonys give signal strength as well as signal quality and the two don't always correlate. On the PALs, I have to confirm a 98 is solid almost as often as a 70. That's one of the factors making the pieces to this puzzle hard to put together. But even with solid reception the quickness of the clock reset changes: from almost instantaneous to unknown. When I restored my DC zip at 7:10pm there was no discernible change because it went from correct to correct (but when it went from Baltimore correct to DC correct is a mystery). The Baltimore Guide remained until almost 2am when, magically, the full DC Guide appeared.

Anyway, when you get tired of the pathetic Baltimore Guide, give the old 7:10pm DC zip change a try. So far, it's two for two.

Stations with signal strengths of 70 and 98 frequently appear differently here. Ever since digital broadcasting started, we've noticed pixelization and occasional break-ups when receiving signals from anything less than the most powerful stations. Maybe because of local trees, if its a rainy day, a windy day, and especially both, digital broadcast quality suffers.

All this makes me wonder whether folks who live out in the country can still watch OTA TV now with digital broadcasting. After the digital conversion, I wouldn't be surprised to find out that the sales of satellite systems greatly increased for those same people who previously were able to receive NTSC TV from far away cities via relatively high gain log periodic antennas mounted on 40 ft towers.
post #12629 of 18096
One significant reason for use full bandwidth (not "over-allocation" per se ) - to prevent visible artifacts during dynamic scenes, and provides maximum quality of picture as any of us likes and creators pursued.
post #12630 of 18096
Quote:
Originally Posted by J-D-H View Post

...
All this makes me wonder whether folks who live out in the country can still watch OTA TV now with digital broadcasting. After the digital conversion, I wouldn't be surprised to find out that the sales of satellite systems greatly increased for those same people who previously were able to receive NTSC TV from far away cities via relatively high gain log periodic antennas mounted on 40 ft towers.

You posted already same thought and you got the answer, please re-read it here: http://www.avsforum.com/avs-vb/showp...ostcount=12538
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: HDTV Recorders
AVS › AVS Forum › HDTV › HDTV Recorders › The Official AVS Dish DTVPal DVR Topic!