DBSTalk Forum banner

Painfully long reboot times

1638 Views 24 Replies 13 Participants Last post by  TomCat
My HR21-200 decides to freeze every once in a while. Particularly when it is recording two HD shows while I'm watching an HD show. It loses its mind and goes grey screen and doesn't respond to any remote or button commands. So I do the old RBR....

Then I sit back and wait, and wait, and wait.... Now while I can understand the initial boot time where the OS loads etc, it's the "Getting information from satellite" that really irritates me. It can't possibly take that long to acquire signal and tune to a channel. The rest of the setup, downloading of guide etc., could be done in the background. That way I can get back to watching my show while the rest of the information gets acquired.

Is speeding up the reboot time on a wish list somewhere given how often this seems to happen to HR2x users??
1 - 20 of 25 Posts
msingh said:
My HR21-200 decides to freeze every once in a while. Particularly when it is recording two HD shows while I'm watching an HD show. It loses its mind and goes grey screen and doesn't respond to any remote or button commands. So I do the old RBR....

Then I sit back and wait, and wait, and wait.... Now while I can understand the initial boot time where the OS loads etc, it's the "Getting information from satellite" that really irritates me. It can't possibly take that long to acquire signal and tune to a channel. The rest of the setup, downloading of guide etc., could be done in the background. That way I can get back to watching my show while the rest of the information gets acquired.

Is speeding up the reboot time on a wish list somewhere given how often this seems to happen to HR2x users??
Heres a link to the wish list thread:

http://www.dbstalk.com/showthread.php?t=93995

If it isnt on there, sign up and let your voice be heard
msingh said:
My HR21-200 decides to freeze every once in a while. Particularly when it is recording two HD shows while I'm watching an HD show. It loses its mind and goes grey screen and doesn't respond to any remote or button commands. So I do the old RBR....

Then I sit back and wait, and wait, and wait.... Now while I can understand the initial boot time where the OS loads etc, it's the "Getting information from satellite" that really irritates me. It can't possibly take that long to acquire signal and tune to a channel. The rest of the setup, downloading of guide etc., could be done in the background. That way I can get back to watching my show while the rest of the information gets acquired.

Is speeding up the reboot time on a wish list somewhere given how often this seems to happen to HR2x users??
I agree, the step of getting satellite data is ridiculously long. I used to believe that was the step when the initial couple days' worth of Guide data as it (slooowly) streams in off the sat. However, since Guide data has been cached for quite a long while now, this can no longer be the case. :confused:
Psh, you guys need to try the Tivo based receivers if you think the HR2x boot time is long. The Tivo units are like watching paint dry. :p

Also remember that rebooting is meant to try and clear caches/reinitialize things to try and fix any issues that have caused said reboot.

I agree, even the HR2x units take a long time to boot, but it is pretty much the same story for any of the decent DVRs out there (Dish, Directv, Tivo) and even some of the crappier ones (Cable, etc.).
LameLefty said:
I agree, the step of getting satellite data is ridiculously long. I used to believe that was the step when the initial couple days' worth of Guide data as it (slooowly) streams in off the sat.
It's the first couple hours (not days) of guide data.

LameLefty said:
However, since Guide data has been cached for quite a long while now, this can no longer be the case. :confused:
Yes, that is still the case. Just because the data is cached doesn't mean it's still "correct". Those first couple hours of data must be "verified" in case some of it has recently changed.

And don't forget the DVR doesn't remember when/why it was rebooted. For all it knows, it was shut off for 5 days due to a power outage or you unplugged it for your 2 week vacation ... meaning it must interpret WHERE in that cache the current data is.

Also note that setting/verifying the "program listings" is not the only function of step 2. It also must aquire, decrypt, parse and set the current date/time along with remapping what channels come from which transponders for each satellite WHICH INCLUDES 100% of the local channels (SATELLITE AND OTA) across the country even though your receiver will only authorize one or two markets, not to mention internationals and all sorts of other channels you can't watch.

It's not like your guide just has a couple hundred channels.
It has a few THOUSAND channels!!!
;)
See less See more
And for the record, I usually time my reboots whenever I have to do it for one reason or another (excluding software downloads) and regularly it takes LESS THAN 7 MINUTES to get from red button back to live tv.

This is less time than it took my old tivo's to reboot.
Heck, my dad's WinXP computer takes longer to fully boot up!!!
The Motorola DVR's deployed by cable companies only take a minute or so to bring up live TV. However, all other functions, including guide, DVR, menus, etc., take significantly longer to be restored. I once had to wait a full hour after rebooting that box before I could access recordings on the drive! (Usually doesn't take THAT long, but it can still be a wait.) Although the box remembers no guide data, it somehow remembers upcoming recordings (shown as TBA in the to-do list). I've had a recording appear in the playlist as To Be Announced, since the guide didn't begin populating until after the show ended (the box was rebooted around 15 minutes before the half-hour show started).

Although I don't like the HR2x's long reboot time, I was even more frustrated by the Motorola box's very slow restoration process (which is at least partially related to the very early restoration of live TV viewing, since the rest of the init process must be done in the background with less CPU availability).
See less See more
dvdmth said:
The Motorola DVR's deployed by cable companies only take a minute or so to bring up live TV. However, all other functions, including guide, DVR, menus, etc., take significantly longer to be restored. I once had to wait a full hour after rebooting that box before I could access recordings on the drive! (Usually doesn't take THAT long, but it can still be a wait.) Although the box remembers no guide data, it somehow remembers upcoming recordings (shown as TBA in the to-do list). I've had a recording appear in the playlist as To Be Announced, since the guide didn't begin populating until after the show ended (the box was rebooted around 15 minutes before the half-hour show started).

Although I don't like the HR2x's long reboot time, I was even more frustrated by the Motorola box's very slow restoration process (which is at least partially related to the very early restoration of live TV viewing, since the rest of the init process must be done in the background with less CPU availability).
While at first it sounds like this is exactly what I'd want - quick restoration of the TV, the delay time to have everything else up and running seems excessive. While I realize that the box has a lot of information to gather, it just doesn't seem to be that difficult to run much of this in the background.

The steps I'd want the box to take are:

1) Startup.
2) Get rid of bogus/corrupted files and data caused by box shutdown.
3) Restore TV and channel navigation.
4) Restore scheduler information.
5) Restore Guide data.

The first 3 steps shouldn't take more than 1 minute post satellite acquisition. The rest can take up to 5 minutes for all I'd care. Since the HR2x is built on top of Linux, reboots should be far faster than what people experience with Windows :grin:
Supervolcano - I don't buy that as an excuse for the startup delays.

The system has a real-time clock. All it has to do is compare the RTC to cached Guide data. I would venture to assert that in most cases, it could be observed by the system that the date/time as of the system coming back up is not more than 20 minutes off from the most current Guide data, absent an extended power outage. From a usability standpoint, it is absurd to have the system totally non-responsive while it streams in Guide data again which it has already cached on the disk "just in case." Again, I would bet most restarts do not result in Guide data being substantially different for the next hour or so after the system comes back up to justify the delay in the startup.
Supervolcano said:
And don't forget the DVR doesn't remember when/why it was rebooted. For all it knows, it was shut off for 5 days due to a power outage or you unplugged it for your 2 week vacation ... meaning it must interpret WHERE in that cache the current data is ;)
It knows exactly when it was last up and running.... or if it doesn't it would be trivial to be able to do so, so you can strike that as a valid excuse for the long boot up time.

Also, almost half the time of the ten minute boot up time is spent on the "acquiring satellite data" step. If that is being spent acquiring the first day's (or more) worth of guide data, that could be greatly truncated and continued in the background after boot up was completed.
Supervolcano said:
It's the first couple hours (not days) of guide data.
It's much more than the first couple of hours. When I first come back up from a reboot where guide data was flushed, there is 24-48 hours worth of guide data present right after the boot up completes.
The reboot doesn't take too long..the need for them occurs way too often.
cartrivision said:
It knows exactly when it was last up and running.... or if it doesn't it would be trivial to be able to do so, so you can strike that as a valid excuse for the long boot up time.
Whether or not it "knows" when it shut down is irrelevant and wasn't meant to be an excuse in the way your implying.

My point is if the dvr was unplugged for 2 minutes, 2 days, or 2 weeks, it must run queries against the guide database to eliminate all programs prior to the current new time/date. Large queries against large databases take time to execute, and they are very processor intensive.

cartrivision said:
Also, almost half the time of the ten minute boot up time is spent on the "acquiring satellite data" step.
From red button reset to live tv takes under 7 minutes for my HR20-700, not 10 minutes. Please use a watch to time it next time.

Note - If you have a bunch of stuff in the todo list, it will take "extra time" above those 7 minutes to rebuild the scheduler, but that's STEP 3 (even though it technically doesn't SAY STEP 3 when it switches to that "rebuild scheduler" screen) and shouldn't be measured as part of STEP 2.

cartrivision said:
If that is being spent acquiring the first day's (or more) worth of guide data, that could be greatly truncated and continued in the background after boot up was completed.
Tell that to the first person who's scheduled recording doesn't begin ontime when his programs start time/date actually changed while his receiver's power was lost.
The dvr's "stability" has been taking a LOT of heat from this forum and directv users ever since it's release .... including currently .... and the only thing that speeding up the boot time would do is LESSEN that stability even more.

Personally, I want MORE stability, NOT LESS!!!
And I don't think I'm alone in that opinion.

Take whatever bootup time you need to create a stable environment.
7 minutes is fine for me.
LameLefty said:
The system has a real-time clock.
Incorrect sir.
The DATASTREAM contains the realtime clock.
There is no CMOS battery inside the current line of receivers.

LameLefty said:
All it has to do is compare the RTC to cached Guide data. I would venture to assert that in most cases, it could be observed by the system that the date/time as of the system coming back up is not more than 20 minutes off from the most current Guide data, absent an extended power outage. From a usability standpoint, it is absurd to have the system totally non-responsive while it streams in Guide data again which it has already cached on the disk "just in case."
Let's remember what the real purpose was for caching the guide.
It was done so you didn't lose the 14 day extended guide.
It wasn't done to speed up the boot.

LameLefty said:
Again, I would bet most restarts do not result in Guide data being substantially different for the next hour or so after the system comes back up to justify the delay in the startup.
While I do agree with "most restarts" it doesn't account for "all restarts".
And it doesn't account for a possibly corrupt guide cache either.
Post your re-boot times if you think it is taking longer than it should, so there is some guide to make comparisons.
My HR20-700 reboot time is about seven minutes.

I have no idea what my cable DVR reboot time was (I had cable with a DVR for about two years before I switched to DirecTV) as I don't ever remember rebooting the device.

I got rid of cable mainly because of poor Internet service and high price.
Grentz said:
Psh, you guys need to try the Tivo based receivers if you think the HR2x boot time is long. The Tivo units are like watching paint dry. :p
Well I guess mid next year we can start doing paint jobs on the side again.:lol:
Supervolcano said:
Incorrect sir.
The DATASTREAM contains the realtime clock...
Also incorrect, sir. There is also an onboard clock. Otherwise the data stream would have to pulse an update every second to simulate the time (although seconds don't typically display in user mode). DBS STBs use an NTP or SNTP server/client relationship, which implies a master clock (the NTP time server) at the uplink site, and that the STBs are clients, meaning that their onboard clocks get regular updates (unpolled in this particular configuration) from the server.

The transmitted time would be an inefficient use of bandwidth if the trasmit happened every second to simulate an onboard clock, but could be done every minute or so without increasing payload inefficiently, which would be more than enough to sync an onboard clock during bootup or otherwise. NTP on a network is usually set to poll when there is enough local drift, so polls can be as far apart as 960 minutes there, but since sat is 1-way, there is no polling and more-frequent updating.

The updating is of course to keep the local clock synced, since local crystal oscillators are notoriously innacurate and a free-running local clock is not practical. There are many threads about how the local NTP client service or NTPD daemon seems to either quit spontaneously or otherwise have issues keeping some HR2xs in sync, which proves that there must be an onboard clock, since it can fall out of sync. Rebooting restarts the daemon and typically resyncs the clock as well when this happens.

So there is no "realtime" (whatever that means) clock in the datastream, just regular NTP resync pulses targeted to an onboard clock. Bottom line, that does not contribute to the boot time.
See less See more
Mertzen said:
Well I guess mid next year we can start doing paint jobs on the side again.:lol:
Na, you just have to reorder your job work order...first go in and setup Tivo receivers and plug them in, then go outside and mount the dish, align it, peak it, run cables inside to receivers, setup other receivers, and then finally come back to the TiVo that will just about be ready to aquire guide data :D
:lol:
1 - 20 of 25 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top