I have knoppmyth running on my backend server and I'm also running the Mythfrontend on my PC (SUSE 10). I have my PC setup to flag commercials and to transcode as it is much more powerful than my Knoppmyth box.

I have /myth on my knoppmyth box shared via nfs. In /etc/exports I have:

/myth 192.168.1.10(rw,all_squash,anonuid=105,anongid=105)

and I have /myth mounted via NFS on my PC. I can read and write in /mythtv/tv from my PC ok.

I run mythjobqueue on my PC and it picks up Commercial Flagging and Transcode jobs just fine. However, when I do a transcode job on my main PC it does the transcode normally in /myth/tv and generates the /myth/tv/FILENAME.nuv.tmp on the backend box via NFS but doesnt rename the .tmp to the original file and remove the .tmp. This forces me to do the rename/delete manually.

Any Ideas where to look? I want to figure this out so I can write a how-to on setting up multiple backend jobqueues.

Thanks!

EtherNut

I am having the same problems.

my mount is ...

10.100.2.3:/myth /myth nfs rsize=8192,wsize=8192,hard,intr,nfsvers=3


the exports file on the mythbox is..

/myth *(rw,async,insecure,no_root_squash)

In my /etc/exports entry on my backend I am sharing
/myth as uid 105 and gid 105 which is mythtv:mythtv.
The gid and uid statements on the share force all
communications from my PC to write and read with that
permission (105) so I can read and write just fine
from my PC. When mythtranscode runs on my PC it reads
the original X.nuv via nfs and writes the newly
transcoded X.nuv.tmp in the same directory /myth/tv
via nfs. Have I missed something?

I have a hunch that while I'm not seeing my slave
backened PC delete the original X.nuv and rename the
X.nuv.tmp file to the original, that this is only part
of the problem. I'm making the assumption that it is
a communication issue with my master backened but not
sure what all is needed.

Does anyone know what scripts run when doing a transcode
besides mythtranscode? There has to be a portion that does the
delete/rename that is notgetting executed properly because of
some subtle difference between my Slave and Master.

Thanks

Looks like the answer may be in this reply from a other place I posted..


The rename and delete happen inside the JobQueue and are
straight C calls, there is no callout to a shell script.
So, whoever is running mythjobqueue or mythbackend needs to
have write access.

rename() and unlink() are used.

I tracked it down in the source code earlier. that process is running as mythtv which should work.

When I manually replace the files, mv asks for confirmation, either as mythtv or root.



This is strange. both the master and slave is R26.

Unfortunately I'm still having the issue with mythjobqueue not renaming/ overwriting the original .nuv with the .nuv.tmp that mythtranscode creates from my slave box.

Anyone have the answer?

Well I finally figured it out..

on my mythtv master back end (MBE)

NFS is exported to my slave back end (SBE on 192.168.1.10) this line in /etc/exports

/myth 192.168.1.10(rw)

On my SBE, I mount the /myth share on my MBE (192.168.1.11) to my local /myth directory with this /etc/fstab entry:

192.168.1.11:/myth /myth nfs rsize=8192,wsize=8192,hard,intr,nfsvers=3

This correctly configures NFS between the two boxes. The next step is permission based.

Cat the /etc/passwd on your MBE and examine the line that reads like:

# cat /etc/passwd

mythtv:$1$GLU854Ty$NGBuJMMLs4jXBFBVAox9U/:105:105::/home/mythtv:/bin/sh

(if you're curious the encrypted passwd above = mythtv as it is the default mythtv account for knoppmyth.)

Notice the part that says 105:105. the first 105 is the user account id (UID) and the second 105 is the mythtv user primary group and coincides with the /etc/group file.

Next take a look at the group file on the MBE.

# cat /etc/group

notice the line that says:

mythtv:x:105:

This all means that on your MBE there is a group called mythtv that is Group id (GID) 105 and a user called mythtv that has a UID 105 that is a member of the group mythtv.

This is very important because on your SBE you need to make sure you have a group called mythtv that is GID 105 and a user called mythtv that is GID 105.

I run Suse 10 as my SBE and it wouldn't let me make a group called mythtv with a GID of 105 (it chose 1000) nor would it let me make a mythtv user called mythtv with a UID of 105 (it chose something else). So what I did was create them with Suse's YAST and let it use whatever UID/GID it wanted. I edited /etc/passwd and /etc/group then changed what Suse chose to 105 for both User and Group. I also had to change the permissions of the /home/mythv folder as it was created under the old UID and GID. So I issued this to fix that:
# chown -R mythtv:mythtv /home/mythth

Now from my SBE I switch user to mythtv (su mythtv). You may need to edit your /home/mythtv/.mythtv/mysql.txt to point mythjobqueue to your databse on your MBE. The entry looks like:

DBHostName=192.168.1.11

Now execute mythjobqueue. I like to let it run in one of my virtual consoles so I can take a look what is going on.

Make sure mythjobqueue is running as the mythtv user:

# ps -ef | grep mythjobqueue

mythtv 15109 15100 0 18:27 pts/1 00:00:00 mythjobqueue

You should be good to go!

Can I get this moved to the Problems and Solutions forum?

Thanks

EtherNut