WDTV Live sudden stop in MKV playback

This is directed towards those many users that have opted to stay with FW version 1.05.04V, and my apologies for the length of this post.

I have created an MKV backup rip of a recent Bluray film and ran into a peculiar problem.   About 110 minutes into the film, the player suddenly freezes at a particular action scene, either bailing out back to the folder, or restarting the movie from 00:00.  It happens exactly at the same spot each time, and a Mediainfo dump doesn’t reveal anything fishy.  It happens whether the player is set to auto-framerate (where it auto selects 24Hz) or fixed at 1080i or 1080P.  The movie plays perfectly right up to that point, and, if I stop and FF past the bad spot, continues with the remaining 21 minutes without incident.  When played with VLC or the playback engine within Avidemux, the playback pauses for about a second at that spot but carries on from there, similar to the layer switch pause when playing a DVD disc.  The toolchain used was MakeMKV and Handbrake, with a final yielded file size of a reasonable 4.74G.   The bad spot appears very close to 4G into the file, which, perhaps not coincidentally, is the boundary that Handbrake sets for Large File Size select when ripping to MP4.  It is unclear what the tool does for MKV since the Large File Size button is made unavailable with very little explanation.

I intend to re-rip the disc when I get the time since I ran into this before with another BR and fixed it that way without investigating.  Curious to what could be the problem, I opened the MKV in Avidemux.  Scrolling up to the bad spot (an action sequence taking place on the world’s longest and evidently abandoned but lit runway ;-), a frame-by-frame stepping through the bad spot quickly revealed the flaw.  Handbrake had recoded the film with I-frames every 1.5 to 1.6 seconds, filling in between with approximately 30-40 P and B frames at 42millisecond intervals.   At the bad spot, the bounding I-frame distance jumps to 2 seconds, but more critically, there are only seven P-frames forward from the preceding I-frame to the next I-Frame.  Between the seventh P-Frame and the following I-frame, there’s a 1.7 second gap that should have contained around 40 P-frames.  The Live player appears to choke before that last P-frame, revealing a decoder prefetch of about 4 frames.  To be fair, the little NBOX N33 I own also trips up at the same spot in the same manner, but it’s a cheap low end box about 1/3 to 1/2 the cost of the Live; I expected better from the WD product.

The fact that VLC and the CODEC within Avidemux are both able to tolerate such a frame loss gracefully serves as an example to WD how a dedicated media player should treat minor file flaws such as this.  I don’t know if any of the 1.06 generation FWs improve this but have doubts since many of the 1.06 changes focus on UI and app “improvements”. I haven’t pursued WD support for this since I refuse to use any of the 1.06 firmwares that, in my opinion, are fundamentally flawed for reasons I have discussed elsewhere on this forum.  My only option is to inquire in the Handbrake forum why there’s a frame loss in MKV compilations that appears to coincide with the 4G boundary.  Since most of my backups are well under 4G size, I rarely encounter this problem but at least now I know what is happening.

Software players who can handle bad files pretty well do NOT serve as an example to a limited hardware player. If you don’t want to try the 1.06 firmware despite being able to downgrade anytime you want, your only option is to use an encoder that creates proper files. There’s many to choose from: Staxrip, MeGUI, Hybrid, XMediaRecode, Ripbot264…

What handbrake version are you using?

@ Cocovanna

This was created using Handbrake 0.9.9, either .5470 64-bit vesion or .5530 32-bit version, don’t remember which one.  The orginal rip was done with MakeMKV 1.8.6 (Beta). Conversion settings in Handbrake were H.264, Framerate-> Same as source, Constant framerate, Quality setting 20,  MKV file output.


Although I appreciate the list of alternate tools you provided, I prefer using the toolchain I am most comfortable with, and will participate in its improvement.  As for my refusal to upgade one of my players to 1.06, I am well aware of the available options.  However, I endure Flash rewriting this product with white knuckles at the best of times, and prefer to avoid the probability of a bricking.

Finally, I must respectfully disagree with your retort to my assertion that PC based media players should be an example to WD.  I won’t waste our time here on a bogus debate over Hardware vs Software players, however, I acknowledge your underlying point being to fix the broken media and not the player.  My point is, for a device whose sole purpose in life is to play media of all types with tremendous flexibility, it is disappointing that FREE media player software running on a general purpose platform (i.e.:PC) behaves better with minor flaws in the media stream.  If I happen to play a file with a flaw in it, I’d rather find out about it in some benign way like a brief pause in playback.  A high quality player should be able to deliver best effort playback with imperfect media.  I’m sure many on this forum are with me on that point. 

Merry Christmas All

@ RPH_16by9

Appreciated that you disected, sliced and diced what’s going on with the video file in question, etc.  So, is this problem video file , say one bad out of 100 good ones, or even more?  If it happened to me, I would not get all uptight about it; this video ripping, transcoding, etc is a lot of mumbo jumbo - hocus pokus with free tools for the most part, anyway, and I am basically glad it even works most times at all.  So, if the digital file doesn’t work, I would just play the DVD or BD, and not fret about a failed digital copy or dwell on it.  Life is more important than that.  Just my opinion, and how I would handle this, that’s all.  And, if a file created is a biggie, good to know I can expect some issues.

As luck would have it, I acquired a Live Plus recently and it came installed with 1.06.42_B, so before reverting it back to a “working” load, I tried my broken media file; no surprises, the player bailed at the same spot in the same way my 1.05.04 Lives do.  Considering the point made by techflaws, I’m not going to hold WD responsible for the Live player’s inability to handle flawed video files as gracefully as VLC or other PC based media players. 

Incidentally, the file was not broken by Handbrake, but somehow got corrupted either during the wireless transfer from my laptop or perhaps later by the Live.  The original Handbrake output file actually contains the missing frames and plays fine, even though the broken file reported the same size and playback length.  I re-transferred the file, this time using a USB stick, and goodness has returned to my household.


Kind and calming gestures, but really unnecessary as my 30+ years of designing electronic systems and gadgets has not spoiled my appetite for learning new things, such as the structure of video files and using video editing tools.  Contrary to getting bent out of shape over playback issues, I rather enjoy such challenges and in helping improve products that I use almost every day.   I wouldn’t bother to post my experiences here if that weren’t the case.

PS - If anyone is looking for firmware loads to roll back with, WD appears to have deleted all traces of the Live and Live Plus firmware archives from their website; perhaps they were running out of storage space? (sorry, couldn’t resist the hilarious irony ).  I managed to find the 1.05.04_B upgrade image (not the rollback) on the Wayback Machine, although I may stay with 1.06.16_B since the TV this unit will be driving can’t utilize the auto-framerate feature anyways.

So are you telling us now that you had a good copy of this file and you never made an in depth analysis of that original or even tried it to see if it exhibited the same problem.

So in the end probably nothing to do with the player even though I see you do try and implicate it in the damage.


I normally clear ripped and processed files from my PC after transferring over to the media player storage.  In this case, as I went about to re-rip the disc, I discovered that I had forgotten to clear the Handbrake file off and was unaware I still had it while examining the bad file I retrieved from the media storage.  The first thing I did with that file was exactly what you pointedly suggested, only to discover that the missing 40 frames were intact.  I immediately recopied the file to the media player storage, and sure enough, the Live no longer bailed at that point.  My apologies for not revealing these evidently important details in my last post.

I do not know how the file got buggered up, especially since it reported the same size and play time (to the second) as the good one; it could have been the transfer operation across my network, the media drive, or, could still implicate the Live player as you so astutely observed.  In my view, I’m glad this happened since it revealed a significant difference between the Live player and VLC with respect to minor media file faults, and, if it happens again, I’ll know what to look for.   As I mentioned, I don’t hold WD responsible for the player’s capability (or lack thereof); case closed as far as I’m concerned.


I prefer to stay with 1.05.04_B for my Live Plus, it is stable and working well version, and all subsequent ones are not.  I have both the original and rollback versions saved on my PC and can post them in a cloud server for anyone who wants it.  Send me a PM if you do.

I too have had the exact same problem, freezing, stuttering after about 20 mins, the solution for me was to use TVersity and use this as a media server, works great, plays the whole film start to finish without problem…


Peters04 wrote:
I too have had the exact same problem, freezing, stuttering after about 20 mins, the solution for me was to use TVersity and use this as a media server, works great, plays the whole film start to finish without problem…


No disrespect meant, but that doesn’t sound like the same problem at all.