The Official AVS Dish DTVPal DVR Topic! - Page 411

A power supply with battery backup is even better than a surge protector. I wouldn't run my PAL (or my computer) without one.

+1

ALL DVRs (as well as PCs) go on UPS's, not just surge protectors.

A DVR is just a specialized computer.

Not disagreeing, just requesting clarification/justification:

We are concerned about two negative outcomes caused by unreliable AC line power:

1) Damage to our hardware.

2) Loss of "work" in progress.

AFAIK, a surge protector and an UPS (with equivalent joule rating) do an equally good job at preventing #1, correct? Obviously only the UPS can prevent #2.

If the above assumptions are correct, then the only reason to prefer an UPS over a surge protector in the case of the DVR is if you are concerned about losing some/all of a particular recording due to a power outage right? If so, then a reasonable person with fairly reliable AC line power who does not consider any particular DVR recording to be "critical" might reasonably decide that an UPS is not justified for the DVR, right?

Please let me know if the logic above is flawed or based on erroneous assumptions.

Exactly - The DVRs seem to take longer to recover from a power loss than a non-DVR equivalent.

Some of us believe that it is sometimes possible for a messy power failure with retries (power down, then up, then down, then up, then down to stay, all within a few seconds) to damage actual hardware by overstressing something or to at least trash a HDD so thoroughly that the data on it cannot be recovered automatically by the DVR.

My CM-7000PAL always says it's getting the time setting from TVGOS, so no need to trick it to do so.

The clock setting became virtually perfect for about 24 hours a few days ago. In fact we got excited and thought the problem had been solved (by either CBS or TVG, whichever is responsible) and posted this here. However, sadly, the next thing we knew the time was off again. And now the indicated time error is in the opposite direction from before. It is late by 5 minutes instead of early, the way it had been for the previous month. So now we're wondering whether this was done on purpose. If the clock is going to be wrong, you can argue that it's better to start recording early rather than late (except when this causes it to step on an earlier adjacent recording if both tuners are working).

I have sent the CBS station another email asking what is going on. I hope they'll reply.

The tech guy didn't harp on the "end behind" aspect. He just said to "make use of the start early/end behind screen". I doubt he even kept up with whether we've been seeing early or late recordings here, so his statement was just a general recommendation to use those features.

I agree with you about his wrong interpretation of what "protect" does, and I tried to point this out during the phone call. However he insisted that "protect" is not an anti-delete protection feature. Instead, he claimed it is to make the box apply the early/late bias to all recordings whether done by timer or TVG. That made no sense, I read the user guide description of "Protect" to him, etc., but he said that this was wrong. Oh well. No doubt he was a first tier rep, a "screen reader" type.

If I understood how the clock setting is done, I might be able to comment on your suggestion for a firmware fix. But I don't, so I can't. I always assumed that the clock setting for the CM-7000PAL (or any box similar to it) was something simple like a once every day time setting, probably in the wee hours of the morning. However from what you said, it sounds way more complicated.

Personal computer motherboard clocks have always had the reputation of being pretty bad time keepers with lots of drift. However, even so, with daily updating they usually stay within a few seconds. So I really wonder what the big deal is with setting the clock in the CM-7000PAL. Maybe you can explain the necessities of those things you mentioned (smoothing, etc.). If you don't have time, maybe this is explained in another thread?

I'm confused. In your first post about this issue here, you said your recordings were starting late. This would indicate the clock was late. That message was also in response to someone whose clock was 7 minutes late. Now you say it is late, but was previously early, which is different from what you posted a couple of days ago. The significance of this is that if your clock was early before, then this is not the same issue as what Austin sees. Their clocks are either on time, or late, but never early.


These CBS stations really don't know anything about the TVGOS inserter. It is basically a black box that Rovi installs. The only control CBS has of it, is they can reset it if Rovi tells them to. The box is connected to a network, and Rovi can connect to it to diagnose problems. That is why the CBS engineers don't have any information about how long it will take to fix. There is nothing they can do to fix it. It is all in Rovi's hands.

Mark

Exactly why I use a UPS on my DTVPal and Dish receiver in my AV system as well on as my computer. Rarely does the power come back with one action. This morning we lost power for over an hour about 5:30 am, I have no idea why, and the power tried to come back several times briefly maybe a half-second each. Both UPS's batteries ran down but they shut off clean, gave me time to properly turn off the computer, and the power from the UPS's came back online one time cleanly when it was all over.

You don't let your PC autopower off from UPS software?

Yes, exactly. I'm concerned that a retry during a reboot could totally screw things up and get the PAL stuck in 'loading, please wait' no-man's land.

Nope. Older Tripp Lite "Internet 500" UPS doesn't have that feature. No interface with computer. Just AC outlets.

Only for really bad and rare particular HDD or components; all drives and power supplies and devices passing stress tests for such short on/off during design stages (EVT, PVT).
For 99% of devices the 'messing power' would not destroy HDD.

Hmm, I guess I can see your point in the case of the DTVPal DVR. Over the past 412 pages it has been shown to be pretty flaky and prone to mysterious lock-ups. If nobody knows why these lock-ups occur, then nobody knows that they aren't due to rapid power cycling I guess. I was just commenting on the general nature of consumer electronics (including computers) that they are not permanently harmed by rapid power cycling. I would think that's actually one of the tests they are subjected to prior to being unleashed on the world.

A "clock smoothing" algorithm doesn't have to be implemented, the firmware authors could simply have done a daily "spot check" as you suggest. But they add this additional smoothing code as an "insurance policy" against occasionallly grabbing a bad timestamp during a simple "spot check" and then having the DVR clock be off until the next "spot check" occurs.

The reason I speculate that the DTVPal uses some kind of 24-48 hr rolling average is that we were tracking the actual accuracy of the TVGOS timestamps in real-time a few months ago using TSREADER and the accuracy of the DVR clock seemed to roughly track the accuracy of the timestamps over the past 24-48 hours rather than their current accuracy.

The ROVI rep that I was corresponding to at the time actually cited this firmware "deficiency" in the DTVPal as the "root cause" of the whole clock skew issue. He repeatedly pointed out that user hardware running "certified TVGOS software/firmware" in the Austin broadcast area (primarily TVs) did not show the clock skew despite receiving the exact same skewed timestamps from the TVGOS datastream. I countered that knowingly broadcasting incorrect data for 19 hours out of every 24 hour cycle and then relying on user software/firmware to discard all that bad data and lock on to the correct time hardly represented engineering "best practices". Several weeks later ROVI proposed their infrastructure changes at the local broadcaster to resolve the issue. Not surprisingly, the local broadcaster has balked at the additional work/risk associated with these changes in order to benefit only a relative handful of viewers.

ROVI's reasoning can't stand against hard evidence: our logs with current time stamps and wrong TVGOS' timestamps by ROVI equipment.
I'm still thinking, you guys in those places (Austin, etc) must contact FCC with TSReader's binary samples of ROVI's TVGOS PID.
Play the middleman role between a station and ROVI without access to the equipment and its setting will never bring solution.

I call BS on that Rovi statement. The Sony DHG runs with official Gemstar/Rovi software (Rovi has declared the Sony version as unsupported, but the software was written by Gemstar/Rovi), and it also shows this clock skew issue. The reason that no one with TVs have complained about this, is that it does not affect the operation of the TV in any way. Who cares if the clock on your TV is 6 minutes off? I bet if you could find someone with a TVGOS television in Austin, that you would see the same issue with it.

Mark

That response from ROVI just mean: their licensed SW is capable to recover from their errors. Nothing else.

But ROVI's clock 'skew' - why use the euphemism ? - it's an ERROR - is physical fact and we had PROOF of it !

I discussed the Sony DHG comparison with the ROVI guy at the time. HE SAYS the older analog version of TVGOS SW on the DHG was certified by ROVI and does not show the clock skew issue. HE SAYS the newer digital version of the TVGOS SW on the DHG was never certified by ROVI and that if it shows the clock skew issue, that only proves that it ALSO has "defective" firmware just like the DTVPal...



Also discussed this issue with ROVI guy at the time. HE SAYS that while their ROVI tech was in the KEYE studio he observed the TVGOS clock display on a TV in the studio that was receiving the OTA signal and confirmed accurate time display at the same time that our DVRs were showing slow clocks. I had no way of disproving his claim, so I simply congratulated him for the impressive robustness of their "blessed" software and repeated my contention that knowingly broadcasting bad data most of the time could never be justified as part of their "standard operating procedure".

John

I agree with you 100%. I just raise two points:

1) I'm not confident that anything I/we could ever do would bring about a solution, and thanks to others on this forum I now have work-arounds that enable me to avoid being overly impacted by this problem.

2) I don't know for certain that FCC regulations require accurate transmission of private 3rd-party embedded data streams that are not part of the broadcast program. Even if they do, I think it's pretty unlikely that a gov't beaurocrat is going to decide to mobilize the enforcement apparatus of a federal agency on behalf of a few dozen disgruntled "techies" in Austin, TX...

Yeah, I know. But his implied point was that ROVI is under no obligation to spend engineering resources correcting a "problem" that it only observed by users of unlicensed software. His position is that hardware that uses unlicensed TVGOS software is essentially "freeloading" and deriving commercial value from a service that they have refused to pay for (by not paying the licensing fee). This "freeloading" was bad enough, from ROVI's point of view, but to rub salt in the wound by demanding that ROVI spend additional money to fix a problem only experienced by the freeloaders was ridiculous.

That was essentially ROVI's position and they refused to look into the issue any further until enough of us bothered Dusty at KEYE that he decided to leverage their commercial ties with ROVI and demand some action. That's when ROVI agreed to ship a replacement encoder.

So I can sort of see both sides of this thing... We DTVPal owners are the unwitting owners of freeloading hardware. ROVI has never commited to (or been paid for) ensuring proper operation of that hardware. The fact that the only reason our hardware doesn't work right is that they are knowingly transmitting incorrect data most of the time and that local station managers are tired of hearing complaints about it is the only reason they spent any resources on it at all.

(From my experience with courts) I'm strongly advise you DO NOT DISCUSS with ROVI or station engineer ANYTHING behind solid facts with THEIR signal/packets/data !
They're SPECIFICALLY dragged you into very mud point (SW, licensing,etc) where you LOST.

Please, do not give them the leverage/handle.

Just stand with stream ERRORs, prove it by capturing whole mux (that will have all timestamps from different PIDs), point to obvious and simple errors with ROVI timestamps.
Don't allow them to distract you - don't mention Pal/Sony/etc - say your TV clock is out and you missed your appointments because the TV is set as alarm clock.

Don't buy their argument - 'studio display shows proper time': 1st - you don't know/can't check where is the timestamps taken; 2nd - you have your stream's error - OTA , not that ideal studio packets with minimum delays and routing.

I've had some experience with legal matters as well. IMHO the most important part of the decision of whether to initiate something is being able to foresee likely outcomes, ie "the end game" (see Viet-Nam, Afghanistan, Iraq, Libya, etc.)

IMHO the likelyhood that the FCC would intervene in this issue on our behalf is below 1%. Even if they did, here are the "end game responses" from the relevant parties:

ROVI: Despite being under no contractual obligation and receiving no compensation to support user issues arising out of use of unlicensed products that make use of our proprietary TVGOS datastream, we voluntarily invested engineering resources at our own expense to investigate it as a goodwill gesture. As a result of this engineering work, we have identified the root cause of this technical issue. We have also developed, documented, and published a corrective action plan that, if implemented, will completely resolve this issue. We have no control whatsoever over whether the broadcaster in question chooses to implement our corrective action plan.

KEYE: Several years ago, we entered into an agreement with ROVI to host a piece of their equipment as part of our broadcast infrastructure. The installation configuration that was identified for this ROVI hardware at that time was (and still is) compatible with our other infrastructure. Recently ROVI has proposed an alternate installation configuration for this ROVI hardware in order to resolve a technical issue that is unrelated to our broadcast programming and is only observed by a small number of our viewers. This alternate installation configuration is likely not compatible with our other infrastructure because it requires additional ATSC bandwidth to be dedicated to the ROVI hardware. At the very least, significant KEYE resources would be required to re-configure and re-certify our infrastructure. We are not obligated by the terms of our agreement with ROVI to implement any infrastrucure changes that they may recommend, and we have made the business decision not to implement the proposed alternate hardware configuration from ROVI. If ROVI concludes that our infrastructure environment is no longer compatible with their hardware, there are several other broadcasters in the Austin area with whom they are welcome to discuss their needs.

I've taken a LITTLE artistic license here, but both of these position statements are essentially what I got directly from the horses' mouths. So doing a little math: 1% chance of FCC taking any interest in this issue in the first place multiplied by 1% chance that either of the above two positions would be found legally unsupportable works out to 0.1% chance of any positive outcome from my forwarding this issue to the FCC. I don't like those odds...

Echostar/Dish is not really a freeloader from the standpoint that as a result of the many lawsuits that seem so popular in this business Echostar got the rights to use the TVGOS stream but they are not using ROVI's code.

The thing that gets me is that they have declared code that they wrote a few years ago as unsupported and no longer valid.

jrpastore,

We should deal with it or that chances (I would be more optimistic, especially if you could involve a press ) become zero. Easy, as you can see it happening from current status quo.

My point is in an active position based on simple UNDISPUTED facts, do not allow to skew it.

As soon you'll add layers like they loading on you - they will mothballing any issues, especially like this.

Being granted the rights to freely access some private communications does not carry with it the right to sue for damages (or injunctive relief) if the content of those private communications does not meet your needs.

You have the right to freely access the public airwaves with a radio. Lets say a taxi company dispatches it's cabs via unsecured analog radio comms. You are certainly allowed to listen to these comms on your receiver. You are probably even allowed to make commercial use of these comms by sending your taxi to the dispatched location in order to pick up the fare before the other guy gets there. However, if the data proves to be incorrect (wrong address) you certainly have no legal recourse against the taxi company dispatcher for sending out wrong data. That's pretty close to the scenario we're dealing with here.

Making commercial use of anything you hear with a scanner is illegal.

OK, so to make this analogy completely applicable all we need to do is stipulate that due to some prior, (but now discontinued), business relationship, a court has granted your taxi company the right to make commercial use of the other taxi company's dispatch calls. I still think you would have no right to seek any kind of legal relief if the content of any of those dispatch calls proved erroneous.

Don't TV stations dispatch camera crews based on police scanner calls?

As you observe, the clock error has been varying here. When we first noticed it 3-4 weeks ago, all recordings were beginning 2-3 minutes late. Then a few days ago the error shifted to the other direction and the amount of the error increased to around 5-6 minutes. Just today the clock was within a minute of being accurate, this time running fast (i.e.: 6:33 PM when it should read 6:32 PM). I have no idea why we're seeing this variation.

I take your word for it that Rovi is at fault here. So far they haven't replied to any communication. The local CBS station rep has replied to emails, and it sounded like they have some input on this problem. If they're getting complaints and have no technical control over the problem, maybe they will apply pressure to Rovi. I hope so.