Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Hendrik]

Over the last year we've been working on an all-new JRemote for Android, dubbed JRemote2.

Today, we're finally ready to officially announce its release! Some of you may have already found it on the Play Store and followed its Beta, but now its official!

This thread is about JRemote for Android only. iOS will continue to use the app it currently has, which Bob is maintaining.

Lets get to important things first:

Play Store: https://play.google.com/store/apps/details?id=com.jriver.jremote2

If you sign-up for the beta, you'll receive early updates, but be warned that we may be testing changes in Beta which may not be 100% proven yet. You can always opt-out of the Beta again in the future.
Beta Sign-up: https://play.google.com/apps/testing/com.jriver.jremote2

JRemote2 is available for $9.99 on the Play Store now.

The history of JRemote for Android, or, Why JRemote2?

JRemote was created back in 2015 by Lespaul, after he joined JRiver and we acquired JRemote for iOS from him. Unfortunately, he left JRiver before JRemote for Android was ever fully finished, at which point I was asked to salvage it and get it out to you guys. Unfortunately, being thrown nose first into the deep-end of a foreign code-base is not a good situation under the best of circumstances, and I wasn't exactly an experienced Android developer at the time either (and Android in 2015 was also in a much different place then it is today). Eventually we did produce a working JRemote for Android, at least I've been using it almost daily for years now, but it was never what it could've been.

Jump to six months ago, when Jim asked me to look into some of the reported issues in JRemote, my first step was to bring it up to date to the latest Android kit, at which point I already noticed that it hadn't aged well at all. While many of the development concepts used in JRemote were still very similar to what has become the standard today, the implementation was not. JRemote used a dozen or so third-party libraries, many of which had disappeared over the years - often because Google had created something similar for every Android developer out of the box. It didn't take me long to decide that it would be better to start almost from scratch.

JRemote2 is born

JRemote2 was created practically from scratch. The only thing I did re-use is the UI design, for one I think as a starting-point it was solid, and it makes the app feel familiar.

Everything else is new. Not a single line of code was simply copied. JRemote2 is written in Kotlin instead of Java, which has a lot of advantages, including crash-safety and a faster turn-around on new features, and I used all new modern Android development concepts and libraries, based on Android JetPack, a toolkit from Google to make modern apps.

Audio and Video Playback now uses Google's ExoPlayer2, which is far more capable then the default MediaPlayer JRemote used previously, this means we can support lossless FLAC up to 192/32, including gapless playback. And its extensible, which might allow us to add more native formats, and add some core DSP features like Volume Leveling in the future.

One key focus of JRemote2 is to make it reliable over all else, and hopefully we can deliver on that. Features that do get built-in should function reliably, and the app should ideally never crash.

What can you expect?

JRemote2 is still in full development, but we are confident that in the majority of cases JRemote2 is a solid replacement for JRemote and/or Gizmo. But be assured that we're not done with it yet, and many additional features are planned over the course of 2020.

Overall we're pretty confident about JRemote2, as it has shown a much better stability and responsiveness than the previous app, and additional features will be worked on over the coming weeks.

Current Features:

• Local Playback of Video and Audio streamed from Media Center
  • Native Audio Playback for MP3, M4A AAC, FLAC (Gapless!), OggVorbis
• Remote control Media Center
• Play Doctor
• CloudPlay
• ChromeCast
• TheaterView Remote, known from Gizmo
• SSL support
• Preliminary Metadata Display

While the current feature list may seem short, those are the key foundation features that everything else eventually builds up on.

Coming Soon:

• Image Support
• Improved Landscape and Tablet Layouts
• Full Playlist integration, with edit capabilities

And finally, Planned Features for 2020:

• Volume Leveling
• Streaming Improvements
  • Newer audio formats, AAC for lossy, investigate Lossless transcoding (FLAC transcoded streaming?)
  • Improved video streaming - more control, higher quality, avoid transcoding if possible
  • Streaming Live TV
• Most Importantly: Your Feedback
• .. and things I haven't even thought of, yet, or forgot when writing this list!

Feedback

We strongly rely on your feedback to make JRemote better. No single person will ever use every aspect of JRemote extensively, and everyone has different priorities of what it should do. So please do let us know!
For the time being, please keep in mind however that its still very much in-development, and this is a first look.

Known Issues / Missing Features

- The Search view in the Nav Drawer is not implemented yet
- Playlists cannot be "linked" to Playing Now yet, so you can't reload a playlist.
- Modifying Playlists, other then the Playing Now list itself, is not implemented yet

[Hendrik]

JRemote 2.3.0 (02/04/2021)

1. NEW: Selecting the audio/subtitle language during video playback on JRemote2 (requires Media Center 27.0.61 or newer)
2. Changed: HLS Video Streaming is enabled by default.

JRemote 2.2.0 (09/08/2020)

1. Fixed: JRemote2 will properly refresh the CloudPlay login if it expired or becomes invalid.
2. NEW: Support for native ALAC playback.
3. Changed: Moved Play Mode from the action bar to the "kebab" overflow menu, with icons and proper selection list.
4. Changed: Play Mode is saved on a per-view basis similar to the view mode, allowing eg. audio views to default to Play All and video views to Play Single.
5. NEW: Added server system control commands (Shutdown, Restart, Sleep).
6. Changed: Casting to ChromeCast supports longer playlists.
7. NEW: Improved video streaming to ChromeCast with Media Center 27.
8. NEW: Optional HLS video streaming when playing locally for more reliable playback (requires Media Center 27).
9. Changed: In local playback, the "Previous" button behaves in a CD-player style, returning to the beginning of the track on a single click, and to the previous track on double click or when near the beginning.
10. Changed: Increased the height of the video seekbar touch area for better control.

JRemote 2.1.0 (04/10/2020)

1. NEW: Full CloudPlay support (requires Media Center 26.0.52 or newer)
2. NEW: Theater View Remote
3. Fixed: Saving Rating changes was not working properly

JRemote 2.0.9 (01/16/2020)

1. NEW: Implemented Wake-on-LAN
2. Changed: Added a long-click popup on the server list, which allows editing/deleting/waking servers.
3. Fixed: Resolved an issue that prevented JRemote2 from starting on Android 4.x.
4. Fixed: Repeated attempts to connect to a server would silently fail, instead of actually re-trying.
5. Changed: The Playlist navigation will no longer skip empty levels.
6. Changed: With MC 26.0.17 or newer, JRemote will avoid the default placeholder images for playlists or library folders.
7. Fixed: Adjusted the visibility of the fast scroll popup in the dark skin, and made the entire popup bigger.

JRemote 2.0.8 (01/10/2020)

1. NEW: Native OggVorbis playback support.
2. NEW: Google Cast support.
3. Changed: Hardware Volume keys can be used to control volume when remote controlling a Media Center instance.
4. NEW: Improved Fast Scrolling in Library and Track views, with Alphabet popup in Library views.
5. Fixed: "Screen Always On" now works as expected.
6. Fixed: JRemote could resume on the Playing Now screen when returning from Standby instead of the last location.
7. Fixed: Video duration is properly shown on Playing Now for local playback.

JRemote 2.0.7 (12/06/2019)

1. Fixed: Using the refresh button in library views would result in icons to be shrinking.
2. Changed: Internal changes to how the Playing Now view is being handled, please report any problems.
3. Changed: Enabled access to the navigation drawer from Playing Now.
4. Changed: Updated the navigation drawer for better support for Android 10.
5. Changed: The Playing Now layout has been updated according to forum feedback.
6. Changed: The name of the current server is shown in the Zone dialog and next to the zone name in Playing Now.

JRemote 2.0.6 (12/04/2019)

1. NEW: View Metadata of individual Tracks.
2. NEW: Support for JSON File Lists for better performance and support for longer lists (requires Media Center 26.0.9 or up).
3. Fixed: Stability improvements and glitch fixes.

JRemote 2.0.5 (11/27/2019)

1. Changed: Significant performance improvements when loading a long list of tracks.
2. Fixed: Stability improvements.
3. Changed: Faster connection to servers if mutliple IPs are available and not all are reachable.
4. Fixed: The Navigation Drawer opens much more consistently and predictably.
5. Changed: Increased the responsiveness of "App follows Sever Zones" in combination with ZoneSwitch.
6. NEW: Implemented the Edit Server dialog.
7. NEW: SSL/TLS support.

JRemote 2.0.4 (11/21/2019)

1. Changed: The Zone selector dialog refreshes the zone list on show, and has a manual refresh button.
2. Changed: Closing Playing Now will always restore the Main Activity, even if it wasn't open before (eg. when coming from the notification)
3. Fixed: Remote Controlled Playback uses Error Free Mode to avoid popup dialogs on the server.
4. Changed: Using the "Back" key on the root view will open the Drawer, and close JRemote on another "Back" press, instead of closing directly.
5. Fixed: Stability and responsiveness improvements.

JRemote 2.0.3 (11/20/2019)

1. Changed: Updated to ExoPlayer 2.10.8, fixing an issue detecting certain FLAC files.
2. Changed: The Notification is dismissable when playback is paused, which will stop and shutdown the player.
3. Changed: The current JRemote2 version is shown in the top of the navigation drawer.
4. Fixed: When streaming video, Playing Now would claim its receiving MP3.
5. Changed: The keyboard is automatically hidden on the Add Server screen, and no longer obscures any error messages.
6. NEW: Cover Art in the Notification
7. Changed: Enabled horizontal text scrolling (marquee effect) on Playing Now and the artist field in the track list header.

JRemote 2.0.2 (11/19/2019)

1. NEW: Play Doctor support
2. Fixed: Server List would show one corrupted entry

JRemote 2.0.1 (11/19/2019)

- Initial Internal Beta Release

[Hendrik]

I've collected a few common requests that'll be worked on in the near future:
- Volume keys when remote controlling MC (they already work for local playback) (done)
- Indication which server you are currently connected to (done)
- Improved scrolling in long lists (the current grabbable quick-scroll bar is too small, and no alphabet display) (done)
- Option to disable ratings (also, changing the ratings in Playing Now doesnt work yet)
- Playlist views (and others) show the ugly default folder icon in their header (done)

[Awesome Donkey]

Congratulations on this milestone! JRemote2 has been incredibly stable in my testing, and can play all my native FLAC files on my phone regardless if they're 16/44.1 to 24/192 (which other remotes can't go beyond 16/44.1 but JRemote2 can on my phone, thanks to ExoPlayer2 no doubt).

I've collected a few common requests that'll be worked on in the near future:
- Volume keys when remote controlling MC (they already work for local playback)
- Indication which server you are currently connected to
- Improved scrolling in long lists (the current grabbable quick-scroll bar is too small, and no alphabet display)
- Option to disable ratings (also, changing the ratings in Playing Now doesnt work yet)
- Playlist views (and others) show the ugly default folder icon in their header

Yes please to all of those.

I'll post my revised feedback and feature requests lists...

Feedback:

1) What do the refresh/reload buttons do? Sometimes I add new stuff to my library, but they don't show up in JRemote2 unless I force quit the app and reopen it. I thought the refresh/reload buttons might fix that but they don't seem to do anything, as far as I can tell, hence my question. Like I add a new album for an existing artist in my library, in JRemote2 go to the artist I added a new album to, and look at the albums list. The newly added album isn't in the list and I press the refresh/reload button at the top right, and it doesn't make the new album appear. So the button there kinda confuses me to its purpose. If that's not how it works, having a feature that does this seems like a good idea to me, IMO.


Feature Requests:

1) Option to allow the Previous |< button in Now Playing to restart the current track instead of going to the previous track. Double pressing the Previous |< button could then be used to go back to the previous track. This would really come in handy and would address my biggest annoyance right now, trying to restart the currently playing track but instead after pressing Previous it goes to the previous track. Right now I have to try to use the seekbar to restart the track (which usually doesn't work too well, as I tend to 'restart' tracks a couple seconds into the track).

2) Have Settings and perhaps My Servers shortcuts in the three-dot menu in Now Playing.

3) Option to remember the current Playing Now list between runs (aka option to store the local playlist between runs).

4) Screen always on setting added (or amend the existing one for video) to work with audio during the playback of audio. I guess I could also see the use case for an option to always have the screen on regardless of playback state, for those who create a little system using an Android phone/tablet as a navigation/progress/control device. I do admit, creating something like this is rather tempting.

Out of all of these, the first one and the third ones are the most important to me (but first one over the third, easily). Like a bonehead, I keep making the mistake of trying to replay the currently playing track by pressing the |< (previous) button, only for it to play the previous song and not restarting the currently playing track... then I have to facepalm at my mistake at doing it once again. I guess I'll never learn, huh? Also I've also noticed if you only have one song in your Playing Now list, the |< button doesn't actually do anything (neither does the >| next button for that matter) but I'm not sure if that's intended. They should at least do something, right?

[HTPC4ME]

Thanks Hendrick for the update, and for re-creating/polishing this up... MUCH APPRECIATED!
few bugs/wishes from other thread, of things ive notcied/would enjoy seeing.


bugs/wishes:
1. editing of servers does not work/nor ability to rename servers
6. no sleep timer
7. no widget for homescreen
8. ability to adjust volume increments by 1% instead of 5 in original jremote/first volume button / media volume seems too loud for lowest setting
9. no ratings/or editable ratings on video playback

Thank you

[Hendrik]

1) What do the refresh/reload buttons do? Sometimes I add new stuff to my library, but they don't show up in JRemote2 unless I force quit the app and reopen it. I thought the refresh/reload buttons might fix that but they don't seem to do anything, as far as I can tell, hence my question. Like I add a new album for an existing artist in my library, in JRemote2 go to the artist I added a new album to, and look at the albums list. The newly added album isn't in the list and I press the refresh/reload button at the top right, and it doesn't make the new album appear. So the button there kinda confuses me to its purpose. If that's not how it works, having a feature that does this seems like a good idea to me, IMO.

The Reload button works, however MC caches the view structures for a bit (a minute at most, IIRC), so when you work on your server and then immediately refresh in the app, it might not be there yet, but give it a minute or so and Reload should then work.

[Hendrik]

8. ability to adjust volume increments by 1% instead of 5 in original jremote/first volume button / media volume seems to loud for lowest setting

The volume increments for on-device playback are controlled by the device itself. I just display it as 0-100%, but for the device it might be 0-20 or such (depends on the device, I ask it for the range and translate that to 0-100), and you don't get any more granularity.

[Awesome Donkey]

The Reload button works, however MC caches the view structures for a bit (a minute at most, IIRC), so when you work on your server and then immediately refresh in the app, it might not be there yet, but give it a minute or so and Reload should then work.

Ahh, gotcha. I'll have to add something new in and test that.

1. editing of servers does not work/nor ability to rename servers

This works for me. Does the EDIT button not work? I'm able to press EDIT and change the name and server details. Do note I'm using IP addresses, not access keys so maybe that's different?

Since you brought it up, here's a thought... why can't we set a server name as we're setup the server (via access key or IP address) when adding the server details - something like a Server Name field under the Access Key field (for access key method) or the Server address or IP and Port (for IP address) fields?

[Hendrik]

Since you brought it up, here's a thought... why can't we set a server name as we're setup the server (via access key or IP address) when adding the server details (a server name field somewhere, maybe at top or below authentication details)?

Honestly, because most people won't need that. It'll query the name from your server on first connection, and only if you need various different ones would you ever want to set a specific name, I reckon.

[HTPC4ME]

editing of servers/rename....must have just been fixed recently.... was not working on S7, and i was using access keys.
TY!

Hendrick just an FYI.. on physical media/volume buttons, when loading EOS, and pressing volume down button on the S7 it would be MUCH lower for me on EOS, then Gizmo or jremote. Not sure why... but the lowest setting was considerably lower on the SAME device.

EDIT....(i dont have a different/newer device @ this time to test,)

[Awesome Donkey]

editing of servers/rename....must have just been fixed recently.... was not working on S7, and i was using access keys.

Yep, it was added in 2.0.5. It works great now.

[HTPC4ME]

TY Awesome Donkey

[JimH]

Thank you, Hendrik!

[DJLegba]

The Reload button works, however MC caches the view structures for a bit (a minute at most, IIRC), so when you work on your server and then immediately refresh in the app, it might not be there yet, but give it a minute or so and Reload should then work.

I have a view that shows albums in random order, which I like to use when I haven't decided what to listen to. I thought the reload button just didn't work, but now I see I have to wait a minute or so and it will give me a new list. It would be nice if reload first cleared the cache (or if there was an option to make this happen).

[Hendrik]

I have a view that shows albums in random order, which I like to use when I haven't decided what to listen to. I thought the reload button just didn't work, but now I see I have to wait a minute or so and it will give me a new list. It would be nice if reload first cleared the cache (or if there was an option to make this happen).

The Cache is in MC, can't influence that on the apps side, unfortunately. We recently already changed it to clear itself after a minute, instead of being stuck until MC restarts.

[DJLegba]

The Cache is in MC, can't influence that on the apps side, unfortunately. We recently already changed it to clear itself after a minute, instead of being stuck until MC restarts.

It must be a cache specifically for remote views, as reloading a view with a random order within MC works immediately. So could another change to MC be clearing the cache in response to a request from the remote?

[rakon]

Playlists which are larger than 10,000 Tracks don`t work!

[DJLegba]

The metadata display is great, and it's fantastic to see the date fields display correctly. I realize that only non-empty tags are displayed. On a particular track, under Copyright I see Date with a value of 43101 and below that Date with a value of 2018. Looking at the same tags in MC I see "Date" with a value of 2018, and below that a non-editable tag "Date (filename friendly)" with a value of 20180101-000000.

[Hendrik]

Playlists which are larger than 10,000 Tracks don`t work!

So make them shorter
Or make a smartlist that provides a small random excerpt of the bigger list.

And there is no inherent limit to how big playlists can be, another user just tested a playlist with 111.000 entries and it was fine for him. The only reason it would fail is if your phone runs out of memory.
With JRemote 2.0.6 and MC26, the performance should also improve significantly and allow larger lists.

[rakon]

hmmmm.... it seems ..i need a Tablet with more than 3 Gigs of RAM

but i have only  Ver. MC 25.0.114, but i bought the Key for MC26!

[JimH]

MC26 will be available by mid-December.

[Hendrik]

The metadata display is great, and it's fantastic to see the date fields display correctly. I realize that only non-empty tags are displayed. On a particular track, under Copyright I see Date with a value of 43101 and below that Date with a value of 2018. Looking at the same tags in MC I see "Date" with a value of 2018, and below that a non-editable tag "Date (filename friendly)" with a value of 20180101-000000.

The Date field with 43101 is not formatted yet, for some reason MC has two ways to present dates, I'll add formatting to that.
The second one is probably cut-off by its name, not sure yet what to do about cut-off field names here. The "filename friendly" field is probably not included at all, since its a calculated field.

[rec head]

1) Great work, I like how responsive it is.

2) REQUEST: It would really be nice to be able to set a default zone for startup. I will almost always want to play to the device but occasionally directly to my AVR. Doing this turns on the AVR and starts blasting music through the house even if I'm not there. I know it is my fault and I'm asking you to protect me from myself. MO4media allows this and it has saved me a couple times I'm sure.

3) I never used the first JRemote but I think it is weird UI to have the volume slider next to the player controls and the time elapsed bar (which can be used to fast forward and rewind) at the top.

[Awesome Donkey]

3) I never used the first JRemote but I think it is weird UI to have the volume slider next to the player controls and the time elapsed bar (which can be used to fast forward and rewind) at the top.

I kinda agree with this, it's kinda hard dealing with the seekbar on the top (along with the Song Title - Artist - Album info but you do get used to it. I could live with an option hiding the volume slider (and moving the seekbar into that position) since I personally don't have a use for it.

[Hendrik]

I believe this layout was chosen because JRemote for iOS uses it. But I generally agree, the seek bar on top feels weird, it should be at the bottom with the controls, and either leave the top empty, or use the space to show a bit more text.
But where does the volume go? Stay where it is, below the controls (maybe shrink it in height a bit), and seek bar on top of the controls? Maybe a speaker icon with a popup thing? Not sure how well that would work. Or no volume bar, and rely on the buttons only, like many other player apps tend to do?

I'm open to suggestions here, better to change it now then later, and right now all the layout was mostly just taken from the old JRemote, which was based roughly on JRemote for iOS.

[rec head]

I'm fine with just the buttons that is what I tend to use anyway. I'm also usually playing from widgets so volume isn't even an option.

Perhaps some kind of small indicator like phone reception bars to show roughly where the level is at if people really need it.

[milsdrewbulch]

Thank you so much for the effort being put into this!

As it stands, the volume control is terrible compared to the first release of JRemote for Android though.

The phone or tablet volume toggle switch does not control playback volume in a zone on MC like it did so well in the original JRemote for Android with 1% increments which were great.  It gave a very sophisticated way to adjust internal volume when played back on a hi-fi system.

With the large 7% increments you can get get clicks through the hi-fi and it's pretty awful and clunky.

When playing to "This device" in Jremote2 (something that I don't do other than for this test) the switch works to slide both the Android "Media volume" and JRemote2 slider simultaneously (with those 7% jumps which seems OK on the phone actually), but when controlling a zone on MC, the only way to adjust the volume using the phone is with the screen slider that more often than not just swipes the screen left.

It would be great to see it reverted to the most brilliant way that it worked in the first version and with 1% increments when controlling MC zones.

[HTPC4ME]

+1... I'd prefer seekbar on bottom (near player cntrls) vol on top as well. (didnt notice this.. have only ran  jremote2 video library so far, upon going to audio then i noticed it.)

also just an fyi... Volume...had time to play w/ jremote2 and eos today, and i can confirm (not sure about others w/ other devices/non Galaxy S7) but when in eos and using volume keys/side of phone, your 1st YOL up. one can barely hear the audio, next click tad louder, when using jremote. it's considerably louder from a mute/off volume postion to the 1st vol up click. (not sure if this can be fixed, or if im the only experiencing it.. but seems 2b issue from my tests)

[HTPC4ME]

also to add.. i just opened playerPro (app that plays media files on device) and volume was different from EOS and Jremote2. It seems like each media app hardkey volume button pres up. is different... player pro/eos... takes about 2-3 volume up clicks to hear audio quietly. (bout 4-5 clicks to = jremotes first volume click.)

[RoderickGI]

On my Sony Xperia XZ Premium, Android 9.

I don't mind the layout the way it is, but I could live with a change if others hate it.

I would not like to have two bars down the bottom, being the Seekbar and volume slider. The current layout separation makes it possible to use either control with fat fingers. So if you move the Seekbar down, you must be able to (optionally?) turn off the volume slider display, and the physical buttons must control volume on a connected MC Server. Of course, then I would lose the volume % display, which would be annoying... Maybe leave a speaker icon somewhere, with a % volume display overlaid?

When I play on the Sony, my physical volume buttons control the volume and a volume slider pops out from the right, which has "fine" control. This is good. The Pop-out also has a musical note symbol, which when tapped mutes the volume, and when tapped again, returns the volume to its previous value. I think the JRemote2 speaker symbol to the left of the volume slider should work the same way. See image. If the volume slider was turned off or removed, and a visible speaker icon displaying the % was retained, then tapping that should mute/unmute volume, as above.

As explained above:

The volume increments for on-device playback are controlled by the device itself. I just display it as 0-100%, but for the device it might be 0-20 or such (depends on the device, I ask it for the range and translate that to 0-100), and you don't get any more granularity.

So the smallest volume increments in JRemote2 depend on the number of increments the Android device provides, and that is rounded up to a 0 - 100% scale. It appears that my Sony uses 30 increments, as each increment in JRemote2 is 3.333333%. i.e. It needs three steps to go from 50 to 60%, showing 50-53-56-60%. So if the volume increments 7% with one click, that means the device only has 15 increments based on the hardware buttons.

However, if controlling an external MC installation, then the number of volume increments on the device should not matter. Or at least it sounds like the original JRemote for Android, EOS, and Player Pro worked out how to do smaller increments on an external device. I would like that when controlling volume on a MC installation. So I guess I support this:

It would be great to see it reverted to the most brilliant way that it worked in the first version and with 1% increments when controlling MC zones.

If that needs to be driven by the Volume Slider, the layout becomes an important issue for me again. So, the answer depends on what is possible in controlling a MC installation with the physical buttons.

PS: I note that the volume slider can control the volume of a MC installation in 1% increments.

[Hendrik]

When remote controlling MC there is definitely no limit on the volume granularity - other then your finger precision on the bar. It should offer full 1% step precision. Of course as mentioned it doesn't actually accept hardware keys right now, but thats a seperate topic.

The precision limit only applies to the on-device player, as it doesn't even take a percentage, it takes an "index", which goes from 0 to max, and when max is 30, then you only get 30 steps.

[Hendrik]

Here is an example with the seekbar at the bottom (on top of the buttons, as that makes more sense to me), and volume on top



How does that look? Feels already better to me.

[Awesome Donkey]

Indeed, feels much better. Though personally I don't need the volume controls (my Android phone's on-screen controls are pretty good) so being able to hide it would be great.

But honestly the *only* other thing, which just feels weird about the layout to me, is the track title, artist and album at the very top. Typically in the majority of Android media players (e.g. every one of them I've tried including Poweramp and Neutron), the information (using your mockup above as an example) is usually always right below the album art display. Personally, I like it like this...


                                                                    Track Title
                                                                 Artist - Album
Elapsed Time                                   Track Number of Track Total                                   Time Remaining
                                                                     Seekbar

Yes, this would likely use up some of the space (likely for the album art or the volume controls if hidden) but this would be worth it to me. This way you have room for more buttons at the top if desired or you could use that area to put the current server indication.

[Hendrik]

Typically in the majority of Android media players (e.g. every one of them I've tried including Poweramp and Neutron), the information (using your mockup above as an example) is usually always right below the album art display. I think right below the album art it should go like this...

For the record, the Google Play Music player is just exactly like JRemote in this regard..

The problem with taking too much space from the cover art is that it'll shrink and leave room on the sides. I could set it to be cut-off instead and always fill the full horizontal space, but in tests that also looked weird.
As an alternative I could test making the top controls translucent, or at least the rating bar and the two control buttons, and have that overlay the cover art, but at least the rating stars might stand out too much and ruin it (stupid rating stars)

[Awesome Donkey]

For the record, the Google Play Music player is just exactly like JRemote in this regard..

Yuck! Well, Google isn't known for their great designs.

The only alternative idea I have is to move that top bar containing the track information and the three button menu to the bottom. Neutron has something like this, so it'd work for me too. The X close button is a bit of a potential issue, if it's moved to the bottom too it could get accidentally pressed when using other controls. I suppose leave it at the top with the other buttons and ratings or something? If the rating stars are hidden, then having translucent controls wouldn't be an issue. Stupid rating stars indeed.



EDIT: In my screenshot of Neutron above, I see a couple translucent controls on the album art including an X close button. Odd place to put that indeed.

[Hendrik]

I would want to keep the top toolbar, as the top left close/back button is pretty standard android UX. I wonder how it would look if I ban the rating to up there?

In fact, it looks decent to me:


Thoughts?

[Awesome Donkey]

Works for me!

Plus the room at the top could come in useful in the future, e.g. new buttons and whatnot. Could potentially even add the current server info at the top too like move the rating stars slightly up to put the server info under it? Or even above the rating stars, I'm not sure which would look better in that case.

[Awesome Donkey]

I think server info above the rating stars (with the stars moved down towards the bottom part of the top bar) looks pretty good. Here's a quick 10 second mockup mod of yours I did with how it'd look if I was using it with my Pi server...



That... actually looks rather good.

EDIT: I did a second quick mockup (for the fun of it) to see how it'd be like to have the Elapsed Time/Track Number of Track Total/Time Remaining fields above the seekbar instead of below. I'm not sure if it looks better or not like that even though I'm personally leaning towards liking it because it *does* make sense to me with the song title/artist - album fields above it. On the other hand I can see how leaving it alone gives more room above and below from accidentally hitting another button when seeking, so it doesn't matter to me which way it goes in that case.

[Hendrik]

EDIT: I did a second quick mockup (for the fun of it) to see how it'd be like to have the Elapsed Time/Track Number of Track Total/Time Remaining fields above the seekbar instead of below. I'm not sure if it looks better or not like that even though I'm personally leaning towards liking it.

The reason I put it below it was to give a bit more space between the touch interactive elements of the seekbar and the control buttons, to reduce accidental clicking.

[Awesome Donkey]

The reason I put it below it was to give a bit more space between the touch interactive elements of the seekbar and the control buttons, to reduce accidental clicking.

I literally added that conclusion to my post above after looking at it more, hahaha. If it was switched around, you'd have more of a chance accidentally clicking the zone and player controls buttons than how it'd be if it was left alone. So it makes sense leaving that as-is when taking that into consideration because it adds about equal distance of "padding" between the shuffle/repeat and zone/player control buttons to avoid accidental presses.

[JimH]

Before you start moving much around, we should probably have a general discussion of how remote interfaces should work.  I've been thinking about our other remotes, as well.  It would be nice if there was some consistency among them.

And it should probably be in a separate thread.

Home and Back are the most important navigation buttons for me.  I'd like to see them in that order in the upper left corner.

Theater View works by using the left arrow key on a remote or keyboard to back up. 

The X in JRemote2 gets used as a back button sometimes, doesn't it?

Brad and I have had a discussion about whether the "standard" Android navigation is right or even standard.  No conclusion so far.

I'll split this to a new thread.

[JimH]

I'd also like to have a Playing Now icon available on every screen, or at least most screens.  It's hard to find now.

So, my recommendation is to have icons like this:

[Home]  [Back]                                      [Icon1]   [Icon2]  [Playing Now]

where Icon1 and 2 are used as needed.

I think it's important that we make the navigation reasonably consistent across JRemote2, Panel, JRiver for Android, Gizmo, etc.

[Hendrik]

You can access Playing Now from every screen already, just click the Player Bar at the bottom.
And JRemote really has no "home" screen, because thats the drawer, which you can access by swiping.

The Toolbar is actually quite limited, you can only fit so many icons on there, and the ChromeCast Icon is still missing, which already maxes it out, it literally has no room to hold 7 icons or such without doing a full custom job (which I'm very much against, since the chromecast component for example holds a lot of logic that only works with the default toolbar) - and you also can't put any icons in the front except the default back/up icon.

I think its more important to fit into the Android scheme then trying to force some unity between different remotes, when most people are only ever going to use one. And a Phone UI and a In-Browser UI have quite different design goals.

[DJLegba]

I would want to keep the top toolbar, as the top left close/back button is pretty standard android UX. I wonder how it would look if I ban the rating to up there?

In fact, it looks decent to me:


Thoughts?

In this example it would be fantastic to have an option to remove shuffle and repeat and give the track name the full width of the screen. When playing classical music the name never fits the space allocated and has to scroll. And when playing classical music you're almost never going to use the shuffle or repeat controls.

[Awesome Donkey]

In Panel, the shuffle and repeat buttons are located in the three button menu, but I actually use those buttons so hiding could be optional.

JRemote already kinda follows Panel in basic ways, with a player bar on the bottom (playing now is accessible by clicking on the player bar at the bottom in both JRemote and Panel). Having a dedicated back button seems redundant since Android devices already either include a hardware back button or an on-screen back button so it'd be overlapping the same function. It makes sense in Panel since it runs primarily in a web browser (and doesn't really have 'access' to the hardware/on-screen button on touch screen devices because of the web browser) but doesn't make sense in an actual Android app.

I suppose you could change the X close button in playing now to a back button because it basically already does the same thing.

[HTPC4ME]

just my .2

i been using playerpro for local files on droid, and have really gotten use to/liked their layouts/options galore.

here are some screenshots of their layout to give u guys more ideas
Personally i like the ratings/shuffle/repeat...use them almost daily. (notice in player pro, they do not have option to 5 star in playing now, but do in homescreen widget, i like the ratings feature in jremote playing now...allows for quickly sync'n back to server.

another really neat feature in player pro/which i use almost daily.. is to play a genre/playlist on shuffle, once i hear something i like, then one can chose to "go to artist" then disable shuffle, and play everything from that artist next in your playlist/see screens 2 get idea.

EDITED: i'm still on version 21 of jriver.. but i guess it would be similar to theaterview for jriver... once you drill down to a artist/movie/etc then you can click on artist-Actor/director/series and jriver in theaterview will show you everything thats available with those Artist/s in the currently playing media... it's like a super shortcut...saves alot of time for us users...GREAT feature.

[Awesome Donkey]

I'm personally not a fan of the larger player controls and lack of a stop button. Having larger player controls will most definitely eat into the cover art space area.

[Hendrik]

The Shuffle/Repeat buttons are definitely not going away, although adding a few options to customize the layout of the Playing Now page is definitely possible, so you can hide the ratings, or the shuffle/repeat buttons.

For the X in Playing Now, I don't really care if its an X or a back arrow, it ultimately does the same thing. The reason its currently an X is because Playing Now is a seperate "action", a new screen which pops-up over the navigation screen, which you close again (which is also why the Drawer is not accessible there), instead of being a different screen you simply navigate to. But I've been thinking about changing that, primarily so that I can get the drawer working in there.

[HTPC4ME]

awesome donkey, if you are talking about playerpro's larger playing now buttons Play/RWD/FWD.. i agree 100% and have thought the same thing since using it... wasted space/too big imho/they could fit more in there.

[Awesome Donkey]

For the X in Playing Now, I don't really care if its an X or a back arrow, it ultimately does the same thing. The reason its currently an X is because Playing Now is a seperate "action", a new screen which pops-up over the navigation screen, which you close again (which is also why the Drawer is not accessible there), instead of being a different screen you simply navigate to. But I've been thinking about changing that, primarily so that I can get the drawer working in there.

Yeah, if you get the drawer working there you could have the 3 line hamburger menu (to access the "home" drawer) and the back button at the top left. Should be enough space there to do it and still have space for the cursed ratings.

I guess adding a playing now button to all the screens (even though pressing on the player bar works) to the right of the search button (in between the search button and any other buttons) would help those who don't realize the player bar works like that.

Casting button would make sense next to the zone button in that regard. There should still be ample space between two buttons on the left and the player controls (with a little space between the two buttons, e.g. the amount of spacing used for player controls).