INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: JRiver Architecture  (Read 5688 times)

jmone

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 14463
  • I won! I won!
JRiver Architecture
« on: December 20, 2017, 03:45:10 am »

I'd suggest something a much broader and it goes to the basic architecture of how MC works.  If I look into my Crystal Ball, I would not be surprised to see the continued decoupling between the server and clients.  Both Server and Clients would be supported on all platforms, eg Windows, iOS, Andriod, OSX, Linux and these instance would be aware of each other and inter-operate across these Platforms.

Media Server:  Runs as a service on any/all platforms.  It would host the DBase and control access to the media files anywhere on the network.  It would sync across and between all databases on the network.  Will allow any client to connect to it.  Has no UI.  The key expansion feature is the library is not just "shared" with clients but also supports replication across and between the libraries so you have a unified library across all servers that is then available to the clients.  It would also allow you to "rehome" and "cache" content from one device to another.  Eg if I add a music track on my Android Handheld, it should be able to "rehome" that track to my Windows PC.  If I have a set of content on my Windows PC I should be able to select what to cache on my iOS device.  If I play a track on my Linux box it will be fetched from wherever it is located (could be my Android Tablet, or my Windows box).

Admin Client: Like Std View today and this is where all the options are exposed.  It would not need to be "pretty" but would be powerful as you could do all your library management and configuration from this client.  Would be the tweakers delight.  You could play content from this client but that would not be it's focus.  This client should be available on Windows, OSX and Linux.

Desktop Client:  Keyboard/mouse driven, Looks "pretty" and is aimed purely for playback on Desktops.  Comes in Apple White.  There is no equivalent to this at present in MC.  This client should be available on Windows, OSX and Linux.

TheaterView Client:  10ft IF, Remote driven.  Like Theaterview is now.  This client should be available on Windows, OSX and Linux.

Handheld Clients:  Finger Driven, aka JRemote / Gizmo / Eos (I think EOS is still the "best" of these) but it is a client not just a remote.  This client should be available on Android and iOS.

3rd Party Clients:  As MCWS is now, support the ability for 3rd party apps to interface with the MC (eg how DLNA clients can connect now to MC.  Expand to Airplay etc)

3rd Party Content:  This has fallen away but the ability to aggregate content from clould suppliers of content (Netflix, Spotify, also other discoverable devices like Airplay, Sonos etc etc).  This one may be out of your control.

Logged
JRiver CEO Elect

dtc

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3113
Re: JRiver Architecture
« Reply #1 on: December 20, 2017, 08:57:03 am »


...

Desktop Client:  Keyboard/mouse driven, Looks "pretty" and is aimed purely for playback on Desktops.  Comes in Apple White.  There is no equivalent to this at present in MC.  This client should be available on Windows, OSX and Linux.

...

Handheld Clients:  Finger Driven, aka JRemote / Gizmo / Eos (I think EOS is still the "best" of these) but it is a client not just a remote.  This client should be available on Android and iOS.

...

I like the architecture.

Separating Desktop Clients and Handheld Clients is critical. Trying to use the same interface on a 27" monitor and on a phone is not practical. Both suffer. And future development is hindered by having to address both platforms simultaneously.

IMO, that is a problem with Panel. It tries to use essentially the same interface for Playing Now on a desktop client and on a mobile client.  If the desktop UI looked more like Standard View and was customizable like Standard View (or whatever the next generation desktop UI is) and the mobile client looked like JRemote, then I would find it much more usable. As it is, it is not optimized for either type of device and therefore does not work well on either. 

Panel is a good future platform, but needs to recognize the separation of desktops and handhelds, rather than introducing yet another interface that does not work well on either.  Your architecture clearly calls that out.
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72413
  • Where did I put my teeth?
Re: JRiver Architecture
« Reply #2 on: December 20, 2017, 09:54:37 am »

I like the architecture.

Separating Desktop Clients and Handheld Clients is critical. Trying to use the same interface on a 27" monitor and on a phone is not practical. Both suffer. And future development is hindered by having to address both platforms simultaneously.

IMO, that is a problem with Panel. It tries to use essentially the same interface for Playing Now on a desktop client and on a mobile client.  If the desktop UI looked more like Standard View and was customizable like Standard View (or whatever the next generation desktop UI is) and the mobile client looked like JRemote, then I would find it much more usable. As it is, it is not optimized for either type of device and therefore does not work well on either. 

Panel is a good future platform, but needs to recognize the separation of desktops and handhelds, rather than introducing yet another interface that does not work well on either.  Your architecture clearly calls that out.
It's one thing to draw a picture or conceptualize a system, and quite a different thing to implement one.

Panel was intended for phones and tablets, similar to the purpose of Gizmo and JRemote.  It also works OK on a desktop, in my opinion.
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72413
  • Where did I put my teeth?
Re: JRiver Architecture
« Reply #3 on: December 20, 2017, 09:59:15 am »

jmone,
I don't mean to disparage your picture or your description.  Your view and mine aren't that different.

One point of difference is that presently one piece of code (JRiver Media Center) currently can serve as client, server, or both.  The fact that a client is present in the code of a server doesn't have any affect on the server's performance. 

And ... the devil's in the details.  Pink or white, Madame?
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72413
  • Where did I put my teeth?
Re: JRiver Architecture
« Reply #4 on: December 20, 2017, 10:04:15 am »

Speaking of the devil, drmimosa's post here illustrates how convoluted simple things can get:

https://yabb.jriver.com/interact/index.php/topic,105883.msg785646.html#msg785646
Logged

drmimosa

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 690
Re: JRiver Architecture
« Reply #5 on: December 20, 2017, 10:55:10 am »

 ;D

Don't listen to the devil. Keep your eye on the details instead.
Logged

jmone

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 14463
  • I won! I won!
Re: JRiver Architecture
« Reply #6 on: December 20, 2017, 03:48:22 pm »

jmone,
I don't mean to disparage your picture or your description.  Your view and mine aren't that different.

One point of difference is that presently one piece of code (JRiver Media Center) currently can serve as client, server, or both.  The fact that a client is present in the code of a server doesn't have any affect on the server's performance. 

And ... the devil's in the details.  Pink or white, Madame?

No offence taken at all....and yes describing an architecture is much quicker than creating the product!  More of taking a step back and looking at the next XX Years.  Decoupling is the way to go and allows for a mix and match.  I like that all the newer clients are already decoupled (Andriod, Web, iOS) and IF you where going to go for a new "pretty" Desktop Playback focused GUI then I'd suggest it be separate decoupled app as well.... and of course "Apple White" is the way to go :).  This way you are progressing down that path instead of a monolithic app.
Logged
JRiver CEO Elect

RoderickGI

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8186
Re: JRiver Architecture
« Reply #7 on: December 20, 2017, 04:29:15 pm »

There are some great ideas coming out in this thread. One which I support 100% is this one.

I'd suggest something a much broader and it goes to the basic architecture of how MC works.

I won't bore you with my experience with large database dependent software systems and their transition from central mainframe processing to distributed fat client processing back to central server processing with thin clients, and now to SaaS implementations. But I will point out that nearly all our favourite mobile Apps whether music streaming or social media are using central processing and thin clients.

Panel, or more specifically the use of HTML5, is a good move, but it needs to go much further and get better.

This sort of thing is a problem as far as I am concerned:
Speaking of the devil, drmimosa's post here illustrates how convoluted simple things can get:

https://yabb.jriver.com/interact/index.php/topic,105883.msg785646.html#msg785646

A user should just never see that stuff. That is why we aren't all software developers. A product should be designed to be a great user experience, and as simple as possible. All the complexity should be under the covers, and the developers should be looking after that. So a user just says "I want to play music from my server", the software says "Here are all your servers. Which one do you want to use?", the user picks one, the software connects and offers the contents. The user then says "I want to shut down/restart/whatever that requires authentication", the software says you need to sign in to do that Yes/No, the user provides credentials, or uses a token or similar provided by the owner of the server, only the first time they connect, and the software connects. The user never sees a URL, or credentials unless they are the owner, and the whole process is done with AAA+ security. No plain text User ID and Password.

This is why MC is a Geek's tool and not a Luddite's. Let's face it, even savy users can't or don't want to understand the tech underneath the software tool they are using.

One point of difference is that presently one piece of code (JRiver Media Center) currently can serve as client, server, or both.

This is great, but there is one huge hole in that statement. That is that for important maintenance functions such as building or editing Views, collecting Cover Art and so on, a user has to go to the MC Server, or use third-party tools like Teamviewer, Remote Desktop, VNC (Geeks tools), none of which I find acceptable when working in MC Standard View doing maintenance. Again, if the use of the Client or Server version of MC was transparent to the user in terms of what they could do, then this wouldn't matter. But in actual fact, not only does the user need to be aware that they are on a Client of the MC Server despite the two looking identical, but they also need to know what they can do which will work, and what they can't do because of the architecture. In fact, the user has to understand the architecture to some degree in order to avoid being tripped up. There isn't even a readily available, complete list of what will and what won't work when doing maintenance using a Client!

I see so many threads where it is genuinely hard to work out what sort of MC configuration people are using, and sadly often they don't know, or can't describe it.

Again, this is why MC is a Geek's tool and not a Luddite's. Users of Android and iOS, the main computing platforms of many if not most people these days, are getting used to fantastic integration, brilliant Discovery functionality, and generally being led by the nose by software that not only hides any and all technical issues but works really well.

Anyway, I'll get off the soapbox now. I hope all the comments and suggestions in this thread are taken as they are meant; constructive feedback on a product that we all love and want to see succeed well into the future.
Logged
What specific version of MC you are running:MC27.0.27 @ Oct 27, 2020 and updating regularly Jim!                        MC Release Notes: https://wiki.jriver.com/index.php/Release_Notes
What OS(s) and Version you are running:     Windows 10 Pro 64bit Version 2004 (OS Build 19041.572).
The JRMark score of the PC with an issue:    JRMark (version 26.0.52 64 bit): 3419
Important relevant info about your environment:     
  Using the HTPC as a MC Server & a Workstation as a MC Client plus some DLNA clients.
  Running JRiver for Android, JRemote2, Gizmo, & MO 4Media on a Sony Xperia XZ Premium Android 9.
  Playing video out to a Sony 65" TV connected via HDMI, playing digital audio out via motherboard sound card, PCIe TV tuner

rec head

  • Citizen of the Universe
  • *****
  • Posts: 1008
Re: JRiver Architecture
« Reply #8 on: December 20, 2017, 05:19:55 pm »


Admin Client: Like Std View today and this is where all the options are exposed.  It would not need to be "pretty" but would be powerful as you could do all your library management and configuration from this client.  Would be the tweakers delight.  You could play content from this client but that would not be it's focus.  This client should be available on Windows, OSX and Linux.

Desktop Client:  Keyboard/mouse driven, Looks "pretty" and is aimed purely for playback on Desktops.  Comes in Apple White.  There is no equivalent to this at present in MC.  This client should be available on Windows, OSX and Linux.


This sounds like a great idea. I have a question about your idea for the Desktop Client, would it be strictly playback? The only time anyone else in my house is using the current Standard View is to build playlists. I think we'd all be happier if they didn't have to see all the complexities.
Logged

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4216
Re: JRiver Architecture
« Reply #9 on: December 20, 2017, 06:25:19 pm »

Jim's comments (opening the thread) do not mention this sort of architecture at all. The impression I have, from assorted threads over the years, is that this is rewrite territory.

Fair comment or not?
Logged

RoderickGI

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8186
Re: JRiver Architecture
« Reply #10 on: December 20, 2017, 06:32:52 pm »

I think the current software could easily become the Media Server component.

But all the Clients would be rewrites. Maybe all in HTML5. That would work.
Logged
What specific version of MC you are running:MC27.0.27 @ Oct 27, 2020 and updating regularly Jim!                        MC Release Notes: https://wiki.jriver.com/index.php/Release_Notes
What OS(s) and Version you are running:     Windows 10 Pro 64bit Version 2004 (OS Build 19041.572).
The JRMark score of the PC with an issue:    JRMark (version 26.0.52 64 bit): 3419
Important relevant info about your environment:     
  Using the HTPC as a MC Server & a Workstation as a MC Client plus some DLNA clients.
  Running JRiver for Android, JRemote2, Gizmo, & MO 4Media on a Sony Xperia XZ Premium Android 9.
  Playing video out to a Sony 65" TV connected via HDMI, playing digital audio out via motherboard sound card, PCIe TV tuner

jmone

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 14463
  • I won! I won!
Re: JRiver Architecture
« Reply #11 on: December 20, 2017, 06:48:00 pm »

I'd suggest it is about timing more than a massive big bang re-write.  For example, lets say JR decides it want to update the GUI for desktop playback.  Instead of modifying the existing core base code, create it as a decoupled app.  Anyway, MC UI's work for me.  I use StdView for admin, and TheaterView for consumption on the HTPC.  Could TheaterView look better?  Sure but... I want to watch movies not TheaterView.  I'd personally rather the dev goes towards features.  These sort of architecture decisions help set HOW the dev is going to be done over a period of time.
Logged
JRiver CEO Elect

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72413
  • Where did I put my teeth?
Re: JRiver Architecture
« Reply #12 on: December 20, 2017, 11:36:47 pm »

Instead of modifying the existing core base code, create it as a decoupled app.
Not saying that you're wrong, but why do that?  What is the perceived advantage?

The code relies on many components, and both client and server would need most of them. 

After dividing the baby, some fixes would need to be done in two places instead of one.

It's a little like Media Server.  It looks like it has a very narrow function, and a different interface, but in reality, it's just Media Center with some components unloaded to save a little memory.  A few MB of memory probably doesn't even matter anymore.
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72413
  • Where did I put my teeth?
Re: JRiver Architecture
« Reply #13 on: December 20, 2017, 11:51:00 pm »

Decoupling is the way to go and allows for a mix and match.  I like that all the newer clients are already decoupled (Android, Web, iOS) and IF you were going to go for a new "pretty" Desktop Playback focused GUI then I'd suggest it be separate decoupled app as well.
I think that you're describing the direction that Panel (aka Pretty Face) is going, although the initial reason for starting it was to solve a problem with perceived complexity by some.

When people uninstall, we ask why.  I also read the replies to the followup e-mails we send after someone has downloaded.   We get all kinds of reasons why people stopped trying JRiver, but the most common one is some version of "too complicated".  In my opinion, that's the most important problem we need to solve.  People like RoderickGI will always be able to overcome obstacles, but most "normal" people will quit.

And because we have so few females as customers, I'm leaning toward pink.
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72413
  • Where did I put my teeth?
Re: JRiver Architecture
« Reply #14 on: December 21, 2017, 12:13:44 am »

A user should just never see that stuff. That is why we aren't all software developers. A product should be designed to be a great user experience, and as simple as possible. All the complexity should be under the covers, and the developers should be looking after that.
A lot of good points in your post, and I don't have time right now to reply in full, but this is an especially pertinent one.

Yes, I agree in principal.  But the devil made different kinds of users and some want more control than others.  We often end up groaning and adding yet another option, which adds more complexity, but at least it's only on the options page.
Logged

jmone

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 14463
  • I won! I won!
Re: JRiver Architecture
« Reply #15 on: December 21, 2017, 12:23:52 am »

You certainly would not want to duplicate functions between disparate elements.  That I agree on.  But over time, I'd still look at the decoupling.

- Clients ask the server for stuff and does the actual playback on the device that they are running on.  So they need all the playback goodies and the pretty front ends to suit the various flavours of Desktop (like your new Pink UI), Handheld (Like the Remotes), Theaterview (existing) and Administration (like StdView).  Potentially much of the reusable code could be their own libraries that are then used by many or all of the clients.

- Servers need to stuff to expose the content (from possibly many different other servers) then provide it in the format required (eg like how the DLNA Server works now).  This could potentially be a small subset of the code you have.  It has no UI at all.

Lets take the example of the Admin View.  I should be able to run such a UI up that then finds all of the MC Servers instances on the Network.  It would allow me to change the settings as we can do now in Std View but on any or all of them.  It would also have new features where I can see what media is in each local MC Servers Media Store and decide where I want to "rehome" or cache this content.

Playback Clients.  Likewise when I fire this up on my Device (say a Phone), it sees the aggregation of all the Media from all the Media Servers but this is abstracted from the user completely.  It does not matter if the song to be played is physically on a Windows based MC Server, or on the Linux box (or even a the users phone that is also running MC Server).  The client just selects Play and it Plays from whatever MC Media Store it is located in.  Similarly I may be out and about with my phone and download some track that is imported into my Phones Media Server.  When I reconnect to my network at home this content has been configured to re-home back to my Windows Based Media Server.  I've also set my Phone to cache a copy of my Top 100.  Regardless of what Media Server on my network has the content, my Phone's cache will be updated.

In summary the components would be:
- Media Server : The database and code to respond to requests and keeping each other synced
- Media Store : Where the actual media is stored
- Clients : The various UI to interact with the Media Servers for Playback and Administration

Every devices running MC would have the appropriate OS version of the Server, Store, and Client(s)

... anyway, it's fun postulating what may be the the reality of what can be done when is a different matter entirely!
Logged
JRiver CEO Elect

jmone

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 14463
  • I won! I won!
Re: JRiver Architecture
« Reply #16 on: December 21, 2017, 12:42:11 am »

I should also add re the "Fat" vs "Thin" client debate.  I not normally a fan of "Thin" clients as they tend to be very weak on the features they can provide and ignore all the grunt that is normally available on the device running it.  Take Video Playback.  I like ROHQ.  How is this ever going to work on a Thin Client?  Sure it may be good to have a universal lightweight web app but it will never have the grunt to do what a traditional local app can do.
Logged
JRiver CEO Elect

rec head

  • Citizen of the Universe
  • *****
  • Posts: 1008
Re: JRiver Architecture
« Reply #17 on: December 21, 2017, 07:28:07 am »

The Admin View would be great just so that I don't need to do any management from the HTPC. Doing all the admin work from this office PC that runs as a client would be so much easier. It could also allow the installers to remotely help their clients.

Jmone - Calling the place where media stored the Media Store is confusing at best. Media Store sounds like the place where I go to buy media. MC doesn't need any more confusing names.
Logged

Headcool

  • Junior Woodchuck
  • **
  • Posts: 70
Re: JRiver Architecture
« Reply #18 on: December 21, 2017, 09:25:18 am »

I actually like the fact, that the "Admin Client" and the "Desktop Client" are not seperated. The different views give both the possibility to efficiently tag and to nicely present the files. There could always be more views (only the category-type view is really suited for presentation right now), but that is another topic.
The views of the server should be the default views of the client, however it should be possible to customize the views on the client.

Furthermore, I agree on the topic of thin clients. This could probably work with a theater view based on HTML5.
There is also a new possiblity for thin clients using hardware encoding. Most modern graphic cards support some type of encoding, including lossless H264 and HEVC. Such technologies are for example used in Steam Link. A simple H264/HEVC hardware decoder is sufficient and very cheap as client. The server would render the theater view with OpenGL/Vulkan to GPU memory to encode and send it via network. This approach could provide more eye candy than the HTML5-approach, through the usage of shaders and 3d-graphics. On the other side, it would be more complicated to create custom skins and views.
Logged

mattkhan

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 4216
Re: JRiver Architecture
« Reply #19 on: December 21, 2017, 10:15:38 am »

IMV the problem is that there is a particular client instance that has super powers and that there isn't an easy & obvious way (that I know of) to manage client configuration without logging into each box and setting it up.
Logged

Manfred

  • Citizen of the Universe
  • *****
  • Posts: 1038
Re: JRiver Architecture
« Reply #20 on: December 21, 2017, 11:57:46 am »

My PoV - a little different approach to the different discussions: (putting aside the commercial aspects of streaming)

⦁   Persona "Apple Only - Total Opposite to a MC User" - Owns Apple TV (Streaming Netflix, Apple Music etc.) + iPad + Other iDevices, a Soundbar+Sub and a TV - on the extreme only a macBook Pro  + iPhone + Audeze Sine (or other Headphone) - Yes and the Persona could live with mp3 and streaming quality of Apple Music and Apple TV. Persona has no local media files.

⦁   Persona "Audio Only Music Library < 1TB" - Owns a NUC (internal Storage) with MC + A/V Gear

⦁   Persona "Audio Only Music Library < 1TB" - Owns a DIY Music Server (internal Storage) with MC+ A/V Gear

⦁   Persona "Audio +RO Standard for Video; Library < 2TB" - Owns a Nuc (internal Storage) with MC + A/V Gear

⦁   ... Other Persona's ....

⦁   Persona "Large Media Library > 20 TB" - Owns multiple computer's with MC installed in a media network;  uses madVR with High End Video Card + High END DAC/Amp + Speakers

In all case's - if properly setup -  for all MC Persona's it is from my PoV easy to play music, view images or a video controlled through JRemote.

The amount of work it takes using standard view (including ripping, network configuration, metadata administration (incl. lyrics), MC configuration, set-up view's for JRemote, madVR setup, speaker correction etc.) to get it perfectly running is much different for the Persona`s described above and could be very large and seems to make MC complex.

Finally you can get really the best sound & video quality out of it (e.g. using madVR the video quality is really stunning and much better than playing it directly through DLNA on my LG TV). How much different is the video quality of Apple 4k TV?
The key question for me is, how JRiver will address the different requirements the Persona`s have in the future. (e.g. from an architecture perspective JRiver could write an App for Apple TV in combination with a preconfgured Nuc (JRiver-ID)) to put something in between the "Apple Only Persona" and the MC Persona's.

I personally are a Persona "Large Media Library > 20 TB"  but before I invested a serious amount of money into my new central media server, I had asked myself if Apple TV + the new coming CoreInfinity Streaming Module for my Devialet would make it. Because I have bought so many CD's, DVD's and BD's in my life and did not want to miss the video quality of madVR delivers I decided to go forward with MC. For audio only it could be that the new CoreInfinity Module with the upcoming app will deliver all I need?

It would be nice if MC could deliver something in the future which is inbetween the two extreme scenario's descibed above and a hybrid approach between streaming and have your media files all local in a common UI.

I do my administration on my win 10 based media server (no GPU; KVM Management Module; >20TB storage) using remote Desktop from my Home Office PC using Standard View - it is easy to use.

My MC Media player in my Living Room I control though JRemote: The Client's MC promote for me are not bad at all - JRemote is pretty easy to use and looks pretty cool- I have tested that with many friends.

The challenges for me are what I described above - how to set it up with less effort and complexity.
Logged
WS (AMD Ryzen 7 5700G, 32 GB DDR4-3200, 8=2x2+4 TB SDD, LG 34UC98-W)-USB|ADI-2 DAC FS|Canton AM5 - File Server (i3-3.9 GHz, 16GB ECC DDR4-2400, 46 TB disk space) - Media Renderer (i3-3.8 GHz, 8GB DDR4-2133, GTX 960)-USB|Devialet D220 Pro|Audeze LCD 2|B&W 804S|LG 4K OLED )

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72413
  • Where did I put my teeth?
Re: JRiver Architecture
« Reply #21 on: December 21, 2017, 12:16:05 pm »

Manfred,
You're right that setup is often the biggest obstacle.  Anything we can do to make it easier will make the experience more pleasing.

Thanks for your thoughts.
Logged

AndrewFG

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3392
Re: JRiver Architecture
« Reply #22 on: December 21, 2017, 12:22:43 pm »

IMHO if you were to split it up, then you would actually need to split it into 3 parts not 2. Namely a server, a renderer, and a control point. Sounds a bit like UPNP/DLNA architecture. .. Oh!!
Logged
Author of Whitebear Digital Media Renderer Analyser - http://www.whitebear.ch/dmra.htm
Author of Whitebear - http://www.whitebear.ch/mediaserver.htm

RoderickGI

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 8186
Re: JRiver Architecture
« Reply #23 on: December 21, 2017, 03:07:18 pm »

I should also add re the "Fat" vs "Thin" client debate.  I not normally a fan of "Thin" clients as they tend to be very weak on the features they can provide and ignore all the grunt that is normally available on the device running it.  Take Video Playback.  I like ROHQ.  How is this ever going to work on a Thin Client?  Sure it may be good to have a universal lightweight web app but it will never have the grunt to do what a traditional local app can do.

I agree, but think it is just a matter of selecting the right point between Fat and Thin Clients, perhaps taking advantage of some of the technologies Headcool mentioned.

But any video app has to make the best use of local resources and capabilities. That is a given. Audio might be a lot easier. Video is never going to be presented as SaaS. But then again, SaaS apps have that issue now, though usually at a simpler level.

Frankly, without taking away from all the comments above, I would just be happy if a MC Client could do ALL maintenance on a MC Server, remotely. I would spend much more time cleaning up my music collection, and perhaps tweaking the MC interface. Moving files via R,M,&CF is a pain having to go to the HTPC. Same with Cover Art, Importing new media, ripping CDs, etc. There are workarounds, but I would prefer to do all that work on my 2560x1600 Workstation at a comfortable viewing distance than sitting on the sofa looking at a 1920x1080 TV. Of course, a Client still needs to have some configuration that is local and separate from the Server configuration. Maybe on a Client the Options should be split into Server and Client Options?
Logged
What specific version of MC you are running:MC27.0.27 @ Oct 27, 2020 and updating regularly Jim!                        MC Release Notes: https://wiki.jriver.com/index.php/Release_Notes
What OS(s) and Version you are running:     Windows 10 Pro 64bit Version 2004 (OS Build 19041.572).
The JRMark score of the PC with an issue:    JRMark (version 26.0.52 64 bit): 3419
Important relevant info about your environment:     
  Using the HTPC as a MC Server & a Workstation as a MC Client plus some DLNA clients.
  Running JRiver for Android, JRemote2, Gizmo, & MO 4Media on a Sony Xperia XZ Premium Android 9.
  Playing video out to a Sony 65" TV connected via HDMI, playing digital audio out via motherboard sound card, PCIe TV tuner

astropuppy

  • Junior Woodchuck
  • **
  • Posts: 56
Re: JRiver Architecture
« Reply #24 on: December 24, 2017, 09:38:21 am »

Manfred,
You're right that setup is often the biggest obstacle.  Anything we can do to make it easier will make the experience more pleasing.

Thanks for your thoughts.

My two cents: Would it be hard/easy to differentiate audio vs video setup options by text color? Maybe change all the audio setup items to green or similar.
Logged
Pages: [1]   Go Up