Hangs after playing MP4, AVI, or MKV files

Firmware: 2.01.86

Network setup: All Ethernet connection (no wireless), all PC machines on network = Windows 8.1 Client (not Server), files are on QNAP SMB-shared box. NFS is not in use.

WD box is NOT set to go to sleep.

Playing files on the local “server” QNAP box.

Problem: If I play an AVI, MKV, or MP4 file, I can play several of them in a row… If I stop playing and let the machine idle for a long time (overnight), when I go back to the machine, I can still use the arrow keys and exit button to back out of the file share menu, but I cannot play another AVI, MKV, or MP4 without rebooting the WD box. If I try to play another file, I get a blank screen with a spinning orange donut, and the title of the file I’m trying to play does NOT show up. (unlike normal playback, where the screen goes black, I get the orange spinny donut, and the title of the file I want to play shows up, THEN the movie starts). No amount of waiting will let the file start playing. Doesn’t matter what file I try to play, MKV, AVI, or MP4, the files won’t play. But (and here’s the really odd part), if I try to play a folder that has been ripped from a DVD, and contains the .IFO and .VOB files (etc), it plays just fine. But self-contained files hang the WD. I can back out of trying to play the hung file with Exit, but going back and trying to play the file again still hangs.

It’s the oddest problem and yeah I can reboot it every day but makes the WD box pretty much annoying as **bleep**.

Another weird thing is that if I reboot the box and play one MKV/AVI/etc file, then immediately play another, or let it “roll over” from one clip to the next in the folder, that works fine. It’s only if I let it sit for a while that it will need rebooting.

The other WD boxes I have in the house (I have 3), have older firmware and I’m not sure if they exhibit this problem or not. I will try that out this week and re-post.

Hi, I recommend you to contact WD directly on your case.

http://support.wd.com/contact/index.asp?lang=en

I want to know if other people are seeing the same issue. I found out this morning (via my 9 year old son) that it happens as well when going from one AVI/MP4/MKV file to the next, but less frequently.

my only thought on this

the WD is a DNLA device

meaning any DNLA network on your device can take contol of it, and use the WD for playback of media

now initially that doesn’t sound too bad

but that also means it’s possible for a 3rd party dnla server running maybe on the qnap or maybe even a cell phone to crash the WD

we’ve even had people accuse WD of copy photos from cell phones because they were displayed by WD, and the person could not get rid of the photo

well it was a dnla server on a phone, that kept taking over

so anyways, all that it’s just an idea, but I’d turn off any dnla media server that is not being used, including phones, tablets, etc …

well I have THREE WD devices on my network, each of them a DNLA device. Is this a problem? I also have a Yamaha stereo (fancy) that is a DNLA device. Why would these devices crash the WD box? Shouldn’t the DNLA implementation on the WD device be tested/proofed against random DNLA requests crashing it?

is there a log mode for the WD device, so I can see the last thing it was doing before it hung?

I don’t have anything to offer more than this:

My setup is identical to yours – I have several Live SMPs and my primary NAS is a Qnap TS-412.

I’ve yet to experience any problems like you describe.

I only offer this to say that there’s more to your condition than just that specific mix of hardware – mine’s identical to yours.

there’s no log mode or debugging mode available

a dnla device is not necessarily a dnla server, the WD SMP’s are not dnla servers, they are DNLA renders

what I’m suggesting is turn off any dnla servers you are not using

windows play to feature

check smart phones, they are common, particularly samsung’s galaxy line has a bad dnla implementation

routers sometimes have dnla servers on by default

qnap, likely has some dnla server

only way to access logs would be to hack into the device ,which some like myself do

but even then, you would have to tail the log files in realtime, because general if it crashes it will stop logging

and logs are stored in /tmp so once you reboot /tmp is wiped and recreated

and of coarse this is just a theory, but from what I’ve seen in the most common reason for they type of behavior

I checked my network. My router has UPnP turned off, there are no DNLA servers on my network, and the only network protocol being used is Windows, not NFS, and no Apple… Still hangs. Even the older firmware (1.X) hangs. I’m shocked nobody else is seeing this. I’m almost temped to put a different router on the network and/or switch to NFS instead of WIN.

ultimately up to you

but NFS gets my vote

typically NFS has better throughput and is usually more stable

No NOT ultimately up to me. This is a WD bug in their software and I’m tired of dealing with it and/or diagnosing it.

AngryAtWD wrote:

This is a WD bug in their software and I’m tired of dealing with it and/or diagnosing it. 

Quite possible, but unless they (or us helping) can reproduce it to narrow down what causes it to happen, it likely won’t get any attention.  

I’ve never had this issue, and from reading the forums, not many (any?) people have reported it.

I have litterally thousands of MP4 and MKV files; I reboot my player once in a blue moon  (Maybe every two weeks?)

The only consistently reproducible symptom like you describe is what happens after you try to play a “bad” file (whatever that means) the WD won’t play ANY file after that.   People are often able to find out what file’s at fault and fix it.

But given you’re saying that it happens 100% of the time.  I doubt ALL of your files are “bad” in that way – or are these internet downloads over which you have no control?

I’m sorry, maybe I wrote the details wrong:

On my network setup: Playing almost any AVI/MKV/MP4 file which has H264 or MP4 compression results in not being able to play any further of the same type of files - cannot play another AVI/MKV file after that. Hangs. This happens with the 1.X firmware and the 2.X firmware. but I can play DVD-based-rips all night long. The WD units will happily play any set of .VOB/.IFO files. But the unit will spin-donut on another H264-based single-file.

I tried this with the NFS system, and in addition to my QNAP box, I also have a SYNOLOGY DISKSTATION which acts as a file-backup of the QNAP system. Same deal. I’m going to try transferring the files to a disk drive and hook that up to the WD box next, so it won’t even be a network issue. I’ll try that tomorrow.

These ARE internet downloads, by the way, but I believe the bulk of them are in H264/some flavor of MP4 compression.

95% or so of my MKVs are h.264 (a/k/a AVC).   I don’t know what “MP4” compression is – all of my MP4s (or m4v’s) are also h.264.

There’s a few MKVs that have VC-1 compression instead of AVC, but not many.

My AVIs are mostly MPEG2 IIRC.

There’s HUGE numbers of reports of people downloading cr@p from the internet that is poorly / improperly encoded, or encoded in a manner that’s not compatible.

Just because it’s h.264 doesn’t mean the WDTV can play it reliably – it must be complient with the detailed specifications WD publishes.

bull. just because it might be a little off from whatever spec WD publishes doesn’t mean it should hang the g.d. box. if the box can’t play it, it should say so. Having to reboot the box is TERRIBLE from a user-interface perspective.

here’s my feeling about what’s going on: WD probably didn’t write the decoder themselves. Very likely the MP4 (H264/AVC/MP4 are all flavors of MP4) decompressor they licensed is hanging, waiting for some event to happen  that isn’t happening so it’s sitting there waiting, blindly. Most decoders out there are strictly asynchronous, meaning when you tell them to do something, it happens “later”, and you get notified when it’s done. Probably they’re waiting for this event to happen, and waiting forever. What they need is a watchdog timeout, and when it times out, when opening a file, the decoder is completely reset and the open operation is tried again.

how do I know this? I write software for a living AND I interface with and use some of the world’s most licensed MP4 decoder engines. I do have a clue about what’s going on here.

AngryAtWD wrote:

here’s my feeling about what’s going on: WD probably didn’t write the decoder themselves.  

You’re exactly right.  WD did not write the decoder.   The decoders are implemented in hardware, not software.  The software does have the splitters (which divides the audio / video / etc into separate streams) and playback control.  That’s about it.

AngryAtWD wrote:if the box can’t play it, it should say so.

So, do these numerous MP4 decoder engines with which you’ve worked scan the entire file for playability before attempting to play it?   Or do they just look at the headers to see if it’s as expected?  

The WD *does* look at the headers and *does* report if the metadata paramaters indicate that something is unsupported.   But if the bitstream is flawed, there’s nothing the WD can do to know that ahead of time.   Users would quickly tire if the box scanned the file for 15-20 minutes (for a 2 hour video) before playback started on the off chance something was wrong with it.

Yeah, while I agree that the WD could do better with exception handling, ultimately feeding the box garbage and getting a less-than-desirable result is a user error, not the player’s.   That’d be like filling your car bad gasoline and then blaming the engine for not running.   “Doesn’t matter that the gas was ‘a little off.’  The car should have told me that it didn’t like it before it quit and left me stranded.”

this sort of went downhill fast

yes, WD can do better with error handling

but Tony is right ths is hardware encoding/decoding not software

I already mentioned you have the option to crack in and do whatever you like to it

if you’re a software engineer that shouldn’t be to difficult, especially considering

I’ve already supplied a way for anybody to access device internals

http://forum.wdlxtv.com/viewtopic.php?f=23&t=8707

there is no way I’m going to dive down and crack open the device and look for bugs. This is a consumer device. I’m posting on this forum to let WD know that their stuff is badly in need of some error handling and to see if other people see the same issues. I’d sooner buy a media server and install it in the corner of my living room than dive down and investigate WD’s bugs.

Oh, didn’t see Tony’s reply… Tony, you really come across as an unpleasant know-it-all in-your-face kinda guy. Read my posts more carefully or read them at all. I will admit there are lots of compressors and decompressors on the market that do mess up the bitstream. they either encode it wrong or decode it wrong and god knows I’ve done my time trying to work around that. But I didn’t write that the file plays for a while then crashes, or that it plays but looks bad. It hangs upon OPENING the file. Doesn’t even display the name of the file it’s trying to decode. when it tries to open a new file, or perhaps it’s hanging trying to close the old file it’s playing, it needs to set some kind of watchdog and pop the stack on whatever is hanging up the whole thing. KillProcess or whatever. Are you a programmer? Do you know what I’m talking about? Yeah, I agree if it botches up somewhere into the file, then of course WD is not responsible for it being authored wrong.

I’m positive the problem is actually way more simple than that.  It’s probably stuck in a while( true ) loop, waiting for a flag to be set from the decoder.

I’m shocked the decoder is hardware, but then if it is, all the more helps bolster my guess. You tell the hardware “start decoding this and notify me when a frame pops out” and the decoder never gets back to the device. i’m not saying WD should be able to decode the file, I’m saying it should abort if it doesn’t start decoding in less than - oh - say - an hour. Plus, if I reboot the box the file that hung can play. So, WD should not only stop trying after a second, it should also reset the hardware decompressor chip to get it into a known state. The file clearly does play (all the way through), and certainly plays on my PC (and my phone and my ipad, and my android).

Hiya. I have seen this exact same issue for ages, across multiple firmware versions on the SMP. Symptoms are exactly the same (SMP has SMB mappings to shares off of a NAS, DVD ISO files always play but every so often MKV (or similar) files refuse to play - Spinning Circle of Death appears, and no image thumbprint etc appears. DVD ISO’s continue to be fine but MKV’s etc will not play until SMP is rebooted - then the self-same MKV files play with job issues - for a while at least :)).

Network set-up is different from OP’s - I use Live Hub (with attached USB drives) as SMB Nas (I’m cheap, I know :D) with SMP’s attached via switched wired LAN.

It would be great to get a fix, but d’ya know what? It takes all of 2-3 mins to fix with a reboot, so it’s one of the quirks which comes with using a media player - I’ve used loads, and they all have their little foibles.

AngryAtWD wrote:

Tony, you really come across as an unpleasant know-it-all in-your-face kinda guy.

Sorry you feel that way, but WOW.    This coming from the guy who at first seems to be agreeable to looking at specific network configurations:

  

AngryAtWD wrote:

 I’m almost temped to put a different router on the network and/or switch to NFS instead of WIN.

And then followed IMMEDIATELY by:

AngryAtWD wrote:

No…This is a WD bug…and I’m tired of dealing with it and/or diagnosing it.

bull. just because it might be a little off from whatever spec WD publishes doesn’t mean it should hang the g.d. box.

[I know all of this because] … I write software for a living AND I interface with and use some of the world’s most licensed MP4 decoder engines. 

That’s a heII-of-a-lot more “In your face know-it-all” than I’ve ever been toward you, so as long as you want to wear the same label, that’s OK with me…

AngryAtWD wrote:

… I didn’t write that the file plays for a while then crashes, or that it plays but looks bad. It hangs upon OPENING the file. 

I get that.  

And now that you’ve cleared up the progression of things that cause it, we can now see that the issue you’re describing has been discussed SO MANY TIMES that WD even has written a KBA article on it.

It’s usually not the file you’re opening – it’s the file you were watching before.

http://wdc.custhelp.com/app/answers/detail/a_id/6615/