Print

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

[wer]

I wondered whether to post a response to this or not... In the end I decided to, but I hope no one at JRiver will take offense.  I don't intend this to be overly critical, it's just my own personal opinion, a customer perspective.

I appreciate Jim's comments, and what jmone says is also valid.  MC is very good software, and generally represents a good value.  The licensing/development model (they're in effect linked because each has implications for the other from a purchaser's perspective) is certainly unique, but it does have some downsides in my view.

I used to be on the MC upgrade wagon.  But I'm now much more circumspect about upgrading, and this is why... The constant effort to innovate via frequent upgrades, while laudable, brings with it a lot of bugs.  When I was regularly upgrading MC, to me it sometime seemed like two steps forward one step back:  there would be some bug or issue that I hoped would be fixed or some new feature I anticipated, and by the time that was implemented a new bug was introduced affecting something that had (for me) worked fine previously.  Then I had to wait/hope for that to be fixed before the new version was launched.  That wasn't a rinse/repeat cycle I enjoyed; it was frustrating.  When I finally got to a state where all was stable, I was thrilled, and wanted to hang on to it.

My personal view, which perhaps is a minority opinion, is that more time should be focused on reliability and eradicating bugs reported by users (not to mention developing documentation) at the expense of new feature development.  I feel that JRiver is so far ahead of its competitors in terms of features that it can afford to spend more time on other things.  But I know Jim feels the current approach charts what he thinks is the best course.

But consequently, because of how the licensing model is handled, it sometimes seemed to me that there was never a reall GOOD time to buy MC.  Early on in a new version, lots of new features were introduced, along with lots of bugs.  Not a good time to buy if you value stability, as I do.  Only later in the version cycle does the focus shift to bug eradication; but that's also not a great time to buy because then shortly after a new version comes out and development is ended, and you don't get much active life for your money.

One way that might make users more comfortable, without changing the development approach, would be to slightly shift the licensing model, to provide upgrades for "until the end of your purchased version, or for one year, whichever comes LAST."  That way if the cycle lasts 8-9 months (as it sometimes does) then the user who bought halfway in would get a year's worth, and if the cycle were to stretch to 13-14 months, they would still make it to the end of the version.

A while back there was a thread from Jim requesting suggestions for "too easy" improvements.  I wonder what became of all those suggestions?  It would be really great and make people more informed about all the effort that goes into the process if perhaps once a year Jim could give a "state of the union" sort of address, where he says what they're planning for the next version, along with what were the major things requested by the community over the year, along with how they were addressed (or why not). 

The people at JRiver obviously work very hard on developing and improving the software.  But although I wasn't one of the people who evidently were complaining to Jim enough to prompt his post, I can understand why people might be frustrated or unhappy with the way development is focused.  And Jim is certainly fortunate that one of his hardest working staffers works literally for kibble.

Anyway sorry if this was too rambling.  Jim, I hope it wasn't so long you ignored it!

[JimH]

Thanks, wer.  I split it from the Apology thread because I think it deserves it's own focus.

You're in favor of stability.  So am I.  But we have to balance.  Our "solution" is to add capabilities (not just features) at the beginning of the cycle and shift to emphasis on stability in the middle of the cycle.

We try to take problem reports seriously, though perhaps 1/3 of the reports are problems related to antivirus, bad drivers, misconfiguration, networking issues, etc.  We tend to focus on problems that are reported by more than 1 or 2 users.

I just took a look at the Release Notes on our wiki:
https://wiki.jriver.com/index.php/Release_Notes_MC24

For MC24, there were:
210 Fixes
261 Changes
124 New

Many of the changes we do are to address user suggestions.

Here's the Too Easy thread:
https://yabb.jriver.com/interact/index.php/topic,112049.0.html

I tried to mark the ones we did as "Done" in red, but I'm sure I missed a few.  Why didn't we do them all?  Some suggestions were covered by features that were already there.  Some were bigger than we had time for.  Some we didn't like.  Some we didn't get to.  But that thread did get considerable attention.  It was helpful to have the suggestions. 

Frequently people make suggestions that seem obvious in retrospect.  Why didn't we do that already?  Just oversight.  We benefit immensely from the collective intelligence and experience of our forum users.

Why don't we just do what our users want? 
a.  They often don't agree.  HTPC vs. Audiophile segments, for example.  We try to provide solutions.  The Simplified Interface is a good example.
b.  We don't like the idea or we think it has a limited lifetime.  MQA, for example.  Support for streaming services that are financially unstable (Tidal).
c.  Roadblocks.  Netflix doesn't allow good support.  Nor do many other services.
d.  Cost/benefit.  A few users would dearly love to have something that nobody else cares about.  MQA.

Why do we do things our users aren't asking for?
a.  It's fun.
b.  Because it has a promising future.  Panel, for example, solves the problem of having to support so many different screen sizes and configurations.  Android, though we chose to build a solution that is much more ambitious than might have been done.
c.  We feel a need for it.

A State of the Union would be nice, but I'm not smart enough or patient enough to survey the landscape of digital media and project a future path we should follow. 

Instead, I try to follow what our customers want and engage with them when possible.  Our development is incredibly iterative.  We've done something like 1000 builds in the last ten years and maybe half of those were stable enough to make it to the Download Page.  That's quite an accomplishment.  This is a very talented team of people.

JRiver has been doing this since 1998.  I think we must now have one of the longest intense development efforts of any software.  I'm very proud of that and very grateful to you and everyone else who has supported it.

[blgentry]

From my perspective, I only see two areas that are "unstable" in MC.  Maybe I've missed the important ones to "wer" or other people:

1.  DLNA communications:  This seems to change frequently and breaks something for an existing user many times.  DLNA is really hard because it's a standard without a standard.  I understand why it keeps breaking certain brands of DLNA devices and things.  But if you are the one affected it probably still hurts the same when it breaks even if you understand it.  I wish DLNA would be replaced by something else.  I'd also like a few million dollars in the bank, if anyone is listening. 

2.  TV support:  This is still in a somewhat early development stage and seems to break various things with new releases.  I don't keep track of this closely; just my observations.

I don't recall any other systemic thing that's "unstable" in any way.  My experience with MC hasn't changed a lot in the last few years.  It seems to work the same way and hasn't really broken anything for me.  I do not use either of the above features.  I have experimented with DLNA and abandoned it.

Thanks,

Brian.

[Awesome Donkey]

If JRiver focused solely on adding features and only doing a minimal amount of bug fixes, MC would turn into Windows 10 and we know how well that's been working out for Microsoft.

I will say this though, JRiver Media Center is one of the most stable applications I've ever used. Only very rarely I encounter a major issue, and it's usually an issue that's been reported by others. I also think it's worth repeating this... if you encounter something you feel is a bug, try working out steps to reproduce the issue so it saves the developer's some time in trying to reproduce issues. If issues can be reproduced, then issues can be fixed. Don't assume any issues you perceive as bugs aren't caused by antivirus or firewalls for example, because they can and do cause issues.

[JimH]

From my perspective, I only see two areas that are "unstable" in MC.  Maybe I've missed the important ones to "wer" or other people:

1.  DLNA communications:  This seems to change frequently and breaks something for an existing user many times.  DLNA is really hard because it's a standard without a standard.  I understand why it keeps breaking certain brands of DLNA devices and things.  But if you are the one affected it probably still hurts the same when it breaks even if you understand it.  I wish DLNA would be replaced by something else.  I'd also like a few million dollars in the bank, if anyone is listening. 

2.  TV support:  This is still in a somewhat early development stage and seems to break various things with new releases.  I don't keep track of this closely; just my observations.

I don't recall any other systemic thing that's "unstable" in any way.  My experience with MC hasn't changed a lot in the last few years.  It seems to work the same way and hasn't really broken anything for me.  I do not use either of the above features.  I have experimented with DLNA and abandoned it.

I don't believe you're using either of these.  Correct?

I don't think either are inherently unstable in JRiver.  It's more about how many different devices and broadcast standards there are.  I think both are quite mature and JRiver does an excellent job on both.  It's just a bit of the Wild West sometimes.  Device manufacturer support of DLNA is often problematic.

Our DLNA support is strong enough that other developers and manufacturers use it to test against.  It's become a de facto standard on its own.

[muzicman0]

My general rule is buy early, install late.  I will take advantage of the sale (usually, not always), but I will not install until there is either a feature that I can't live without, or I feel it is stable.

[JimH]

My general rule is buy early, install late.  I will take advantage of the sale (usually, not always), but I will not install until there is either a feature that I can't live without, or I feel it is stable.

How about movie trailers?

[muzicman0]

How about movie trailers?

If you're asking if that is a feature that I can't live without, then the answer is no.  That would not be a feature I would use, or care about.

[rec head]

2.  TV support:  This is still in a somewhat early development stage and seems to break various things with new releases. 

I haven't been following the TV support because I stopped using it a year or 2 ago when my tuner died and it was just easier to use Hulu. I'm just sayin' I don't think it is in early development.

[JimH]

I haven't been following the TV support because I stopped using it a year or 2 ago when my tuner died and it was just easier to use Hulu. I'm just sayin' I don't think it is in early development.

I think we have more than 15 man years of development in it.

[muzicman0]

I think we have more than 15 man years of development in it.

And other than a few things, it works quite well.

[wer]

People shouldn't focus on the word stability, as I didn't mean to imply MC was crash-prone - it's not at all.  I was referring more to glitches.  I don't use the TV tuning functionality at all, but the only part of MC I have ever found unstable (in terms of becoming unresponsive or corrupted to the point of uselessness) is theater view. There is in fact a whole separate thread on one aspect of that instability that someone else started.

As Jim mentioned, a huge amount of effort has gone into tv support, and since I don't use it that's of no value to me at all, but that's why I expect mine is a minority opinion.

MC, when used interactively as a normal windows application, is very stable and non-glitchy.  But that is not my use case.  I primarily use it as HTPC software, so that means theater view and a remote.

Theater view is graphically rich and complicated, and has to deal with video drivers and multiple video modes and refresh rates, as well as interacting with and depending on "3rd party" software like madvr and lav.

So the stability and glitch-free operation of theater view is of paramount importance to me.  Different people, different priorities, different interpretations...

[wer]

@JimH, what do you think of the licensing concept I described, since I anticipated you don't want to make any changes to the development approach.  Someone else had commented on that in the original thread, too.

[JimH]

@JimH, what do you think of the licensing concept I described, since I anticipated you don't want to make any changes to the development approach.  Someone else had commented on that in the original thread, too.

I think it would take some time to implement and probably not improve sales, so I'm not inclined to do it.

[JimH]

wer, are you using stock Red October settings?  Or are you customizing madVR?

I don't think we've seen general Theater View problems for some time.

[blgentry]

I wish I hadn't said anything.  Carry on as if I had not.

Brian.

[swiv3d]

I think they already are Brian

[Manfred]

Stability:
I have my media server now 1Y3M and using MC now ~6 years - in the early day' only on one HTPC. The media server run's 7x 24 x 365. During the 1Y3M period it has never crashed. 1 x planned shutdown for adding a new disk and the monthly reboots for the Microsoft Win 10 upgrades. That is from my PoV extremely stable. Problems occur always on the integration part (Nvidia Video Card , DAC, DLNA), e.g. I never get my Devialet working without stuttering with the MC DLNA server - for what reason ever -> but I think its on the Devialet side) 

Features
I think most people today want to have a more agile approach and not one release per year. But if one wants one has the choice between stable path and most recent release. I am pretty OK with your approach.

[Spike1000]

People shouldn't focus on the word stability, as I didn't mean to imply MC was crash-prone - it's not at all.

No, it's not crash prone but there is a clear perception of 'stability' issues with MC. Standing on the outside looking in gives a different perception of 'stability' than the MC team looking out; two areas come to mind.

The weird interaction between MC and antivirus applications on some people's PCs. In all my years in enterprise IT I have never seen such issues from any other application. . . .  Very strange considering the function of MC. There's never been an explanation or an improvement in MC, just a need to tame some people's AV.

There are too many 'side effects' created when a new minor version is released. ie fixing X caused Y to happen. The Y's aren't usually catastrophic so they don't affect many users but they show lack of testing before release. In a earlier post I thought one stable release a quarter on the stable channel with minor (less stable?) releases on the latest channel would be worth considering.


Spike

[Vocalpoint]

No, it's not crash prone but there is a clear perception of 'stability' issues with MC.

Agreed. One area that needs some serious work is the thumbnailing. This out of all MC functions causes me the most trouble. It either uses all the CPU, locks the machine (with an out of focus view of the UI) or a combo of both. Not sure why it would be so hard to create a thumbnail of album art - maybe it's an issue with FLAC files? That's all I use.

Search is another - at least here. I have had numerous incidents in the last few weeks just searching for something. I type in a Search term (in the upper right field) - and MC crawls through the search results like it's in molasses.

Then the molasses clears and search returns a result - other times - results are painfully being squeezed out while I type and hard freeze. And yet other times - MC just disappears off screen. Wish I could figure out what the deal is but it is never consistent.

I can type the same identical search three different times and I have gotten three different UI results (molasses result, molasses then freeze and finally crash and burn). Other days - I can search for a half hour straight and nothing bad happens.

Library is local to the machine on a super fast SSD - so I do not understand the painfully slow "let me grind through your results while you are still typing" user experience. I would much prefer - put in search term, press Search - see results.

If MC is going to be like Google Search - the Search box needs display it's results as fast and as smooth as Google Search does.

VP

[rec head]

I only have 10612 audio files but search works really fast here on this client.

[Vocalpoint]

I only have 10612 audio files but search works really fast here on this client.

I keep wondering if my search issues have something to do with a segmentation of files. (or paths/locations?)

I have 78000 FLAC files in the main library (On our network server) but I have a view that points to a local folder where I do all my file tagging etc.

But since search is presumably using the local library files and (I assume) is not actually be "looking" at anything physical in the network folders - I still do not understand the pokey search. (sometimes).

VP