XML data used by MCEBuddy to customise processing

[spin35]

One thing that I noticed when I upgraded to V5 was the presence of an XML file with each recorded TS.
What I've only just discovered is that MCEBuddy reads that XML data.

The problem that I was trying to solve was to prevent recordings from the ABC being processed through Comskip.  With NextPVR V4 I had set up a conversion task in MCDBuddy that took all recordings from NextPVR, ran Comskip over it, then transcoded it to X264 MP4 for insertion into my Plex Media Server's file tree.  The problem with at is that Comskip is done to all recordings with a common .ini file which sometimes resulted in bits of programs going missing - particularly from ABC and SBS recordings.

I had been toying with the PostProcessing.BAT in NextPVR scripts area but I wasn't getting an elegant solution.
The discovery that MCE buddy reads the XML file means that I can now have multiple conversion tasks in MCEBuddy which are tailored to different channels, without the need for PostProcessing.bat .

For the ABC task I set the Channel Name match to ABC* so that it will process any recording with a channel that begins with ABC, then set Remove ads to "no", so from now on any ABC recordings just get transcoded.

This now lends itself to having conversion tasks with different comskip.ini profiles to account for the difference between some channels e.g SBS and the other commercial stations.
I now have a conversion task for SBS with the channel match set to SBS* and the Remove ads is set to Comskip and the Comskip INI line points to an .ini file that is tailored to SBS.

The last task is the original that I was using with V4 but which now has the channel match set to *;~ABC*;~SBS* {all channels Except ABC or SBS} with comskip on and the comskip.ini for the commercial stations.

I'm now in the process of tweaking the ini files to get better results for SBS and the other stations.  The Comskip Tuning Guide is a great help.  The discovery that there is a -w debug screen option is great news as well as the option of running comskip with a previously generated [recording title].txt file that allows you to manually adjust the ad-breaks in the show.

I realise that this post is more about MCEBuddy and Comskip than NextPVR, but I thought this might help the community of NextPVR users.  I've struggled to find coherent information to make things work the way I wanted it to.  The fact that MCEBuddy reads the V5 xml files was an accidental discovery, and the fact that the Channel Name Match field reads the <Channel> in the xml was all new to me.  The syntax for the matching was derived from the MCEBuddy advanced doco that was explaining how to match show names.

The last part of my process before inserting into plex is to trim off the Pre and Post padding from the recordings so as to just have the program from start to finish in the Plex server.  Currently this is mandraulic, using VLC with a time.lua add-on to show the elapsed time on the screen to determine the Stime and Ftime to type into a batch file that has an ffmpeg line with -ss and -to parameters.  I'm thinking that I might be able to use the Comskip .txt file option to generate an edl file that I can use to trim off the pre and post padding, but I don't think this reduces the manual workload very much other than saving me having to scribble down the times while reviewing in VLC in order to type them into the Trim.Bat.  I know that MCEBuddy has got Start and End trim options in the conversion task, but you need to review the completed file before you can trim it.

If anyone has any suggestions on how to automate the removal of pre and post padding , I'm all ears   .

[sub]

If anyone has any suggestions on how to automate the removal of pre and post padding , I'm all ears   .

You could always see pre and post padding to zero, and not record it in the first place.

[mvallevand]

I agree about 0 prepadding because I've never seen a show start early except for children's programming. I wouldn't mind getting a few seconds for my slow tuning devices though.

Postprocessing is a little more difficult because it isn't guaranteed. Testing with my outro skip program does give a way for shows with regular music during the credits but generally it is just as easy to hit stop when the credits roll

Martin

[spin35]

If anyone has any suggestions on how to automate the removal of pre and post padding , I'm all ears   .

You could always see pre and post padding to zero, and not record it in the first place.

The problem lies in the fact that TV stations sometimes/often don't start and finish programs at the times in the EPG - especially as the evening progresses and if there are any "big News" items that result in news-flashes and longer than expected evening news broadcasts, or reality TV shows that seem to specialise in going on for an extra 5 mins or so just to drag out the misery of someone's eviction/elimination.  I have set Pre to 2 mins and Post to 20 mins in order to ensure that I capture the ending of the program.  

I've been surprised and delighted that the later version of Comskip (V82.012) sometimes removes the pre-padded stuff and it gives me the program right on the start.  Sometimes it clips the "Previously on ..." segment at the start which is a bit of a hassle, but I'm hoping that my tweaking of the ini file will solve this.

The long post padding I see as a necessary overhead to ensure that I get the endings.  I could reduce this for the ABC and SBS as they are generally more on track with the EPG than the commercial stations.  I sometimes edit the settings for my recurring recordings on those channels, but the 2/20 default is to ensure I don't get caught out when I pick a recording from the EPG.  The plus side of a long post pad is that I see whatever is on next, this might be the headlines in the late evening news, or a series that wasn't on my radar that turns out to be of interest.