[Milhouse]

To clarify, I'm only talking about PR5307, making it so that "play" does not also pause if something else is playing (and not selected in a list in the GUI). Now "play" does nothing in that situation, and no additional ability is gained and no other behavior is changed, as far as I can tell.

Not sure what you mean. PR5307 accomplishes two things as far as a remote is concerned: 1) <play> now toggles playback, so in a list it will pause the playing item (eg. music) and then continue playback when pressed again - previously it would always restart playback; 2) It resumes playback during trick-play when the <play> button is pressed (without the 3rd commit, it would switch to pause when fast forwarding/rewinding).

Edit: Ignore, just seen your post #15.

[Ned Scott]

I thought the music behavior was unchanged from that (at least vs v13?), but you got me about the trick-play resume normal speed part. I didn't think of that. Well, okay, then I'm fine with all of them :D

[Milhouse]

With all that considered, I concluded that it wasn't an issue to advise people to copy the whole keymap file in order to learn and easily make changes.

I've tried to think of some kind of wording that would prevent users from duplicating maps wholesale (or any other setting, for that matter) and I've failed to think of anything that doesn't make the process even more complicated. But even with an appropriate warning, there will always be users that don't read or comprehend the warning and copy entire button maps/settings regardless, rather than cherry-pick.

So I guess we live with the current situation, with some users unintentionally enforcing legacy default behaviour with their custom maps (which in reality might be changing one mapping out of 20+), but this shouldn't prevent default behaviour being changed/improved in future. Anyone applying a custom map is responsible for the mappings from that point onwards - if the default behaviours change but their custom mapping doesn't, IMHO it's their problem as that's surely the accepted risk of making such changes.

I'm also no longer sure the problem reported by Wotok is due to the PlayPause change.

I thought the music behavior was unchanged from that (at least vs v13?), but you got me about the trick-play resume normal speed part. I didn't think of that. Well, okay, then I'm fine with all of them

It's such a long time since I used v13 that I can't be 100% sure but I believe (in OpenELEC, at least) that the VRC-1100 would restart music in a playlist as the remote only outputs the KEY_PLAY code, and with the <play>Play</play> mapping, non-full screen windows (eg. playlist) would interpret the command literally and restart the currently playing item rather than pause it. It was never a problem with full screen playback, where <play>Play</play> would toggle (behaviour removed by PR5245). Certainly this was how it behaved in early v14 until the changes from da-anda.

With PR5245 the Play function only resumes playback - it no longer toggles between play and pause. PR5307 fixes this by changing the default <play> button mapping so that it does toggle.

If the user wants the old behaviour, which is now broken by a custom mapping, they need to change their map so that the <play> button is mapped to the PlayPause function (or better yet, not mapped at all).

I think the new default mapping is saner, but it was always going to break some setups that were enforcing their own behaviours.

[Milhouse]

I changed my remote.xml to this and still no joy. The play, pause, stop, seek forward and seek backwards buttons do nothing at all except make the receiver blink. They work in the Videos Ubuntu application though. (Well, not the seek back and forward buttons).

I would suggest starting a new thread, perhaps in the Linux sub-forum, along with a debug log (wiki) of you pressing the various buttons, as you have more non-functional buttons than are addressed by this thread which deals only with a *working* Play button and the function to which it is mapped.

As far as I understand it, if you're using the system default button mappings and are not using a custom mapping, you should not require any remote.xml/keyboard.xml changes when switching to Kodi 14.

[Ned Scott]

Actually, we do now have that awesome keymap editor add-on... hmm, I think that's enough for the newbies :)

[Wotok]

I tried the keymap editor, but it didn't work for me. Tried to fix the stop button if I remember right and it didn't change anything.

As suggested, I started a new thread here: http://forum.kodi.tv/showthread.php?tid=209933.

Thanks for your assistance!