Print

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

[jmone]

I know these are both being worked on actively so I thought I throw a couple of things in:
- Android TV Support
- Only Convert Audio / Video if required option (eg don't transcode, just remux)
- Ability to select streams (Audio, Subs etc) for the remux stream
- Display Rate changing option (eg so a Sheild, TV etc can change to the correct frame rate for the video stream)
- TV Support (only EOS does this currently and it is getting long in the tooth - I've even got the set of MCWS calls for this if needed)
- Popcorn Maker and Beer Cooler

...that about it!

[Hendrik]

Practically all of those are already planned to a degree, long-term or otherwise, for JRemote and/or MC itself (streaming changes would obviously need to be implemented in both MC and the remotes). You'll have to provide the beer cooler (and the beer) though.
Just not sure when we'll be able to get through all of the features, many of them are tightly coupled together.

[jmone]

figured you were on it!

[Awesome Donkey]

My only two things on the wishlist are...

- Gapless playback when not converting audio... okay maybe when converting audio too, but I'm not sure how easy that'd be.

- Having the ability to have MC/MCWS/JRemote only convert specific bit-depths/sample rates while leaving others unchanged via some kind of user configurable rule(s). My use case is my current phone has issues playing back 24/96 and 24/192 music, but has no issues playing back 16/44.1 so in that example I'd want it to only convert the 24/96 and 24/192 to 16/44.1 while leaving "normal" 16/44.1 alone (so not converted at all). Can't recall if Convert audio if necessary already covers this one or not, so please correct me if it does.

Though, thinking about it, if gapless playback worked for conversions (e.g. setting everything to PCM 16-bit) that'd likely eliminate the need for the second, more complicated thing on my wishlist. Currently all remotes (mainly MO 4Media and BubbleUPnP that support it) can't engage gapless playback if any conversion is involved. So being able to have gapless playback even with conversions in JRemote (or any remote using MCWS) would be quite nice, if possible.

[Hendrik]

Gapless should work with the new audio player in JRemote2, in theory, try it out once native playback is available. For transcoded audio, we might need to look into writing gapless metadata, especially when transcoding into block-based lossy audio formats like MP3.

Selective conversion... lets see if those playback issues actually persist with the new JRemote2 audio engine.

[fitbrit]

Wait! JRemote2? What have I missed?

[jmone]

Shhhh nothing to see here 

[jmone]

I figure now is the time to put forward any ideas as the team is coding away on both JRiver and JRemote2 for Android. 

[JimH]

Wait! JRemote2? What have I missed?

https://yabb.jriver.com/interact/index.php/topic,122878.0.html

[jmone]

Here is some feedback I sent off line to Jim on the Remotes/Android App.  He asked me to post it here.

As always some free (and hence useless advise) after having more of a play with JRemote2 and JRiver for Android.  I know you posted that you are keen of separate apps but I think they are both missing parts that could be leveraged off each other.  Some things that come to mind:
•   UI : Pick a theme that makes them look at least similar
•   Video : Long way to go on JRemote2 for full featured video support though I think Hendrik will get there…… and hence I trust Brad can lift and shift the video support code from JRemote2 into JRiver for Android sooner rather than later.
•   Library Sever Client : I get that some will want to use JRiver for Android as a server, but for the majority this may be awhile till the hardware becomes more powerful (CPU and Storage).  It really need to be able to load a remote library and do this sooner rather than later.
•   Feedback on the Playstore for JRiver for Android is terrible, and unfortunately well deserved.  There are many comments like “Man I'm such a fan of jriver but this app is the worst”.  It has been a year so far and the progress is poor and the natives are restless (or “revolting” as the old joke goes).  It does have merit to extend the reach of JRiver if it could load a Library but as a standalone Media App for Android, the gap between JRiver for Android and other local Android Media players is daunting.  In its current state it is really not a competitive option as a standalone player.  Without the ability to load a MC library it has little merit in the expansion of the JRiver ecosystem.  To me there are 3 options left for JRiver for Android:
    o   Double down on the dev and get it up to scratch
    o   Merge it with JRemote2 for now
    o   If it cannot be fleshed out in a reasonable period of time I’d seriously consider cutting the loss on this one for now. 
•   I’m surprise to see that the timeframes on JRemote2 keeps slipping.  The good news is that it is now on parity with the old JRemote.  To close the gap between JRemote2 and other 3rd Party remotes (and then better them) is still a big task but I think you will get there.
 
JRiver for Windows is solid, full featured and continues to improve.  Leveraging off that code base for JRiver on Android and JRemote2 is a great idea but from my long distance perspective the realisation of this in a reasonable time frame (and development cost) is failing.   


Thanks
Nathan

[jmone]

This is the feedback from the Google PlayStore on JRiver for Android that kicked off my thoughts:

[RoderickGI]

I think your blunt assessment is fair and accurate Nathan.

I don't need a MC Server on Android. At least not now. I need a configurable MC Client that runs well on an Android TV, and supports a good 10' user interface. The "Panel" interface doesn't support the configuration required.

Well, need is perhaps too strong a word. That is what I was hoping for. So that I could move the MC Server out of the lounge room, and use it directly for all MC maintenance. Then just run a good, solid MC Client on the TV for all viewing. Also my timeline is very relaxed on when I might do that. I bought JRiver for Android to support the cause. I only use it for testing.

However, I would like to use JRemote on Android as a player, with the ability to play local files or connect to a MC Server and play that media, and some offline file support. I will no doubt buy JRemote2 when it is "ready".


A roadmap for where JRiver think they will be in five years would perhaps explain the current strategy. Along with these Android issues, streaming is a looming threat to the long term survival of the core MC functionality.

[JimH]

I don't need a MC Server on Android. At least not now.

I believe that Android will grow into a direct competitor of Windows and OSX.  Things we can't imagine doing now with Android may become common.

A roadmap for where JRiver think they will be in five years would perhaps explain the current strategy. Along with these Android issues, streaming is a looming threat to the long term survival of the core MC functionality.

This isn't a roadmap, but it is a snapshot of our network of apps:
https://yabb.jriver.com/interact/index.php/topic,122878.0.html

We've learned a lot doing the Android TV changes for JRiver for Android.  Hopefully some of the changes will have fixed some of the crashes.  We will try to pay more attention to the crash reports.

[JimH]

jmone,
I wish I had your vivid imagination and a budget to go with it.  I can only say that it is a lot harder to build solid software than it is to imagine what could be done.  For one thing, the development platforms for Windows, OSX, iOS, Android, and Linux are all different.  What we do for JRemote2 on Android can't easily be ported to iOS.

We're working on a lot of your list, and I believe it's coming together.

You might be willing to give up JRiver for Android for JRemote.  I'm not.  I believe there is room for multiple remotes, using JRiver Media Center as the engine or kernel.

You're mainly a video user of MC, and unfortunately video has been the last work to be done in the apps.  It may also be the hardest.  We'll get there.

[RoderickGI]

Thanks Jim.

I think this is an important feature, but I haven't tested it on my TV yet, as I'm waiting for the JRiver for Android TV version.

JRiver for Android
It can act as a DLNA Renderer, for example.

That means I can push media to JRiver for Android (or JRiver for Android TV) from my server using a remote. While that would give me a bit of an issue handling audio at the moment, it is a very handy capability and one I will be testing.

While I could use Panel or Gizmo on my phone as the remote right now to push to the TV, JRemote2 on Android should be a better experience.

I look forward to it all coming together.

[jmone]

Hi Jim,

I'm not sure my kids would agree on the Vivid Imagination but they are fine working though the funds..... on some of the other points you raised:
- I was not talking about porting code from Android to iOS, more pointing out the JRiver eco system already has basic video playback working on Android in JRemote2 (and for that matter JRemote and even Gizmo) that may be leverageable for JRiver for Android. 
- I know, appreciate and support the work being done.  I also hope that "my" list expresses the wider wish list of users.
- I love the concept of leveraging the MC engine/kernel and making it extensible across platforms. 
- I don't want to give up on anything.  I want you to succeed in putting out a High Quality Android version.  This is where we may disagree (and I start to feel like the child in the tale "The Emperor's New Clothes" )... as it stands, JRiver for Android is neither a well received Local Media Player or functions as a Library Server Client.  It's got a 2 Star rating, relatively few users, and mostly poor reviews.  Attached is a pic of similar media apps I tried, showing their ratings including other JRiver apps.  It is just a good time to realistically review where it is at and what to do about it.  I'm glad you are committed to it.
- I do talk a lot about Video as the Audio side pretty well does most of what I want, but thanks for reminding me to bring up "Whole House Audio" again!  ...and Intercom

Always looking forward to the journey!

Thanks
Nathan

[jmone]

....and now I'll slink back into my corner.

[mattkhan]

A roadmap for where JRiver think they will be in five years would perhaps explain the current strategy.

the OS strategy is something that IMV definitely needs explaining

atm it reads to me like

- windows remains the primary platform
- linux and osx are paused and unlikely to reach feature parity with Windows
- android is essentially broken atm but there appears to be the desire to make it usable, the UI strategy for MC on Android is unclear though
- panel is the "invest" thin client
- jremote2 is the "invest" app client, not clear whether this is android only though (and hence where this leaves iOS is not obvious)

no idea whether this is accurate or not but it's how I read various forum posts.

[Hendrik]

JRemote2 is Android-only, cross-platform apps are rather limited, especially if you want to do "proper" media playback.
It'll be the proper Android remote that MC deserves - eventually. We'll talk about it more soon.

[JimH]

- linux and osx are paused and unlikely to reach feature parity with Windows
- android is essentially broken atm but there appears to be the desire to make it usable, the UI strategy for MC on Android is unclear though
- panel is the "invest" thin client
- jremote2 is the "invest" app client, not clear whether this is android only though (and hence where this leaves iOS is not obvious)

This isn't accurate.

Linux and OSX are getting regular updates, along with Windows.  The only major things I can think of that they don't do are TV and CD ripping and burning.  OSX has ripping.

JRiver for Android isn't finished, but most of it is working (not broken).

[mattkhan]

This isn't accurate.

Linux and OSX are getting regular updates, along with Windows.  The only major things I can think of that they don't do are TV and CD ripping and burning.  OSX has ripping.

JRiver for Android isn't finished, but most of it is working (not broken).

Off the top of my head.... the main MC UI on Linux is not a great experience due to issues with how windows are drawn and modal dialog behaviour, video performance tends to be glitchy and has nothing to compare to ROHQ, audio device handling is a bit tricky, there is no line in or WDM equivalent, BD playback not possible, interoperability across platforms remains a bugbear (though ISTR a 1st step at improving this, not sure if it was delivered or not)

I don't use OSX but I gather it has similar deficiencies (e.g. there was a thread on video playback quality).

Some of these are platform issues, others aren't. I don't recall these differences being well articulated by JRiver but perhaps I misremember. Hence my view that Linux (and presumably OSX) MC looks and feels like a 2nd class citizen (even for an audio only user).

Anyway I wasn't trying to bash MC as it is what it is, I was just agreeing with RoderickGI that having a clearer idea about the OS strategy would be good thing.

[Awesome Donkey]

Honestly I don't think it's possible to get close to the quality of ROHQ on Mac or Linux because madVR or LAV filters aren't available outside of Windows. None of the DirectShow stuff is.

In fact, most of the stuff you mentioned above relies on Windows components that aren't available on other OSes (WDM driver, ISO playback, television stuff, etc.).

Audio device handling also comes down to the OS as well. macOS is more forgiving and straight forward with Core Audio which is kinda like WASAPI, but Linux has multiple audio drivers (ALSA, PulseAudio, JACK, etc.) which can and do have weird quirks.

[mattkhan]

https://www.alsa-project.org/wiki/Matrix:Module-aloop is a WDM equivalent that comes for free, there are 3rd party equivalents on OSX (not sure if anything is built in)
linux audio device handling is certainly not the user friendliest though MC is arguably less friendly than a desktop env
Not sure why you think ISO playback is Windows specific.
TV driver support is certainly going to be different to Windows but it's false to think support doesn't exist, not something I do these days so I can't give uptodate commentary on that (a quick google finds devices with linux driver support though & given the way OSX has historically been lead OS for media creation then it would be pretty surprising if OSX can't handle this)

agree that madvr is windows only

[mattkhan]

Anyway the point here is that MC supports 3 OS's at the moment, 1 is feature complete and 2 lag behind for various reasons and which may or may not have a meaningful impact on the end user (e.g. I use MC Linux quite happily for audio playback use and it works just fine, meanwhile it is somewhat usable as a secondary video playback platform but it's not ideal).

A 4th OS now exists, has a different UI and another different feature set.

It would be good to know what the aim for that new platform is & how that might impact existing platforms.

For example, since the main MC UI does not work on Android but MC Android is a server product and the existing js UI is not adequate for server config then what UI will be built to satisfy this need? Will it be android specific (e.g. on top of jremote2) or will it build on top of Panel hence be useable on all platforms or will it be something else?

[MikeO]

JRemote2 sounds good

I have a MyGica1960 ,media player primarily for Video, Netflix etc , it has Kodi natively that sees MC Dlna. The recent Kodi update broke it so I looked for an alternative . MyGica is a mini Android device running Android 5.1

JRiver for Android wow then I realized it didn’t see my. MC library ...sad, I would say the top priority should be that to make it an Android player. Imagine it installed on your smart TV

So I installed JRemote , works like charm, looking forward to JRemote2, it’s getting time for a new tablet and Android looks much better than Apple at the moment, this could be the deciding factor

[blgentry]

This is what I see:

A.  Development for JRemote on IOS seems to only be in maintenance mode.  It's written in an unusual cross platform development system which implies that it needs a total rewrite in order to really move forward.  Maybe my perception here is off, but it does not seem to be getting attention like the new JRemote 2 for Android.
B.  Many people are asking for more advanced local playback on JRemote 2.  If you focus on this, you will shift development resources to a mobile platform.  Which by definition is a low resolution experience.  This is seemingly the opposite of JRiver products core mission to provide the highest quality audio and video experiences.  JRemote should exist to remote control the REAL version of MC.  Not as a playback device.
C.  Focusing on mobile playback lacks direction and a plan.  Spending a ton of resources to get good local video on JRemote doesn't really help anything long term.  It just lets people give their kids tablets that will play JRiver content.  Which frankly is a waste of everyone's time when that same tablet can play 10s of thousands of other streaming programs (from many services) using the very mature players that already exist and have existed for years.
D.  JRiver for Android TV is a glimmer of hope for getting JRiver set top box playback.  But it doesn't work for video (yet) and may or may not yield high quality results.
E.  JRiver seems to hate Apple and all of it's products.  Development on OSX is slow and filled with complaints of "This is Apple's problem" every time something breaks.  This implies that JRiver isn't engaged with the Apple development process and doesn't want to be.  This is a real shame because the AppleTV 4k is a super powerful, very high quality set top box that would be a great home for a JRiver product.  I would easily pay $30 to have JRiver on AppleTV.  As long as it really worked.

Brian.

[S. Pupp]

I, on the other hand, use JRemote primarily for streaming video to my iPhone.  I used to use Younity, then StreamToMe, until they were discontinued.  The ability to access my video from my home library  is very useful when, for example, waiting for my car to be repaired.

[DangerJP]

In JRemote : A switch to "only transcode audio when wifi is not connected".

When I'm connected to a wifi network, I'm usually not concerned with bandwith, but when I'm on the road, I always transcode audio.

[Hendrik]

I just want to quickly note that playing on a phone and playing on a Android TV box are really not that different. So when we work on improving one, we improve both.

Android might never offer the ultimate audiophile experience, but we can do our best to offer decent quality and a decent feature set. Ultimately, what good is a properly curated media library, filled with good audio and video, if you can't access it while traveling, visiting friends, etc?

I'll always prefer a HTPC to watch my video collection at home, but when I'm in the subway, visiting friends or family, I should have the ability to still watch or listen. Of course I could also watch something on Prime or Netflix, but if I'm in the middle of a show I'm binging, why should I not be able to continue!

On a technical note, improvements to video streaming will.largely be in MC itself which will benefit much more than just JRemote. It'll be usable by all remotes, for DLNA, and even offline transcoding.

[thecrow]

Android might never offer the ultimate audiophile experience, but we can do our best to offer decent quality and a decent feature set.

I am not sure I agree with this. LG have made a series of audiophile phones using ESS DACs starting with the V10, I currently have a LG G7 with its ESS Quad DAC and using this with apps that bypass the Android audio path, to drive the DAC directly, sounds amazing.
Beyond LG you can attach high-end USB DACs to phones and tablets and again using the right apps drive them directly without any limits of the Android sound path.
If JRiver could also drive these DACs bypassing the usual Android limitations that would be a great step forward.