[Tolriq]

Not very important but may impact some other users.

Since a few days in the nightly the button code SELECT during playback does no more rotate trough aspect ratio but now show the OSD.
We can still use other ways like actions and such but is there a new default button in keymap to do this ?
Since I suppose this was the easiest way to change AR.

[da-anda]

AFAIK SELECT did never trigger the change of the aspect ratio but show the OSD - it's like this since I first used XBMC.
Which keymap/remote are you using?

[bibi]

I had the same behavior on last build. I had to add a custom remote.xml to come back on first behaviour.
I use Nightly Openelec so maybe it is a change in Openelec and not in xbmc ?

[Tolriq]

I admit that my message is perhaps not very clear and misses some details

But sending via EventServer the button code R1 - "select" did rotate aspect ratios in Xbmc at least from Eden to Frodo 7th November Alpha.

Perhaps it was not the correct use and it has now be reverted to correct one that's why I reported here only.

Edit for Bibi answer : I'm on official Windows build and some of Yatse user reported this also but don't know on what platform

[khaoohs]

I'm running XBMC (12.0-ALPHA7 Git:20121112-158aac0), Platform: Linux (Ubuntu 12.04.1 LTS), my Harmony One remote configured as MCE remote, the select button still cycles through the AR.

[jmarshall]

The default mapping from <select> to AspectRatio was removed, yes. It didn't make sense for a number of remotes. Feel free to re-map it should you wish (alternatively, the same feature is available on the video OSD->video settings).

[Begall]

Just an FYI, you've left <select> as bringing up the Visualisation menu when in fullscreen music. Perhaps it would make sense to change that to the music OSD so it's consistent with video?

[zarac]

I had the same behavior on last build. I had to add a custom remote.xml to come back on first behaviour.
I use Nightly Openelec so maybe it is a change in Openelec and not in xbmc ?

Could you share your custom remote.xml?
I also like the old behaviour better, but can't figure out how to create the file myself.

Thanks

EDIT:
Nevermind, I finally found out what I was doing wrong.
Here's the contents of remote.xml to revert to the old behaviour if anyone else needs it

Code:

<keymap>
    <FullScreenVideo>
        <remote>
            <select>AspectRatio</select>
        </remote>
    </FullScreenVideo>
</keymap>

[DiQ23]

EDIT:
Nevermind, I finally found out what I was doing wrong.
Here's the contents of remote.xml to revert to the old behaviour if anyone else needs it

Code:

<keymap>
    <FullScreenVideo>
        <remote>
            <select>AspectRatio</select>
        </remote>
    </FullScreenVideo>
</keymap>

Thanks for that.

Quite what the logic behind this change is I can't quite work out. Using "Official" XBMC remote for Android and it seems that I already have a play and pause function. Why would I need more of the same ?

Perhaps all the buttons should be either play or pause, with some both play and pause.

Chicken oriental !

[Begall]

Because select on most hard remotes is the large button in the middle, for which having something as marginally useful as quick aspect ratio changes is a huge waste and very confusing to most users.

[DiQ23]

So you're saying that it's the "official" app that's wrong ?

[da-anda]

why should "select" change the aspect ratio by default? Doesn't make sense to me and is not really intuitive. So IMO current behavior of XBMC is sane.

Also - I personally didn't have to change the aspect ratio of movies, tvshows or livetv more then like 5 times in the last 2 years maybe - so why waste a button on a feature that in future will have to be used even more rarely. (The setting "strip black bars" works pretty nice in case you have a 16:9 movie in 4:3 format).

[DiQ23]

And having 3 out of a very limited number of buttons with the same function as each other does make sense ?

It doesn't seem like a very efficient use of screen space to me.

[da-anda]

If there are buttons doing the same it should be changed - there is no need for this indeed. But the select button should IMO work the same all over XBMC and thus behave like "ENTER" on the keyboard.