The Official AVS Dish DTVPal DVR Topic! - Page 427

Originally Posted by LuvMyDVR33

I'm confused about why there is still talk about this update setting being useful. If a DVR isn't always connected to the internet, there is no way to get anything updated anyway. The TVGOS doesn't need an internet connection and is NOT firmware. There is not going to be a firmware update, so no one needs the updates enabled. Here is the definition of firmware. It has to be something that operates the DVR, and TVGOS is just info, it doesn't control any functions itself.

"Firmware is programming that's written to the read-only memory (ROM) of a computing device. Firmware, which is added at the time of manufacturing, is used to run user programs on the device. "

Originally Posted by LuvMyDVR33

I'm confused about why there is still talk about this update setting being useful. If a DVR isn't always connected to the internet, there is no way to get anything updated anyway. The TVGOS doesn't need an internet connection and is NOT firmware. There is not going to be a firmware update, so no one needs the updates enabled. Here is the definition of firmware. It has to be something that operates the DVR, and TVGOS is just info, it doesn't control any functions itself.

"Firmware is programming that's written to the read-only memory (ROM) of a computing device. Firmware, which is added at the time of manufacturing, is used to run user programs on the device. "

Originally Posted by nopedals

Bingo -- I just figured out how to do a discrete on. Press sys info, and then select.

Since the unit has auto shutoff, don't need a discrete off.

So ... added those two commands to the macro that switches to watch TV.

Originally Posted by Mike`L

Just added this to the macro on my remote. Works great! Some one get this man a beer!

Originally Posted by keyboard21

I am still not understanding what a Discrete on/off is and why you would need it?

Anyone?

thanks, Happy holiday weekend

Originally Posted by AV Empiricist

THE AUSTIN SHUFFLE
You have duplicated the Austin experiment. In Austin, they used TSReader software to examine the broadcast time-stamps. Most times-tamps were skewed, but a few were dead-on. When they rebooted the Pal to coincide with a perfect time-stamp, the PAL clock corrected. A few hours later, the clock skewed again.

Here's a possible scenario:

You rebooted at 10pm. This forced the PAL to seek the TV Guide clock broadcast which was accurate, so the PAL clock corrected. The Pal checked the broadcast time again at 11pm, 12am, 1am, and 2am. At about 1am the TV Guide program listings started broadcasting which delayed the time-stamps. (In Austin, they assume the stamps were buffered because of a shortage of bandwidth). After the 5 time samples were collected, your PAL made its final clock adjustment (which resulted in a skew of -3 minutes).

GUYS! Let's stop with the 6pm-7pm magic time reset. That worked for a while in Austin and it seems to be ok in DC--for now. No one on this thread reported success restoring their clock at that hour during the original DC time skew crisis. In fact, J-D-H and I reported the opposite: a 6:30pm reset only lessened the skew. My successful clock resets occurred after 7pm and continue to maintain the correct time.

Based on my experiences: Reset your PAL at 7:10pm (maybe 7pm-8pm) by doing one of the following:

1. A zip code toggle,
2. Deleting, then adding the TV Guide broadcast station.
3. A reboot (hard or soft),
4. A full channel scan,

Leave the update disabled. The Pal seems to repeat the time scan during the same period each day (according to the time of your reset) so, if nothing else goes wrong, you'll be ok. (And avoid anything that triggers a clock reset at the wrong time of day).

Originally Posted by ss_sea_ya

Well, I've set my PAL back to B'more zip code to avoid the crappy DC time issue. For kicks, I tuned my TV to Ch 9, sure enough, the clock quickly set itselft to 5 minutes. Tuned to ch 4, clock quickly went accurate. Back to Ch 9, 5 minutes fast. (this was right around 1am when I did this.)

Guess its time to email Ch. 9 again and fine out whats up and what their plan is.

Originally Posted by AV Empiricist

Thanks ss_sea_ya, J-D-H, gary-in-dc, and ETGorm. I've been trying to piece together how the PAL's clock works. The devil is in the details. If we each keep a log of when a clock skew occurs, as well as any of the six reset actions:

1. A zip code toggle,
2. Deleting, then adding the TV Guide broadcast station.
3. A reboot (hard or soft),
4. A full channel scan,
5. A factory default reset,
6. Enabling the update,

We'll get a better handle on how to counter the skew. ss_sea_ya's 1am adventure corroborates my belief that ETGorm hit a good time-stamp at 10pm but bad time-stamps at 1am and 2am which caused a blended -3 skew (instead of the full -5). Again, all 3 of my PALs are accurate, but that does not mean that was the case last weekend. J-D-H can you remember in detail the time slots and dates of your abridged shows? This is critical for piecing together a scenario in which all of our PALs skewed for a day or 2, but were correctly re-adjusted by Monday.

These TV Guide reliant dvrs are supposed to adjust their clocks every day. The Sony gathers 5 clock samples each day, and there is no reason to believe the PAL is any different. Even if the time stamps were -5 minutes all Friday, the PAL (which was reset at 7pm even weeks earlier) wouldn't skew until it finished collecting its time data maybe at 11pm. So my Friday shows were still fine. By the same reasoning, if the evening time-stamps were corrected by Sunday, The PAL wouldn't correct until 11pm Sunday. J-D-H forced a clock correction at 9:30pm, but bit might have happened by midnight on its own.

As far as enabling the update option: It's a matter of probabilities. If you enable your update for 7pm and your PAL isn't skewed the next morning, you didn't need the update.

What we've learned is: Just because there are bad time-stamps doesn't mean you'll automatically hit them. The same goes for perfect time-stamps. All the evidence shows that the PAL has a window of several hours each day to collect its clock data. Bad data outside that window doesn't affect it. If there is bad clock data at the end of the window, then, yes an update can give you a few hours of correct time. If there are bad time-stamps at the time of the update, you're skewed.

Originally Posted by J-D-H

There were three shows recorded with a skewed clock. One was recorded on Friday, 20May, from 10-11 PM. Then two others were recorded on Sunday, 22May, one from 7-8 PM, and the second from 9-10 PM. We happened to begin watching the three shows on Sunday at around 10:30 PM, and that's when we found that all were missing the first 5 minutes. It sounds to me that our clock was off for three days or so, and the DVR's routine data acquisition did not fix it over that period. Only the soft-reset did it.

Originally Posted by mabuttra

When I read his message, I thought he was talking about the show name, and not the episode name. However, the episode name is sent out with the TVGOS data also. It is the DTVPal that discards it. The Sony DHG shows the episode names in the episode descriptions, of all the recorded shows.

Originally Posted by AV Empiricist

Thanks for the dates. I was looking at the wrong weekend. All my Friday series ended, so I had no Friday May 20th recordings scheduled. But, I recorded the Jesse Stone CBS movie from 8:59pm to 11:02pm on May 22nd with perfect results. May 23rd programs also recorded perfectly. That could indicate I had no skews. The only conclusion I can draw is you were picking up a different window of time-stamps.

Do you remember the last time you did any of the 6 clock reset actions before your clock skewed?

1. A zip code toggle,
2. Deleting, then adding the TV Guide broadcast station.
3. A reboot (hard or soft),
4. A full channel scan,
5. A factory default reset,
6. Enabling the update,

If you initiated any one of those actions, it would have altered the window for clock checks. Also, if your window ran into 1am we know others have hit bad time-stamps then.

The reason I'm attaching so little importance to updates and other forced reboots is the logs on my 3 PALs:
1. PAL #1 last reboot 258 days ago (9/12/10 at 11:15am).
2. PAL #2 last reboot 61 days ago (3/8011 at 3:49am).
3. CM-PAL last reboot 179 days ago (12/5/10 at 10:02pm). (About when I bought it).

My guess is I did an evening channel scan for my Magic #1 PAL after I reconfigured my antennas several months ago. The other two PALs needed to be corrected by the 7:10pm zip code reset.

Since the 7:10pm zip reset has not failed me yet, I would force a clock reset at that time and keep tabs on the clock. If your clock goes bad and mine does not, there's some variable in play we have yet to discover.

I am considering the possibility that signal interference at the time of a clock data check could also cause the PAL to change its scheduled clock update window. If such unpredictable events could reset your clock search, then you might have to resort to the update option.

Originally Posted by P Smith

Three blind gurus touching an object (an elephant) and telling us what it is ...

Guys, if you will have a log of TVGOS packets from your TVGOS source - REAL DATA from OTA stream, then you will make REAL theories about TR-50 internal algos ...

For now, you are those three gurus.

Originally Posted by jrpastore

The thing is, we're talking about free software and hardware (an ATSC tuner card) that only costs around $20 to buy. So based on the old addage that "time is money" If we take $20 and divide by the number of hours that several DC area viewers have spent on this issue, the result implies a frighteningly small value being placed on their time...

That said, I think some of the theories about the internal clock smoothing algo in the DTVPal are fairly convincing, but P Smith is right, you'll never really know what the elephant looks like until somebody turns on the lights...

Originally Posted by AV Empiricist

At this point your approach seems reasonable. During the original clock skew episode, I believe there was a difference between 6:40pm and 7:10pm. But we can't blame the PAL for that. As with any computer, it's, garbage in garbage out. If bad data is being broadcast, the PAL and similar devices will dutifully assimilate it.

What's really puzzling is that after the DC Clock was fixed, I toggled the zip on my CM-PAL 3 times: Once at 3:30pm, again at 4:27pm and finally at 5:33p.m. That means my CM-PAL was reset at 5:33pm. It functions as a back-up, so the clock isn't critical. I thought if the skew returned, it would be the PAL most susceptible to a skew. There's no evidence it has skewed. The clock is accurate, but I haven't scheduled any recordings on it for weeks so I can't check for start time discrepancies.

If the PALs I reset after 7pm have accurate clocks and the one I reset at 5:33pm is accurate, what could have happened to derail your 6:40pm reset?

I don't have an answer. When I have a chance, I want to momentarily disconnect the antenna from the CM-PAL around 5:33pm to see what happens and also at 10pm and 1am. We already know that one of the Austin guys essentially used that trick (by putting his antenna amplifier on a timer) to reset his clock every day.

It isn't that I believe the PAL will accept corrupt data when there is signal interference. It simply might cause the PAL to reset the time for its clock data search--leaving it vulnerable to bad time-stamps at a bad time of day. Again, this wouldn't be the fault of the PAL: The broadcast data is supposed to be correct at all times of the day.

I have my antennas favoring 4, 7, and 9 in one direction and 2, 45, 54, and 22 in the other. I can't remember seeing the faintest glitch on Hawaii-Five-O or the Mentalist anytime this season. But strong wind gusts can occasionally pixelate 5, 11, 13, 50 and 66 (hence, I record 45 and 54).

Originally Posted by J-D-H

Since I've seen some strange things here with clock error as well as advance TVG info, things not seen by you and others, I would otherwise wonder about my PAL hardware. However if it's malfunctioning, it's sure exhibiting it in a strange way. Many months of perfect operation, then weirdness, than weeks of perfect operation, 2 days of bad clock, and now back to perfect again. Through the whole period of ownership, not once have we seen any functional problems -- it has always recorded and played back perfectly. If it's failed or failing, the symptoms are mighty peculiar.

I'd love to see a flow chart of the FW's operating system as regards how it collects the TVGOS data. You and others have intuited some of it by external observation and clever sleuthing, but I have the feeling it's even more complex (and maybe logically tortured) than we imagine.

Originally Posted by AV Empiricist

I'm inclined to believe your PAL is operating within its design parameters. I had worse problems with my previous dvrs (the LG and Sony) and this 3rd party TV Guide transmission was at the heart of it all. That's why experienced members want an option to cut the TV Guide and clock completely out of the picture. Your TV Guide listings could have gotten jammed by a number of seemingly innocuous events--like an interrupted transmission from a power outage or an unfortunate timing of an antenna rotation. And you are surely correct: Even with a battery of exhaustive testing, we're not going to divine all the inner workings of the PAL. But, the fact your PAL's normal operation was restored by a factory reset is a good indication it's fine.

Get this: With the Sony, I missed 2 weeks of a scheduled program because I didn't realize the Guide listing had changed from 10:00pm to 10:01pm. That was enough for the Sony to ignore it!

Originally Posted by P Smith

Last 24 hrs TVGOS stats is here, ch29 KPIX SFO: