mtdean at thirdcontact
Jun 27, 2012, 7:02 PM
Post #8 of 9
On 06/27/2012 04:47 PM, jrh wrote:
Re: Mac OS X secondary backend setup problems
[In reply to]
> On Jun 26, 2012, at 9:34 PM, Craig Treleaven wrote:
>> At 8:57 PM -0400 6/26/12, jrh wrote:
>>> On Jun 26, 2012, at 1:26 PM, Craig Treleaven wrote:
>>>> Thanks. Where did your OS X binaries come from? osx-packager.pl, osx-packager-qtskd.pl? Do you know which version of Qt?
>>>> Also, I'm curious about running a slave backend on OS X, if you don't mind. Obviously, any backend could talk to the HDHR3. Why set up the Mac as a slave as opposed to having your primary backend control the additional tuners?
>>> I downloaded the latest .25-fixes dmg from sourceforge for 10.7 and is dated 2012-06-05.
>>> fixes/0.25 [v0.25.1]<http://www.mythtv.org>www.mythtv.org
>>> Qt version: compile: 4.8.1, runtime: 4.8.1
>>> My objective is to use the mac slave backend only when I want mythtv to transcode and I have set up a startmyth.sh and stopmyth.sh to mount nfs/start mythbackend, and umount nfs/stop mythbackend respectively.
>>> My master backend is a lightweight AMD fusion processor with low power requirements and is configured to not transcode jobs. It suffices for all recording, and serving of video. I do not have any tuners configured on the Mac slave backend.
>>> I have the mac do an nfs mount of the /var/lib/mythtv dir structure from the mac to the master backend to read the source mpg and write the transcode file to.
>> I think you only need to run the job queue; not a slave backend. Was MythJobQueue.app in your download from sourceforge? AFAIK, a backend must have tuners defined. Also, I don't think you have to use nfs mounts but I really don't have any experience with transcoding.
> MythJobQueue was in the download, and I did not realize that it was independent of the backend. Interesting, I will look into it.
Yes, that's what you should use.
> Looks like if you are using a secondary backend, it doesn't need tuners defined; only the primary backend does..
It will run, but it's not a supported configuration. Besides,
mythjobqueue takes 1/10th the resources of a slave backend (literally):
> I did try transcoding without the nfs mount, and it failed, not creating the new/updated version of the video. It did go through the motions which was interesting, just created no new video file. Using the nfs mount cured this problem.
Yes, transcoding (just like recording) requires "local" access to the
file system to write the video. We don't support writing video over the
network using MythTV's protocol. NFS provides a local view of that
remote file system, allowing you to write across the network.
mythtv-users mailing list
mythtv-users [at] mythtv