Transcoding scheduled for wrong host.

[martin@…]

I have continously had transcoding jobs scheduled for the wrong host on my systems. Looking through old posts it seems that this it not unique for my setup.

Example: Show recorded on Martin64, set to transcode commercials out of the show while recording some other show. It usually only gets the right host if the wrong host is recording and the right one is not. I would really like some better way to do this....

Result:

id      chanID  starttime               inserttime            type    cmds
650  	28  	2005-09-18 10:00:00  	2005-09-18 11:13:44   1       0
flags   status  statustime              hostname              args
1  	304     20050918124959  	athlonpc  	      [BLOB - 8 Bytes]

I have activated the setting to only run jobs on the original recordinghost through mythtv-setup, but it is not honoured.

Changing the hostname manually in 'jobqueue' works when you then requeue it after it failed the first time. Surely it must be possible to honour that setting or is it meant to do something else?

My backends have separate storage so they cannot directly access each others recordings.

I have verified that this still happens as of revision 7270.

[Martin Moeller]

A few more transcoding and I might have a pattern. I am not entirely sure, though. I usually watch the recorded shows on the 'athlonpc' backend which is also my primary frontend. A couple of days ago, I went through a lot of show that needed transcoding, but I did this on the 'Martin64' host as I way sitting by it at the time. It seems (this is where I'm not 100% sure) that all transcoding jobs i scheduled in this case got the host set to 'Martin64' and I had to change some of them back to 'athlonpc' in this instance.

Would it be fair to say that the system currently grabs to hostname you schedule the job from and not the hostname of the original recording?

[cpinkham]

(In [7274]) Fix bug that would queue up jobs using the frontend's hostname instead of the recording backend's hostname when a user queue jobs using a playlist on the Watch Recordings screen with the JobsRunOnRecordingHost? setting turned ON. Closes #352.

[Martin Moeller]

This problem is back for be, now that the wrong starttime issue has been fixed. Has the hostname field somehow gotten a change after this fix? It usually schedules for the host I'm viewing on to transcode the job whether or not that is the right machine...

I have tested several revisisions and am currently at revision 7682.

[cpinkham]

(In [7749]) Fixes #352. When queueing jobs for a playlist, the JobsRunOnRecordHost? setting was not being honored because the code was checking for an incorrect setting called JobsRunOnRecordingHost?.