[replayed]

I swear I'm not imagining things, but ever since I upgraded my 5040's stock drive to a new 7200rpm 8MB 200GB Maxtor a few months ago, I've noticed that DVArchive is putting a *much* greater stress on my ReplayTV during transfers.


Before the upgrade, it seemed like I could have 2 concurrent download streams going at 600 kB/s each, and my 5040 would barely flinch. But since I moved to the larger, faster drive with more cache, my 5200 is paradoxically crippled by even a single 600 kB/s DVArchive transfer. The unit now takes forever (we've talking 10 seconds or more sometimes) to respond to commands if I try to watch something while the download is going. I can kinda manage to watch a standard show already in myReplay Guide, but trying to watch a "live" program is essentially an exercise in futility as my unit takes forever to acknowledge a command before processing them in bursts if I happen to have keyed ahead. More damagingly, it sometimes takes the unit 15 seconds or more to initiate a scheduled recording should a standard-bandwidth DVArchive transfer happen to be in progress. So I find myself having to transfer shows from DVArchive in single streams of about 300 kB/s if I want my unit to be available for anything else while the transfer is in progress.


Everything else is better about the unit since the upgrade. Menus are snappier, scrolling faster, etc. But two things have deteriorated. The big one is the problem described here. (The other one is much more subtle and I can live with it: pressing Play from FF mode restarts normal play several seconds farther along the recording than it did before the upgrade. Weird.)


But again, I'm more curious about this sudden weakness in dealing with DVArchive streaming. I'd be curious to hear if anyone has noticed something similar in the wake of an upgrade or could float some theories that might explain this counter-intuitive behavior.

 

[SkiTyke]

Are you now recording at the high quality setting?


When I record in high quality then stream the shows off, my RTV behaves as you describe. Low and medium recordings do not cause this behavior.


Remember DVArchive looks like another RTV on the network. Each of the three quality settings requires a minimum bit rate to support smooth video, and the RTV will try hard to maintain that rate. Therefore streaming high quality programming is more demanding than streaming low quality.

 

[gduprey]

Its not DVarchive - it cares nothing about the size of your hard disk.

As mentioned, defaulting recording to high quality can have an impact on available CPU cycles (both when you are recording a show and when the ReplayTV is "just idling' (buffering live TV). It may be that managing a larger drive takes up a little bit more RAM in the ReplayTV, but I can't imagine it being a big deal. You may want to check that.


1 single 300KB/sec stream is generally what most folks have been reporting as what a RTV 5xxx can handle while remaining responsive. In fact, because so many have reported that, it is my recommendation in the DVA FAQ.

 

[replayed]

Quote:

In fact, because so many have reported that, it is my recommendation in the DVA FAQ.

Ah, I wasn't aware of that update to the FAQ. I'm still going by what I read in the original DVA guide lo all those months ago. Also, the options dialogue still leads me to believe 2 concurrent 600 kB/s streams are perfectly viable defaults, presumably for an active unit.


In any case, I just want to make it clear that I never record at High Quality, although I don't see that it would make any difference what quality show I'm transfering since the transfer bitrate is capped in DVA. And as I tried to make it clear, watching a "live" signal (which is of course being encoded at high quality) is indeed much more prone to unresponsiveness during DVA streaming.


I'm willing to abide by the 300 kB/s recommendation -- and the many folks who are recommending it may well have upgraded drives in their units -- but I just find it peculiar that my unit should have developped this suddenly low tolerance precisely when I moved to the larger, faster drive. Maybe the larger cache is somehow getting thrashed in ways the smaller cache didn't. Odd.


Anyway, thanks for the advice, Gerry, and for the wonderful thing that DVArchive is.

 

[burger23]

Easiest solution: Use DVA's built-in scheduler to download shows while you are sleeping.


I have been puzzled by this topic (downloading while using RTV) comes up. Why does the show need to be download while RTV is being used (recording or viewing a show)? The only reason that I can think of is that someone want to burn a DVD of a show NOW-- otherwise, just schedule downloads when the RTV is not being used.

 

[gduprey]

Quote:

Originally posted by replayed Ah, I wasn't aware of that update to the FAQ. I'm still going by what I read in the original DVA guide lo all those months ago. Also, the options dialogue still leads me to believe 2 concurrent 600 kB/s streams are perfectly viable defaults, presumably for an active unit.

The defaults are really for a 4xxx series which has quite a bit more horsepower. When DVA first came out, 4xxx units were all that there is and so this was the default.
Quote:

In any case, I just want to make it clear that I never record at High Quality, although I don't see that it would make any difference what quality show I'm transfering since the transfer bitrate is capped in DVA.

It wasn't so much the download speed as the extra effort the RTV unit has to put into encoding in high quality. If it's recording a show (or buffering live TV) at high quality, the process of encoding high quality video uses most of the CPU in the RTV, making other things (like DVA downloads of other shows and such) have a great effect (taking more out of a reduced pool of CPU resources).


Beyond that, I can't really explain the coincidence of you upgrading the hard disk and noticing the slow down, but I will say that all 5xxx folks I know of, with original or upgraded disks, have the same 300KB/sec recommendation for minimizing the impact on the RTV during downloads. It isn't, at least directly, attributable to the drive change as there are lots of folks with original drives and the same issues you noticed. Of course, there could be something special about your machine too - difficult to tell. But the outcome (i.e. capped download speeds) is very common/the norm for 5xxx series units.

 

[replayed]

Quote:

just schedule downloads when the RTV is not being used.

Yes, I already do all of that. And oh by the way, transfering overnight still doesn't address one of the pitfalls I described, i.e. that a scheduled recording can experience a significant delay in startup, enough sometimes to cut off the beginning of a program on a punctual channel.


But my main point has gotten hopelessly lost: I didn't start up this thread in the hopes of finding workarounds. I appreciate those suggestions, but I was hoping instead for an explanation of what I consider fairly counter-intuitive behavior. To wit, what is it about the stock 5400rpm low-cache stock drive that makes it so much more immune to concurrent disk activity than a high-end state-of-the-art drive?


I mean, am I the only one who finds it curious that Gerry could once blithely recommend dual DVA downloads at 614 Kbytes/s (and that I could once get away with doing just that with impunity) while nowadays a single 300 Kbyte/s stream is all a ReplayTV is expected to be able to handle with minimal side effects?


I'd be curious to hear from someone who still has a stock 5040 and could give DVArchive a spin to see at what transfer rate it stars interfering with the unit. But I take it folks around it here who know and use DVArchive are more likely to have upgraded their drives.

Edited: Ah, just saw Gerry's last post which addresses my last two paragraphs. If I hadn't given away my original drive to a friend, I'd put it back in just to make sure I'm not hallucinating.

 

[Wrecks]

That would be the next logical option for DVArchive: The ability to set different download speeds at different times of the day. Say, 400 or 500 during the wee morning hours when I'm asleep and 300 during prime time hours when I'm likely to be watching TeeVee.

 

[plyons10]

Quote:

Originally posted by replayed But my main point has gotten hopelessly lost: I didn't start up this thread in the hopes of finding workarounds. I appreciate those suggestions, but I was hoping instead for an explanation of what I consider fairly counter-intuitive behavior. To wit, what is it about the stock 5400rpm low-cache stock drive that makes it so much more immune to concurrent disk activity than a high-end state-of-the-art drive?

I'll be the first to say it... I've not heard of this ever before... and you are unable to reproduce these results (even if it is because you gave away the drive). So... I just don't believe that there is anything about the low cache drive, etc. It's more likely something else -- especially since you are the only person to have noticed this.

Quote:

Originally posted by replayed I mean, am I the only one who finds it curious that Gerry could once blithely recommend dual DVA downloads at 614 Kbytes/s (and that I could once get away with doing just that with impunity) while nowadays a single 300 Kbyte/s stream is all a ReplayTV is expected to be able to handle with minimal side effects?

Curious? Not at all.. it's because Gerry doesn't want to be held indirectly responsible for locking up someone's unit and the newer 5K series has a reputation for inconsistency and lack of horsepower in its hardware.

Quote:

Originally posted by replayed I'd be curious to hear from someone who still has a stock 5040 and could give DVArchive a spin to see at what transfer rate it stars interfering with the unit. But I take it folks around it here who know and use DVArchive are more likely to have upgraded their drives.

I've had both upgraded and stock machines.. now both running stock drives (it's easier to just add more storage to my PC and DVArchive everything). I've never noticed a difference in download speeds and would be very reluctant engaging in any sort of speed tests. The 5xxx series are just too quirky and it's not worth locking one up to test the highest speed.

Quote:

Originally posted by replayed Ah, just saw Gerry's last post which addresses my last two paragraphs. If I hadn't given away my original drive to a friend, I'd put it back in just to make sure I'm not hallucinating.

It's probably just as unlikely that you're imagining this.... But I really still don't think it's just the drives... is there any other process that you changed on your network, PC, or Replay that you can think of????

 

[replayed]

Quote:

is there any other process that you changed on your network, PC, or Replay that you can think of????

None that I can think of for certain. I used to use DVArchive fairly heavily before I upgraded my 5040. In fact, I used it to back up half the contents of my original drive right before I made the upgrade to 200GB. I was lucky and successfully copied all my shows over as part of the RTVpatch. So I ignored DVArchive for a few months until I filled up my 200 GB drive and started offloading shows again. That's when I first became aware of the need to throttle my transfer rate. I upgraded one of my client machines from Win98 to Win2K in the interim, but I kept my Linux box the same and it too pegs my 5200 in ways it didn't my 5040.


I appreciate that the performance I'm seeing right now is precisely what is expected. But I kinda feel like I stumbled across the secret of eternal youth with my old 5040 setup. Of course, I had no idea I had it at the time. And now that I'm looking for it again, it's irretrievably gone.

 

[plyons10]

I'd still bet good money that even if you got that old drive back it wouldn't be the same.


If I had an extra one I'd send it to you, but I"ve downgraded both my 5040s back to their stock drives and put all my big storage in my server.

 

[replayed]

You know, another thought (finally) occurs to me. Could the ReplayTV software have gotten poorer at handling multiple streams of activity? I can't pinpoint which software release might have introduced the sluggishness (maybe 5.1?), but is it possible that while tweaking the network section of the code, an inefficiency was introduced that makes 5xxx units somehow more sensitive to concurrent activity? Just a thought.

 

[plyons10]

Good suggestion... I too am ignorant of any recent releases however.