Print

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

[TheShoe]

Does JRiver think it might be good to have a "Feature Request" thread where you could track all in one place?  I see them often distributed throughout the usual bords.  Might make searching easier before requesting something someone already posted, and you could possibly lock threads or put a status on them as "not going to do", "roadmap", etc....

Dunno...  just thinking of a way to organize the boards a bit more.  Having it of course is no commitment at all to doing it.  It may also draw more attention to the brief requests lacking detail where others could help shape the request with more feedback, details, and possibly suggest alternatives/existing solutions to an already complex product.

Just a thought

[JimH]

I think you just started one.

[TheShoe]

Ha - I wasn't clear

A feature request board...

[JimH]

I'm not in favor of adding a new board just for requests. 

[Awesome Donkey]

I can just imagine the constant requests for Tidal, Qobuz, MQA, full SoX, Amazon Music, Apple Music, Spotify, DSD1024, etc.

[zybex]

You still get all those requests, just spread out across all boards. I like the requests board idea.

[JimH]

How would JRiver benefit?  It's a lot of requests now, but it's possible to see what's valuable.  A certain percentage of requests are for capabilities that already exist.  Some are for things we'll never do.  Some are beyond the scope of what a small team can do.

A good request, well presented, is often implemented within days.

[BryanC]

+1 to a feature request board

A certain percentage of requests are for capabilities that already exist.  Some are for things we'll never do.  Some are beyond the scope of what a small team can do.

Provide your reasoning in the thread, and after a few weeks of no new discussion lock the thread to create a "feature request graveyard" that newer users can search so they don't keep on suggesting the same "features" you aren't keen to implement. Would also make it easier to link duplicate requests to past discussion and JRiver's response so users can see the whole picture. You can sticky and lock the really pernicious ones for prominence.

It should lead to fewer annoying requests, as they'll be 1) better contained and 2) less redundant.

[JimH]

Another factor... sometimes we want to go in a different direction than our users.  Think of it as artistic license.  If we'd only listened to our audio customers, we never would have done video, for example.

I acknowledge that it appeals to a certain sense of organization.  Personally, I prefer things a little more chaotic.

Here's a challenge.  Name a couple of requests that we missed because we didn't have a dedicated request line.

[BryanC]

They aren't easy to find because they exist all over the forum with inconsistent formatting. Some boards have multiple Feature Requests threads, some FRs have dedicated threads, others are located in unrelated topics or subforums. Sometimes the discussion is broken out into new topics from a larger FR thread, sometimes there is no JRiver response (fine), sometimes your response is buried later in the topic. If there was a dedicated forum it would be easier to find and track feature requests and they wouldn't just disappear when the board is retired since FR's usually aren't tied to versioning.

I like how Discourse-based forums suggest related topics prior to posting in order to nudge users away from posting repetitive topics. It forces good forum habits on the users instead of expecting them to do it on their own. While a separate forum isn't that, it does substantially narrow the search space so users can find (and avoid duplicating) existing feature requests if they follow good habits.

If you prefer a more informal approach that's understandable, it's probably not good business to have an entire board of telling the customer off, but it would streamline things.

[HPBEME]

A dedicated request board makes complete sense to me as well, and BryanC has nailed the supporting rationale perfectly. A "request graveyard"... brilliant. Perhaps even have dedicated request boards for Audio, Images, and Video to match MC's primary functions. For those interested in audio only, they won't have to sort through mixed in video enhancements requests, and vice versa for videophiles.

How would JRiver benefit?  ... A good request, well presented, is often implemented within days.

- JRiver benefits by allowing users to see all requests in one place, which over time will reduce redundant requests, which in turn will reduce your need to repeat the same answers over and over across multiple boards
- Having a dedicated board does not prevent "A good request well presented", and this is where BryanC's "request graveyard" is key: by maintaining/showing only requests that are viable and still under consideration active. 
- There could be multiple graveyards (as linked sub-threads?) where various DOA request types are moved: redundant; impossible/rejected; MC already does it; etc. Users could and would look at those posts if clearly organized
- I think most forum users would find an organized request system preferable to the current random request approach - and that, almost by definition, makes it beneficial to JRiver

That said…

Personally, I prefer things a little more chaotic.

If that is the case, there is no remedy. You must be very happy with a certain president twitler then!

[Peter M]

I've respectfully requested an improvement to chapter navigation in Theater View for video files with each new MC version.

The last couple of times I've not received an acknowledgment of the issue, let alone any indication that an improvement may be in the works.

[BryanC]

I was serious about a Jim LLM, OK maybe a zybex or marko LLM would be a better choice .

Create a new unified views designer (for Standard/Theater/DLNA/Remotes/others I'm overlooking) that incorporates an AI model to translate plaintext -> JRIver Expression Language for creating views/smartlists/wizard searches/fields, etc. If satisfied with current state of disparate view design, could also be a completely separate Expression Designer tool.

Create a different chat model that's trained on the wiki/Interact and add it to the help menu.

Host your own custom models if you want an excuse to buy new GPUs.

[zybex]

There's not nearly enough data to train an AI model with any decent accuracy. This forum is reaching 1 million posts - most of them are questions, duplicates, opinions, wrong assumptions and deprecated info. Probably far less than 1% contain Expression code, even less contain working Expression code. Any model trained on this data would be useless, not much better than the current Search functionality.

Good AI modeling requires billions of data snippets.

That said, the Search functionality could use an overhaul - most search results are heavily polluted by the "media center x.x.x - available here" announcements which are hard to filter out.

[BryanC]

I'm not suggesting that JRiver create a generative AI, there are many (IMO, more useful) smaller models that can be trained on specific data sets like FAQs/Wikis/Forums (glorified search) or generate code based on language definitions/documentation (glorified lint). These are ubiquitous now.

More generalized models already do a good job writing JRiver expressions, presumably mostly based on the wiki documentation.

[JustinChase]

Here's a challenge.  Name a couple of requests that we missed because we didn't have a dedicated request line.

here's one I have requested a few times, but have never seen JRiver acknowledge.  It's never been addressed, or implemented.

I haven't brought it up for years, since it's been ignored several times, so I assumed JRiver just doesn't want to implement, but it would be nice to see it addressed one way or another (and hopefully implemented)

https://yabb.jriver.com/interact/index.php/topic,135621.msg939768.html#msg939768

[JimH]

I use a detached display often while working to watch videos, and I'm constantly having to manually adjust the display window size to match the video playing aspect ratio, which just gets old fast.

I would really love it if MC could behave like youtube and windows media center, and force the display window to match the video aspect ratio automatically.  if a playlist moves to a different video of a different aspect ratio, the window should adapt to keep the video 'full screen inside the detached display' automatically/dynamically.

Or, if I grab any side of the detached display to resize it, the window should adjust both horizontal and vertical sizes to keep the video 'full screen'.

Could you start a thread and describe your setup in more detail?  Are you using JRVR? 

[JustinChase]

Could you start a thread and describe your setup in more detail?  Are you using JRVR?

Of course, here it is...

https://yabb.jriver.com/interact/index.php/topic,141282.0.html

[JustinChase]

Hi Jim.

I did start the new thread as you requested, but there has been no response to it so far.

https://yabb.jriver.com/interact/index.php/topic,141282.0.html

As you can see in that thread, I've done this many times over the years, and each time I've received no response from JRiver about whether this will even be considered.

I'd given up on this request several version ago, due to the lack of response, but when you asked me to post once more, I was happy to do so.  I spent a considerable amount of time looking over my history and posting all the times I'd made this request, each time with what I thought was plenty of detail and context.

Could you please be so kind as to just respond and let me know if this will ever be considered, and if not, maybe why not, so I know whether I should ever bother mentioning it again.

Thanks in advance.

[Manni]

I +1 TheShoe's suggestion of a more structured way to organise feature requests

For me, one of the most interesting ways to do achieve this (compared to having hunders of thread in the forum) is when the way it's done allows for users to look at existing feature requests and upvote (or downvote) them.

This allows users to see if a similar request has already been made, comment on an existing request and vote for it, create one if no similar request exists, and also see if anyone else is interested in it.

If your request gets traction, it makes it more likely to get implemented (if it's feasible), but if you hear crickets, it might make it easier to understand/accept why it's not worth the devleoppers' time.

This also allows devs to see which requests are the most popular, and possibly prioritize them.

Finally, marking a request as "under consideration", "in progress" and "done" allows users to see how the feature implementation progresses (when it's picked up for consideration). This allows to see a kind of roadmap of what's being developped.

It's also reassuring to see that a request is being "considered". Even if it's never implemented, at least it's on the list, so we know it's not been forgotten in a forum thread that sinks at the bottom of the list if no one bumps it up.

I attach a screenshot showing how this can work, from a team that develops a Wordpress plugin (FluentBoards) that allows to do exactly this (no affiliation, just really good Wordpress plugins, including this one).

I fully understand that this might be too structured for some, or might mean too much extra work to manage for the JRiver team, but with a plugin similar to the one I suggested I don't think the overhead would be huge.

A similar system can also be used for bug reports.

Anyway, that approach has always been my preference because it's organised, interactive and informative, and many software development teams decide to go that way. It doesn't mean you have to

[JimH]

Finally, marking a request as "under consideration", "in progress" and "done" allows users to see how the feature implementation progresses (when it's picked up for consideration). This allows to see a kind of roadmap of what's being developed.

It's also reassuring to see that a request is being "considered". Even if it's never implemented, at least it's on the list, so we know it's not been forgotten in a forum thread that sinks at the bottom of the list if no one bumps it up.

We could probably get AI to mark your requests "under consideration". 

Realistically, we don't have time to add and tend another system.

And, though we heavily rely on user feedback, we're not limited to what users want.

And then there's the "minority rights" issue.  Windows users heavily outnumber Mac and Linux.  Voting alone wouldn't work.

So ... no, we aren't going there.

[Manni]

We could probably get AI to mark your requests "under consideration". 

Realistically, we don't have time to add and tend another system.

And, though we heavily rely on user feedback, we're not limited to what users want.

And then there's the "minority rights" issue.  Windows users heavily outnumber Mac and Linux.  Voting alone wouldn't work.

So ... no, we aren't going there.

I was expecting that reply