*Official* WD TV Live Streaming Media Player Thread - Page 58

1.08.17 appears to be a significant release. I have tried this player and took it back due to slow navigation when using the Media Library feature and BD stuttering when streaming MKV and ISO files via a network share. Can anyone comment if any of this has been fixed/improved?

Thanks for the input WDFan. I can't figure out what is wrong. My router is a Linksys E3000
which which has a Gigabit switch (not using the wireless for this). Tried talking to WD support but they were no help. Do you know of a way to troubleshoot this?

^jsinco, I ran in to this issue with iso and mkv files as stated above. I tried both SMB and NFS shares with SMB shares having worse stuttering/performance than NFS. I also was using a wired network. I believe this issue has been a confirmed bug and based on the release notes for 1.08.17 it should be fixed. I do believe I read in previous posts that using a DNLA server and transcoding worked perfectly when streaming to this player.

Search for my earlier posts in this thread where I discuss and trouble shoot the problem. The Live-SMP has an issue with being connected to a GigE switch. When I connected the Live-SMP and the NAS through a 10/100 switch (no GigE switches in the path) all the stuttering over SMB disappeared.

And yes, DLNA streamiing .m2ts works perfectly -- even when connected with GigE switches. That is what I do.

Sorry to see it's not fixed in this firmware release -- I seem to recall writing the same thing about the last firmware release. Just for the record the Live+ has none of these issues in its final state, but did have them in its early firmware.

just got the SMP last week, could NOT get it to update firmware by itself, had to d/l on to a USB to update, still it wouldn't stream from PC. his apart I thought it a was pretty good piece of kit. However, the reason I bought it was to be able to STREAM. Earlier today though when I turned iton I noticed it was promting to update the firmware, result! Firmware updated 1.08.17 and the unit is streaming away happily. One problem though there is now no option to manually download 'content info' it will still d/l automatically, but it obviously never gets every thumb for every file. Is there another way perhaps?

I have just brought the WD TV Live. I was looking for an easy simply option for a 2nd TV.
I was wondering if any one else has issues playing videos in this Format?
H264 MPEG-4 AVC (part 10), 1280x720.
Decode Format: Planar 4:2:0 YUV 10-bit LE
(P010)

I am a noob to this, so be kind.

It shudders, pauses for 5 secs, plays 2 secs, shudders, pause for 5 secs, repeat.. I am playing from a HDD attached by USB.

I have a lot of Videos, of the kids fav shows in this format, and do look forward to redownloading in a new format.

Agreed... By Raw, I was meaning to suggest "unmodified." The only time I *do* modify the m2ts files in any way is using TSMuxer to "concatenatate" the various streams of multi-stream BDs into a single TS file, while stripping out the foreign subtitles and audio tracks.

Just a bit of personal experience. I find TSMUXER does a good job of concatenating the playlist if the number of segments in a seamless branching title are small (say around 15). It has been my experience that if the number of segments is "large", TSMUXER could have a problem with audio synch -- the audio is delayed a little bit with each segment join and the effect is cumulative. In an extreme case I had a title with ~100 segments that I joined with TSMUXER. By the time we got to the end of the movie the audio was almost a full second out of synch with the video.

Someone here on AVS told me that was a known problem with TSMUXER and suggested I use Clown_BD instead. Clown calls eac3to first to do the demux of the streams you want and join the segments together. eac3to does not have the audio synch problem of TSMUXER when there are a lot of segments. TSMUXER is then used to mux the joined streams into the final .m2ts file. Since then, I've never encountered an audio synch problem. So you might want to keep Clown_BD in mind should you ever run into the TSMUXER audio synch problem with a seamless branching title.

I used Clown_BD for all of my HD movies. I've never had an issue with seamless branching

thanks for the reply.i tried the subtitle button and it doesnt seem to work.it just tells me no subtitles.

Then you may have a bad subtitle file. Have you tried playing the files with VLC or some other media player?

Kelson, just for kicks I ran a couple of experiments on my stuttering problem. I re-wired my network through an older 10/100 switch (Linksys WRT54GS) and wow, the stuttering did indeed go away on the three movies I checked (Avatar, Star Trek 2009 and Taken). That is really weird. Sadly however I also tried my Live+ (latest firmware) through the GigE switch and it still stuttered. I am somewhat perplexed as to what to do as I would prefer to use the "faster" switch in my network.

^what I would like to know is why the GigE switch isn't transparent to the WDTV Live, could the WDTV being having trouble negotiating a 100mb/s speed for some reason and only connecting at 10? Something doesn't make sense, network experts, where are you???

10-bit is likely where your problem lies. And you mention kids, so I'm assuming you have animation encoded with the 10-bit color scheme, which is very slowly eeking it's way into software media players on computers. WDTV does not support 10-bit the last time I checked.

Hmmm . . . I had the Live+ and the Live-SMP wired side-by-side to the same switches and streaming the same high bitrate files from the same NAS units when I did my SMB streaming tests. While the Live-SMP choked horribly with a GigE switch, the Live+ cruised right along and played the files perfectly -- this is all detailed in my posts.

Interestingly, I brought this up months and several firmware revisions ago. Nobody else seemed to notice and it wasn't until recently that people are starting to discover the high bitrate stutter problem. My network backbone is GigE and I'm not about to downgrade that. My solution has been to use the DLNA server on my NAS units or Mezzmo on my Media-PC. All my BD rips are stored as BD.m2ts which is not transcoded by a DLNA server.

I guess I could be considered a network expert..

As you say, the switch should be completely invisible to the SMP; it shouldn't matter if the links are faster than the hardware.

My home network is pretty extensive. My SMP is connected to a NetGear GS108Tv2 switch (Switch 2).

That switch is uplinked to ANOTHER GS108Tv2 at the other end of my house (Switch 1).

*ALL* of my NAS devices (5 of them) are connected to yet another NetGear GS108Tv2 switch (Switch 3), which is uplinked to Switch 1.

So there are three Gig-E switches between my SMP and my NAS box (SW2 goes to SW1 goes to SW3); never had a problem streaming any high bit-rate content.

One thing these managed switches provide is visibility. I had a problem with slow performance on one of my NAS boxes when I first installed it. At that time, I had UNMANAGED switches. I suspected I had a cabling fault somewhere but with dozens of cables to look through, I didn't know where to start.

I looked at the error counters on the devices where I COULD look, and all of them reported clear connections. The WDs, of course, provide no way of knowing anything relevant.

So I just decided to upgrade the switches to managed switches, and immediately saw which of the connections were racking up errors left and right.

It took me about 3 minutes to narrow the problem to two bad factory-made cables, which I repaired, and the problems went away.

Visibility is key when looking at possible network issues; and the cheap-o unmanaged switches give no visibility at all.

So. yeah, the managed switch cost $30 more than the equivalent unmanaged switch, but it saved me at least that much money in time spent troubleshooting.

Plus, it gives me all kind of cool geeky reports as to where bandwidth is being used at the WDTV, like the attached.

^ So in your opinion, the stuttering issue streaming from a NAS is not a bug in the WDTV SMP firmware? This is the main reason I returned the box, other than the slow Media Library...

Well, there was a bug with MKV bandwidth that affected some users, but even that never affected me with stuttering, even though I could see that the bug was present by looking at network switch data. That particular bug was, indeed, fixed in 1.08 release.

So even though what should have been a 20 megabit per second BD Rip to MKV was using 70 megabits per seconds of NAS and Network bandwidth, I never saw a hiccup.

Could have been because my NAS is higher performance than some, with better caching, or that my network is much cleaner and reliable than some. I don't know.

But I would never state with certainty either way, because people's environments and media are always different, and different bugs will thus affect users in different ways.

But this bug:

http://community.wdc.com/t5/WD-TV-Li...n/idi-p/312872

was indeed fixed.

Might be worth another try since most all of my br rips are 1080P MKV. Any improvements in speed in moving through metadata and thumbs using Media Library Manager?

We've had this discussion before. You are not using the usual consumer grade switches but managed switches. I use the unmanaged Netgear GS108 switches. I can readily believe the managed switches are compensating for the issues in the WD.

I have assumed it is a firmware issue with the Live-SMP because the previous Live+ model also had these issues early in its firmware cycle. However, I'm starting to wonder -- after 7 firmware revisions the problem still persists with the Live-SMP. Perhaps they changed some network interface hardware which is now causing the problem. Reports of 10/100 devices having problems when connected to a GigE switch are not unknown.

Again, I only see this problem with high bitrate BD.m2ts files -- i.e Avatar, Tranformers I,II,III, StarTrek 2009. Bitrates well north of 30Mbps.

Yeah, I guess it's possible... I also have Star Trek 2009 in MKV format. No problems for me.

The only way to get at the root if the issue would be to do a network capture of your data streams and see what's going on...

I hesitate to post, as I only updated last night, but...

One thing I noticed was that navigation through my 800-odd films in Media Library appeared to be quicker.

Don't take that as gospel, it's just something I'm pretty sure I noticed.

I tend to move my cursor to the centre film on the page , then click next >>| to whizz through a whole page at a time. It used to 'stall' quite a lot, but last night I though it appeared smoother and faster.

I'll check again and report back.

Steve W

Kelson: If you can get into your NAS to look at TCP statistics, and you see a lot of TCP retransmits during streaming, then I would bet I know what's happening: The Gig Switch you're using doesn't have large enough buffers.

Any time a switch has a SOURCE connected at 1 Gig, and a Destination connected at 100 meg, the switch must be able to buffer all of the packets from the source to the destination because it has to transmit them at 1/10th the speed.

If it doesn't have enough buffer (128 kilobits is a good number) then it will discard packets. If it discards packets, then the TCP session has to recover from that.

And depending on how aggressive the TCP stack is, that recovery can drastically reduce performance.

According to the Specs posted on Amazon: On the GS108, there is a queue buffer memory of only 12 kbytes per port.

The GS108Tv2, by comparison has 10x that amount.



Not saying that IS the problem, but I suspect it is...

Thanks for the post Steve.

I'll have to go through the NAS menus an see if I can find that log. Your hypothesis sounds plausible, I'm not really that familiar with the internal workings of switches. But I have to keep coming back to point that the Live+, when run side-by-side with the Live-SMP, does not have this problem. So whatever the issue is, it's still within the Live-SMP.

Although it is a pain for some, at this point it is a curiosity for me since I do all my BD streaming via DLNA and would continue to do it that way even if the problem were fixed. When the time comes that I need to buy another switch, I will be taking your lead and buying the Netgear managed switches.

Bingo. Smoking Gun.

See the attachment. This is a snip of a wireshark capture from my WDTV reading an MKV file.

The TOP red box highlights a BUNCH of full-size packets being sent from my PC to the WDTV -- there are 45 in all! If they were all full-size packets, that'd be roughly 45*1448 bytes, which equals 65,160 bytes.

This is confirmed by looking at the last few packets, the one highlighted indicates "Bytes In Flight" is 63,712 bytes.

That's 5x the capacity of your switch's buffers.

I'd about bet you'd have a bazillion TCP retransmits.

BTW, most NAS devices won't have that in the GUI menus... You'd need to look in the CLI, something like this:

... my NAS is reporting zero retransmits. "0 segments retransmited"

So as to why the Live+ doesn't exhibit this issue, I've only one guess: It's not using optimized TCP connections like the SMP is using. I'd have to dig out my old Plus to see if that's the case.

Nice work, WDFan. But what's optimized in this context and how does it mess up the transfer?

It's just conjecture on my part, really... My guess is that the Plus uses a much smaller TCP Window Size, which prevents as many "Bytes In Flight."

I would have to see KELSON'S Wireshark captures to see what's really happening; I don't have any unmanaged switches to test against.

If the TCP stack starts seeing lots of lost packets (due to buffer overflows), TCP is supposed to narrow the "Sliding Window" size, which reduces the amount of data being sent in any one instance, to prevent that from occurring. The TCP protocol should adjust itself to that. Perhaps the SMP is not doing that correctly, and that WOULD be a bug. But it would be such a low-level thing I doubt anyone ad WD would have a clue what to do about it.

Oh, and what s optimized is the Samba stream. Samba sees that session as 64Kbyte segments, which lowers the Samba overhead a LOT. Using smaller segments increases overhead, but so would lost packets...

Even though I don't need it right now, you are making me temped to buy a GS108Tv2. It's only $25 more than a GS108.