That would be very clever, seeing as the HDR's Ethernet port is 100Mbps top whack, then you have to account for protocol overheads, and the processing is not likely to be able to sustain such a rate. I suspect you are being told porkies.
No.
That sounds odd, as I can playback HD recordings without issue from one HDR to a second HDR when they stream at approx 9.5-11Mibps as shown in the WebIF/Sysmon - Network Usage graphs (I have package system monitoring installed). This was watching something like Avengers Assemble HD recorded from BBC1. During testing I noticed there will be stutters during the action sequences if the connection was lower than, say 9Mibps..
I think the max Mbps figure for a powerline/homeplug network relates to the whole set of plugs in the network. So the number of homeplug devices share the, eg 500Mbps connection. How many of these homeplug devices do you have in your network? What is the Mbps rating for them? Also how is the Xbox connected to the router? Ie via Wifi or another one of these homeplugs?
I tried this method and the test file (STV HDTV) shows marvelously. I cannot readily make this the norm, but I can induce the occasional trip-hazard if needed.
The Comtrends show some kind of measurement all the time and it's way up high as reported, whether I stream or not; the page refreshes periodically and the numbers fluctuate. I don't know how they take these measurements, but yes, they appear optimistic. Here is an example for those interested:
I downloaded the sysmon package and decided to copy the STV HDTV file across the boxes this morning, my idea was to extrapolate bandwidth from file size and duration. I can see graphs; can I see numbers?
Possibly, if you can read databases. The file in question is /mod/monitor/monitor.db, but it does not appear to be available for inspection via WebIF >> Diagnostics >> Database Browser. That does not mean you can't use sqlite at the command line, or copy the file out and examine it using sqlite (or something) on a PC.
It's been "a while" since I last handled a DB, I would have too much catch-up to do. I can see the timestamp of the last file copied for this recording on the CLI. I will do it again tomorrow, note down when I start and that should suffice.
As a rough guess your file took 40 minutes to transfer, its size is probably close to 3500MB.
dd bs=1MB if=/dev/urandom of=z-dummyfile1.mkv count=500 status=progress
- The folly: what do I get if I cross-transfer.
Did you risk turning on the X-box to see if that was indeed a factor in the problem
And what does your cockpit thing report? That's a lot short of 100Mbps!
Just going back to this.
We were able to watch it with no problems at all, not a single glitch.
I have now deleted this recording.
Your network is not coping. Maybe you're getting electrical interference from one or more possibly faulty device.
Not radically maybe, but copying is not bothered by fits and starts. For streaming, the average overall data rate might be sufficient, but if a break is long enough for the buffer to empty you get a break in service.
That's what I was trying to isolate.
At the times of test, the WiFi.
I use three plug-in timers: for the subwoofer, an evening light and some active speakers.
It looked like it. And it looked like it could cope with the boiler on too.
Yes.
Occasionally, yes.
So it should be doing better?
Good idea, but I don't need to; the sound drops out first.
Indeed. This is why I am wondering if the problem is delay or jitter (understanding of the buffers may be helpful here, but it starts streaming almost immediately, is my memory, so they may be small...).
That doesn't seem very likely, from a hardware point of view.
It doesn't matter how large they are, they only fill at the rate the data comes in and empty at the rate the data is consumed. If the data isn't coming in very fast, it won't get far ahead of the read. What can help is pausing playback for a few minutes - the buffers get a chance to fill up a bit.