Tutor
•
7 Messages
Wireless multi-room sharing
I have three DVR's, one hard wired, one powerline, and one wireless. The hardwired and powerline can see each other and share no problem. The wireless cannot get internet access.
Question: since I am using WEP security, wouldn't I need to input the password to enable the wireless DVR to access my home network? If so, I have a problem because I cannot locate a place to input the password. Or, will wireless sharing be available only for open (unencrypted) networks?
Question: since I am using WEP security, wouldn't I need to input the password to enable the wireless DVR to access my home network? If so, I have a problem because I cannot locate a place to input the password. Or, will wireless sharing be available only for open (unencrypted) networks?
midiwall
Tutor
•
8 Messages
15 years ago
I searched around (before I posted even! :)) and found the "l o o p" fun. dang..
0
0
midiwall
Tutor
•
8 Messages
15 years ago
(looks like describing what a vacuum does (s u c k s) is a bad word. {is lousy} works though)
I fired up MRV at home this morning, got the stuttering, and started wandering the forum and fired up a protocol analyzer. 30 seconds with an analyzer can show a lot. 🙂 The issues with MRV on wireless has nothing to do with _wireless_. It has a LOT to do with (what I see as) a real poor implementation of streaming.
The echo on the forum seems to be "wireless {is lousy}; DTV won't support it at release; run CAT5". That's a silly bandaid around a design issue. The issue here is that what DTV is doing with MRV is VERY ACK/NAK chatty, and that's a poor design of a feature.
"ACK/NAK" doesn't fit with wireless (for high bandwidth applications like streaming) because of the propagation delay. I suspect DTV is depending on the CPU in the "server" DVR to handle the transport controls of PAUSE/REW/FFW and they wanted to provide a quick user experience. That's not how to handle streaming, because it requires... an ACK/NAK heavy interface.
The right way to do this is to put the onus of transport controls on the client side, and implement a FIFO buffer managed by a thread on the client. If someone wants to FF past the end of the buffer, then you stop the buffer thread, do the math for the seek, and seek on the server, and restart the buffer. It's not rocket science, it's old-school buffering.
I figure that once the DTV "engineers" saw the issue on wireless, they just figured that the easiest thing to do was to start a rumor about how wireless {is lousy} and let the community propagate it. That's very sad... Though it probably comes from them being under pressure from marketing to get this out. No one had the time to go back and fix it.
The easy fix here is to vastly increase the size of the buffer on the client side, that would buy their protocol time to handle the chatter with the server and stop the stuttering. But, memory is short on these boxes, and I'll bet they implemented this by feeding into the standard playback driver, which of course was designed to stream from a local harddrive.That would explain the stuttering, which comes from the buffer not being large enough to handle the delay in getting the data from the server.
fwiw, my two Roku N1000 video boxes have NO problem streaming 720p HD content across the same network that my DTV HR20's are on. This is not a problem with "wireless".
sigh... I had such high hopes for this, and (we all) waited so long for this...
0
0
greywolf
Professor
•
3.9K Messages
15 years ago
0
0
dcd
Expert
•
20.7K Messages
15 years ago
0
0
midiwall
Tutor
•
8 Messages
15 years ago
Umm, I said that the "transport controls" should be the responsibility of the client, "playback" is a pretty broad term.
I'm unclear as to at what level you're saying the client doesn't have "playback abilities". Clearly the data from the server to the client isn't analog video 🙂 so it must be ("should" be) the raw MPEG4 data from the server. If so, then the interface on the client side should just be changing the data stream that the MPEG decoder is drawing from. Instead of local disk, it's a network source.
If the the driver is designed right, it shouldn't care where the data came from.
It's the same concept as connecting to a drive through a local IDE/SATA/SCSI connection versus SMB, NFS or Samba. It's all invisible to the application layer (in this case, the playback driver/MPG decoder), you map the drive, point to the file and say "go".
0
0
bimmerdude
Tutor
•
4 Messages
15 years ago
0
0
greywolf
Professor
•
3.9K Messages
15 years ago
0
0
bimmerdude
Tutor
•
4 Messages
15 years ago
Thanks again!
0
0
midiwall
Tutor
•
8 Messages
15 years ago
Good luck!
0
0
bimmerdude
Tutor
•
4 Messages
15 years ago
Thanks again!
0
0
litzdog911
ACE - Sage
•
46.4K Messages
15 years ago
The red circle usually means that another DVR or HD Receiver on your network is accessing that DVR's recordings. The DVR can only stream video to one device at a time.
0
0
mwa96imp
Contributor
•
3 Messages
15 years ago
0
0
bimmerdude
Tutor
•
4 Messages
15 years ago
0
0
dcd
Expert
•
20.7K Messages
15 years ago
0
0
midiwall
Tutor
•
8 Messages
15 years ago
---
As I mentioned above, this is a falsehood. There's is nothing specific to wireless that creates burst data traffic. My Roku boxes present 720p 5.1 streams just fine across a wireless network. Please point me/us to the DirecTV2PC forum and I'd be happy to explain this all again over there.
I've been writing network based applications since there were networks to write for, and I've written TCP stacks from the ground up. I have NEVER had to code specifically for a wireless network.
DirecTV engineered MRV totally wrong, it's very apparent to those folks that do this for a living.
0
0