Hangs after playing MP4, AVI, or MKV files

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/

Oh jesus. Wish you had pointed me to that earlier. That explains it then. There’s a KB about this and they ADMIT the internal service crashed? So… when they detect the internal service crashed, they can’t reset it? Wwwoooowww. And I thought my programming was bad. Even I have a routine that hucks the current decompressor and creates a new one from scratch if the old one crashes. I praise WD for attempting to play lots of different types of files - it’s what distinguishes the WD box from other ones on the market. But I ding them big time on simply hanging instead of trying to reset stuff and play again.  This bug IS fixable, but I seriously suspect it’s end-of-lifed or something.

So now what - install Plex on my QNAP box? ha ha.

AngryAtWD wrote:

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.

 

if your point is for WD to recognize the problem, then you’re going about it wrong

this is a user forum

if you want somebody from WD to look at this

you have 2 options

post an official issue report here http://community.wd.com/t5/WD-TV-Live-Streaming-Issues/idb-p/streaming_issues

or call wd tech support

no, I didn’t search enough when I made the post, WD knows about the issue already, they just aren’t fixing it. All I really wanted to know if other people had seen this, and if there was a work-around. Apparently, there’s lots of stuff that can crash the WD service and they (WD) aren’t really paying attention or fixing it. Corrupt files, badly authored files, DNLA servers on the network sending out bad packets, UPnP packets being sent from QNAP servers, the list goes on and on. What’s pretty clear is that WD’s decoder service is FRAGILE and we all just have to put up with it.

My best bet now is to go home tonight and see if my QNAP box is doing some kind of uPnP port forwarding. I doubt it is, and I think my router is set with uPnP turned off. I’ve never really understood uPnP, and figured it’s a huge security risk to turn it on. But if my router has uPnp turned off, will other stuff on the network still try to send uPNP packets, and if they do, does the router strip them? I have no idea. Anyhow, it’s worth a try.

yeah, I’ve never been a fan of DNLA or UPNP from a security standpoint

basically, allows 1 device (server) to control another device (renderer)

most consumer router’s disable upnp only applies to request from WAN,

it likely does’t do any filtering of LAN traffic

qnap, I know they have severs

so does synology

but I doubt they are enabled by default, they should be off by default

the biggest culprit with upnp/dnla is phones and tablets

AngryAtWD wrote:
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.

 Except of course from the obvious fact that decoding is done in hardware. You needed an upleasant know-it-all-in-your-face-guy to enlighten you about it.

AngryAtWD wrote:

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

Look who’s talking. Actually, Tony is one of the most helpful and friendly guys I’ve ever met on the forums. He’s even putting up with guys like you rather than telling you to shove it as pretty much everyone else would have done.

AngryAtWD wrote:

no, I didn’t search enough when I made the post

You don’t say! And guess what, it’s still an issue with your crappy files. If you don’t use crappy files, this bug can’t even turn up.

  1. So what if it’s a hardware decoder instead of software. Still might use callbacks that happen on a different thread. Still can be reset. In fact, easier to reset if it’s hardware. This doesn’t prevent WD’s software from being crappy and doesn’t mean it’s NOT an easy fix. I can’t even imagine why WD shipped with a h/w decoder chip, considering all the flavors of codecs they wouldn’t be able to decode and CPU power is cheap and easy. Surprised.

  2. I *hate* having to get online and post a question, knowing a bunch of self-proclaimed **bleep** will only partially answer my question and then act like it’s MY crappy files that keep WD from fully testing their decoder. I’m not allowed to write software that hangs. I have to put my software through a team of testers that bangs and bangs on it until it (a) works for everything we throw at it, or (b) says “I can’t play this”. WD is shipping a commercial product, not some beta-board-for-testers. I shouldn’t have to crack open the device and debug it OR have to reset it every time I want to play another file, just because the file flavor is slightly off from whatever format it claims to decode. Trolls.

  3. the WD box locks up for many many variants of files, from a wide variety of sources. Plus, it now locks up on stuff it didn’t lock up on before.

  4. TechFlaws, Tony - do me a favor and don’t reply to this post any longer. Let somebody useful reply, or somebody who has more insight or experience or something more useful to say than “nyah nyah it’s your crappy files”. Thanks

so far we’ve got to theories

  1. UPNP/DNLA

  2. bad files

how about you put a bunch of files on USB drive and completely disconnect the WD from the network

if you’re able to watch everything on USB drive while not connected to the network

then the files are not the problem

if you still have issues playing the files from a USB drive even when completely disconnected from the network

then the problem is the files

AngryAtWD wrote:> Trolls.

I’m sorry that you feel you have to resort to name-calling, but, did anyone try to tell you that there is no bug?   No problem?  No, so what on earth do you expect us to do?  Fix the bug?  We can’t.  We are not the software developers.

We have offered you one of the few solutions we can – stop feeding your box flawed files and the bug won’t present itself.  You’ve already vocally refused to do any other isolation or troubleshooting, which is of course your own choice.

Short of that, the only thing you can do proactively is open a tech support case with WD, and then come back and complain (if you so desire) that they aren’t fixing your issue.   I don’t think anyone will argue with you on a point like that.

I already agreed with you that WD could do a better job with error handling.  Yet you still resort to insulting me simply because I’ve offered you the ONLY suggestion I can offer.

AngryAtWD wrote:

…I can’t even imagine why WD shipped with a h/w decoder chip, considering all the flavors of codecs they wouldn’t be able to decode and CPU power is cheap and easy. Surprised.

Surprised that you’re surprised.   *EVERY* set-top-box media player of this vintage and price range use hardware decode.

AngryAtWD wrote:

  1. So what if it’s a hardware decoder instead of software.

So what if you keep using an argument from authority while at the same time knowing next to nothing about the device you keep whining about? Impressive.

AngryAtWD wrote:
4. TechFlaws, Tony - do me a favor and don’t reply to this post any longer. Let somebody useful reply, or somebody who has more insight or experience or something more useful to say than “nyah nyah it’s your crappy files”. Thanks

Captain Obvious -  do us a favor and don’t expect anyone to treat you any better as long as you keep acting like a clueless jacka$$. Thanks.

KAD79 wrote:

if you still have issues playing the files from a USB drive even when completely disconnected from the network

then the problem is the files

We’ve already established that, no? The genius admitted that WD’s knowledgebase entry describes the bug he’s experiencing. Since the bug only manifests after a bad file has been played, the question is already aswered.

Of course he can keep shouting at windmills and whine on about how WD dares not to fix the WDTV’s crappy error handling ASAP as a master coder as himself would have certainly done. The smarter people however already moved on, making sure to play only properly encoded files.