tel8618217223380 / sagetv-addons

Automatically exported from code.google.com/p/sagetv-addons
0 stars 0 forks source link

Add event trigger for Tasks assigned to Sage objects #219

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
As it stands now Tasks associated with Favorites are run when all types of 
SageEvents happen.  I'd like to see the ability to specify which SageEvents 
trigger Task execution.

If I understand it now the Test Script has to contain all of the logic to 
determine if the Executable should be run.  Adding this feature would make it a 
lot easier to write test scripts since the script developer would have more 
control over when the script is invoked.

I think at a minimum we need to have some environment variable that the test 
script could read to determine what SageEvent triggered the task to be run.  
(Maybe it's there already and I just don't know about it.)

Original issue reported on code.google.com by tom.mira...@gmail.com on 6 Nov 2010 at 8:16

GoogleCodeExporter commented 9 years ago
Actually, tasks for favs are only queued on the RecordingStarted event.

Adding support for other events is possible - actually quite trivial from the 
engine code point of view.  However, in the case of favs, I think it only makes 
sense to really support four events:

RecordingStarted
RecordingSegmentAdded
RecordingStopped
RecordingCompleted

The first two are already done - SJQ currently queues the list of tasks for a 
fav on RecordingStarted or RecordingSegmentAdded events.

The last two could be done, but instead I use the test script to check if the 
recording is active and if it is I just return the task to the queue until it's 
done recording.  I suspect we'll actually get asked to separate out all of 
those events rather quickly once we go to public beta.

We could also listen for MediaFileDeleted and if it's a media file associated 
with a fav then handle that, but I think we'll wait and see what users say once 
we get into beta.

Like I said, adding support for all the events is rather trivial for the engine 
code - I designed it knowing we may want to add more events down the road.  For 
me it's literally 5 mins or less to add any event listener to the engine code.  
The real work is with the STVi.  How much do you want to support?  How much 
more are you willing to do?  That's why I stuck with the "big three" for now 
and then we'll see just how much more the users want.

Original comment by de...@battams.ca on 7 Nov 2010 at 3:40

GoogleCodeExporter commented 9 years ago
This I understand :)  I was thinking of the ability to let the user choose what 
events fire the task for the Favorite.  The STV code for this would be a little 
more complicated because when the user selected a Favorite he would have to 
choose what task to run against that favorite and then what event would fire 
the task.

This would make script writing easier and give the users a lot more 
flexibility.  Say I want to create a task that runs VideoReDo on a recording 
that has a messed up timeline (which is something I do now.)  So I create a 
Task called "FixTimeline".  The test script needs to first check if the 
recording is still in progress (because the Task will get fired when the 
recording starts, and that's not when I want to run VideoReDo). I'd like to 
specify that the task ONLY get run when the RecordingCompleted event happens.

Original comment by tom.mira...@gmail.com on 7 Nov 2010 at 10:59

GoogleCodeExporter commented 9 years ago
Comment 3 of issue 218 applies here as well.  If you're willing to do the STVi 
work then I'll definitely do my part. :)

There are some things to keep in mind though...

Yes, we can allow them to attach lists of tasks to specific events, but there 
will still be some scripting required to differentiate which event the user is 
handling UNLESS they write separate scripts for each event type, which is a bit 
messy itself.

Again, I put this ticket's fate in your hands.  I'll make the engine changes 
for sure if you decide you want to tackle this on the STVi side.

Original comment by de...@battams.ca on 7 Nov 2010 at 1:42

GoogleCodeExporter commented 9 years ago
Same comment as for 218, I'm willing to give it a go because I think it's a 
very nice feature to have.

Original comment by tom.mira...@gmail.com on 7 Nov 2010 at 1:45

GoogleCodeExporter commented 9 years ago
Renaming this ticket for the more generic case.  Basically, we're talking about 
attaching lists of task ids to Sage objects for specific events.  Namely, we're 
talking about this list copied from 
http://download.sage.tv/SageTVEventListener.java:

All of these will be added to the plugin config screen for SJQ to allow simple 
lists for any time the event is fired by the core.  The separate groups shown 
below will also (possibly) be handled in the STVi as described.

 * MediaFileImported - vars: MediaFile

Config menu only.  The MediaFile object doesn't exist until imported so there's 
no where else to add menus for this event.

 * RecordingCompleted - vars: MediaFile 
 * RecordingStarted - vars: MediaFile 
 * RecordingSegmentAdded - vars: MediaFile 
 * RecordingStopped - vars: MediaFile
 * MediaFileRemoved - vars: MediaFile, Reason[String; will be one of Diskspace, KeepAtMost, PartialOrUnwanted, VerifyFailed, User or ImportLost], UIContext[String, will be null or undefined if not from a 'User' reason]
 * PlaybackStopped - vars: MediaFile, UIContext[String], Duration[Long], MediaTime[Long], ChapterNum[Integer], TitleNum[Integer]
 * PlaybackFinished - vars: MediaFile, UIContext[String], Duration[Long], MediaTime[Long], ChapterNum[Integer], TitleNum[Integer]
 * PlaybackStarted - vars: MediaFile, UIContext[String], Duration[Long], MediaTime[Long], ChapterNum[Integer], TitleNum[Integer]

This group can be added to the various media file details screens (recording 
details, video details, music details, pic details, etc.).  So users can attach 
task ids to events on a per media file basis.  These events can also be added 
to favourites.  For example, queue a list of tasks when a favourite is played 
back, recording started, file deleted, etc.

 * SystemMessagePosted - vars: SystemMessage

This probably only needs to be in the plugin config.  Given the nature of 
system messages, there probably isn't a need to requeue a system message, but 
if it were (heavily) requested by users then you probably could add a menu 
option to the "view sys msg" screen in the current STV.  I definitely would not 
worry about this one for now.

 * PluginStarted - vars: Plugin
 * PluginStopped - vars: Plugin

Basically, you could add a "Configure SJQ" button to the installed plugins 
screen to allow this.  However, this seems like something that only a few 
users, if that many, would ever use.  So I'd hold off on this one, too, until 
we get some feedback.

 * FavoriteModified - vars: Favorite
 * FavoriteRemoved - vars: Favorite

I could envision users queuing some kind of email notification task anytime 
someone modified/removed a favourite.  But again, I'd put this in the "wait for 
someone to ask for it" category.

 * PlaylistAdded - vars: Playlist, UIContext[String]
 * PlaylistModified - vars: Playlist, UIContext[String]
 * PlaylistRemoved - vars: Playlist, UIContext[String]

Again, you'd be adding "Config SJQ" options to the playlist editors in the STV. 
 I'd also "wait for someone to ask for it" - I don't expect many users will be 
processing MP3s and pictures with SJQ.

 * ClientConnected - vars: IPAddress[String], MACAddress[String] (if its a placeshifter/extender, MACAddress is null otherwise)
 * ClientDisconnected - vars: IPAddress[String], MACAddress[String] (if its a placeshifter/extender, MACAddress is null otherwise)

Initially, I think this just goes on the plugin config.  But I could see use 
cases where users want to attach tasks to specific clients when they 
connect/disconnect.  Of course, the core does not provide any kind of menu in 
the STV for client info so you'd have to create it.  I think we go with just 
the plugin config option for now and see if enough users actually want the per 
client options.

Original comment by de...@battams.ca on 7 Nov 2010 at 2:15

GoogleCodeExporter commented 9 years ago
Information overload!  I think the bottom line for this is that you will add 
everything to the plugin config screen and if the need is identified we will 
implement this on a "per object" basis in the future.  Correct?

Original comment by tom.mira...@gmail.com on 7 Nov 2010 at 9:40

GoogleCodeExporter commented 9 years ago
Actually, your new "Assign Tasks to Events" screen will be replacing the 
"everything in plugin config" screen because your screen is much nicer than 
mine. :)

We'll decide where to add object specific SJQ functionality as user demand 
arises.  Currently, we already support favourites and manual recordings.  User 
feedback will decide if/where we add others.

Original comment by de...@battams.ca on 7 Nov 2010 at 10:33

GoogleCodeExporter commented 9 years ago
Plugin config options removed in favour of your "Assign tasks to events" menu 
item in STVi.  API changes completed in issue 229 for this.  Bugs with this 
feature should have new tickets opened for them.

Original comment by de...@battams.ca on 8 Nov 2010 at 7:52

GoogleCodeExporter commented 9 years ago
Fix verified.

Original comment by de...@battams.ca on 14 Nov 2010 at 2:53