Print

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

[jmone]

All this BD Menu talk has me excided!

If menu support took a few days, sure.  If it's a lot bigger project, I'd rather put it into intercom support

  - I have faith for both and even more!  

I remember it took a couple of years of pushing for BD support and there was plenty of "physical discs are dead... online is the future".  And look what happened, BD support arrived... the heady days with Hendrik and madshi developing RO, MC became a Videophile player and new wave of users arrived.  And... drum roll, Glynor is now pushing for more, Matt seems to have a few BDs (not sure he has ever played that Eagles BD however   ) ...but the current feature set is no longer on the leading edge.

I have a dream!
- JRiver hires Hendrik done
- MC will support BD Menus
- Particles will be finished
- Gizmo will be a zone that you can push to
- Gismo's cache can be used to sync for offline playback (replaces the current HH Sync)
- Gizmo will be ported to iOS, Windows, Unix, and OSX
- MC will be able to serve "Connected Media" like TV, Radio Stations etc to Clients (like Gizmo, DLNA etc)
....oh and since Gizmo is now cross platform and will be 2-way you could use it for Intercom as well!

Think of how universal this ecosystem would be.  You would have clients on all major platforms and could push/pull all media types with MC server being the backbone of it all.

This is not a new dream.  Here is the Pic I originally posted in 2009

[InflatableMouse]

Your dream doesn't include 3D stereoscopic playback support?

[jmone]

Idea: 3D BD External Player Support (Easy Addition!?) http://yabb.jriver.com/interact/index.php?topic=77211.0

...other idea was to see about using/licencing the required 3d decoder/transformation/renderer filters as is done by the Steroscopic Player http://yabb.jriver.com/interact/index.php?topic=84509.0

These ideas got even less support than the intercom! ...and since I only have 1 3D disk.... my dream on this is fleeting!

[SamuriHL]

It's not fleeting for me. 3D support would be very nice. But the challenges there are greater than for menus. We need codec support and renderer support. I'm quite certain my ps4 will see 3d playback before that happens. I know madshi talked about it for madvr at one point but I don't think it's coming soon.

[glynor]

Your dreams are kinda boring, Nathan.

Mine involve flying.
Or nudity.
Or both.

[InflatableMouse]

LOL! 

[rpalmer68]

Your dreams are kinda boring, Nathan.

Mine involve flying.
Or nudity.
Or both.

Oh do tell!!

[jmone]

A flying nude Glynor is not a dream .... a nightmare!

[glynor]

A flying nude Glynor is not a dream .... a nightmare!

I didn't say it was me. 

[MrC]

Mine involve flying.
Or nudity.
Or both.

Mine too.  And also supermarkets.  I have no idea why.

[InflatableMouse]

I always wanted to fly in my dreams. Sometimes its like I'm flying, but when I look down I'm just growing real large.

[fitbrit]

but when I look down I'm just growing real large.

Ummm, is this related to the nudity again?

[InflatableMouse]

Ummm, is this related to the nudity again?

Nah its just you who has an obsession with nude forum members  

[glynor]

- Gizmo will be ported to iOS, Windows, Unix, and OSX

Moving on more seriously with the original post (figure I should since I side-railed the topic)...

Why do you want this?

That's weird in a bunch of ways:
1. Why OSX and Windows?  Isn't having MC itself good enough?
2. Why iOS?  That would pretty well ruin JRemote, and I really like JRemote.  Is there some category where it is failing (other than places it can't yet support like Video, where Gizmo would have the same limitation)?
3. Why Unix?  For all twelve people who might want this?

- Particles will be finished

I'll throw you a bone on this one.  Yes, I agree.

Don't think I'm letting you get off that easily, though because...

- MC will support BD Menus

I really could not care less.  I do, maybe, agree that it could help gain new users, though I think that the AnyDVD HD requirement limits growth there anyway.  Anyone who really, really wants a "full featured" BluRay player application is probably also going to want it to be a fully licensed decrypting player that can handle commercial discs.  So, I'm dubious on how much this really gains us there.

And...

Maybe you've seen some really amazing ones, or just think they're way cooler (generally) than I do, but... Meh.  The Menus just get in my way.  I want to watch the movie.  Not look at some junky (and usually poorly designed) UI whipped up by an intern somewhere.

I don't know.  It'd be fine if it was simple, but clearly it isn't.  I think I'd much rather have Hendrik work on lots of other stuff first.

What's your reason?

[fitbrit]

I agree with (clothed) glynor on the BD menus. However, I would love it if MC could recognise TV show discs and play all the episodes, not just the longest one.

[InflatableMouse]

I agree about the BD menus. I also think it would be neat if it worked, but I much rather see particles work flawlessly and I would never look back. Theater View with its menus is perfect, I don't need another menu from a disk for all the reasons clothed Glynor already pointed out. I wouldn't trust him if he were nude.

I think with anydvd hd MC can play commercial disks right (sorry I never tried). How cool would it be if carnac and particles worked on the fly and made the disk accessible as any other movie or series episodes? You'd choose DVD or Disc and it shows the cover and synopsis like when you choose a movie from your library. Or it shows the episodes that are on disk as if it were part of your library.

[fitbrit]

Theater View with its menus is perfect, I don't need another menu from a disk for all the reasons clothed Glynor already pointed out. I wouldn't trust him if he were nude.

[jmone]

Actually, Matt's request that I "train" my family to use the JR Menu system worked... for most things.  The issue is not getting the BD Menu per say but the logic that it contains for being able to identify and select:
- Theatrical Vs Alt endings
- Multiple Eps on TV BD's
- Forced Subs (that are not marked as forced)
- Extra's

These are covered in the thread started by SamuriHL (with apologies to Glynor for attributing to him in the OP), so I won't bang on about it in this thread.

Now SamuriHL's post got me thinking about other aspects of the current state of play on usability.
- Particles:  No brainer, great feature, just needs to be rounded out
- Gizmo.... This one is much more "interesting" and my OP on this was from my "intercom" project.

My entire family has MC on their laptops.... and they never use it.  I put the tablets as part of the "intercom" project in their rooms... and guess what.  They use it to consume content all of a sudden.  The kids use it for watching Video (TV Eps) and my wife for the Radio.  I asked why they use the tablets not their Laptop and got an odd shrug and a vague explanation that Gismo worked.  I pointed out that MC on their Laptops was better quality, bigger screen etc etc and they just looked at me blankly and suggested it was too hard.

It finally occurred to me that Form follows Function.  They don't see their laptops as a media consumption device.  They eat their content on their phones and now their tablets.  My daughter alone eats 5GB per month on her iPhone.  

So why is Gismo a Hit when MC is not?  It is simple, it works, and it is focused on consuming (not managing) content.  So my suggestions are about expanding Gizmo to work across platforms, expanding it to support all content types (eg Connected Media) and fixing the Video playback issue we are now seeing on some devices.

Why should JR not have a Purely Consumption App (aka Gizmo) that just pulls all content from the MC Server regardless of platform?  JR has slowly being decoupling the server/management of content from consumption of it, so may as well look at owning the consumption end as well.  For example it is great people like JRemote but it is useless for me given our Video consumption requirements.  

This is the model all the Youtubes, Facebook, Twitter, etc etc apps use.  They have one backend platform and a cross platform consumption app.  Can we not have the same?

JR is spending all this effort creating a cross platform MC, but for me I'd much rather have a cross platform Gizmo.

The new generation is mobile and MC is not.

[jmone]

....so building on that original pic of playing any media to any device, if I look at the function of Media Server & Media Player by platform, I'd say we have (though I'm guessing on OSX / Linux):

Media Server
- Windows:  Fully mature and best of breed
- OSX: Under development and best of breed?
- Linux: Under development and best of breed?

Media Player
- Windows:  Thick Client Only, Theater View, High Quality Audio and Video
- OSX: Under development Thick Client Only, Theater View, High Quality Audio no Video
- Linux: Under development, Thick Client Only, Theater View, High Quality Audio no Video
- DLNA: Stable, Video, Audio using preset config (no customisation of formats)
- Andriod: Thin Client, Audio and Video, preset configs, some compatibility issues with newer model, no offline playback
- iOS: None (third party app for Audio no Video)
- WinMo: None


To me the opportunity is the cross platform playback.  We have the server pretty well sorted (some more flexible transcoding is needed for video and support for connected media) but the options to consume this media is limited.

[AndrewFG]

So why is Gismo a Hit when MC is not?  It is simple, it works, and it is focused on consuming (not managing) content.  So my suggestions are about expanding Gizmo to work across platforms, expanding it to support all content types (eg Connected Media) and fixing the Video playback issue we are now seeing on some devices.

In my household, we use TheaterView on the TV.

I justified to my wife the purchase of a really big and really flat TV by means of the argument that "it's the biggest iPad you ever did see"  

For user play functions, I could happily live with TheaterView on the TV and Gizmo on the tablet. And I would only use MC for "management" functions.

So therefore my vision would be:

• The UI of TheaterView and the UI of Gizmo should follow common design guidelines. (Which they definitely do not do right now).
• Both of these UIs should implement "right click" context menus to take you to "other stuff related to this"  1)

1) I still look back fondly to the Logitech Media Server (RIP) where, wherever you were located in a browsing tree, you could drill down resp. link to something else (e.g. story lines like: you are playing a random track, you right click, you select the menu option that says show me the album in which this track is located, you right click the menu option on the album to add it as the as next to play, ...) With that model you could surf through your music library on infinite tours of exploration, without ever needing to come up to the home menu. It was great!

[jmone]

This is similar to our usage pattern;
- I use MC to manage the library on the "Server"
- We consume content on the HTPC using TheaterView on the main TV/PJ MC Server
- We consume content on android tablets using Gizmo served by MC Server
- We consume content on the PS3 using DLNA from MC Server
- We don't consume any content from the laptops or iStuff

Interestingly, competitors such as MediaBrowser3 seems to be focusing on standardised playback clients on HTML5, iOS, Windows Phone, Android though while the clients look good their server is ordinary.

[JimH]

My entire family has MC on their laptops.... and they never use it.  I put the tablets as part of the "intercom" project in their rooms... and guess what.  They use it to consume content all of a sudden.  The kids use it for watching Video (TV Eps) and my wife for the Radio.  I asked why they use the tablets not their Laptop and got an odd shrug and a vague explanation that Gismo worked.  I pointed out that MC on their Laptops was better quality, bigger screen etc etc and they just looked at me blankly and suggested it was too hard.

It finally occurred to me that Form follows Function.  They don't see their laptops as a media consumption device.  They eat their content on their phones and now their tablets.  My daughter alone eats 5GB per month on her iPhone. 

So why is Gismo a Hit when MC is not?  It is simple, it works, and it is focused on consuming (not managing) content.  So my suggestions are about expanding Gizmo to work across platforms, expanding it to support all content types (eg Connected Media) and fixing the Video playback issue we are now seeing on some devices.

Why should JR not have a Purely Consumption App (aka Gizmo) that just pulls all content from the MC Server regardless of platform?  JR has slowly being decoupling the server/management of content from consumption of it, so may as well look at owning the consumption end as well.  For example it is great people like JRemote but it is useless for me given our Video consumption requirements. 

This is the model all the Youtubes, Facebook, Twitter, etc etc apps use.  They have one backend platform and a cross platform consumption app.  Can we not have the same?

While I think you need a full featured app for many reasons, I do agree with you about the need for a simpler interface for consuming media.  We've always thought of Theater View as the best interface for consumption, but even that is too complex for some people. 

Gizmo gets used a lot in our house for playback.

Thanks for the analytical thoughts.  I think you're correct.

Linux, though, is extremely important for OEM's.  Mac is important to a lot of audiophiles.  Porting to Mac was clearly the right decision.

[fitbrit]

I find the touchscreen experience to be much better on JRemote/Gizmo than in Theater View. We could afford to make theater view behave a bit more like the touch apps for touch screens.

[jmone]

Ports - Don't get me wrong, I'm sure the ports to OSX/Linux is a good business decision for JR.....  The lack of enthusiasm on my part is just that JR is not currently working on the things I care about.  Like all of us, I do my best to try to get MC's precious dev resources onto stuff I want.  I mostly fail  

Full Feature App Vs Consumption App Vs Server - I too use TheaterView as our prime GUI for the HTPC and it has served well since it's introduction....but as it is a skin over the full thick client you are sort of stuck if you want to keep this UI on other devices (phones, tables etc etc).  The benefit of the Full version running TheaterView is all the high end VQ and SQ goodies we get.  That said, Gismo was an a stroke of genius and from memory was developed in a very short period of time.  The result with the family (that they don't use the MC Front End but do use Gizmo) shows that for these devices the presentation layer is a key driver for use.

Now I don't profess to know what a cross platform "Gizmo V2" should be built on (HTML5, Java, Cobol) & I don't care as long as it works and looks the same across these devices.  

[csimon]

Separation of each distinct function of MC?  e.g.

1. Database (library) server.
2. Decoding/processing server.
3. Maintenance client.
4. Browser/player/renderer client.

Each module could then be ported to platforms that make sense (e.g. it might not make sense to run a database server on an iPhone, nor would it make sense to put a renderer on a NAS box), and customers can then make the choice as to their preferred devices for each purpose.  This really is the only way to achieve a goal of MC being a truly networked, portable, platform-independent, media centre for the whole household.

One scenario:

Database server on a central NAS.
Dad performs ripping, tagging, maintenance etc on his office PC (note: no need to bother with synching, creating temp libraries and switching libraries, nor any need to leave this machine switched on all the time).
Teenagers use their own PCs in their rooms.
Kids use tablets and phones.
Family uses the TV and hi-fi in the living room, controlled by mobile devices or remote controls.

One-person, one-room scenario:

The same machine can indeed be both client and server at the same time, just install all modules on the same PC.

[JimH]

I think we have most of the advantages of that now, without any of the disadvantages.

MC is both a client and a server and it can serve both purposes at once, even serving several clients and playing to several devices. 

We've also done the major work needed for porting.  It's as free as it can be of OS dependencies.

All of the scenarios in your post (csimon) work now.  I don't know why you would need to create temp libraries.  You could start a thread on this if you like.

[csimon]

Well, I don't really want to start another client/server debate, it just ends up going round in circles! But no, it's not possible to do the things mentioned above at the moment, it's all been discussed before. Here's another thread with someone trying to get their head around it as the procedures are not explained anywhere and it's up to each person to find out for themselves that it doesn't work.  http://yabb.jriver.com/interact/index.php?topic=85886.new;topicseen#new

Basically, the workarounds involve various combinations of switching to a temp local library, maintaining separate libraries, or using a third-party client/server protocol (i.e. RDP, VNC) - all of which mean not using the MC client/server functionality.

It is not possible to rip CDs on a client into a remote library, nor to import into a remote library, and people have also mentioned deleting/moving issues. There are also suspected synching issues where changes made on a client are not guaranteed to reach the server. See above thread for an example. I can also imagine that turning off the client after making changes is going to be dangerous.

I'm talking specifically here about a "library maintenance client", i.e. the ability to connect to a library whever it is on the network, whether it's hosted by another PC or whether it's hosted by the PC you've got the client on, and maintain it. There shouldn't be any limitations on functionality and data integrity just because the library is not on the same machine, it should behave in exactly the same way regardless of what library you are connected to.

With regards a "playback" or consumption client, there are also possible issues regarding the ability to control a client when connected to a server, or vice versa (it's a bit vague to me at the moment, but this question has criopped up several times). It seems that to be able to control all MC instances and zones, you actually have to set up multiple servers and switch between them, which is counter-intuitive when you think you've designated a "server".

jmone's diagram is actually a classic client/server model when you break it down into basics and I'd love for MC to get to that point as a multi-platform networked media system but the individual functions need to be separated and client/server issues ironed out before it can become seamless, logical and useable for the average non-techie.