LONG delay in play from playlist?

For now, it's normal. When the firmware gets updated, it should improve a bit, but whether that will be a long term solution is anyone's guess for these older sat boxes. Notice that I have 3 of them, HR20-700, HR21-100, HR20-100.

D* is aware of the sluggishness of the user interface on many of their boxes, and they claim to be working on it. The problem (sluggishness) comes and goes (and has over the last year or more).

Only time will tell if they can fix it on anything but the HR24 and newer boxes. (and it's not completely fixed on them either)

The good news, is your box is probably fine. The rest of my comments is the bad news.

 

If what I bolded is true you probably had no need to put a 1.5TB hard drive in your HR. I would recommend using a 500GB drive instead as long as its of equal caliber, cache/speed/etc.

Unless you need all that storage space, larger drives are not necessary, and can be slower at least in my experience. My suspicion is that the larger drives use much larger indexes, taking longer to access. All that said, what 1.5T drive did you use? Makes/models do make a difference.

 

This has been the frustrating norm for sometime now.

 

Larger HDDs also have more platters, more actuators, and data condensed closer together than smaller HDDs, which means access time for a single file (and all of the other files on the HDD are not in play when accessing any single file) is probably about the same, possibly even faster on a larger drive. There is no bottleneck there; if there is a bottleneck, it is much more likely in the serial processing done by the OS in the CPU, none of which is affected by the size of the HDD.

I think any drive can read the entire catalog database and index on a full 2 TB drive very quickly, especially one that contains long media files rather than hundreds of thousands of small files. The largest percentage of what is indexed is guide metadata, and on a drive that has less than 5 hours of media, that percentage is about 99%. We're talking a few MB, and a modern HDD had 300 mb/s throughput and the capability to stream 12 HD programs simultaneously, so we are talking a small fraction of a second even on a full, large HDD, to read the entire index, even if simultaneously doing R/W for multiple program streams.

And of course when you play a program it does not read the entire index or even much at all of the index, it simply goes to the DB and locates the pointers for where that program start of message is, and starts streaming from there. Reading a small part of the index would be invoked if you were looking at info, cast and crew, etc., which you are not doing when you press "play". So, what happens when you press "play" is not handled any differently with a large HDD than a small HDD, nor does it take any longer.

Selecting the program in the playlist opens a page with info about the program on it, so that task does indeed read a tiny fraction of the index to get that info. But the delay is never in displaying that info, which means reading that part of the index happens instantaneously; by the time it takes to fetch the graphics page, the info is already there. Pressing "play" happens afterwards, and does not cause the HDD to go back to the index.

Indexing is a way of speeding access, not hampering it, and it does that by taking multiple pieces of info (usually the metadata) about, in the case of a DVR, a recorded program or program in the guide, and creating a single piece of info to represent all of that data, which has the effect of reducing the sheer number of pieces of info and size of that info that the drive needs to access to go to where you ask it to go. Its a cheat sheet for shortcuts to data written in short hand. DVRs index in the background to speed access time to events listed in the guide, primarily, and to the list of recordings and info about them, secondarily.

And "in the background" is the key, or operative phrase here. Pressing "play" is not a background task, and background tasks are paused and preempted by actionable tasks like button presses and record starts. So, theoretically, indexing and journaling and all other background tasks should not even be in play when you press "play".

That said, I see this problem on occasion as well. I also see that when I FFWD a program to the end in order to delete it easier, that it sometimes reaches the end and sits there in FFWD for as long as 15 seconds or so, before showing the "delete" dialog.

Does this, or the occasional pause at play have anything at all to do with the size of the HDD or how full it is? I really think not, knowing how HDDs work. And, knowing how the OS and microprocessors work, it seems more like a slowdown due to inefficient programming combined with a slow CPU with a small cache (which now has been retrofitted to support HD graphics which were never considered in the original design specs). DISH DVRs are snappy, and do not have these problems; they are not using magical HDDs, they are using the same HDDs that everyone else uses, including DTV, and including DTV subs that replace their stock HDDs. It's not the HDD, the size of the HDD, or how full the HDD may be, its the platform and the programming techniques used that mostly affect performance.

Bottom line, you pay an infinitesimal, microscopically-tiny price at worst which DOES NOT include a performance hit when you use a larger HDD or fill that HDD with programs, certainly not enough of an issue to consider that or anything else a "con" when considering a larger HDD.

 

Good post by TomCat...

I very much lean towards poor programming. My HR24-500 also has these long delays at times, and I have a stock HD in there.

Bottom line, I think DirecTV just doesn't know how to code well. It's unfortunately a common thing, not specific to DirecTV.

A few years ago, my DirecTivo SD DVRs had exceedingly poor performance in showing the guide. Horrible, actually. Up/down a channel could take 2-3-5-7 seconds. This isn't a complicated task - but someone at Tivo made a hash out of it (pun not intended). People were pulling their hair out, and putting in faster HDs and even soldering additional RAM to the board - somehow thinking that this would speed things up.

I knew that it was poor coding and said so. I got flamed for it, but months later Tivo released new software and lo and behold, the guide was positively snappy and remained so.

Some how, some way, DirecTV is in over their heads here. Since I have no idea how they work I can't comment, but I can see the results and it's not very pretty.

 

300 mb/s - Maximum theoretical throughput
130 MB/s - Maximum sustained throughput

for a WD AV-GP WD20EURS

 

Since the HD update, I experience long delays (5 seconds or more) every time I try to play something from the list while it is still recording. Playing items that are fully recorded never give a problem on my 24/500. It seems like the length of the delay is longer the longer the recording is scheduled to be.

 

Welcome to the program! Doesn't it get you fustrated? :eek2::lol:

 

I would also add that throwing the remote across the room will make you feel better temporarily, but is a poor long-term solution.