WDTV live plays mkv but stops halfway also can't FF

Ok I have been searching but I haven’t found a solution to this problem.  I am using the newest beta firmware release. 1.03 .43.  I am watching mkv files and they will be playing fine and than just stop out of nowhere.  Since these files don’t have “trick Mode” enabled, I am not able to FF back to an hour into the movie to see what is wrong.  The file plays fine and can skip forward on my PC.  This has happened on the last mkv movies I have watched.  

I am looking for something that can either remux hopefully or re-encode a file  so it can FF and skip scenes.  Chapter selections also don’t work.    I also need to know how I can check the file to find out whether or not it is going to crapout  on me halfway  so I don’t start watching a movie and it just stops before the end.  I have tried to remux it with mkv merge with no header compression but no success.   Here is an example of one of the films media info.

(MKVInfo) + EBML head
(MKVInfo) |+ EBML version: 1
(MKVInfo) |+ EBML read version: 1
(MKVInfo) |+ EBML maximum ID length: 4
(MKVInfo) |+ EBML maximum size length: 8
(MKVInfo) |+ Doc type: matroska
(MKVInfo) |+ Doc type version: 2
(MKVInfo) |+ Doc type read version: 2
(MKVInfo) + Segment, size 11964889191
(MKVInfo) |+ Seek head
(MKVInfo) | + Seek entry
(MKVInfo) |  + Seek ID: 0x15 0x49 0xa9 0x66 (KaxInfo)
(MKVInfo) |  + Seek position: 4099
(MKVInfo) | + Seek entry
(MKVInfo) |  + Seek ID: 0x16 0x54 0xae 0x6b (KaxTracks)
(MKVInfo) |  + Seek position: 4254
(MKVInfo) | + Seek entry
(MKVInfo) |  + Seek ID: 0x1c 0x53 0xbb 0x6b (KaxCues)
(MKVInfo) |  + Seek position: 11964837423
(MKVInfo) | + Seek entry
(MKVInfo) |  + Seek ID: 0x10 0x43 0xa7 0x70 (KaxChapters)
(MKVInfo) |  + Seek position: 5532
(MKVInfo) |+ EbmlVoid (size: 4028)
(MKVInfo) |+ Segment information
(MKVInfo) | + Timecode scale: 1000000
(MKVInfo) | + Muxing application: libebml v1.0.0 + libmatroska v1.0.0
(MKVInfo) | + Writing application: mkvmerge v4.4.0 (‘Die Wiederkehr’) built on Oct 31 2010 21:52:48
(MKVInfo) | + Duration: 9133.312s (02:32:13.312)
(MKVInfo) | + Date: Sat Nov 13 06:04:06 2010 UTC
(MKVInfo) | + Segment UID: 0x8f 0xd8 0x59 0x6b 0xcd 0x3b 0x23 0xb6 0xb6 0xb8 0xa0 0x88 0xa3 0x92 0x3b 0xb4
(MKVInfo) |+ Segment tracks
(MKVInfo) | + A track
(MKVInfo) |  + Track number: 1
(MKVInfo) |  + Track UID: 1498657700
(MKVInfo) |  + Track type: video
(MKVInfo) |  + Lacing flag: 0
(MKVInfo) |  + MinCache: 1
(MKVInfo) |  + Codec ID: V_MPEG4/ISO/AVC
(MKVInfo) |  + CodecPrivate, length 55 (h.264 profile: High @L4.0)
(MKVInfo) |  + Default duration: 41.708ms (23.976 fps for a video track)
(MKVInfo) |  + Language: und
(MKVInfo) |  + Video track
(MKVInfo) |   + Pixel width: 1920
(MKVInfo) |   + Pixel height: 1080
(MKVInfo) |   + Display width: 1920
(MKVInfo) |   + Display height: 1080
(MKVInfo) | + A track
(MKVInfo) |  + Track number: 2
(MKVInfo) |  + Track UID: 1042648481
(MKVInfo) |  + Track type: audio
(MKVInfo) |  + Codec ID: A_AC3
(MKVInfo) |  + Default duration: 32.000ms (31.250 fps for a video track)
(MKVInfo) |  + Language: und
(MKVInfo) |  + Audio track
(MKVInfo) |   + Sampling frequency: 48000
(MKVInfo) |   + Channels: 6
(MKVInfo) |+ EbmlVoid (size: 1084)

Chapters don’t exist in that file, apparently… That is just a lousy encode.

Sorry, I deleted the chapters off the info file because it was just too long. Fast Forwarding also casuses some mkv files to stop and give me an error message about checking the list of supported files.  I also forgot to say that the files sizes listed for these mkv filesare much smaller than they are on my PC.

tianfeng wrote:

Since these files don’t have “trick Mode” enabled, I am not able to FF back to an hour into the movie to see what is wrong.

 

I am looking for something that can either remux hopefully or re-encode a file  so it can FF and skip scenes.

As Tony said, it’s just a lousy encode.  Instead of trying to “fix” it, it would be much better to make a proper encode from the original source, with a different encoder that makes proper files.

Re-muxing won’t work because you’d just be putting the bad streams into a new container.

Re-encoding should work, but why re-encode from a broken file when it’s better to reencode from the original source?