[mythtv-users] 0.25 lookup metadata as part of jobqueue?
Michael T. Dean
mtdean at thirdcontact.com
Sat Mar 17 16:28:41 UTC 2012
On 03/17/2012 08:46 AM, Scott & Nicole Harris wrote:
>>> OK, I've attached the logs of two transcodes I just tried that both
>>> failed. I then ran killed mythjobqueue and started mythbackend on the
>>> slave and re-queued the jobs and both went through fine.
>>> 2012-03-16 21:34:58.739 Generating Keyframe Index
>>> 2012-03-16 21:34:58.755 Opening
>>> 2012-03-16 21:34:58.768 Couldn't open input file, error #-22
>>> 2012-03-16 21:34:58.783 Transcoding
>>> /mythtv_storage5/recordings/1081_20120315220000.mpg failed
>>> 2012-03-16 21:34:58.789 Transcode: delete old file: waiting while
>>> program is in use.
>>> 2012-03-16 21:34:58.798 Transcode: program is no longer in use.
>>> 2012-03-16 21:34:58.814 Deleting
>>> 2012-03-16 21:34:58.824 Requesting delete for file
>>> 2012-03-16 21:38:14.437 Opening
>>> 2012-03-16 21:38:14.447 Couldn't open input file, error #-22
>>> 2012-03-16 21:38:14.458 Transcoding
>>> /mythtv_storage2/recordings/1131_20120315220200.mpg failed
>>> 2012-03-16 21:38:14.463 Transcode: delete old file: waiting while
>>> program is in use.
>>> 2012-03-16 21:38:14.471 Transcode: program is no longer in use.
>>> 2012-03-16 21:38:14.481 Deleting
>>> 2012-03-16 21:38:14.489 Requesting delete for file
>> In both cases, mythtranscode was unable to create the temporary file in
>> which it planned to transcode.
>> It looks like you're running mythjobqueue as a user that doesn't have
>> permissions on (at least some of) the /mythtv_storage*/recordings/
>> directories (meaning that mythtranscode then inherits the
>> user/permissions of mythjobqueue). This may also explain why some of
>> the transcodes succeed--because some of those directories have more lax
>> permissions. You should check ownership of all your recordings to
>> ensure they're correct (likely mythtv user) so that you don't have
>> problems deleting them at some later date.
>> FWIW, I don't think the --user argument works for mythjobqueue, so you'd
>> need some other way to start it as the right user. I'm clueless on
>> upstart, so I'll let someone else help you figure out how that's done.
>> And, BTW, thanks for helping figure this out. Once it's figured out,
>> perhaps we can get Ubuntu to start shipping a proper mythjobqueue start
>> script (or at least get one on the wiki).
> I was wondering (it amazes me the things that run through my head when I'm
> supposed to be sleeping) if it might be something with permissions.
> However, as far as I can tell, all the mythtv_storage* folders have the same
> permissions, which were set with the -R flag...
> drwxrwsr-x 4 mythtv mythtv 0 2012-03-17 08:03 mythtv_storage1
> drwxrwsr-x 3 mythtv mythtv 0 2012-03-17 08:03 mythtv_storage2
> drwxrwsr-x 3 mythtv mythtv 0 2012-03-17 08:03 mythtv_storage3
> drwxrwsr-x 3 mythtv mythtv 0 2012-03-17 08:03 mythtv_storage4
> drwxrwsr-x 3 mythtv mythtv 0 2012-03-17 08:03 mythtv_storage5
> I went through each of the recordings folder in those directories and all
> recordings have mythtv:mythtv as ownership and all new recordings seem to
> have the same permissions of -rwxr--r--
> So if it's a permissions thing, I would have to assume that
> mythjobqueue/transcode is running not as the mythtv user but my local user
> that I launched mythjobqueue with, whereas mythbackend is starting using the
> mythtv user (as expected). The only thing that's throwing me off is some
> transcodes are working (though they're far fewer than those that fail), and
> as far as I can tell there is no permission difference on any new recordings
> between mythtv_storage*/recordings folders.
> While testing all this, I am not u sing any scripts or anything to start
> mythjobqueue, I'm just starting it from terminal....
> mythjobqueue --logfile /tmp/mythjobqueue.log&
Yeah, that means it's running as your user, who doesn't have permission
to write to the recordings directories.
Try with the start script that Michael W posted.
More information about the mythtv-users