Plugin: Sage Job Queue (SJQ) v3

[kchase56]

I've just added some SageAlerts to some of my SJQ tasks and now I'm getting the following in my SJQ server log =>

2010-07-28 08:02:13,769 ERROR [TaskQueue]: Cannot fire alert: SageAlert RPC client packaged with SJQ is incompatible with your installed version of SageAlert!

I'm running SJQ v3.1.0.898 and SageAlert v2.0.x. Any ideas would be greatly appreciated.

Thanks.

[Slugger]

SageAlert support is broken in Sage v7 + SJQ 3.1.x + SageAlert v2.x. It simply will not work b/c SageAlert v2.x uses the new Sage v7 core event model and SJQ v3.1.x still uses the old SageAlert RPC model for firing alerts, which doesn't exist in SageAlert v2.x.

Eventually, it'll be fixed, but there's no ETA at this time.

I believe the plugin description for SJQ in the plugin manager for Sage v7 says that SageAlert integration is broken - if it doesn't let me know and I'll add it, but I'm pretty sure it does. Anyway, it'll eventually be fixed, just not sure when.

[Slugger]

Originally Posted by Slugger

I believe the plugin description for SJQ in the plugin manager for Sage v7 says that SageAlert integration is broken - if it doesn't let me know and I'll add it, but I'm pretty sure it does. Anyway, it'll eventually be fixed, just not sure when.

Why hide it? Honestly, this probably won't be fixed in SJQ 3.x, but instead will be fixed in SJQv4. Trust me when I say that there is absolutely no ETA on SJQv4 - there isn't even a definitive design done yet - though I have lots of ideas floating around in my head as to what I want it to do. If people wanted some kind of clue, I'd say the earliest possible time frame for some initial usable betas for SJQv4 would be Q1 2011. Q2 2011 seems more reasonable. But there's a lot of other things going on for me right now so even Q2 2011 is not something I'd be circling on my calendar.

[kchase56]

Thanks for your quick response and honest answer.

This is the most powerful plug-in that I've used and your hard work and effort doesn't go unnoticed!

Originally Posted by Slugger

Why hide it? Honestly, this probably won't be fixed in SJQ 3.x, but instead will be fixed in SJQv4. Trust me when I say that there is absolutely no ETA on SJQv4 - there isn't even a definitive design done yet - though I have lots of ideas floating around in my head as to what I want it to do. If people wanted some kind of clue, I'd say the earliest possible time frame for some initial usable betas for SJQv4 would be Q1 2011. Q2 2011 seems more reasonable. But there's a lot of other things going on for me right now so even Q2 2011 is not something I'd be circling on my calendar.

[QueOnda]

I just updated my sjq to version 3.1.0.898 then I tried to login but either I don't remember the user name and password or do I need to update the client also (manually?)

[Slugger]

Originally Posted by QueOnda

I just updated my sjq to version 3.1.0.898 then I tried to login but either I don't remember the user name and password or do I need to update the client also (manually?)

In a bit of a mistake, I accidentally enabled the Jetty id/pwd on the SJQ interface starting with 898. So, when you attempt to load the GUI you get a browser prompt for id/pwd. This is your Jetty id/pwd (default is sage/frey). Then when you get by that prompt, you'll be asked for another password - this is your SJQ password, which is not the same (though it could be, but it's not read from the same source). Then you're allowed in.

I was doing some work on a branch of the SJQ code to eliminate the second password and just use the Jetty credentials and part of that change was also applied to trunk, which is why there's two different prompts now in SJQ. When time permits, I'll probably remove the Jetty creds prompt from SJQ 3.1.x.

[QueOnda]

Thanks slugger!!! That was it. I'm rolling again.

[ohpleaseno]

I want to make sure I understand something before I explore it.

I recently moved to having Sage on a Win 7 machine. In order to save hard drive space, I would like to start moving some recorded TV over to my WHS, but only after I convert it to .mkv. If I understand correctly, MOVEREC will allow me to do this. I would just set the ruleset to look for .mkv files and then I would activate the MOVEREC internal command.

If that is true, do I need to set the WHS folder they are moved to as a Recorded TV directory?

My second question is about the ruleset/client config. Would this be correct for what I'm trying to do?

if [IsObjMediaFile == true && $.IsTVFile{} == true && Filename =$ ".mkv"]
{
_MOVEREC
}

and

_MOVEREC

     "\\\\WHS\\RECORDED TV"

I know I'm totally wrong on the client rule, but thought I would take a stab at it.

[Slugger]

Since _MOVEREC is an internal task, you don't configure it on a client and if you do SJQ will error out saying the task name is invalid for a client.

In your ruleset:

if [IsObjMediaFile == true && $.IsTVFile{} == true && Filename =$ ".mkv"] {
   :MOVERECOPTS "\\\\WHS\\RECORDED TV"
   _MOVEREC
}

[ohpleaseno]

Ive never used internal tasks before, so thanks for the help. What about within sage, do I have to add the WHS drive as a recorded tv drive?

[Slugger]

Originally Posted by ohpleaseno

Ive never used internal tasks before, so thanks for the help. What about within sage, do I have to add the WHS drive as a recorded tv drive?

Sage v6.x + SJQ v3.0.x: No, you don't need to add the target as a tv or import drive.

Sage v7.x + SJQ v3.1.x: Yes, the target directory must be a registered tv recording drive OR an imported videos drive. If it's not then the file will still be moved just fine, but it'll just never show up in Sage. Regardless of whether the target is a recording drive or an imported videos drive, the file will still be listed in tv recordings - unless you change the new settings introduced in Sage 7.0.13 to prevent it from coming back as a tv recording (I don't remember the setting name, but it's in the release notes for 7.0.13).

[phelme]

Need some help here. I want to setup a rule to transcode files only created *after* a particular date and not touch the ones that already exist (say everything recorded after 8/9/2010). OriginalAirDate won't work because it won't catch repeats that are newly recorded. MediaAge will catch everything.

What I think I want is something along the lines of a "MediaCreationDate." Does a test like that exist or am I missing another angle at this? Thx.

[Slugger]

Originally Posted by phelme

Need some help here. I want to setup a rule to transcode files only created *after* a particular date and not touch the ones that already exist (say everything recorded after 8/9/2010). OriginalAirDate won't work because it won't catch repeats that are newly recorded. MediaAge will catch everything.

What I think I want is something along the lines of a "MediaCreationDate." Does a test like that exist or am I missing another angle at this? Thx.

$.GetStartForSegment{0} may do what you want. Problem is it seems to return a long, which would be a Java timestamp. You'd then have to compare it to another long, meaning you'd have to convert "8/9/2010" to a long and compare that way. Not pretty, but at least doable. Tread lightly because I've never actually tested the use of that test so I really don't know what it actually returns. Ideally, a test to make this easier, such as the suggested "MediaCreationDate" test, would be added to SJQ. Open an issue ticket, but not likely to happen in SJQv3 (though a great idea for SJQv4). Alternatively, a custom test could be written by someone to achieve this desired functionality.

... time to think about it: The plumbing to make this happen actually already exists in the OrigAirDate test so to do a MediaCreationTest really wouldn't be too much work. If you really want this then open the issue ticket and I will try to get it in there this week - as long as it's as easy as I think it will be (i.e. 10 mins, tops) otherwise it won't happen.

[phelme]

Originally Posted by Slugger

$.GetStartForSegment{0} may do what you want. Problem is it seems to return a long, which would be a Java timestamp. You'd then have to compare it to another long, meaning you'd have to convert "8/9/2010" to a long and compare that way. Not pretty, but at least doable. Tread lightly because I've never actually tested the use of that test so I really don't know what it actually returns. Ideally, a test to make this easier, such as the suggested "MediaCreationDate" test, would be added to SJQ. Open an issue ticket, but not likely to happen in SJQv3 (though a great idea for SJQv4). Alternatively, a custom test could be written by someone to achieve this desired functionality.

... time to think about it: The plumbing to make this happen actually already exists in the OrigAirDate test so to do a MediaCreationTest really wouldn't be too much work. If you really want this then open the issue ticket and I will try to get it in there this week - as long as it's as easy as I think it will be (i.e. 10 mins, tops) otherwise it won't happen.

Cool. After lookng at it again I can sort of get what I need by having a bounded MediaAge test. If that doesn't work out sufficiently I'll issue a ticket. Thanks!

[graywolf]

Using current version of SageTV 6.6

Ran a couple tests of _MOVEREC task and it worked fine with a couple "exceptions"

Original recording has M,W,A (manual, watched, archived) flags.
After processed by _MOVEREC (which moved it and related [edl, etc] files properly) it only had the A (archive) flag.

Any means of maintaining the existing flags?

Tried to do workaround as follows but it didn't work


:Priority 10
:MOVERECOPTS "location"
_MOVEREC

:Priority 8
_WATCHED

:Priority 6
_MANUALREC


Checked the log (not at home now so don't have the actual log) and it appears that once moved, that it "loses" track of the file?

Any suggestions?

[Slugger]

Originally Posted by graywolf

Using current version of SageTV 6.6

Ran a couple tests of _MOVEREC task and it worked fine with a couple "exceptions"

Original recording has M,W,A (manual, watched, archived) flags.
After processed by _MOVEREC (which moved it and related [edl, etc] files properly) it only had the A (archive) flag.

Any means of maintaining the existing flags?

No, unfortunately when you move a recording it requires the creation of a new MediaFile object and Sage automatically sets the flags and it always and only sets the archived flag. I suppose I could keep track of the flags that are set before doing the move and then set them after the move, but it currently doesn't do this - nor will it ever in SJQ v3.0.x - I don't run Sage v6 anymore so have no env to test fixes/changes for SJQ v3.0.x and therefore no longer support it. If you opened an issue ticket for this it may get fixed in SJQ 3.1.x (unlikely) and will probably be addressed in SJQv4. Without a ticket, I'll probably just forget about it by the time I get around to starting SJQv4.

Tried to do workaround as follows but it didn't work


:Priority 10
:MOVERECOPTS "location"
_MOVEREC

:Priority 8
_WATCHED

:Priority 6
_MANUALREC


Checked the log (not at home now so don't have the actual log) and it appears that once moved, that it "loses" track of the file?

Any suggestions?

Yes, you're correct. It will lose track of it because of what I mentioned above - moving the recording causes it to be listed with a new MediaFile object and therefore a new media id, which is why SJQ loses track of it.

Suggestion: Instead of trying all of that in one shot, add a new rule that sets the _MANUALREC and _WATCHED flags on all recordings that are archived and located in your destination folder. For example, if you're moving all your recordings to C:\archives then this should work (untested):

if [IsObjMediaFile == true && $.IsTVFile{} == true && $.IsLibraryFile{} == true  && FileName ^= "C:\\archives\\"] {
   _MANUALREC
   _WATCHED
}

Basically, you wait and mark the manual flag and watched flag after it has been moved. Make sense?

[graywolf]

Suggestion: Instead of trying all of that in one shot, add a new rule that sets the _MANUALREC and _WATCHED flags on all recordings that are archived and located in your destination folder. For example, if you're moving all your recordings to C:\archives then this should work (untested):

Code:

if [IsObjMediaFile == true && $.IsTVFile{} == true && $.IsLibraryFile{} == true && FileName ^= "C:\\archives\\"] {
_MANUALREC
_WATCHED
}

Basically, you wait and mark the manual flag and watched flag after it has been moved. Make sense?

That was exactly what I was going to try next but had to go out of town. Will test out that method once I get back. I'm sure that will be doable. Probably check for destination folder, and if not archived, watched, or manual have it do all three since the destination folder will just be used for my archived files.

Thanks for the explanation. Makes perfect sense.

[wayner]

I am having problems with MAPDIR. I am using the line:
:MAPDIR "E:\\" "\\\\sageserver\\e$\\\\"

But I am getting the error: c:\comskip>start /b /w /belownormal comskip.exe "\\sageserver\e$BluesClues-PlayingStore-362399-0.mpg"

It seems to be missing the \\'s after the e$. I have tried using 0, 2 and 4 \s after the e$. What am I doing wrong? Or can you not map to the root of a drive - ie. E:?

By the way, should I be changing my recording directory to using UNC paths, even if the drive is on the local machine?

edit - Nevermind - I figured it out - the mapdir line should be:
:MAPDIR "E:\\" "\\\\sageserver\\e$\\\\"

[Slugger]

Originally Posted by wayner

I am having problems with MAPDIR. I am using the line:
:MAPDIR "E:\\" "\\\\sageserver\\e$\\\\"

But I am getting the error: c:\comskip>start /b /w /belownormal comskip.exe "\\sageserver\e$BluesClues-PlayingStore-362399-0.mpg"

It seems to be missing the \\'s after the e$. I have tried using 0, 2 and 4 \s after the e$. What am I doing wrong? Or can you not map to the root of a drive - ie. E:?

By the way, should I be changing my recording directory to using UNC paths, even if the drive is on the local machine?

edit - Nevermind - I figured it out - the mapdir line should be:
:MAPDIR "E:\\" "\\\\sageserver\\e$\\\\"

Can you try:

:MAPDIR "E:" "\\\\sageserver\\e$"

That should work as expected. The fact that your last line works is probably a bug on my part, you shouldn't have to end the second part with two slashes. I'll have to take a look at it, but now I'm afraid if I "fix" it to what I think it should be, I may end up breaking a lot of people who have had to do something similar to get the expected results.

[razrsharpe]

Originally Posted by Slugger

but now I'm afraid if I "fix" it to what I think it should be, I may end up breaking a lot of people who have had to do something similar to get the expected results.

to fix it I would drop any trailing \'s in the MAPDIR line and then add back in the one directory separator... then any amount of \'s in the MAPDIR line would not break the rule... my $.02