MRV question

But D* already has the wheel, and the road, and the vehicle. What I got from Cartivision's (apologies to him if I'm wrong) post is that if D* had worked on MRV first, they would be dealing with the least number of variables. They would be developing a program that, for the most part would be dependant on pieces they have the most control over...the HR2x boxes. The only variable would be the network router, switch or hub (if they were even needed). Compare this to a closed water distribution system. D* has complete control over the source (D* dvr) and the destination(s) (other dvrs) of the water (video content). The only variable would be the valves (router, switch or hub). Working on media share, they have to deal with other sources of water (customer computers and software) over which D* has no control.
In other words. If D* had started with MRV, almost all of the pieces that they had to fit together would vary little from one customer to another. The path they took forces them to deal with an infinite number of variables over which they have little or no control.

 

I don't get it... HAHAHAHA

 

Unfortunately, your counterargument consists of changing my statements on the subject into something that is far from what I said, and then shooting down the made up argument that you try to attribute to me.

That trick doesn't work.

There is no reason that MRV couldn't have been properly prioritized higher than other network related functions like media sharing. That wouldn't require "three teams in parallel". The basic networking functionality could have been built slowly and one step at a time with MRV as a priority over other lower value network based functionality. Contrary to your mischaracterization of my argument, setting that priority doesn't mean that I expect the development process to skip the trials and skip all the incremental development steps that need to be taken to achieve a workable core set of functions that are required for and directly related to MRV. Properly setting MRV as a priority doesn't require require getting it all done at once and throwing it out the door to the customer before all parts of the required functionality have been tested and assembled into a usable product.

Other than the fact that it requires network connectivity, (while requiring it's own unique client-server model), media sharing is largely unrelated to MRV and a drain on limited resources that could be more wisely spent developing more of the core building blocks of MRV. It's a separate function that may on the surface look like a simple type of MRV where a computer is the server of the programming, but it's a mostly independent functionality that has a unique set of requirements for interfacing with third party hardware and software, and a unique set of requirements to have to be able to find, select, decode and display media files that are in a format that has absolutely no relation the media that another DVR will be serving to clients for MRV purposes. In other words, it's a resource wasting distraction from developing the higher value functionality that that is still not there but which MRV will need to use as the building blocks to eventually produce a customer ready MRV function.

 

The problem is.... all the time and resources spent on many of those "building blocks" that some people keep incorrectly insisting are need for and going to be used by MRV, but in reality are only needed for a largely unrelated and different client-server function.

 

So how would a singular team develop only a portion without having another team to test against? I content you still have 3 teams. (Or sub teams, to me the same thing.)

Your comments seem to continue to ignore one major fact: DIRECTV wants to build a DLNA compliant server and client MRV.

Granted, Media Share isn't fully DLNA compliant yet. DIRECTV has, I believe, left off some of the full codec set, much as you propose for quicker MRV. Codecs are relatively easily added later.

Nor is DIRECTV2PC fully DLNA compliant--it doesn't transcode to meet all the transcoder requirements of a server. Again, they skipped that compliance for now--to speed things along.

Lastly, DLNA is a nice means to present and find programming. Why not use it as you suggest? Why reinvent the wheel only to abandon it next month?

Oh, well. Guess we'll have to disagree to agree...

Cheers,
Tom

 

As you have pointed out before (but seem to conveniently ignore when laying out your theoretical "3 concurrent team" scenarios), there are existing third party clients and servers (DLNA compliant and otherwise) that DirecTV can use during their MRV development cycle. There is no need to have three teams going concurrently with one or more of them reinventing the wheel by developing something that already exists to use just for testing the other end of a client or server function and then throw it away.

The problem with most of your arguments is that they exhibit a black/white "either or" way of thinking. The approach that DirecTV is taking to eventually rolling out MRV doesn't have to be either all right or all wrong…. it can be somewhere in the middle. Some of the networked based development may be following a sensible path, but I still contend that there have been some poor priorities set and some distractions of wandering into development areas (both network related and not) that MRV should be taking priority over.

 

:beatdeadhorse:

 

Certainly, especially since most of that water has already passed under the bridge :shrug:

 

I have a feeling that horse will continue to be beat until MRV comes out, even then the DLB horse is going to still be getting a thrashing :lol:

 

...and yet - a small community of dedicated developers managed to get DTivos to send program content to each other many years ago - and they did it without all the complications talked about in this thread. Developing software can be difficult - or it can be very streamlined - if it's done using an easily expanded and powerful environment with lots of existing code and tools to build upon. On the other hand, if you're stuck in the 90's doing development on a proprietary code base and trying to reinvent both fire AND the wheel, well...

 

Without a doubt...

Well just wait until MRV does come out and we'll see how people change their tune.

 

Isn't the DLB horse already glue?

 

And just how do you know 100% for sure that they didn't go down the same road?

I think the only reason we see how it's progressing towards MRV is because of the CE program. With the DTivo you didn't have that and therefore didn't see all the steps along the way.

Oh, and btw, MRV on the DTivos NEVER worked on the HD DTivos. Working with HD streams and files is QUITE different. Not to mention we are now in the DRM age whereas the DTivos didn't deal with that.

 

Of course there was incremental development of the community enhancements - MRV and the rest of the features didn't just appear out of nowhere. I know because I watched it unfold in forums like DDB, TivoCommunity, etc. It was a typical opensource development project - with plenty of code sharing, trial & error and leaps forward. What it was NOT was the typical corporate HW/SW development grindstone that becomes impeded by marketing dweebs, bean counters and pointy-haired executives.

My point is that the design decisions made for the HR2X have made this process harder than it needs to be. It's a closed design. It's not based on a development environment that allows previous work done by smart people to be leveraged and reused. They are thinking like a HW company, not SW developers.

Gee, I would think that after spending this long actually producing HD-DVRs, they should know how to deal with the DRM - they do have to decode the data in order to create the video, right?

I do agree that HD & DRM make the job more difficult - but they had a chance to design this unit from scratch to handle this capability. This isn't a general purpose PC - they are able to use DSPs and other custom dedicated HW components to provide the horsepower to do the tough jobs. I don't think the HR10 had the horsepower to do MRV on HD video, and even if it did, the DRM was not something that the opensource community could handle. As a "real" company that (I assume) is licensed appropriately, I don't think obtaining the appropriate development documentation should be a problem for the HR2X development team.

That leaves the other software features and the UI - and they *could have* used the zillions of lines of good SW code that already exists to provide some of the really cool features. But they do not appear to be doing that - they appear to be developing it all from scratch.

 

As I recall, I saw media share of pictures from pcs to a dvr first on a replaytv, then on a tivo, then some other stuff, and finally MRV on replay, and then tivo... so looking at the pioneer of all this dvr technology, and its closest follower, Diretcv seems to be following the overall same path.... Maybe for different reasons and what not, but it looks quite familiar...

 

Has anybody seen ATT Uverse yet? I keep seeing and hearing add's that they have this feature already. Granted Add's and the Real thing don't always go hand in hand.