Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#7887 closed patch (wontfix)

Additional MusicExitAction option for MythMusic

Reported by: mythtv@… Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: Plugin - MythMusic Version: 0.22
Severity: medium Keywords:
Cc: Ticket locked: yes

Description

The MythMusic plugin provides an option that allows one to control what happens when exiting from MythMusic (MusicExitAction?). Currently, three choices are allowed:

1) Stop playing music and exit.

2) Exit, but keep playing music.

3) Prompt the user with options (1) and (2) every time MythMusic is exited.

If MythMusic is configured to prompt the user, the user must choose one of the two choices in order to exit MythMusic. Canceling the prompt returns the user to MythMusic. The option for prompting the user is extremely useful, but the "cancel" behavior does not lend itself well to home automation remote control macros (such as a macro to turn all home theater equipment off).

Attached is a patch that adds a fourth choice for MusicExitAction? that still allows the prompting functionality, but makes it home-automation-macro friendly. At exit, the user is still prompted whether to stop or continue playing music. However, the "cancel" behavior is different. If the prompt is canceled (e.g. ESCAPE is pressed rather than selecting one of the options), MythMusic stops playing music and exits.

Please fold this into the mainline.

Thank you,
Garrick James

P.S. I am not subscribed to mythtv-dev. If you need to contact me, please email me directly or update the ticket log.

Attachments (1)

mythmusic_prompt_with_exit.patch (1.2 KB) - added by mythtv@… 14 years ago.

Download all attachments as: .zip

Change History (5)

Changed 14 years ago by mythtv@…

comment:1 Changed 14 years ago by Jonathan Martens <jonathan@…>

Your action is an undesired (and to many unexpected change IMHO. After pressing Escape once the user is prompted with the choices you stated above. If the user decides to really exit they should confirm either 1 or 2, if the user decides to cancel it can select option 3. The use can (on a keyboard) also press Escape to effectuate option 3. Escape should be used for backing out, not confirming like you desire IMHO. I doubt that the cancel function (ESC) should be used to exit from this prompt other than the current behavior return to MythMusic as the user cancels the exit.

You are trying to override the cancel to do both, cause option 1: "stop playing and exit" as well as your new option 4: "stop playing and exit", this is a race condition which will not likely be added to the source I think.

You can disable prompting IIRC in the database, which might solve your issues in home automation.

Are you sure your home automation can not send a plain ENTER in order to confirm the first (default option) to stop playing and leave MythMusic after the first Escape which causes the prompt?

comment:2 Changed 14 years ago by robertm

Resolution: wontfix
Status: newclosed

Hi Garrick,

Thanks for your effort. This isn't quite the right way to go about what you are trying to do. The best/easiest way to do so is probably to write an event using our new event amanger code to perform an action when mythmusic is closed (probably a two line patch). the way to work around this *without* code is to simply use the exit to main menu jumppoint to leave MythMusic.

comment:3 in reply to:  1 Changed 14 years ago by mythtv@…

Your action is an undesired (and to many unexpected change IMHO).

How so? This patch does not change *any* existing functionality for the existing possible values of MusicExitAction?.

This patch adds a *new* possible value for MusicExitAction? (yes, with different functionality than the existing three possible values; but that's the whole point of a configuration setting). As long as a user does not select this new value, then MythMusic with this patch works *exactly* the same as MythMusic without this patch. I do not presume to force my configuration preferences on others; merely to make a new and useful option available.

How is adding a new value for MusicExitAction? an undesired and unexpected change?

If the user decides to really exit they should confirm either 1 or 2, if the user decides to cancel it can select option 3. The use can (on a keyboard) also press Escape to effectuate option 3.

Please keep in mind the usage case I'm taking about: an IR remote control macro. The remote has no way of knowing what state MythTV is in (e.g. is MythTV currently in the MythMusic plugin playing music, or in MythTV, proper, playing a recorded show, or in the MythVideo? plugin editing metadata for a video, etc) and no way to know if an on-screen prompt is being presented. For remote automation, there needs to be a single set of remote commands to send to MythTV to cause it to exit out of whatever it is doing and get back to an idle state (preferably back to the main menu) regardless of what it is doing.

When not enabling the "prompt on exit" functionality in MythMusic, the single set of commands to send happened to be a serious of ESCAPEs. Regardless of what MythTV is doing, given enough ESCAPEs, it will exit and eventually get back to the main menu. (For all the plugins that I use, it turns out that four ESCAPEs do the trick no matter what state MythTV is in.)

Escape should be used for backing out, not confirming like you desire IMHO. I doubt that the cancel function (ESC) should be used to exit from this prompt other than the current behavior return to MythMusic as the user cancels the exit.

That is perfectly well if you desire that behavior on your MythTV system. This patch will not change anything for you. You will still have exactly the behavior that *you* desire on *your* systems. All this patch does is add a way for others to opt for behavior different than what you want.

You are trying to override the cancel to do both, cause option 1: "stop playing and exit" as well as your new option 4: "stop playing and exit", this is a race condition which will not likely be added to the source I think.

Uh. There's no race condition here.

If (and only if) a user selects the new option for MusicExitAction?, pressing ESCAPE at the exit prompt will do the same as if the user selected "No, stop playing and exit" (or however it is worded) at the prompt and pressed ENTER. Yes, that could be seen as counter-intuitive for many users and that is exactly why this patch implements this behavior *only if* the user explicitly configures MusicExitAction? with the new value. The existing value of "Prompt" still behaves exactly as you prefer it to (namely, if a user presses ESCAPE at the prompt, they will be returned to MythMusic).

You can disable prompting IIRC in the database, which might solve your issues in home automation.

I don't want to completely disable the prompt. I love the prompt! When I'm interactively using MythMusic and want to exit *and* still have music playing, the prompt is wonderful! I've been using it since 0.21.

But I also want my system to be able to work well with remote control macros. One of the macros I have is an "All Off" macro. It ensures that the TV is off (and set to the VGA input), the VCR is off, the DVD player is off, the A/V receiver is off (and set to the optical audio input coming from my MythTV system), and that the MythTV frontend is in some idle state. This makes it brain-dead simple (just press one button on the remote) for my three-year-old daughter to turn everything off when she is done doing whatever she is doing (regardless if she was watching a DVD, a recorded show in MythTV, or listening to music in MythMusic).

I've been using the prompt-on-exit functionality since it was introduced in 0.21. However, I locally changed the behavior in my 0.21 installation to behave the way the new option that this patch adds behaves. I did not submit my local modifications during 0.21, as it was a fixed, non-configurable change. Now that 0.22 has introduced several different options for what action to take on exit from MythMusic that can be *easilyS selected from the configuration UI, I am submitting the patch. Again, as stated above, the patch only changes the prompting behavior if and only if the new value for MusicExitAction? is explicitly configured by the user.

Are you sure your home automation can not send a plain ENTER in order to confirm the first (default option) to stop playing and leave MythMusic after the first Escape which causes the prompt?

Of course it could, but that is not a universal sequence for exiting every state that MythTV could be in. For example, if a recorded show where being watching in MythTV, and an ESCAPE and then ENTER were sent, the end result would be that the show would still be playing (the ESCAPE stops the playback, but the ENTER starts it back up again). As I stated before, a remote control cannot query the state that MythTV is in and then change it's macro (yes, humans are usually pretty good at that, though). Remote macros always play out in the same order from start to finish every time. (Of course, getting a three-year old to understand that the remote needs to remain pointed in the general direction of the TV is little harder. :-)

This patch does *not* change the behavior of the existing prompt-on-exit functionality of MythMusic. This patch simply adds a new configuration option that enables a new (and, yes, slightly different) behavior for the prompt-on-exit. If you do not personally like that behavior, that is fine--you don't have to use it. However, please consider that others would like the choice to configure their systems to behave differently than yours.

This patch is also brain-dead simple. It adds one new line in one file and changes one line in a second file. The increased flexibility of MythTV is well worth such a light-weight patch. Please merge the patch.

Thanks,
Garrick

comment:4 Changed 14 years ago by robertm

Ticket locked: set

The above novel is *exactly* why you need to be subscribed to the commits list. Please read the ticket howto ref: where discussion goes. The message you responded to was not from a dev, he shouldn't have posted his opinion here either.

Note: See TracTickets for help on using tickets.