Closed GoogleCodeExporter closed 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
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
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
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
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
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
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
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
Fix verified.
Original comment by de...@battams.ca
on 14 Nov 2010 at 2:53
Original issue reported on code.google.com by
tom.mira...@gmail.com
on 6 Nov 2010 at 8:16