The Official AVS Dish DTVPal DVR Topic! - Page 529

My DTVPal has started to freeze up during playback of recordings, during recording, and during live broadcasts after about 30 minutes. I can restart it by holding down the power on button for a few seconds and it will come back for a while. I have had better luck -- I think, but this is not well tested -- of recording with the system on off position. Just before it freezes up I notice things like pixelization(?) and slow response to button presses on the remote.

Does this sound like a problem that can be fixed by replacing the hard drive?

Btw, I am getting similar, but worse, response by a new DTVPal I bought anticipating a failure of this kind. The new one has been in my basement waiting to be in service in case the old one failed. But now the new one won't work.

I have pairs of cables and antennae to test with, so I have pretty much ruled out all other problems except perhaps the TV/DVR interaction, because I have only one TV. Is there any chance there is some sort of "handshaking" problem between the DVR and TV? The TV works fine with a Zenith convertor box on live broadcasts.

Brian in Atlanta

Others no doubt will try to help you but it seems odd that you are having this strange problem with 2 of them, one of which is brand new out of the box.

So my guess is there is something else going on. Either bad setup, connections or wiring from your antenna to the PALDVR or from the PALDVR to your TV.

You need to give us much more info as to how you connected the PALDVRs and how you connected it to you TV. For example are you using an Analog TV wih the analog (STD) feed from the PALDVR or are you feeding your TV with HDMI output?

Yes. By STD do you mean yellow for video and red,white for audio? That's what I am using. I have to identical RCA ANTs.
Actually, the new one has deteriorated, likely because I have unplugged it a few times. Now when I plug it in, for about 3 minutes I get the screen 'Please wait or press "Select" to stop.' with a stationary yellow box. Then all at once the box changes color to green, but ignores my clicking of the "select". Then after about minutes I may or may not get a (usually frozen) TV picture -- sometimes I get only a black screen. All click are ignored until the TV picture shows up, and then clicks are only acknowledged in the very brief periods of the picture changing. Mostly the picture is frozen.

Brian in Atlanta

Since you aren't using HDMI, there's no handshaking between the DTVPal and the TV, so that's not the problem. Sounds to me more like the DTVPals are overheating. When an electronic device works for a while but stops working after several minutes, that's often the problem.

Was your second DTVPal used, or did you buy it new several years ago when they were still being made? If it's been used, dust could have accumulated inside.

I'd take the covers off (I know that's a royal pain to do, but there are instructions near the start of this thread) and thoroughly clean them. You might also consider moving the hard drive to an external drive enclosure (if you have room). That will reduce heat and prolong your DTVPal's life. It also makes it easier to upgrade the drive later.

Edit: After reading your second post it sounds like your "spare" DTVPal has more serious issues. You might PM P Smith and see if he'd be willing to try to repair it for you. I still think your original one is overheating, though.

I already removed and vacuumed the old drive after reading the fine instructions I found in this thread for getting the cover off. But the problem persists.
So if it is overheating, will a new drive help?

It might. Newer drives are often more energy-efficient and thus produce less heat. You could even go with a smaller 2.5" drive instead of the 3.5" that came with the DTVPal; you'd need an adapter to make it fit, but those don't cost much. The DTVPal will work with any size drive up to 1 TB (larger drives won't work).

Don't forget to clean the fan and vents too. It's not just the drive that needs cooling.

Your best bet is probably an external drive enclosure, though. The enclosure will keep the drive cool, and removing the drive will keep the rest of the DTVPal cool. PaulJB gave some good instructions for moving your drive to an external enclosure in this thread. Just make sure to get an enclosure with an eSATA port and not just a USB port.

Good luck; HTH

I would disconnect a drive and try to run the DVR as a dual tuner STB; could be something simple, could be CPU is failing.

Yes; that's a simple test: just take the drive out temporarily. The Pal will still operate, although of course no DVR features will work. Watch TV for a while and see if it still freezes up after 30-45 minutes.

If it works OK, there's an excellent chance that replacing the drive and/or moving it to an external enclosure will help. If not, the problem could be a CPU or other chip that's going bad, or a cold solder joint that loses connection as things warm up and expand.

The Logo Disappeared here when the listings data ran out on 1/29 4am ...

Of course, per earlier discussions(atscmonitor.dll plugin tsreader logs/etc), TVGoS data of some sort is still being sent via WKRC during the normal download times .. the size and format of of it during the downloads *seems* to indicate it could be the "normal" (listings/ads/etc) TVGoS data -- but if it is(and it may not be, who knows), for some reason it is not working with DTVPal DVR, not at least with the Cincy DMA ZipCodes the 3 of us are using (Paul210, you and I) ... Also Haven't heard any reports from anyone in area with other TVGoS enabled devices ....

It's been reported that if TVGoS is lost for a while, the Pal will give up trying to download guide info after a few days.

You can try the trick of deleting WKRC, rebooting, adding it back, and waiting for the next TVGoS download; but if that doesn't work a factory defaults reset may be needed. If that doesn't work either, perhaps someone with TSReader could examine the TVGoS zip code packets to see what zip codes (if any) WKRC is broadcasting now.

Yes, I disconnected one of the wires to the drive. In the picture at http://www.avsforum.com/t/1099071/the-official-avs-dish-dtvpal-dvr-topic/14580#post_22367070 it was the red wire. When I did so, the DVR worked fine for over an hour. I noticed at first that the fan was not working, but after an hour I went back and it was working. So I reconnected the red wire and the fan would not work and the DVR tried to go into some sort of temporary mode instead of fully booting up. Could the problem be the fan? If so, do I need to take the fan out of the new one, or is there a good alternative, b/c I don't especially want to tear into the new one even though it is broken.

Brian in Atlanta

I don't see a reason of your conclusion: the disconnecting/reconnecting SATA [red] cable is not affect the fan's functionality. Just remember, you can't manipulate with cables if your DVR is powered. Always disconnect it's power plug.

I did disconnect the power plug.

I don't understand the rest of your comment relative to whether the problem is in the fan or not. The fan came on by itself. Is the fan supposed to go on and off to reduce heat, or is it supposed to stay on?

Brian in Atlanta

The fan controlling by FW and using termochip [LM75] in thermostat mode. So, it do on when int temp reach 50C.

Ok. I did not know the fan goes off and on.

So is the conclusion that I should try to put in a new drive?
JHBrandt has suggested an external drive. I have assumed that the list of approved drives on page 1 are internal drives that work.
I am pretty new to hardware fixing and need an easy, but likely-to-work, solution.

How do you remove the other wire from the drive? Do you pull horizontally away from the drive? Is that all or is there some other issue or tool required, too?

Thanks,

Brian in Atlanta

look closely - both connectors [SATA and power] has small metal tub - a lock; push it down and move the connector horizontally
any SATA drive up to 1 TB will work; buy it from a store like Fry's; if it will not work or would be too noisy for you - return it or exchange

I think I'd try the no-drive test first. If the Pal still overheats even with no drive connected, you need to get it serviced before spending money on a new drive. They are 3.5" drives that have been confirmed to work. They can be mounted internally or externally, but you'll need to buy an external drive enclosure and a SATA-to-eSATA transition cable to mount them externally. You can also mount the existing drive externally, which will save you some money if you don't want to upgrade to a larger drive yet. I think what you're calling the "red wire" is actually the SATA cable. The other cable (with four separate wires & a larger connector) is the power cable. If you disconnected the SATA cable, you were still supplying power to the drive (and producing heat) even though the Pal couldn't see it anymore.

See P Smith's previous post for instructions to disconnect/reconnect the cables. HTH

Tried that a few days ago, no joy for any listings, but the clock data works as expected ... Deleting WKRC channels/rebooting allows for manual time/date set (time not "greyed out"), re-adding WKRC then greys out the time with message "Time acquired from TVGoS" ....

WillN937 reported doing that, so that didn't work either ...

How does one examine the Zip Code Packets with TsReader in such a way that shows the actual zip codes ?

I tried dumping the TVGoS Streams(record PID in Tsreader) to disc for a while and looked at the files with a Hex Viewer, but I don't know how to look for Zip codes there/and or what identifies the zip code packets ... Sure I can find sets of two Hexidecimal values next to each other which match an area 5 digit zip code(in the stream with PID address 0X110 with the files I just checked), but I can also find other 5 digit numbers that would match zip codes elswhere ....

-- anyway -- ZipCode Packets are present in WKRC's TVgoS data -- here is what the log for the Tsreader Plugin ATSCmonitor.dll shows for the ZipCodePackets for a ~30 Min run, 18:56~19:24 EST earlier this evening :


The individual entries in the log for the ID77 all look like this(SCN value differs however), which exactly matches(for WKRC) what I've seen at any time the past couple of years I've been using atscmonitor.dll for ID=77 entries in the log :

In the TSreader Left Pane/tree list For ID77 --- I get something like this(currently with a "110" icon) :

On another note -- I have noticed some somewhat human readable text (URL's/etc) when using hex viewers on the data in those streams --- wonder if there is a way to tell anything/veryfiy anything about the listing data wkrc is sending from that?

Other than in case it is useful to others to give us an idea of what may be going on, I am hesitant to spend too much time or effort(or to ask anyone else to do the same) on this, given we have at most only 3 months or so left of listings...
Edited by Nitewatchman - 1/30/13 at 5:32pm

(reply to zerowords) Time has shown that when your DVR goes flaky a reset to factory defaults and then reenter you preferences is usually a good choice. Sorry, you will have to reenter your timers.

Unfortunately ROVI did not published structures of such packets.
SCN is sequential number; -> one ID77 packet registered -> 55 tables, 55 packets, total size 8635 bytes of ID77 accrued

Never paid any attention to this - but is it "normal" that in any given set time period (say, 30 minutes) there are substantially different number of ZipCode Packets sent? --

...such as due to bandwidth(not that the Zipcode packets are using much at all) being used for other processes(such as downloads /ID70/ etc )

For example -- one ~30 minute log from a few days ago(this one being during a download) :

And a 1 hour log run from jan 27 :

And the one from earlier tonight, ~30 Min run :

There aren't any zip codes in a zip code packet. My theory is that when you enter a zip code into a TVGOS device, it uses a lookup table to find the HostID for that zip code. Multiple zip codes in a city would all return the same HostID number. Large cities may have several HostIDs. The TVGOS host station sends out HostIDs in the zip code packet, which would make the zip code packet much smaller than having to send out hundreds of zip codes.

I have never been able to make heads or tails of the listing data. I suspect it is compressed, or encrypted, or both. Maybe P Smith has some insight into that.

Mark

After getting the sad news about ROVI killing TVGoS stream, all my curiosity went down.

Yes, it is normal. Zip code packets are sent out every thirty seconds, however they are not sent out during downloads. So during the day you can go up to 30 minutes without getting a zip code packet.

Mark

I do remember that here, (~Early 2009) when I first got the DTVPal DVR --- Listings for BOTH Cincinnati+Dayton Market stations(and more if I recall when tropo DX put other stations in the DTVPal DVR Guide) were provided by both (at the time) TVGoS host stations I received (WHIO Dayton+WKRC Cincinnati) --- I.e. If you used WHIO and a Dayton area Zip -- you still got TVGoS listings for Both Dayton+Cincinnati stations --- Same thing With WKRC and using a Cincinnati Zip ..... It may have even been that you could have used either Dayton or Cincy Zip with either station, but I don't recall, exactly ...

But, that changed soon afterwards ... Mid-2009 or so If I recall correctly it changed to the way it is now .... edit -- er, was until TVGoS streams disappeared completely from WHIO a few months ago/etc ...
Edited by Nitewatchman - 1/30/13 at 6:33pm

From the above it sounds like it'll be more trouble to resurrect TVGoS guide data in the Cincinnati area than it's worth. By the time anyone could figure out from the compressed and/or encrypted (but definitely misnamed) zip code packets which host ID(s) were being broadcast; and from the encrypted DTVPal firmware which zip codes correspond to those host IDs, TVGoS would be long gone anyway. In other words: aw, crap.

If a factory defaults with the correct zip code no longer works, I'd probably just throw up my hands, do a factory defaults with zip code 00000, and kiss TVGoS goodbye a couple of months early. Screw it.

I short while ago, I was watching from the cache and suddenly the remote became non-responsive. Not one button on the remote would work but the program continued playing from the cache. I mulled over my options for a few minutes, Finally I took out the batteries in the remote, let it sit for maybe a minute, popped them back in and all was fine. Posting this in case anyone else has this problem. Maybe it's a well known fix but I don't remember running across it before.

Good to know.

Now I've heard everything. Now we have to reboot our remotes

That's a good way to look at it. Best part is that the cache kept right on playing without skipping a beat so no time lost in trying to get back to where things locked up.