WD TV Live Streaming (Gen 3) - MKV files - FF/REW at 8x and 16x not working properly

[Visor]

Hello,

I recently picked up a WD TV Live Streaming Player and noticed a problem with FF/REW at 8x and 16x speeds with MKV files. This problem only occurs while playing back video files using Mezzmo; playing back the same video files via USB or a network share does not exhibit this problem.

The issue is that when fast-forwarding / rewinding at these speeds, the video being displayed does not keep up with the time elapsed. For example, when I fast forward through the opening credits of a TV show, and then I hit Play after I see that the credits have ended, it turns out I'm a couple of minutes past the credits and well into the program itself.

I've tried all 5 of Mezzmo's WD TV device profiles, but the same issue occurs on each. I've also recently updated the WD TV's firmware but this didn't fix the issue. I completely reinstalled Mezzmo (recreating my database from scratch) but the problem persists.

I also own an original WD TV Live (Gen 1), and it doesn't exhibit this problem.

It appears that the "WD TV Live Streaming Media Player" device profile may need to be tweaked? Let me know if you need a set of logs from me.

Thanks,
Visor

[SLPopp]

Watch the status of the PC you are streaming from, I bet is says it is transcoding the file for the WDTVLive SMP. The profile that should be used is the on that has "streaming" in the description (can't remember exactly what it's called). FF/REW won't work if the file is being transcoded.

For what it's worth, I encode all my media in a format the WD TV Live Streaming Media Player (SMP) supports. I have the transcoding option disabled for the WD TVLive SMP, as I have also found the profile for it to be a bit messed up.

BTW - The Gen 3 player also supports True-HD and DTS-HD MA passthrough (DTS-HD MA after the latest firmware update) but your media needs to be in a M2TS file container (there may be one or two others that work, but I know M2TS works).

Steve

[Paul]

Excellent advice, Steve.

Visor: If still no success, then send us a set of logs and we'll see what's happening. Turn on logging (see http://forum.conceiva.com/showthread...nostic-logging) and restart your Mezzmo server. Reproduce the problem and then stop your Mezzmo server and exit Mezzmo. Zip up all the logs and email them to us at support [at] conceiva [dot] com.

[SLPopp]

Just re-read your post. If it works fine via a network share but not with Mezzmo it may be because I believe Mezzmo is a DLNA streamer, not a file sharer. The DLNA streaming has different protocols to optimize it for media streaming.

From what I understand DLNA doesn't make as many "checks" on the data being transferred because if a bit is wrong here or there it's no big deal, just a tiny glitch in the media presentation. It's all about throughput with DLNA. If a bit gets flipped here or there via File Sharing you can have drastic effects such as corrupt files.

I may be "out in left field" here but I thought I read something about that (DLNA vs File Sharing) when I first bought my NAS and I was trying to decide if I was going to use DLNA or File Sharing on the WD TV Live SMP (went with file sharing because DVD .ISO files can't be streamed via DLNA).


I am wondering if Mezzmo is streaming the data to the WD TV Live faster that it can update the video being searched of the monitor??

Steve

[Paul]

I am wondering if Mezzmo is streaming the data to the WD TV Live faster that it can update the video being searched of the monitor??

It may be possible that the network bandwidth is the cause - i.e. the home network connection (e.g. wireless, powerline/homeplug) may not be fast enough to deliver the video data when FF/REW.

[Visor]

Hi SLPop / Paul,

Thanks for your replies. Unfortunately, your recommendations were for things I've already checked, so I'll be sending Paul logs shortly.

I've already turned off transcoding for all devices, and confirmed that no transcoding is occurring for the WD TV SMP (Streaming Media Player).

98% of my material is in MKV containers, utilizing x264 for video and either ac3 or dts for audio. My original WD TV Live (Gen 1) happily plays all these files through Mezzmo with no issues with ff/rew.

I also researched DLNA vs. Filesharing way back when I bought my original WD TV Live in 2009, and I decided to go with DLNA because of the extra throughput (~75 Mb/s on DLNA vs ~35 Mb/s using SMB Filesharing). This helps for some movies that have high spikes in throughput, such as the evil alien broadcast scene in Monsters vs. Aliens or the Hitler-esque newsreel scene in 9.

There definitely isn't a problem with my network connection; as I mentioned in my original post, scanning via a network share is fine, only through Mezzmo is it problematic.

I also exchanged my WD SMP over the weekend, but the problem persists.

As an experiment, I remuxed a few of my problematic files from .mkv to .mp4, and low-and-behold, scanning at 8x & 16x went back to normal. So it appears to be a problem with how Mezzmo is feeding the WD SMP with mkv files vs. mp4 files. Meanwhile, I'm not converting all my mkvs to mp4s because, (a) half of them have DTS tracks, which are unsupported in the mp4 container, and (b) I have hundreds of video files that I've collected over the past 4-5 years that I'm not about to start converting all over to mp4.

At any rate, I will send Paul a set of log files with an example of a file experiencing this ff/rew issue. I'll also send him text files based on FFMpeg Info and MediaInfo details so that he can potentially identify any issues that way.

Cheers,
Visor