This project has moved and is read-only. For the latest updates, please go here.

WTV playback stops prematurely in MCE

Jan 25, 2015 at 11:23 PM
Edited Jan 25, 2015 at 11:31 PM
I'm really enjoying MCEbuddy and appreciate the efforts.

Recently during playback, shows will stop playing as if they've reached the end of the show but they haven't. If I restart playback and fast forward through the spot that the show ended, it'll keep playing. The thing is that MCE really thinks it's reached the end of the show because the option to resume isn't even available when I go back into the recorded tv and select the show. As a result, I have to fast forward through the show and note where it ends. Then I'll do it all over again in order to skip that segment and the file will continue to play just fine.

Often times I get frustrated and just go back to the original file which won't have any issue. I am ready to start "deleting originals" as soon as this issue is resolved but for now, I am forced to maintain duplicates of every show.

Thanks
Jan 26, 2015 at 6:03 AM
How about the original file?
Can you upload your conversion log
Jan 26, 2015 at 11:43 PM
The originals play just fine.

Here's a few log files:
https://docs.google.com/file/d/0B-37hTp_dHbJb0dJMHdGWWtqV0k/edit?usp=docslist_api

https://docs.google.com/file/d/0B-37hTp_dHbJT3FxajU1RWFXM3c/edit?usp=docslist_api

I tried reconverting the original "Inside the NBA" a second time with no luck.
Jan 27, 2015 at 2:46 PM
It's a straight forward remux using unprocesssed should it shouldn't be an issue, looking into it. Can you upload a sample WTV file (I know it' big but we need one) to the mcebuddy server.

Also, try to uncheck the option for "Add Information" under Expert Settings. See if that fixes the issue, have a theory - when using unprocessed profile, mcebuddy just copies all the metadata for WTV file, wondering if that's causing an issue.
Jan 28, 2015 at 4:17 AM
Thanks for your help. I'll post a sample when I get back into town this weekend. If I uncheck the add info box, how will I populate the files with metadata? Should I install another application (such as media center master) that will find it based on filename?
Jan 28, 2015 at 4:57 AM
Lets try this and see what happens, we'll then fix it once we isolate the issue.

Jan 29, 2015 at 10:22 PM
Can you post a link to the MCEbuddy server?
Jan 30, 2015 at 5:04 AM
See the readme before posting sticky thread. It's easier to copy paste from there.

Feb 3, 2015 at 2:37 PM
I got the file posted. It is labeled "discussion 578547.rar"

As you requested, I unchecked the option to add information and it still does it.

Thank you for all the help.
Feb 25, 2015 at 1:17 PM
I finally had some time to dedicate to this yesterday. I decided to do a complete re-install of windows and only install the essentials for mcebuddy. I have not installed the DTB addin in order to keep things as simple as possible.

The shows are still ending early. It is very frustrating because even if I fast fwd past the spot where it happened, it will do it again within a few minutes making the shows unwatchable. I am ready to give up on commercial skipping.

Fixes attempted have been:
check/uncheck add information
check/uncheck hardware encoding (only have onboard graphics)
check/uncheck optimize video quality
Feb 25, 2015 at 2:13 PM
I think I know whats going on. It's possible your tuner card is inserts EOF's at the end of the show which confuses MCEBuddy which causes premature ending of files. A couple of users had reported this happening for them on the forum. Here's one link http://mcebuddy2x.codeplex.com/discussions/570442

The solution if I remember correctly was to update the tv tuner card driver (essentially a bug in the driver, there should NOT be an EOF (end of file) in the middle of a file).

Feb 25, 2015 at 3:09 PM
This seems pretty plausible since I use a ceton tuner card as well. What I don't understand is why do the originals play back just fine? Is there any software I can use to see where these EOF markers are being placed?

Thanks
Feb 25, 2015 at 3:13 PM
unfortunately not that I know, only ffmpeg and handbrake can tell while processing but only by looking at symptoms can the user tell. The other way is to use a binary editor and open the files and look for an EOF marker.

Feb 28, 2015 at 12:50 AM
This is very frustrating news considering that I donated with the expectation of compatibility with ceton tuner cards. Is there any plan to fix this bug in the software?
Feb 28, 2015 at 12:55 AM
Hmm I think your confusing things. This is a CETON bug and not mcebuddy. The drivers are not compliant with the standard. However will look at see if there is a workaround for you

Still you should contact CETON

Feb 28, 2015 at 1:05 AM
Try this

Use the option for streams remuxing. That will use windows direct show filters instead of ffmpeg and it might solve your issue.

Refer to the documentation page advanced commands to see how to use wtv streams remuxing in your profile

Feb 28, 2015 at 1:21 AM
If I read the other thread correctly, there was not a driver fix as I have the latest drivers. I will definitely open a trouble ticket with ceton though.

I am very appreciative for the awesome support you have provided but the semantics of where the bug exists isn't really important. I do know is that playback is normal on an unprocessed file. So after you mentioned that these bogus EOF flags "confuse" Mcebuddy, I made this assumption. I apologize if you felt I was some how taking a shot at this great program. That is certainly not the case. It is pretty frustrating though when you have expectations that aren't fulfilled. I also understand that Mcebuddy is dependent on fffdshow which uses a reverse engineered proprietary codec so there are many factors at play.

What I don't understand is that Mcebuddy continues to process the rest of the file after the bogus eof marker. If I restart playback and fast forward past the spot, the automatic comskip continues to function until it hits the next bogus eof flag. I will point out that I am using wtv unprocessed with xml output to dtbaddin.

Thanks again for everything!
Feb 28, 2015 at 1:22 AM
rboy1 wrote:
Try this Use the option for streams remuxing. That will use windows direct show filters instead of ffmpeg and it might solve your issue. Refer to the documentation page advanced commands to see how to use wtv streams remuxing in your profile
Sounds good. I'll give it a shot tomorrow.
Mar 5, 2015 at 5:18 AM
There are 2 option you can play with (don't use both simultaneously) in your profile
ForceWTVStreamsRemuxing=true
and
UseWTVRemuxsupp=true
One of them will likely work for you
Marked as answer by rboy1 on 3/4/2015 at 9:18 PM
Mar 5, 2015 at 6:00 AM
Also you may want to try the latest 2.4.2 BETA build from today. We've put in a patch for WTV mpeg2video remuxing in ffmpeg, it may solve your issue. If not definitely try the above options.
Mar 5, 2015 at 3:55 PM
I gave the ForceWTVStreamsRemuxing=true command a shot last week and the files conversions were completely out of sync by minutes so that's a no go. I just added the UseWTVRemuxsupp=true command now and will let you know how it goes.

Thanks for the suggestions.
Mar 14, 2015 at 3:39 AM
As you suggested, I tried the both advanced config commands and updated to the beta version still no luck. As I last ditch, I checked the expert setting "skip remuxing files" and it seems to have worked. I've only watched a few recordings but they've all played back correctly. Does this make sense in your opinion or is it coincidence?

Thanks
Marked as answer by rboy1 on 3/13/2015 at 9:28 PM
Mar 14, 2015 at 4:39 AM
It does make sense. Some tuner cards drivers insert EOF's into the middle of the file which they should not. MCE ignores them but ffmpeg does not an hence you end up with issues. Skipping remuxing "jumps" over the issue.
Try to see if you can get updated drivers for your TV tuner card.

Mar 14, 2015 at 5:47 AM
Sounds good. Thanks again