Opened 18 years ago
Closed 18 years ago
#352 closed defect (fixed)
Transcoding scheduled for wrong host.
Reported by: | Owned by: | cpinkham | |
---|---|---|---|
Priority: | minor | Milestone: | unknown |
Component: | mythtv | Version: | |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
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.
Change History (5)
comment:1 Changed 18 years ago by
Owner: | changed from Isaac Richards to cpinkham |
---|
comment:2 Changed 18 years ago by
comment:3 Changed 18 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
(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.
comment:4 Changed 18 years ago by
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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.
comment:5 Changed 18 years ago by
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
(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?.
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?