Won't Read Hard Drives and the Network Shares Stop after a Minute

mike27oct wrote:No need to do it by command line.  It happens automagically.

each to his own … i prefer command line 

(which at leasts displays a verbose output of what it’s doing / errors found and fixing)

So does automatic, Joey.  At the end, click See Details and you see the chkdsk report.

ok you’re right, it does in Win7 but not in WinXp (which i still use on one of my pc’s)

Win XP, I have one, too, mostly for ripping DVDs anymore… They will self-destruct next Tuesday.  Thanks, MSFT. 

I’m afraid it seems the WD firmware is more than a touch flakey. So many people are reporting problems just playing back files. My WD TV Live worked for years without a hitch and then suddenly it starts playing up. Exit out of a movie and the audio keeps playing. Try playing a new file and get the spinning cursor of doom. I’ve tried different switches, NAS, USB, different files that used to behave, even a brand new device and sure enough after 15-20 minutes of watching it starts the issues again. Just watch movie and it’s fine, try pausing etc and it breaks. Unplug, restart etc etc. Total pain in the arse. WD need to sort this out as it is clearly an issue with the devices - you only have to read all the complaints to know it. Too widespread and too frequent to blame on a particular user’s kit or files.

mark2014 wrote:

. Unplug, restart etc etc. Total pain in the arse. WD need to sort this out as it is clearly an issue with the devices - you only have to read all the complaints to know it. Too widespread and too frequent to blame on a particular user’s kit or files.

Some of the WD White Knights jump on posts like this and imply end user is stupid,  totally agree with “Too widespread and too frequent to blame on a particular user’”.

dcb917 wrote:


mark2014 wrote:

. Unplug, restart etc etc. Total pain in the arse. WD need to sort this out as it is clearly an issue with the devices - you only have to read all the complaints to know it. Too widespread and too frequent to blame on a particular user’s kit or files.


Some of the WD White Knights jump on posts like this and imply end user is stupid,  totally agree with “Too widespread and too frequent to blame on a particular user’”.

 

 

so far so good for me but I get where you are coming from. I started with an HTPC - mediaportal on XP then 7. Too many blue screens. Then I went to a TVIX dual tuner box- worked great except it turned itself off all the time… Then to a Humax PVR which I still use - but its streaming capabilities **bleep** and its codec support is woeful. So now I have the wd TV sme to handle that part. 

After all these devices I guess my expectations are lower. I’ve never found one device that can do it all. The TVIX came closest- but overheated and shutdown all the time. The WD does what I need it to do- but I’m feeding it through DLNA so its bare bones.

When that  near perfect device comes out I want one. I don’t think one exists now?

dcb917 wrote:

Some of the WD White Knights jump on posts like this and imply end user is stupid,  totally agree with “Too widespread and too frequent to blame on a particular user’”.

Are you implying that frustrated users like you are any better when they jump on postings like this only to agree but still keep hanging on despite their WD being oh so crappy?

My issue is not that it won’t play a certain file type, it is that both the old device and a brand new one (1 day old) have started misbehaving with new files and with old files that used to work fine.

I accept that there could be an issue with file encoding on new files or that a firmware update on a router or NAS could be causing iffy DLNA packets to fly around but any which way you put it the device should not behave as it is. The cursor of doom and the continuing to play after exiting to the menu are simply errors in the firmware/hardware of the device.

I have also noted that once you connect to a media server it seems to have problems seeing it or anything else (once this issue arises) until a restart is performed. This to me implies there is some state being held on the device that causes the issue and restarting it causes the state to be lost. That is coding. Whilst the WD TV has been the best media playing device I have ever owned by far this sudden onset of bizarre behaviour means, unless fixed, I will never purchase another WD item again nor recommend to anyone else. This has been going on for several years now (from searching) and it seems WD couldn’t give a sh*t.

Techflaws wrote:


dcb917 wrote:

Some of the WD White Knights jump on posts like this and imply end user is stupid,  totally agree with “Too widespread and too frequent to blame on a particular user’”.


Are you implying that frustrated users like you are any better when they jump on postings like this only to agree but still keep hanging on despite their WD being oh so crappy?

The difference is that a frustrated user has parted with their hard-earned currency and seem to be getting nothing in the way of support. Although I have had many years of trouble free use I am now faced with both a new and old device exhibiting the same behaviour and I am amazed that it appears to have been going on for so long (in the wider community). For there to be no fix or remedy other than removing the power cord (which isn’t really a remedy in the middle of viewing) is simply unacceptible. Only by continuing to complain about this will something get done - either it will be fixed or the product simply boycotted through bad press. How else are we supposed to get this fixed?

mark2014 wrote:

This has been going on for several years now (from searching) and it seems WD couldn’t give a sh*t.

Probably because they have issues reproducing this. Which is not all that surprising considering how many issues here are conflated by inexperienced users and people not exactly willing to follow through to get to the bottom of their particular issue. There’s a well communicated bug that stops the WDTV from playing ANY file once a BAD file has been played. And there is the connection problem introduced in 2.0.1.86 which also isn’t conclusive cause some people claimed it stopped after rolling back to 1.16.13 while others claim the opposite. So what you gonna do?

Have you tested files that worked fine previously again on older firmware (where they should work) or from USB to narrow it down to files or network?

OK. I didn’t know about the bad files. Am I right in thinking this is the MKV header compression issue?

If so that is documented here for anyone who subsequently finds this post and is wondering what is going on.

I had a whole host of things happen around the same time: gargoyle installed on router, NAS firmware update for heartbleed and a variety of new files that I worked through. The thing I didn’t know was that after the player cracks the **bleep**s getting it back to a working state involves so many resets and such a long time unplugged to be sure. This means that when I worked through resetting all the other items and after it and a new unit wouldn’t play old files that always worked I was at a loss.

I think your bad file hint is the one here as everything is pointing that way:

  • Both units affected
  • Other hardware unaffected for the same files (computers, tablets etc)
  • Previous good files unaffected
  • Old unit using same firmware for years

I’ll try fixing the files, resetting the unit as per the link and then report back (may take a couple of days). If it works then hopefully this can be flagged up as the main issue and fix as I sure wouldn’t have found it without your response just then, despite hours of searching. Bloody weird that it even affects it seeing network shares and all sorts afterwards.

MKV Header Compression issues were fixed on latest WDTV devices a long time ago.

(the link you posted regarding MKV Header Compression pertains to the WDTV Gen 1 released in 2008)

But, me personally, out of habit, always remux my MKV’s using MKVMerge just to to be thorough …

only takes a couple of minutes

(no quality loss, and i also remove any audio / subitle tracks i don’t need in the process … which reduces the filesize a lot more than any “Header Compression” could do.)

I love MKVMerge … downloaded a *.*flv movie from a streaming website the other day …

(used videodownloadhelper firefox plugin to capture it)

plays fine on my WDTV Live Hub … but i could’nt FF or REW

Dropped it into MKVMerge and remuxed it … plays fine again with FF & REW working

(the Video Codec was AVC and the Audio was AAC)

RULE OFTHUMB:

If a Video File plays *Fine* on your PC (using VLC etc) that’s No Guarantee it will play on the WDTV

PC Software can use Hardware and Software Decoding and be fault tolerant (eg. VLC “rebuild index and play”)

WDTV are Hardware Decoders only … and are Not fault tolerant

Well that’s got me real confused now Joey as both devices (an old WD TV with the …43_V firmware and a brand new WD TV Live streaming that updated itself from v1 to v2 firmware) have had the issue. As I put in a previous post the things that have happened recently are

  • NAS firmware bump for heartbleed
  • Router (WNDR3700v1) from stock to Gargoyle firmware
  • New set of MKVs being played.

If new devices are immune to the MKV issue but both devices have had the same problems:

  • When file playing, after a while, pause and play or info menu interaction (old device) or stop (or back) when wanting to finish the showing don’t work properly. Trying to stop results in the audio still playing although the device returns to the menu.
  • Once this bad behaviour starts it stays until the device has the power cord removed
  • The device gets the old spinning cursor of doom when trying to play any other file. Even if the box is powered off (no cord removed) it refuses to play any files
  • The bad behaviour is persistant
  • Sometimes the new box will refuse to even see the media server until the power cord is removed
  • etc

I am at a loss. I was really hoping this was it. Could there be any other file issues that would do this?

As I had reflashed the router and NAS and power cord reset the old device I am sure the file is the issue (yet to test, but have put through mkwdclean.exe). The new device is a bit more of a mystery if immune.

Update:

Used the mkvwdclean.exe to make sure the MKV files are all good.

Result:

Same bloody issues with the new device on 2.01.86 firmware.

Given the prior mention of this firmware bringing about a “connection issue” I’ll try resetting the firmware and see how I go.

Been contacted by support so I’m hoping they can fix/locate the issue.

I’ve reverted to the original 1.6.13 (or whatever it is) firmware of the WD TV Live Streaming powered down/reset and tried with a cleaned file. Refuses to play file type - possibly an issue with DTS audio. Tried a different MKV → same issue of file continuing to play after going back to the menu.

Allowed the unit to update firmware and powered down/reset. Then played a cleaned MKV via a USB stick with no network connection present. Same issue → file continues to play after going back to menu. Even plays after stick removed, I guess due to buffering. Same problem of media no longer connected (obviously) but allows me to then play a file on the media server when I connect the network. It therefore seems like the issue causes the media source to be blacklisted/unavailable in some way as if I start with a media server then the media server is not available until after a reset.

This seems to remove the possiblity of the network and the media server being an issue as it was observed on the USB stick.

Next I might try a transcode using Handbrake to a different format and see how that goes in order to rule the file out totally.

I am worried though that there may be a fault that persists on the unit even after power down, reset and firmware replacement. I would appreciate it if anyone in the know could tell me if that is a possiblity i.e. some corruption has been caused that cannot be remedied?

I haven’t experienced audio playing on for roughly 1 second when returning to the filebrowser on local files for quite some time.  While I agree this is most likely a buffering issue, I’ve never had any disconnects or interuptions during playback.

As I have informed the support people I found the following to work. After resetting the device (running latest 2.01.86 firmware) and restarting after a power off (and with no internet connectivity to fully isolate from the network) I ran one of the issue-causing files from a USB stick after using handbrake to transcode using the Apple3 codec as I assumed this would be pretty vanilla. This worked perfectly with no issues when trying to return to the menu. To me this proves there is an issue with MKVs still with the current firmware on current devices. I appreciate there is a difference in bitrate after transcoding but here are the details (issue-causing file first) for anyone that knows what this stuff means and how it may cause issues…

General
Format : Matroska
Format version : Version 2
File size : 2.26 GiB
Duration : 46mn 33s
Overall bit rate : 6 958 Kbps
Encoded date : UTC 2010-09-06 15:26:38
Writing application : mkvmerge v4.3.0 ('Escape from the Island') built on Sep 5 2010 10:30:51
Writing library : libebml v1.0.0 + libmatroska v1.0.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 9 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 46mn 33s
Bit rate : 5 955 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.270
Stream size : 1.94 GiB (86%)
Writing library : x264 core 104 r1703 cd21d05
Encoding settings : cabac=1 / ref=9 / deblock=1:-3:-3 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=7 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.80 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:0.80
Language : English
Default : Yes
Forced : No

Audio #1
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 46mn 33s
Bit rate mode : Constant
Bit rate : 640 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 213 MiB (9%)
Title : English
Language : English
Default : Yes
Forced : No

Audio #2
ID : 4
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 46mn 33s
Bit rate mode : Constant
Bit rate : 224 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 74.6 MiB (3%)
Title : Commentary
Language : English
Default : No
Forced : No

Text
ID : 2
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Title : English
Language : English
Default : No
Forced : No

 and the “good file”

General
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42
File size : 1.22 GiB
Duration : 46mn 33s
Overall bit rate mode : Variable
Overall bit rate : 3 754 Kbps
Encoded date : UTC 2014-05-02 10:55:16
Tagged date : UTC 2014-05-02 11:28:43
Writing application : HandBrake 0.9.9 2013051800

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 46mn 33s
Bit rate : 2 942 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 23.976 fps
Minimum frame rate : 23.810 fps
Maximum frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.133
Stream size : 980 MiB (78%)
Writing library : x264 core 130 r2273 b3065e6
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=30 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=25000 / vbv_bufsize=31250 / crf_max=0.0 / nal_hrd=none / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2014-05-02 10:55:16
Tagged date : UTC 2014-05-02 11:28:43
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio #1
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 46mn 33s
Bit rate mode : Variable
Bit rate : 166 Kbps
Maximum bit rate : 264 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 55.3 MiB (4%)
Language : English
Encoded date : UTC 2014-05-02 10:55:16
Tagged date : UTC 2014-05-02 11:28:43

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : ac-3
Duration : 46mn 33s
Bit rate mode : Constant
Bit rate : 640 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 213 MiB (17%)
Language : English
Encoded date : UTC 2014-05-02 10:55:16
Tagged date : UTC 2014-05-02 11:28:43

It does not necessarily prove an issue with MKVs but with this specific MKV (like I wrote before, my MKVs run just fine). Of course this is fixed when you reencode the file. What you could have done is remux your MKV with MKVToolnix 6.9.1 or to m2ts cause your files was muxed with 4.3.0.

Well, I finally solved the mystery in part for my setup - UPnP.

The new WD was returned to the store - it was having problems from the get-go and could have had differing issues. The old WD I have (gen 1) always worked so I figured I’d stick with the known worker and try and solve the issue there.

It was the ability to play a converted file with the network disconnected - that got me thinking and a lucky search came up with this.

Turns out that, for some reason, the WDTV (old and new) has issues with the QNAP putting out UPnP SSDP broadcasts other than just for the Twonky and that by updating the firmware the enable UPnP option seemed to come on. This is what I switched off and everything works perfectly. The strange thing is that the unit had been working fine for a number of days/weeks after the QNAP was updated. Perhaps a reboot of the unit or the router caused a problem.

The new WDTV was probably giving better hints when it complained about losing the media server connection/was unable to find it. I am glad that I returned it though as the fact it exhibits the same issue as a 4+ year old device means there is little hope of a fix.

No other device connected using UPnP/DLNA had a single issue (tablets, phone etc). This seems to be a real firmware issue as it appears to be a matter of how it is dealing (or not) with the SSDP broadcasts which affects the internal state of the device.

Glad to be back to normal as I do love the simplicity of the device.