Print

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

[Hilton]

So iTunes is finally officially dead on MAC OS.

Being split up into different apps to start preparing for their Netflix like streaming service no doubt.
PC iTunes will limp on for god knows how long, not that I use it at all anymore anyway except to do a backup and restore for new devices.

It brings up an interesting discussion point...……….

Should JRiver MC be split up into different Apps? now before some of you start chasing me with pitch forks... hear me out...

1. Keep MC Server as is with all bits included... for server and library management, config etc. (for now)
2. Build a new HTML 5 application for playback with the GUI of JRemote, with some functionality of Panel on mobile/tablet.
3. Theatre View HTML 5 or App with interface of Emby/Roon for 10 foot use for music/video/pictures with basic zone/video/audio settings.
4. Ground up new build HTML 5 streaming App
5. Build a new launcher in HTML 5 or an App with a very simple interface (panel) that allows you to select what you want to do and jump to that app/ web app.
6. JRiver Android still has a place, but not without #2/#3 above.
7. Over time MC server becomes a stand alone server product with basic config and playback from frontend web apps/desktop apps.

??  Let the discussion begin.. 

[JimH]

Since nobody else has replied, I'll give you my two cents.

Overhauling the UI or restructuring the program or replacing parts with other parts could be an overwhelming amount of work.  I'm not sure it would increase our sales or user approval.  I do think it could easily piss some people off.

For example, you've proposed the interface of JRemote.  I have looked at the usage statistics and Gizmo is used several times more frequently than JRemote.  It's free, yes, but JRemote isn't expensive.

I know I sound like Adam Osborne here.  "Adequacy" was his mantra.  That's not quite what I believe, but I do think the market rewards good solutions.  Great solutions are better, but I don't think there's much consensus on what a great solution is.

But, as you know, I have an open mind.   

[RD James]

iTunes was doing a lot more than Media Center, and doing it badly.
Breaking it up into separate apps probably makes sense for Apple because they can have separate teams working on each project rather than a single team handling iTunes as a large mess of a project.
That probably doesn't make a lot of sense for Media Center.

For example, you've proposed the interface of JRemote.  I have looked at the usage statistics and Gizmo is used several times more frequently than JRemote.  It's free, yes, but JRemote isn't expensive.

JRemote is not expensive as a product itself. JRemote is expensive as an app on the app store, where most are free/ad-supported or $0.99 IAPs.
I have no issue with paying $9.99 for an app like JRemote, but the market does.
 
I'm curious since you mentioned it though: what usage statistics are Media Center/Gizmo collecting?

[Hendrik]

I'm curious since you mentioned it though: what usage statistics are Media Center/Gizmo collecting?

None, really. We have download counts for Media Center of course, and for Gizmo/JRemote the usual stuff that the Play Store and Apple Store collects, number of installed devices and such. But neither of these actually collects any data at runtime and phones it home, if thats what you are asking.

Regarding the point about JRemote, I'm not sure people would be happy if JRemote was ad-supported. Did you know google has frameworks to insert audio/video ads into streams? That wouldn't go over well, I'm sure.

[RD James]

None, really. We have download counts for Media Center of course, and for Gizmo/JRemote the usual stuff that the Play Store and Apple Store collects, number of installed devices and such. But neither of these actually collects any data at runtime and phones it home, if thats what you are asking.

I thought as much, but just wanted to check. Since Gizmo is running locally rather than a downloaded app, I wondered how Jim would have stats to compare it against JRemote.

Regarding the point about JRemote, I'm not sure people would be happy if JRemote was ad-supported. Did you know google has frameworks to insert audio/video ads into streams? That wouldn't go over well, I'm sure.

Oh believe me, it was not a suggestion!
It's just that people seem to think that $9.99 is "really expensive" for something on the app store (I disagree).

[Hendrik]

Since Gizmo is running locally rather than a downloaded app, I wondered how Jim would have stats to compare it against JRemote.

Gizmo is still on the Play Store.
https://play.google.com/store/apps/details?id=jriver.mediacenter.android&hl=en

[Hilton]

I still think JRemote is one of the best UI experiences of any media player available on the market so I don't have a problem even paying a yearly subscription for it.  But I do wish it was shown a little more love from a development perspective. 

Now you can run JRiver server and JRemote on the same device (my DX220 by example) …….

I wish for better Native Hires support by JRemote in Android. If JRiver can support DSD and 192khz on Android why not JRemote too?

It would be great if we could at least choose the local playback output device like we can in Linux instead of just the default Android output device.

For example, when using JRiver and JRemote on the same device, I can change the playback device within the JRemote Zones (the JRiver Android "Player" zone) and set the zone to use the available JRiver output devices and have bit perfect output including DSD locally on my DAP while still using JRemote as the interface instead of JRiver/Panel. 

Being able to do the same thing from my main media library to JRemote on the DAP would be great. 

Unfortunately, the only way to get above 96k playback in Android native audio with JRemote is to run JRiver alongside it and use JRiver "player" zone as a playback zone locally as noted above.  I guess it's at least a step forward that JRemote can now compete with the likes of USB Audio Pro and Poweramp etc and do DSD bit perfect playback locally on Android.   (as long as you're also running JRiver)

PS. There's a whole Audiophile community out there that would jump at something like JRemote with DSD/192K and Stream.JRiver integration even if it did require both JRiver and JRemote on the same device. Think of it as something competitive to USB Audio Pro or Roon with Native Tidal integration, but instead of Tidal, you have Stream.JRiver..      UI is super important though which is why I think JRemote should be shown more love.  …. and they have money to spend on a yearly subscription like Roon so a few bucks a year to keep active development on JRemote or a new shoot-off version with JRemote and built-in JRiver and Stream would easily be worth it.

[RD James]

Gizmo is still on the Play Store.
https://play.google.com/store/apps/details?id=jriver.mediacenter.android&hl=en

Ah, okay. That makes more sense now - I thought Gizmo was only the web client.

[JimH]

Ah, okay. That makes more sense now - I thought Gizmo was only the web client.

You're probably thinking of WebGizmo.  Panel has replaced it.

[Hendrik]

I wish for better Native Hires support by JRemote in Android. If JRiver can support DSD and 192khz on Android why not JRemote too?

Quite simply, because JRemote is a native Android application, which uses Android media playback components, and Media Center is not - it does it all by itself.
Android media components are really not suited for hi-res playback, and any apps that implement "hi-res playback" actively work around as much of Android as possible - which was easy for MC, since it already had everything that was required to do so.

To do this in JRemote is not impossible, but definitely a whole lot of work - practically re-implementing MCs audio engine, including input plugins for every audio format you might want to run through this. At this point I think JRemote has more pressing areas that need work.

One small piece as a bonus, a future JRemote update should support FLAC up to 192/24, but without any guarantees what Android might do with the audio until it gets to the DAC.
It'll probably be a while until this is available though, since its part of a larger JRemote update thats being worked on.

[Awesome Donkey]

Shame you can't take a remote like JRemote/Gizmo and have it link to and use JRiver for Android's audio engine, if it's available on the system, to playback media.

[JimH]

Shame you can't take a remote like JRemote/Gizmo and have it link to and use JRiver for Android's audio engine, if it's available on the system, to playback media.

You should be able to do that now.

[Hendrik]

You can control Media Center of course if its installed (and if it doesn't work yet, it should at some point). The playback engine is too tightly coupled with MC. But at the end of the day, is there a huge difference if you're using JRemote as a controller?

[Awesome Donkey]

Personally, I use JRemote/MO 4Media as a means to listen to music from my MC library on my NAS + Pi on my Android phone, for example - I rarely use either as a remote anymore. However if it was possible for JRemote/MO 4Media to be able to "hook" into JRiver for Android and use its audio engine for music playback (in JRemote/MO 4Media), I think that'd be kinda interesting considering remote apps on Android, when playing media back through them, use Android's playback components when it could alternately use MC's through JRiver for Android.

[JimH]

Maybe I'm not understanding you, but JRiver for Android has all the network capabilities of MC, so you could play to it, using DLNA, from any app that could play to a DLNA Renderer.