If your having sound issues aparently

You hopefully don’t mean illegally downloaded movies from the internet, right?

Because there are no commercial MKVs produced that have header compression (at this time).

twopumpchump wrote:

i dont do the encoding, i just download movies that are in .mkv format and alot of them now have header compression.  the header compression is done with mkvmerge v4.1.1, and it can be fixed by remuxing the mkv file with the header compression option disabled.   im sure that in the near future almost all of  mkv movies will have this compression, which will make it a real pita to have to move them from my server to pc—remux—move back to server.  when i purchased this device i thought since it was the latest model and said in the specs it supported mkv i wouldnt have any problems like this…guess i was wrong lol.  i am hopefull that WD will include a fix for this in the next firmware update, if they have no plans to do this i would hope they at least tell us so we can explore other options. 

Don’t you find it strange that its only MKVmerge who has this header compression and it was only implemented recently. The author says that it is part of the MKV spec for years but he has only just got round to implementing it in his software. 

If you read the MKVmerge forum you will see that he has gone on a ‘crusade’ to get developers to update their units and he really does not care if you cannot play the files.

Quote.

“I’m concerned about backwards compatibility, but at the specs level. The specs haven’t changed in this regard, this feature just has never seen very wide use until now. Haali’s muxer has always supported header compression (muxer, not only the demuxer!), but it hasn’t been enabled by default.
What I’m trying to do at this very moment is to get companies to update their software to support a wider range of the specs. Now is a good time for such a move due to an already existing major change in mkvtoolnix 4.0.0 (default values aren’t written anymore) and due to the changes necessary for WebM playback. That’s why I’m pushing for it now.
The Matroska project has always been about pushing into unchartered territory. If we were satisfied with the status quo then we’d still all be using AVIs or MP4 and neither OGM nor Matroska would have seen the light of day. Yes, this process is often painful, but you don’t get (technical) advancement for free.”

Personally I’m staying at version 4.0.0 until he changes his mind or WD update the firmware to take this into account. No big deal to run the files through version 4.0.0 as far as I am concerned.

yeah i just dont see why they wouldnt want to fix this…it doesnt require new hw and they are still working on new firmware for this new model.   i really like my WDTV Live Plus, it does everything i need it to other than play audio from mkv with header compression so i may end up keeping it.  i have 30 days from purchase to send it back hopefully by then i will know if they plan on addressing this issue in the firmware update.

This issue only came to light TWO WEEKS ago.  

Despite the fact that the Matroska Spec has detailed it for five years, hardly any sources are using it.

Anyone using MKVMERGE, 4.1.x+ with defaults will start to have issues.

I doubt we’ll see any support for it until a few months from now, if we’re optimistic.  

twopumpchump wrote:

yeah i just dont see why they wouldnt want to fix this…it doesnt require new hw and they are still working on new firmware for this new model.   i really like my WDTV Live Plus, it does everything i need it to other than play audio from mkv with header compression so i may end up keeping it.  i have 30 days from purchase to send it back hopefully by then i will know if they plan on addressing this issue in the firmware update.

The basic facts are:

WD know about it. They may someday update their firmware but its very doubtful that it will be within your 30 days. There is a simple workaround available.

I’ll return both Live and TV HD Players to my dealer if this isn’t fixed in the next month: MKV was promised and doesn’t work as it should. I will definitely not start to remuxx all upcoming mkvs that are created with mkvmerge (which is THE muxxing tool out there…).

Sorry WD: This issue is self-made. To keep your customers just hurry up and fix it. Shouldn’t be that hard.

btw: Shame on you for not to fix the delay-problems on the live for more than half a year! If you don’t improve those were my last WD mediaplayers. Your HDDs are very good, but the entertainment hardware should be way better.

gorkili wrote:

I’ll return both Live and TV HD Players to my dealer if this isn’t fixed in the next month: MKV was promised and doesn’t work as it should. I will definitely not start to remuxx all upcoming mkvs that are created with mkvmerge (which is THE muxxing tool out there…).

 

Sorry WD: This issue is self-made. To keep your customers just hurry up and fix it. Shouldn’t be that hard.

 

 

btw: Shame on you for not to fix the delay-problems on the live for more than half a year! If you don’t improve those were my last WD mediaplayers. Your HDDs are very good, but the entertainment hardware should be way better.

Whats the hassle in re-muxing until the firmware is updated. Lets be quite clear about this issue, its the author of MKVmerge who is at fault. He knew that a lot of players did not support this compression. It has taken him at least 5 years to get round to implementing this in his program and now you want WD to do in a month. Get real.

 

Whats the hassle in re-muxing until the firmware is updated. Lets be quite clear about this issue, its the author of MKVmerge who is at fault. He knew that a lot of players did not support this compression. It has taken him at least 5 years to get round to implementing this in his program and now you want WD to do in a month. Get real.

 

I agree that the author of MKVmerge is violating a sacred trust by introducing a feature that breaks backward compatibility, even if the spec hasn’t been fully implemented by WD and other vendors.  But re-muxing a 720p movie takes 20-30 minutes - that’s the hassle, and it’s a big one.  As you’ve pointed out, the MKVmerge author is a stubborn %^%)^ but the losers are WD customers.  I haven’t seen anyone from WD respond to this thread, but I hope we don’t end up in a stalemate between WD and MKVmerge about who’s right.  Since we’ve paid good money to WD for their hardware and expect it to work, they do need to fix the firmware asap.

My first attempt at remuxing a file hasn’t worked.  Followed these instructions:

  • Using: mkvmerge v4.2
  • load your file, click on A_DTS(ID3 etc etc)
  • then click ‘extra options’
  • then click on the drop down box beside compression and select ‘none’
  • start muxing

The new file doesn’t work at all on the WDTV Live.  The file loads but just doesn’t play.  mkvinfo confirms that the compression has been removed.  The original file plays but with no audio.

Any suggestions?  Is there something else I need to do?

I can confirm the file remuxed with mkvmerge 4.2.0 won’t work at all. I have the blue circle in the middle of the screen, but the playback doesn’t start. Will stay with 4.0.0

+1 to WeeDee’s post, Remux’ed files dont even start in WDTV :frowning:

I just bought this box yesterday, and im about to pull my hair out :smiley:

Have anyone tried to remux with mkvmerge 4.0.0 ? Ill try that later 2day…

WD: New firmware please!

Juel-DK wrote:

+1 to WeeDee’s post, Remux’ed files dont even start in WDTV :frowning:

I just bought this box yesterday, and im about to pull my hair out :smiley:

Have anyone tried to remux with mkvmerge 4.0.0 ? Ill try that later 2day…

 

WD: New firmware please!

Version 4.0.0 works perfectly OK with the WDTV live.

GuitarBoy wrote:

My first attempt at remuxing a file hasn’t worked.  Followed these instructions:

 

  • Using: mkvmerge v4.2
  • load your file, click on A_DTS(ID3 etc etc)
  • then click ‘extra options’
  • then click on the drop down box beside compression and select ‘none’
  • start muxing

The new file doesn’t work at all on the WDTV Live.  The file loads but just doesn’t play.  mkvinfo confirms that the compression has been removed.  The original file plays but with no audio.

 

Any suggestions?  Is there something else I need to do?

I would assume that either the latest MKVmerge has a bug or there has been another update within the program that makes it completely incompatible with the WDTV LIve. Use version 4.0.0

http://www.bunkus.org/videotools/mkvtoolnix/win32/mkvtoolnix-unicode-4.0.0-setup.exe

Yes, I think the author of mkvmerge had some clever ideas again. Wondering what will bring the 4.3.x version. I guess it can’t be wors. :slight_smile:

After I tried the video muxed with 4.2.0, I couldn’t play any other file, I had to unplug the power and plug it back.

Ref:  MKVmerge 4…2.0 (No Talking) released 2010-07-28 (yesterday)

An enhancement has been added to this version:

2010-07-12

* mkvmerge: enhancement: Header removal compression has been enabled by default for MPEG-4 part 10 (AVC/h.264) video tracks with a NALU size field length of four bytes.

It appears that the WDTV Live cannot cope with the video compression and makes an attempt but does not play the file.

With this version you need to set both the video and the sound to no compression. 

Highlight the video track and then go to the extra options and set compression to ‘none’. Then highlight the sound track and do the same.

You will need to do this every time you use the program or you can simply use version 4.0.0 which does not include this compression.

Note: Trying to play the compressed video will ‘hang’ up the video playing ability of WDTV and you may need to unplug from power for a short time to get it to play any video.

The last ‘enhancement’ took away the sound and now the latest takes the vision. My recommendation is to stay at 4.0.0

I followed RichUK’s advice and use 4.0.0 and it works perfectly.

Without wishing to sound rude…if your box is taking 20-30 mins to run through mkvmerge then something must be wrong? It takes me 3 minutes MAX!

You might want to make sure that the target file is being created on another drive than the one being read, but even so 20 minutes?

I’ve confirmed that MKVMerge 4.2 will work with WDTV if both video and audio compression are turned off.  Hopefully the players like WDTV will soon catch up to the spec, but it really was irresponsible of the MKVMerge author to make these changes without concern for the impact on so many users.

Without wishing to sound rude…if your box is taking 20-30 mins to run through mkvmerge then something must be wrong? It takes me 3 minutes MAX!

You might want to make sure that the target file is being created on another drive than the one being read, but even so 20 minutes?

Older computer :cry:

That is on a 7GB file.  New computer (6 core 2.6 GHz processor) takes 6 minutes.

I really hope they fix this, its getting quite annoying, I am hardly even using my box anymore, I ran an hdmi cable to my video card and did a split screen and just play them off bsplayer.

↑ +1