Feature description:
Using Symfonium on the TV, it makes most sense to set Now Playing to the expanded landscape player. This puts a panel showing the current queue in the upper right, like this:
https://imgur.com/a/56yKcHp
The difficulty here is that the Queue doesn’t scroll on its own, it just changes the selected item. So what started as a nice list of the upcoming tracks quickly becomes ancient history.
I wish that at least in this mode, whenever the current track advances, the queue would scroll down, keeping this at the top.
A similar request was denied in the past (Now Playing Queue Track Playing Stay Focused) but I think this is sufficiently different to warrant reconsideration. Part of the justification for denying that past request was “There’s a button that appears when the current track is out of view, clicking it brings the current track into view.” But as shown within the Now Playing view, there is no such button, so the problem isn’t easily solved by the user. That response also noted possible unintended effects if the user is currently scrolling themselves. I think this is minimal if it’s implemented as “scroll current track to top when the current track changes”, since the tracks only change ever few minutes. But if that’s still too nasty, this behavior could be limited to only the context of Now Playing (where the rationalization of “this is showing what is, you know, now playing; it’s not primarily a navigation tool” is much stronger).
Problem solved:
When shown in the Now Playing view, after playing a few tracks the Queue becomes misleading because the current and future tracks are no longer shown.
Brought benefits:
With this feature implemented, I’ll always be able to see at least the next few upcoming tracks. I like to have that because it lets me remove anything undesired from the queue before they play.
Other application solutions:
PlexAmp will show the upcoming tracks below or to the right of the Now Playing details (depending on window size and orientation). As the player advances through the queue, the just-finished track is moved into a (normally unselected) “Back To” tab, while the future queued items are visible in the default-selected “Up Next” tab.
Additional description and context:
Screenshots / Mockup:
You are supposed to use the Android TV version on Android, that have specific layouts and things.
I’m using the version that Google Play and the installer decided to install for me. My device is an “X88 Pro 13”, which I think is fairly common (Amazon.com : x88 pro). It seems to think of itself as running Android 13, as opposed to a specific Android TV version.
I think you’re saying that anybody who has such a device and wants correct behavior needs to find a way to download the official xapk (which I can manage), and then manually extract whatever the Android TV binary is (which I don’t know how to do), and force it to install that?
Are you telling me that it will have the behavior I’m asking for, if I’m willing to go to that trouble every time a new version is released?
EDIT: the screenshot I included is from my phone, if that’s what you’re referring to. It’s not the device that I’m making the feature request for, just an easier way for me to take a screenshot and extract that image file to post here. Separately, I also have at least one bug I want to report, but I’m not doing so because I have to figure out how to get the log files off that X88 Pro (I expect that transferring through Google Drive will probably be easiest). But that’s a separate conversation.
Android TV requires a lot of things to work with remotes, there’s tons of specific code and UI things only in that build.
The normal app is not made for Android TV, not really my problem if your device think it’s a phone.
You can try aurora store or other ways to install the proper version.
For the logs, you can directly upload them from the app.
You didn’t answer my question: “Are you telling me that it will have the behavior I’m asking for, if I’m willing to go to that trouble every time a new version is released?”
What I’m telling is that you certainly won’t have that with the non TV version.
So if you don’t have the will to do it, I certainly won’t add something that no one will use.
So I’m saying that I will make the effort, if you believe that it will do what I want. But why would I try if it’s not going to work anyway? I don’t get why you won’t tell me whether it should be able to work.
I imagine you’re probably thinking “it’s a weird device, who knows what it’ll do”. I’m not asking for a guarantee of that. I’m asking what the intended behavior is.
You already know it does not work like that …
You make a feature request, I give you the pre requisite.
So it’s up to you either you move to the Android TV version and I’ll look into that else I won’t as already said on the other issue.
