The Official AVS Dish DTVPal DVR Topic! - Page 427 - AVS Forum
Forum Jump: 
 61Likes
Reply
 
Thread Tools
post #12781 of 18262 Old 05-25-2011, 08:50 PM
AVS Special Member
 
mabuttra's Avatar
 
Join Date: Jan 2009
Location: Wichita, KS OTA (w/optional cable connection)
Posts: 1,895
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 30
Quote:
Originally Posted by LuvMyDVR33 View Post

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

They aren't enabling firmware updates to get firmware updates. They are doing it to take advantage of a side effect of enabling updates, and that is the automatic reboot that happens at the time of day that you specify. The theory is that if you reboot the DVR every day when the WUSA time stamps are correct, the clock will stay correct. The reboot causes the DVR clock to immediately synchronize with the TVGOS timestamps.

Mark
mabuttra is offline  
Sponsored Links
Advertisement
 
post #12782 of 18262 Old 05-25-2011, 09:12 PM
Member
 
AV Empiricist's Avatar
 
Join Date: Mar 2010
Posts: 54
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by LuvMyDVR33 View Post

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

I always recommend disabling the update for the reasons you suggest, but..there is one desperation scenario when it could be useful.

The PAL seems to need correct clock data during a window of several hours in order to maintain the correct time. If that window is available and you reset its clock at the correct time of day to take advantage of it, the PAL will adjust its clock within that window each day and no further action is required.

But, let's say you force a clock reset with a reboot at 7pm. The clock might immediately correct, but its final time adjustment happens several hours later. The next day the PAL will wait for the several hours before adjusting the clock. In other words, no initial reset will happen at 7pm. The PAL will simply start collecting timestamps at 7pm but wait until it is finished (several hours later) before it sets the clock for the next 24 hours. That's fine if the time-stamps are all good for that window. But if the time-stamps go bad before those several hours are over, you have a bad clock.

Enter the update option. If you have a good time-stamp at 7pm, but bad time-stamps too soon afterwards, a 7pm update will force a reboot--temporarily correcting the clock until several hours later when the PAL makes its final adjustment. THAT could give you an accurate clock during prime time, after which, the clock will skew until the next update.

We are not at that point in DC. The window of accurate clock data is wide enough so we can let the PAL do its adjustment every day without interfering. Keep the update option disabledfor now. Give credit to the guys in Austin. They were faced with the desperation scenario and discovered this work-around.

If the time-stamps skewed during prime time over the weekend, none of these actions would have avoided it anyway, and the PAL should have corrected the skew on its own when the broadcast data was fixed.

This is all an educated hypothesis.
AV Empiricist is offline  
post #12783 of 18262 Old 05-26-2011, 06:42 PM
Member
 
Mike`L's Avatar
 
Join Date: Apr 2008
Posts: 31
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by nopedals View Post

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.

Just added this to the macro on my remote. Works great! Some one get this man a beer!
Mike`L is offline  
post #12784 of 18262 Old 05-27-2011, 02:34 PM
AVS Special Member
 
keyboard21's Avatar
 
Join Date: Jun 2008
Posts: 1,250
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 15
Quote:
Originally Posted by Mike`L View Post

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

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

Anyone?

thanks, Happy holiday weekend
keyboard21 is offline  
post #12785 of 18262 Old 05-27-2011, 03:10 PM
AVS Special Member
 
frank70's Avatar
 
Join Date: Oct 2006
Posts: 1,175
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 7 Post(s)
Liked: 26
Quote:
Originally Posted by keyboard21 View Post

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

Anyone?

thanks, Happy holiday weekend

The big red button on the DTVPal DVR remote turns the unit on (i.e. not in standby) if it's off (i.e. in standby), but turns it off if it's on.

A discrete on button (or macro) would turn the unit on if it's off, and leave the unit on if it's on.

A discrete off button (or macro) would turn the unit off if it's on, and leave the unit off if it's off.

You would need a discrete on if some robo-device (and not a human who could see with his eyes that the unit was already on) wanted to turn it on at a specific time regardless of whether it was on or off at that time.

So since the SYS INFO button on the DTVPal DVR remote turns the unit on but does not turn it off, then SYS INFO followed by SELECT always leaves it on, and SYS INFO followed by the big red button always leaves it off. So the big discovery by nopedals was this useful behavior of the SYS INFO button.
frank70 is offline  
post #12786 of 18262 Old 05-27-2011, 03:13 PM
Member
 
Donald1800's Avatar
 
Join Date: Nov 2008
Location: Inland Empire, SoCal
Posts: 143
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 5 Post(s)
Liked: 30
The DVR remote has only one button which alternately does the 'ON'/OFF' function. A 'discrete' 'ON' and 'OFF' consist of a button that has only one function - in this case turn it on ONLY.

In the case where your DVR has already turned on automatically due to a timed event, pushing a system-wide programmed remote 'ON' button containing a macro including the standard DVR 'ON" function would turn it 'OFF'. Whereas, using the discrete 'ON' command will keep it 'ON' if already 'ON' and turn it 'ON' if not.

Donald1800
Donald1800 is offline  
post #12787 of 18262 Old 05-27-2011, 04:55 PM
Senior Member
 
J-D-H's Avatar
 
Join Date: Feb 2007
Posts: 225
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by AV Empiricist View Post

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

When my PAL clock became accurate approx. 3 weeks ago, I hoped this fun episode was over and disabled the automatic daily FW updates as you suggest. Then last week when we found that we had lost the first five minutes of several shows recorded the night before (for who knows what reason), doing a soft-reset via the remote brought the clock instantly back to accuracy.

Since I have no idea what caused the clock to go off most recently, nor whether it's likely to happen again, and since we don't wish to lose important pieces of shows again, I'm left with figuring out the best defense (if there truly is one and we aren't just solely and totally at the mercy of CBS / TVGOS.). Having the FW updates disabled certainly did NOT keep my clock from skewing. I do not wish to do your options #1 or #2 since they require manual operations, so in order to do your option #3 (and #4 at the same time, I believe), I've turned the auto FW updates back on again. Do you think this is counterproductive?
J-D-H is offline  
post #12788 of 18262 Old 05-27-2011, 08:00 PM
Senior Member
 
ss_sea_ya's Avatar
 
Join Date: Apr 2009
Location: Alexandria, VA
Posts: 213
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
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 itself to 5 minutes fast. 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.
ss_sea_ya is offline  
post #12789 of 18262 Old 05-27-2011, 10:17 PM
Member
 
AV Empiricist's Avatar
 
Join Date: Mar 2010
Posts: 54
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by ss_sea_ya View Post

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.

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.
AV Empiricist is offline  
post #12790 of 18262 Old 05-28-2011, 08:31 AM
Senior Member
 
J-D-H's Avatar
 
Join Date: Feb 2007
Posts: 225
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by AV Empiricist View Post

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.

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.
J-D-H is offline  
post #12791 of 18262 Old 05-28-2011, 10:10 AM
AVS Special Member
 
dattier's Avatar
 
Join Date: Mar 2008
Location: Chicago IL, Northwest Side
Posts: 2,882
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 28
Funny, for all the problems we have with these units, the two chief reasons that I record shows with the cable-company-leased Motorola DCH3416 whenever I can and use the DTVPal DVR as little as possible are not Echostar's fault.

One is that Rovi's TVGOS info never includes episode titles, and I like to know the episode title, and since my computer and my DVR's are in different parts of the house, I can't just pop onto the web to look it up.  I can always schedule and cancel the same show on the DCH3416 and find its episode title in the DCH3416's history, so this is far less important than the other issue.

That other issue is that the room where I watch TV has no connection to the outdoor antenna, so the DTVPal DVR is on an indoor antenna, so the reception is not always so good and there are a lot of ATSC dropouts on most stations.

If it weren't for those, I'd use the DTVPal DVR a lot more and pretty much save the DCH3416 only for cable channels and three- or four- station conflicts.
dattier is offline  
post #12792 of 18262 Old 05-28-2011, 01:45 PM
Member
 
AV Empiricist's Avatar
 
Join Date: Mar 2010
Posts: 54
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by J-D-H View Post

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.

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.
AV Empiricist is offline  
post #12793 of 18262 Old 05-28-2011, 07:01 PM
AVS Special Member
 
P Smith's Avatar
 
Join Date: Apr 2003
Location: Silicon Valley
Posts: 1,929
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 127
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.
P Smith is online now  
post #12794 of 18262 Old 05-28-2011, 07:23 PM
AVS Special Member
 
mabuttra's Avatar
 
Join Date: Jan 2009
Location: Wichita, KS OTA (w/optional cable connection)
Posts: 1,895
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 30
Quote:
Originally Posted by dattier View Post
Funny, for all the problems we have with these units, the two chief reasons that I record shows with the cable-company-leased Motorola DCH3416 whenever I can and use the DTVPal DVR as little as possible are not Echostar's fault.

One is that Rovi's TVGOS info never includes episode titles, and I like to know the episode title, and since my computer and my DVR's are in different parts of the house, I can't just pop onto the web to look it up.
TVGOS does give episode titles. If you aren't seeing them, then you probably aren't getting TVGOS data. The fact that you have a lot of ATSC dropouts, could explain why your TVGOS data isn't there. I would think that even without TVGOS you would still get episode titles from the PSIP data. The lack of episode titles is an issue with your DTVPal, and not the PSIP, or TVGOS data.

Mark
mabuttra is offline  
post #12795 of 18262 Old 05-28-2011, 07:31 PM
AVS Special Member
 
Chuck44's Avatar
 
Join Date: Feb 2007
Location: Missouri Ozarks
Posts: 2,175
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 4 Post(s)
Liked: 40
Quote:
Originally Posted by mabuttra View Post
TVGOS does give episode titles.
No, it doesn't. Maybe in rare instances but not as a general rule.
At least not with the DTVPal DVR.
Chuck44 is offline  
post #12796 of 18262 Old 05-28-2011, 07:56 PM
AVS Special Member
 
mabuttra's Avatar
 
Join Date: Jan 2009
Location: Wichita, KS OTA (w/optional cable connection)
Posts: 1,895
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 30
Quote:
Originally Posted by Chuck44 View Post
No, it doesn't. Maybe in rare instances but not as a general rule.
At least not with the DTVPal DVR.
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.

Edit: I've attached 3 pictures showing the episode titles on the Sony.
Mark
LL
LL
LL
mabuttra is offline  
post #12797 of 18262 Old 05-28-2011, 11:45 PM
Member
 
AV Empiricist's Avatar
 
Join Date: Mar 2010
Posts: 54
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by P Smith View Post
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.
Yes, I'd love to have the time-stamp logs. The time-stamps would be useful for better defining the boundaries of good clock data vs. bad data. But the Austin data and attempted solutions provide a basis to analyze the PAL's behavior. I'm very confident the DC clock has not skewed from 7pm to maybe midnight or 1am. We already know that 1am updates skewed the clock during the original skew episode and that 1am is skewed now. We know 10pm was correct a few days ago, but that wasn't sufficient to hold the correct time. So the basic operation is becoming clear. The exact window of good clock data required to maintain correct time is unknown, but it's probably 3-4 hours.

The real difficulty is giving proper weight to empirical observations. It's a fact that one of my PAL's didn't skew. It's a fact that the other 2 PALs were corrected by 7:10pm zip code resets. It's a fact that none of the 3 has skewed since. J-D-H needed to do a factory reset in order to straighten out his TV Guide listingsnot to fix the clock. But others are convinced the clock needs a reboot or even the PAL needs to be unplugged to reset the clock. (That doesn't square with my boot logs).

It isn't by magic I've got three PALs with accurate clocks: It's good data. So we know a window of good data is out there. How is it that these other PALs are veering off course? If people want to find the answer they have to be willing to limit the variables and understand that there are a number of actions which cause a clock reset and if any one of these actions is executed during a data skewwell guess what.

Even armed with the time-stamp logs, people have to keep track of their clock resets and the results to make sense of the PAL's operation. Too many disorganized actions spoil the broth.
AV Empiricist is offline  
post #12798 of 18262 Old 05-29-2011, 03:09 PM
AVS Special Member
 
dattier's Avatar
 
Join Date: Mar 2008
Location: Chicago IL, Northwest Side
Posts: 2,882
Mentioned: 1 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 28
Quote:
Originally Posted by mabuttra View Post

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.

Well, then my second biggest complaint about the unit is Echostar's fault after all.  Thanks for clearing that up, Mark.  I can't understand why it would be programmed to discard episode titles, but apparently it is.

Yes, the program name is present, and I definitely am getting TVGOS, with the TV Guide logo and, for most stations, seven-and-a-fraction days of displayed titles and times.
dattier is offline  
post #12799 of 18262 Old 05-30-2011, 06:06 AM
Senior Member
 
J-D-H's Avatar
 
Join Date: Feb 2007
Posts: 225
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by AV Empiricist View Post

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.

I keep a log of DVR changes, clock checks, etc., and it shows that prior to the recent 2-3 day clock error period discovered on 22May11, I had roughly two weeks of proper operation and an almost perfect clock after using the factory defaults option on 8May11 at 6:40 PM.

Your choice for resetting at 7:10 PM and my 6:40 PM one seem so close I assume we can treat them as identical (if the DVR is so fussy that resets 20 minutes apart makes a difference, I truly will wish to throw this thing in the trash !)

As for signal glitches and the like, no doubt it's always possible that this occurred, but I wonder how long the interference would have to persist to make a difference? In general, WUSA is very strong here -- like 96-98 on the signal strength indicator. So we virtually never see any signal breakup or pixelization, even during wind and rain (BTW, this DOES occur on a few other channels). However if the update process if so fragile that a moment's RF glitch can cause corruption, I'd say it's very likely that we'd all be in trouble and see frequent clock problems.

For few days now I've left the DVR set to do FW updates at 6:45 PM. So far, so good, but we'll see. My, isn't this constant checking fun?!
J-D-H is offline  
post #12800 of 18262 Old 05-30-2011, 06:09 AM
Senior Member
 
J-D-H's Avatar
 
Join Date: Feb 2007
Posts: 225
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by P Smith View Post

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.

Very true -- in engineering there's no substitute for hard data. But some don't have the test gear to collect this (nor maybe the inclination nor incentive to buy it).
J-D-H is offline  
post #12801 of 18262 Old 05-30-2011, 04:35 PM
Senior Member
 
jrpastore's Avatar
 
Join Date: Aug 2009
Location: Austin, TX
Posts: 241
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 13
Quote:
Originally Posted by J-D-H View Post
Very true -- in engineering there's no substitute for hard data. But some don't have the test gear to collect this (nor maybe the inclination nor incentive to buy it).
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...
jrpastore is offline  
post #12802 of 18262 Old 05-30-2011, 05:30 PM
Member
 
AV Empiricist's Avatar
 
Join Date: Mar 2010
Posts: 54
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by J-D-H View Post
I keep a log of DVR changes, clock checks, etc., and it shows that prior to the recent 2-3 day clock error period discovered on 22May11, I had roughly two weeks of proper operation and an almost perfect clock after using the factory defaults option on 8May11 at 6:40 PM.

Your choice for resetting at 7:10 PM and my 6:40 PM one seem so close I assume we can treat them as identical (if the DVR is so fussy that resets 20 minutes apart makes a difference, I truly will wish to throw this thing in the trash !)

As for signal glitches and the like, no doubt it's always possible that this occurred, but I wonder how long the interference would have to persist to make a difference? In general, WUSA is very strong here -- like 96-98 on the signal strength indicator. So we virtually never see any signal breakup or pixelization, even during wind and rain (BTW, this DOES occur on a few other channels). However if the update process if so fragile that a moment's RF glitch can cause corruption, I'd say it's very likely that we'd all be in trouble and see frequent clock problems.

For few days now I've left the DVR set to do FW updates at 6:45 PM. So far, so good, but we'll see. My, isn't this constant checking fun?!
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).
AV Empiricist is offline  
post #12803 of 18262 Old 05-31-2011, 05:24 AM
Senior Member
 
J-D-H's Avatar
 
Join Date: Feb 2007
Posts: 225
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by jrpastore View Post

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

If my current main PC had the ability to make use of an ATSC tuner card, I'd have one by now without the need for persistent external urging. Having had them (Happauge NTSC, etc.) in the past, I do understand their cost benefit ratio. The machine I'm building now hopefully will have one, primarily as part of PC-based DVR. Enough said.....
J-D-H is offline  
post #12804 of 18262 Old 05-31-2011, 06:08 AM
Senior Member
 
J-D-H's Avatar
 
Join Date: Feb 2007
Posts: 225
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by AV Empiricist View Post

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

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.
J-D-H is offline  
post #12805 of 18262 Old 05-31-2011, 09:20 PM
Member
 
AV Empiricist's Avatar
 
Join Date: Mar 2010
Posts: 54
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by J-D-H View Post

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.

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!
AV Empiricist is offline  
post #12806 of 18262 Old 06-01-2011, 05:00 AM
Senior Member
 
J-D-H's Avatar
 
Join Date: Feb 2007
Posts: 225
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by AV Empiricist View Post

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!

I never thought about an ill timed antenna rotation as a possible cause for trouble. However, now that you bring it up, this makes sense if a momentary glitch is all it takes to cause the PAL grief. Thanks for mentioning this possibility.

That Sony story about it being impacted by a mere 1 min change is truly amazing. I can imagine coming home after a vacation only to find that the DVR you depend on (and, oh by the way, spent 100's of dollars to buy) was useless. Luckily so far the PAL series has been more rugged than this. Now, as you mentioned, if only they'd mod the FW to let users choose the clock setting source!
J-D-H is offline  
post #12807 of 18262 Old 06-01-2011, 07:20 PM
AVS Special Member
 
P Smith's Avatar
 
Join Date: Apr 2003
Location: Silicon Valley
Posts: 1,929
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 127
Last 24 hrs TVGOS stats is here, ch29 KPIX SFO:
Code:
 TVGOS Tables/Packets Statistics:
IDs        tables   packets      bytes  known type
ID00: \t    37220     39222     558300 [Dummy]
ID01: \t     6178      6178     123560 [Timestamps]
ID26: \t      638      3489    2455407
ID42: \t      311       743     507329
ID58: \t     1240      7577    4759256
ID66: \t      153      8827     494650 [LineupSelPkts]
ID67: \t     1734     24397    6654051 [LineupPkts]
ID68: \t       51        51      21930 [DPP]
ID69: \t     1520     14512    5826320 [ID70]
ID70: \t     3763     26870   14301702 [ID70]
ID71: \t     2782     22340   10635882 [ID70]
ID72: \t       72      3888     264584 [ID70]
ID73: \t      255       867     787032
ID74: \t       51       102      70941
ID75: \t       51        51      16983 [EPP]
ID77: \t     1330      1330     196840 [ZipcodePkts]
ID78: \t       51        51       7854 [TimezonePkts]
ID79: \t      292       876     360912 [HostSchedulePkts]
ID80: \t       39        39      31122
ID81: \t     4697     60200   18320144
ID85: \t       58      1668     233128 [ID27]
ID86: \t      431      1833    1697668 [ID27]
ID87: \t      336       336     130544 [ID97]
ID88: \t        8         8        376 [ID97]
ID89: \t     6206     21480   20077878 [ID97]
ID96: \t     3168      3168     768464 [ID97]
ID97: \t       16        48      44696 [ID97]
ID98: \t     5222     22880   21008852 [ID27]
ID100: \t    19674     97196   74641212 [ID27]
\tTotal:97547/370227, Size:184997617

 

24hrs.zip 375.3095703125k . file
P Smith is online now  
post #12808 of 18262 Old 06-03-2011, 05:33 AM
Senior Member
 
J-D-H's Avatar
 
Join Date: Feb 2007
Posts: 225
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 10
Quote:
Originally Posted by P Smith View Post

Last 24 hrs TVGOS stats is here, ch29 KPIX SFO:
Code:
 TVGOS Tables/Packets Statistics:
IDs        tables   packets      bytes  known type
ID00:       37220     39222     558300 [Dummy]
ID01:        6178      6178     123560 [Timestamps]
ID26:         638      3489    2455407
ID42:         311       743     507329
ID58:        1240      7577    4759256
ID66:         153      8827     494650 [LineupSelPkts]
ID67:        1734     24397    6654051 [LineupPkts]
ID68:          51        51      21930 [DPP]
ID69:        1520     14512    5826320 [ID70]
ID70:        3763     26870   14301702 [ID70]
ID71:        2782     22340   10635882 [ID70]
ID72:          72      3888     264584 [ID70]
ID73:         255       867     787032
ID74:          51       102      70941
ID75:          51        51      16983 [EPP]
ID77:        1330      1330     196840 [ZipcodePkts]
ID78:          51        51       7854 [TimezonePkts]
ID79:         292       876     360912 [HostSchedulePkts]
ID80:          39        39      31122
ID81:        4697     60200   18320144
ID85:          58      1668     233128 [ID27]
ID86:         431      1833    1697668 [ID27]
ID87:         336       336     130544 [ID97]
ID88:           8         8        376 [ID97]
ID89:        6206     21480   20077878 [ID97]
ID96:        3168      3168     768464 [ID97]
ID97:          16        48      44696 [ID97]
ID98:        5222     22880   21008852 [ID27]
ID100:      19674     97196   74641212 [ID27]
        Total:97547/370227, Size:184997617

Okay, I'm a bit lost. What exact knowledge was this listing supposed to impart? Not the column definitions. I mean what are we supposed to take away as a conclusion that this listing log demonstrates?

Wading though the first part of the file yielded many 1 or 2 second time errors, so though these may be technically errors, I'd count them as totally acceptable. If something goes really awry with the time data farther into the file, I don't know how to find those log entries. There was a summary at the very end, but it wasn't obvious how it was helpful regarding bad time stamps.

Can you educate we unfortunate few who are unfamiliar with this file structure? Can you suggest a fast and efficient way for us to see what you want us to see? Manual searching was just way too arduous.
J-D-H is offline  
post #12809 of 18262 Old 06-03-2011, 08:59 PM
AVS Special Member
 
P Smith's Avatar
 
Join Date: Apr 2003
Location: Silicon Valley
Posts: 1,929
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 11 Post(s)
Liked: 127
Mr. mabuttra had most extensive knowledge of the bursts, packets, etc
With his help written the DLL and captured logs, stats.

Read his posts here (last few months) and at AVSforum's forums.
P Smith is online now  
post #12810 of 18262 Old 06-06-2011, 05:07 AM
Advanced Member
 
Pete-N2's Avatar
 
Join Date: Jun 2009
Location: Lynchburg, VA
Posts: 544
Mentioned: 0 Post(s)
Tagged: 0 Thread(s)
Quoted: 0 Post(s)
Liked: 19
Mark

Do you have a link for a description of how DIGITAL TVGOS works?

What do the letters MDI stand for?
Pete-N2 is online now  
Reply HDTV Recorders

User Tag List

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