Print

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

[Hilton]

Let me know if you want me stop. I'm happy to keep it to myself.

[jmone]

Don't stop.   I was about to add a post diatribe on this in general, so I'll add it here.

Matt posted a few years ago that the computer was a universal can opener that is or can better than dedicated AV devices.  There was nothing that a dedicated AV device could do that could not be done as well as or better by general computing equipment.  And so it was!... as an example we had a raft of great changes in a short period of time like the focus of bringing Video playback to the fore:
- Red October (LAV and MadVR for the broadest and finest PQ you can get)
- Video Clock
- Remote Clients for the pulling content

What was great was the to and fro on ideas and directions that lead to all this development.  But the landscape keeps moving and that vision is still far from realised.... and the "Whole House" media is one example.  There is a heap of tech being pushed by others to achieve this in the market place, but what worries me is the utter silence from JR on this and to me it is even more surprising as Audio is a Core Strength and part of the MC DNA.  It has me utterly baffled.

Lets looks at the eco system already in place:
- The finest Audio Engine bar none
- Platforms on Windows, OSX, iOS, Linux, and Android

You think you could hook it all up?  A bunch of your users what to pump Audio around their house (not just sit on a PC with Headphones arguing about some esoteric bit polishing).  

So instead of leading the debate on what should be done, Hilton (myself and others) are in the weird position on actively promoting other mfrs products such as;
- a third party audio server!  (eg Tuneblade, Airfoil, Airplay)
- third party audio receivers! (eg Airfoil PC Clients, Airplay speakers
- third party audio controllers!  (Tuneblade remote to control what end devices are on/off, sound levels etc)

Are these not all part of what MC does?

.... the good news for JR is while it "works" it falls way short of MCs high Audio Std as all you get is 2ch 44.1/16Bit Audio at best.  The danger is that in such a distributed environment it matters little how "good" MC is if all the serving, transport and rendering is done by someone else's sub standard audio, may as well use iTunes.

Please (even if it is not this topic).... just articulate a "What's Next" and take us on that ride.

Thanks
Nathan

[Hilton]

Personally, It is a little frustrating, but the guys do eventually get there. (eg. I had NAS mounting and USB mounting on the Id months ago and it's now way ahead of what I thought they'd achieve by this time)
However, I can also appreciate the apprehension and careful consideration for what path to take.
JRiver could take a wrong turn and burn dollars on development that someone can just switch off overnight.

There is no clear path that I can see other than to accept you need to have a better web engine which has already been stated by Jim anyway.
I think enabling a full chrome engine is the best bet at the moment. That enables HTML 5 with EME encryption support off the bat. Pretty much any video or audio streams in the future will be using this.  Seems to me the best browser for the job is a full version of Chrome.

Some of the other smaller steps have already been made in the way MC can now handle streaming media, and it is only very early but look what I've already achieved.

The AirPlay thing is working for me so im not too concerned about that now. It actually works very well and I'm not sure MC could be made to do it better without significant development.
Not sure I think it's worth it.  Adding NTP sync to linked zones for the native MC implementation would be useful though.

I just think the safest way forward at the moment is to have a fully enabled web engine and tweak the library to handle different files better. (which I've been doing manually)

Create a playon type chrome plugin that allows you to right click send to library for storing urls more seamlessly.
Create a keyboard or navigation plugin for the web browser view.

Some days in the recent past ive been on the verge of just going with something like XBMC/Kodi or going the hardware path.  But then I miss too much of what I've come to expect from MC.

A few years ago I first started with MC13 and it didn't really ring my bells back then. So pretty quickly I went back to XBMC on the xbox and iTunes.
It wasn't until MC17 or 18 that I really got back into MC.  That was mostly driven by hi-res music and the desire for proper DTS-HDMA audio and ripping my bluray collection.

Now it seems there is another fork in the road and it leads up multiple paths.  I guess I'm not unsatisfied now, but if no further development towards streaming media handling of DRM protected content is made, I can see MC just being my private collection media server until something better comes along.  

[imugli]

Let's not forget also that it's one thing for a user here to say it works and explain how to do it, and a completely different thing for Jim et al to endorse it, especially given there are third party apps involved. If any of these apps change in a way that renders MC unable to use them, JR have endorsed something that no longer works.

JR has to stand behind their product, users here just get to play with it and do great things.

[JimH]

I'd like to point out that we had Netflix working pretty well before they removed their API support.

We're just a small team competing in a space where big companies are spending hundreds of millions.  We have to choose what veins to mine, and we can't afford to make big mistakes.

In the last year...
Adding Linux and video on Mac and Linux took a lot of time.

Many tedious changes to TV and setup.

A ton of new code to unhook from Windows.  We're still not finished with this.  Mac and Linux need images and Theater View.

Integration of Robert and Hendrik and the re-integration of Matt.  Matt is still not quite full time.

New Android version of JRemote.

Id -- you may not need it, but it is a way we can serve non-technical users.

Pono -- still unclear where it will lead, but we had to try.

Many audiophile manufacturers and new distribution in other countries.  These take time, but they pay the bills.

DSD, Double DSD, Peppermint DSD, etc.

In many ways, I think we're winning.  You may be able to do more by bolting a lot of other packages together, but the average person, even average technically skilled person, just won't do that.  And it's not piece of cake to make it all work as one smooth system.

I'm really proud of the team and what we've done.  It will only get better.

[JimH]

Let me know if you want me stop. I'm happy to keep it to myself.

No.  I don't mind at all.  I'm glad when you stir things up.  Just look what you've done to Nathan.

[Hilton]

No.  I don't mind at all.  I'm glad when you stir things up.  Just look what you've done to Nathan.

LOL 

[Matt]

I just think the safest way forward at the moment is to have a fully enabled web engine and tweak the library to handle different files better. (which I've been doing manually)

Could you expand on what's missing from the web engine?  Because I thought our version of Chromium was basically the latest and greatest.

Thanks.

[Hilton]

Could you expand on what's missing from the web engine?  Because I thought our version of Chromium was basically the latest and greatest.

Thanks.

I guess this sums up the current problem pretty well.

https://news.ycombinator.com/item?id=8956276

http://www.html5rocks.com/en/tutorials/eme/basics/

[Hendrik]

I'm not aware of an official and supported way to embed the full binary Chrome browser into your application, which is the only way we would be able to use it, and even then I would be rather reluctant.
Chromium of course doesn't support HTML5 DRM.

You could always try the IE engine, maybe MS allows these things to be used from a browser control, but I wouldn't hold my breath. DRM is the death of good user-experience, as it *severely* limits what you can do.

[mwillems]

I'm not aware of an official and supported way to embed the full binary Chrome browser into your application, which is the only way we would be able to use it, and even then I would be rather reluctant.
Chromium of course doesn't support HTML5 DRM.

You could always try the IE engine, maybe MS allows these things to be used from a browser control, but I wouldn't hold my breath. DRM is the death of good user-experience, as it *severely* limits what you can do.

Didn't mozilla effectively find a way to introduce a closed-source DRM blob into their open source browser (firefox)?  Could you repackage Firefox or is that a non-starter for a similar reason?

[Hendrik]

You cannot just "repackage" a browser, it needs to offer a way to officially integrate its rendering window into another application. And considering Mozilla's DRM module is closed source, I'm not sure they would be happy anyone else re-distributing it inside their own app.

[mwillems]

You cannot just "repackage" a browser, it needs to offer a way to officially integrate its rendering window into another application. And considering Mozilla's DRM module is closed source, I'm not sure they would be happy anyone else re-distributing it inside their own app.

Got it; I wasn't sure what their support for third-party integration was like.

[jmone]

No.  I don't mind at all.  I'm glad when you stir things up.  Just look what you've done to Nathan.

but in my defence, Imagine the shame I feel as I've resorted to purchasing Apple Devices (3 Speakers and 1 AirPort Express) to just get audio.  The Horror!  I'll be buying Bose Cube speakers next and wearing a Turtle Neck. 

[JimH]

I'm weeping as I read.

[jmone]

You may be able to do more by bolting a lot of other packages together, but the average person, even average technically skilled person, just won't do that.  And it's not piece of cake to make it all work as one smooth system.

I agree, no one wants to bolt all these bits together as at best you end up with a bunch of compromises even if you can work it out.  The thing that struct me in the exercise however is MC already has these functions in spades (serving, transporting, rendering) but we are effectively replacing them all just because the current MC setup does not sync the renderers.  

I'd still love to hear if this is an area that JR is considering for MC?  At this stage I don't care what the underlying protocol is used, MC homegrown, DLNA2, NTP Sync, Airplay, Pixie Dust - but more if it is on the "short list" of stuff to implement in MC.  I'm also fine if it is not even on the "long list" and I'll just move on (I've not mentioned Intercom for a very long time!)
  

I'm really proud of the team and what we've done.  It will only get better.

+1 You have my agreement on that!

[JimH]

... just because the current MC setup does not sync the renderers. 

I'd still love to hear if this is an area that JR is considering for MC? 

Yes.

[jmone]

Now I'm a happy boy!  [insert dancing emoticon here]

Thanks Jim!
Nathan

[jmone]

I'd like to point out that we had Netflix working pretty well before they removed their API support.

I feel for JR on these ones, and the iStuff sync was a similar story.  Go to all the time, effort and money to write to a company's API only to find that they pull it.....  You can see why interest just wanes at that point.

At least with the Audio Sync there are a bunch of published specs that can be used + it's not like some exec from Company X can just wake up and close it down in this case.

[gvanbrunt]

but in my defence, Imagine the shame I feel as I've resorted to purchasing Apple Devices (3 Speakers and 1 AirPort Express) to just get audio.  The Horror!  I'll be buying Bose Cube speakers next and wearing a Turtle Neck. 

I think I puked in my mouth a little...