[mythtv-users] Updating "remove extra audio track" job for storage groups

[Michael Stucky]

On Thu, Feb 6, 2014 at 7:26 PM, Ian Evans <dheianevans at gmail.com> wrote:

> On Thu, Feb 6, 2014 at 6:47 PM, Michael Stucky <mike at stucky.us> wrote:
>
>> On Thu, Feb 6, 2014 at 12:59 PM, Ian Evans <dheianevans at gmail.com> wrote:
>>
>>> [snip]
>>> Here's something curious: the script runs fine for me if I call it
>>> manually. Was recording a series and decided to add it as a post recording
>>> job as the channel runs multiple tracks.
>>>
>>> The job still runs fine, the track is removed, but if done as a
>>> post-processing job, suddenly the show shows up in Wacth Recording as a
>>> 'yellow' damaged show. But it's not damaged. If I run it manually by
>>> selecting the recording->user jobs it doesn't show as damaged.
>>>
>>> What theme do you use? I use Steppes and have run the script from the
>> command-line, as a part of the recording profile and as a post-processing
>> job and don't think I have ever had a recording show up damaged. Another
>> thought, I always run the script before I do any sort of transcoding.
>>
>>
> Tinted Glass. And it's the only job that was run automatically (except for
> the commflagging)
>
>
> On the outside chance that it might be theme related, I switched to Tinted
Glass but none of my recording show up damaged (of course they didn't show
up damaged under Steppes either). So I ran the script on a couple of
recordings (one 720p and one 1080i) that weren't setup to run it
automatically and they both show up as normal recordings afterward.

The mythcommflag --rebuild line near the end of the script should have
produced a log file (assuming the permissions allowed it) of the format
/var/log/mythtv/mythcommflag.<timedate stamp>.#####.log. Anything it that
log file provide a clue? On a normal/good run I see 3 or 4
"RingBuf(<recording name>): Waited 1.0 seconds for data to become
available..." and a "decoding error..." at the end of the run followed by a
"Waiting for threads to exit.", anything else might indicate a problem.

I should probably figure out how to log the output of the mythffmpeg line
as well!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20140206/1f1f18d8/attachment.html>