The Official AVS Dish DTVPal DVR Topic! - Page 473

Just checked this morning and my unit is at 265 days since last boot. Now if only any of my Windows machines could come close.

Nice. Yeah, computers love upgrading. Even Mac OS X and Linux require reboots for those system updates (e.g., Kernel). DTV Pal DVR hasn't updates forever so it doesn't need to reboot.

I'm not sure if the full F208 firmware release notes from Dish have ever been posted on this thread so I figured I would post them for anyone interested. I obtained these from Dish in July 2009 when F208 was released and I just came across them in a file folder on my computer. I am posting exactly what I received from Dish via email:

F208 Release Notes
The following issues have been addressed and are fixed in this release:
Stop PSIP time sources adjusting time when TVGOS time has been acquired. This is the behavior where the time is seen to jump back and forth when TVGOS is the time source.
Improved handling for inaccurate PSIP time sources, using a weighted mean calculation to select the correct time. Also added guards to handle daylight savings transitions being signalled incorrectly.
Initial time is now acquired from all available PSIP time sources during installation. Once (if) TVGOS time is acquired, this will be used as the time source.
Added secondary splash screen to notify user that unit is Entering Standby. This avoids the confusion for some after powering up a unit that was in standby before power cycling, this screen only appears in this situation.
Improved USB support - should now support all removable USB sticks.
Daily Schedule now lists repeating events correctly when the event name changes (Dynamically picks the event name for that day rather than copies the initial timer name)
Failed recordings now get reported correctly (with reason) rather than being reported as complete.
Removed a blank screen instance after stopping recording - only occurred when 2 Record Entire Event recordings were in progress.
Correctly display start time, end time and duration for Record Entire Event recordings in menus.
Removed long delay in audio synchronization after trick modes and pause.
In the Guide, the long No Information periods have been segmented into individual 1 hour periods, allowing recordings to be easily scheduled for times where program information does not yet exist.
Fixed an issue where corrupt timers were stopping the unit initializing. This should avoid the situation where the unit stops on the Loading Please Wait splash screen.
Added option to toggle the tracker bar off/on (using the CANCEL key) when using trick modes, or paused.
Added page forward/back in Program Guide using FWD and BACK keys.
30sec skip occasionally jumps to end of program (was fixed in F207).

As I had chickenpoopèdly deleted all recurring timers last Thursday, this morning's time change came and went with no effect except to advance the clock, and all my event timers and manual timers came through unscathed to be triggered according to Central Daylight Time.  After catching up with AVS Forum I'll replace those that recur with repeating timers.

Let me try again.
Question #1 - If I use a BlacX type external drive with its own power source do I still need to turn off (pull plug) the main unit (TR-50 ) when changing HDD in addition to turning off the BlacX unit?

Question #2 - Is the correct sequence to turn on the BlacX first and then turn on the TR-50 unit or does it even matter?

Thanks

A#1 - yes. I did try to bring easy analogy with a system drive of any computer ... Just try to make actions what you questioning (mentally !!!) with your PC.
A#2 - see A#1. No, it's a matter.
For turning OFF: TR50 first, drive - next; reverse order for turning ON: drive - first, TR-50 - second.

Here is gold rule of computerized electronics: before, turn on all peripheral devices: KB, mouse, GPS, drives, solar panels, etc; then turn [power on/reset] processing block.

Just timers set to record once. Not sure it will matter seeing as there was no problem with the clock or time on my 2 units.

Yeah, that's why you have no problems.

Just to clarify, there were no issues with the clock. It was correct before, and now after the time change. Only the repeating timers were confused.

Mark

That is correct.

I tried to set the Observe daylight time savings to NO but it comes back right away to YES.

Saskatchewan does not have DST. What can users of a CM-7000 DVR do?

Maybe set it for a different Time Zone...

Just a wild guess here, but try setting to a US Zip code in your time zone that doesn't support DST? Like Arizona. Saskatchewan is in mountain time zone same as Arizona right?

No, an hour ahead of Arizona.  Most of Saskatchewan is on CST all year.  A few areas along the western edge keep Mountain Time like Alberta and would have switched from MST to MDT yesterday morning.

I had a similar problem before the time actually changed. I can't remember what I did, but I remember that the solution was counter-intuitive. You will probably have to expirament with it. I think when I tried to change it I got a screen saying something like their record showed my area did have savings time. No matter what buton I clicked on it switched back to yes. I think what I did was to change it to no and then not click on any buttons, but just push the view live tv button on the remote. I think that left the system on stardard time. A day or two later I got a screen that said something like the system says it should be savings time, do I want to change it --I clicked on No. Good luck.

Just curious, is that very common? My CM-7000PAL has gone through 3 time changes since I bought it with no problems. I have many repeating timers, ten for weekly and 2 for Mon-Fri, and they have always worked. I have already watched a couple of these since the time change over the weekend. I also scanned the upcoming timers for the next 10 days, or so, and everything looks correct.

AJ

Perhaps your local station's contributing to the guide an accurate info during time changes ?

My stations sometimes mess up in the Fall, but usually they do better with the Spring DST change.

The PSIP datastream has room to enter 'day' of change, but not the month. A station can enter the day up to a month early, but not until after that day has passed in the month prior to a change. Last Fall, 2 stations entered the "6" flag prior to 10/6, and I had 3 bad times for recordings on 10/6 and 10/7. The stations fixed their time, but however the Pal handles such changes, the recordings ended up being adjusted twice, so they were off by two hours, instead of just one. All other timers in the guide were ok, and it wasn't until 2 weeks later when more bad times showed up that I realized the Pal treats long term weekly timers differently than near term timers (with attached dates). A number of long term timers (represented on the timer list by the 'double circle' repeater symbol) had been flagged "STD" and as they appeared in the guide, the times were all off. That double whammy is why some say just dump it all and start over after the time change.

There seem to be additional mysteries with time changes. Last week, I added a weekly timer for early Sunday morning, setting the recording from the guide. I checked later in the week and everything looked ok. But Saturday, I noticed that the time was not right. I checked the guide and saw the program info had changed, my program was no longer on. That wouldn't explain why the timer got changed, or why the scheduled recordings list showed a second channel due to record at that same odd time, and I'm sure I didn't set a timer for that channel. It just appeared with that same odd time.

This was my 4th time change since owning the DTVPal. This is the first time the timers screwed up before the time change. The first time change that I went through the timers were off after the time change. The next time change I deleted all my timers on Saturday and re-entered them on Sunday. The third time change I waited until after the time change, and some of the timers were off, so I deleted and re-entered all of them.

I've owned the Sony DHG for almost 6 years, it uses TVGOS exclusively (no PSIP capability), and it has never had any issue with time changes.

Mark

Timers off during DST changes.

See known issues:
http://www.avsforum.com/avs-vb/showt...p?t=1099071#A6

YMMV - seems that some markets are worse than others (or rather some may not have an issue at all for unknown reasons. A search of posts around the time changes will see the same consistent complaints for every DST change. This time, I did a factory reset, and redid all the timers on Sunday. Worked well. When approaching a DST change, you have to monitor the "daily schedule" to verify timers and correct (or replace) existing timers.

TVGOS for the Charlotte market is on one of our PBS stations (WTVI) and it has worked flawlessly, as far as timer recordings, through the 3 time changes since I bought my DVR. I have also never found the time to be off by a minute or more, which lots of folks apparently experience in other markets.

I better "knock on wood" before I hit the submit reply button!

That would add more weight to my point in post#14220.

There seems to be some quirks in installing it, but once it's set up it works well. At least, there are no reports to the contrary - yet. Still very new.

Of course, there are future enhancements not yet released: Seamless integration between 2 Hoppers in that configuration; OTA tuners via USB and Bluetooth wireless to headphones and some hearing aids.

I use a DTVPal on a 36" guest room SDTV that might get replaced by a Joey if I ever move to Hopper/Joey. But my DTVPal DVR I keep at an RV in the summers. I bring it home for winters, but based on the TVGOS comments, I haven't powered it up at home, where there is TVGOS. At the RV, just PSIP, which is quite adequate for our needs there.

I hope to get many years out of my DTVPal DVR! I'll probably sell my Sony DHG500 and keep the Pal DVR.

How old is your DTV Pal DVR today? I hope to keep using mine until the summer before I move to another home that most likely can't get OTA (still need to try a roof top antenna but even that might not work due to a huge hill/small mountain blocking the view), so most likely bye bye to DVR Pal DVR for me.

Hopper discussion moved to its own thread.

Not meaning to divert from technical discussions of the Pal past this post, but just a quick suggestion - if you're really considering doing that, I probably wouldn't wait too much longer, if you want a decent return.

Yesterday my PALDVR every so often would display a message saying it could not connect to the internet to update. Only thing is it is not connected to the internet and update is turned off.

However my TV is wired to the internet. I later discovered when I tried to use my PC that my internet connect was down. So how in the world does the PALDVR know the TV is connected to the internet? And why when the TV is connected would the PALDVR produce an error message if the connection is down? That would imply communication with the TV and my network through the TV?

Everyone but me know about this?

For me, I am still using a 20" Sharp CRT TV from 1996. Obviously, no Internet/network. DTV Pal DVR does not have Internet/network connected either and the update checker is disabled. I think it is just a weird glitch since its software can be buggy. I also confirm it doesn't have a valid IP address. Just ignore it.

Have you double checked that the the Updates option in the DVR is disabled?

I'm going to do a test (anyone on this forum with a PALDVR and a TV connected to the internet can do it). I will disconnect my router and see if the PALDVR gives me messages when that happens.

Although the issue I had was with my router hanging so disconnecting it isn't exactly the same issue. I could also wait for it to hang again and then no reset it and see how the PALDVR responds.

In any even I will be keeping an eye on this and report back.