Print

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

[flac.rules]

My two cents:

I'd like to see JRiver continue to add features/customization around the display of metadata in Theater View - for example, the artist images idea in 16 should be expanded to general "fanart".  It's the only way they can continue to be compelling on a TV in the living room.  In this sense, I agree with some of the posts here.  Some of the mockups look great.

But there are plenty of third-party solutions already for bringing outside metadata in.  We already have "plugins."

Don't forget, full "sidecar" support exists, and how many tools/systems can build an XML file?  I wrote a CL tool in two hours the other day to convert some XBMC XML files in to JRiver format.  Then I hit one "Update Library from Tags" - all done.  Maybe with enough encouragement, I can build that tool out more significantly.  

Joking aside, development time costs money.  Don't spend it on scraping websites/APIs, because you'll just have to fix it everytime something changes.  Theater View is entirely under the control of MC, so innovate there - on the TV.

*steps off soapbox*

That might be a good solution, a third-party "info-scraper" that writes a file which is compatible with the sidecar-feature in MC. However, as you say, we still "need" a Theatre-view update IMHO.

[sunfire7]

We need to explore every option, and if none of them is legal wise, a sidecar file or 3rd party plugin can be the solution, and as Daydream and Elvis133 said, Theatre View needs to be more customizable to attract more skin makers and bring more creativity to Theatre View

[rick.ca]

This discussion has illustrated some very real dilemmas facing JRiver. First, despite self-imposed user befuddlement concerning the issue, they can't just steal data belonging to others for the benefit of their paying customers. They would be ordered to stop, and would lose any lawsuit. I've suggested a solution of providing a scripting engine that would allow users to do as they please with whatever sources are available to them. (I'm not at risk for scraping a publicly available site for my own use.) I don't believe Jim or his attorneys have commented on previous discussions of that idea, so I'm not sure if it would effectively address their concerns. But it seems the real dilemma is with users, not the legal situation. From comments here, it seems the expectation meta data should just magically appear without any user effort (even to choose preferences of data source, content and method of display) is so powerful and entrenched, a scripting engine may not be well received. It's the sort of thing that requires a certain amount of user momentum, so it may very well flop.

There is the option of using the API's of TheMovieDb and theTVDb. This, I believe, would at least put MC on the same playing field as some of its competitors. As good as these sources are for providing basic information and art for popular movies and series, they're lacking depth and coverage. They're not going to do it for serious collectors or those with any significant interest in media produced outside of the US. So would implementing these be "good enough," or would it just lead to a flood of complaints that it's not?

The "scripting engine" I had in mind would necessarily include all the "management functions" involved in the whole process of finding, downloading and adding meta data to the library—a configuration system (sources to use, data required, when and how to update, fields to use, etc.), a monitoring system that would effect the automatic update of files, and a system to supervise/run the actual updates. If such a thing were created, it could be "seeded" with TheMovieDb and theTVDb. A scraping script would be quite different than those, but perhaps could be demonstrated with a legally "safe" source like Wikipedia (assuming JRiver could get permission to do so). Theoretically, such a system would allow users to create scripts capable of getting data from any source, for any media type (e.g., as I've illustrated in getting Allmovie data for my music albums). This (again, theoretically) would remove JRiver's legal exposure and the burden of maintaining scripts (which have to be regularly updated to deal with changes in the design of the source website).

Another (completely separate) dilemma is the apparent user perception that Theatre View just won't display information in the database in the manner required. I'm not (yet) referring to the admittedly limited graphical aspects, but the data itself. It seems many are reluctant to configure it, and don't look past the stock views provided. The fact of the matter is an extraordinary effort (including much heated consultation with users) when into its development. The result is an elegantly powerful system that can be configured to display just about anything. This aspect of it is completely unrivalled by the competition. The dilemma arises because with this power and flexibility comes the barrier of being perceived as being difficult to use. I don't believe it's particularly difficult to use, or there are any glaring deficiencies in the design of the configuration system. The difficulty is an inherent one. If I can display any information for any media in any manner I please, I have to have some clear vision of what I want and a willingness to configure it. I don't find it "easy." I have to compensate for a lack of aptitude for such things (or uncertainty about what I want) with a willingness to build views by trial and error. It's sometimes frustrating, but I always appreciate the result.

And I recognize much of the criticism is unfair. For example, there's the often repeated idea the program will not handle series. It's difficult to be sure what is meant by this, but I'm usually left with the impression the person has not tried, and is not currently using MC to manage series. It's true there are ways series could be handled by default, and JRiver's commitment to do so is overdue. But the idea the program will not handle series is simply false. Using the tools provided, it's not difficult to configure views of series by title, season and episode—viewed or not viewed, etc. There's nothing wrong with wanting something different or preferring XBMC, but suggesting the program can't handle series is just wrong. Not only does it handle series, the fact it handles it using exactly the same framework that handles all types of media makes it easier to configure, understand and use. Perhaps the developers have been slow to "fix" the handling of series because they realize doing so might actually make things more difficult.

I also consider the frequent wholesale comparisons to competitors like XBMC and Media Portal to be a significant dilemma. Those who claim these programs are superior in some significant aspect seem to believe it, and must convince others this is so. I've tried most of the competitors in the past, and these two recently. I might need to give them more time, but I just don't see the validity of any of the claims being made. I've tried finding the right plugins, skins and options that would illustrate anything they do better than MC—and have failed. I think we all agree, none of them come close in terms of database functions, speed, advanced features, etc. They're all slow and clunky by comparison. Although skins can be changed, they seem to rely on the same rigid model for displaying different views. I suppose this is good if you can't be bothered configuring your own views, but completely unacceptable if you need anything more. Since MC's ability to handle data is essentially unlimited in comparison, it follows most MC users require more.

Theatre View is not very graphical, so I've always assumed there must be something to be learned from the competition on that count, and this might be the primary motivation for others making comparisons. Having had another look, I now wonder if even that is true. I have yet to find anything compelling, that would work consistently for everything in my collection, and does not impose some unacceptable limitation in how the data is displayed and interacted with. It seems I'm largely at the mercy of a skin designer who is unlikely to appreciate the nature of my data or how I want to use it. Just one example: A four-line scrolling text box designed for viewing a one-paragraph synopsis or review is completely useless for the 500 to 1,000-word reviews I prefer. MC has an elegant way of dealing with this—the same mechanism works well no matter how long the text is.

I hope we'll see improvements in the graphical presentation of art and data in Theatre View. I don't have the creative or technical background to understand exactly how this might be done. I do know it has to be done in a way that preserves the vastly superior data handling and configuration aspects of the current Theatre View. I'm still willing to look for good ideas in other programs that might be feasible to implement or adapt to MC. I'm not at all in favour of changing Theatre View to mimic an inferior program.

[flac.rules]

Your viewpoints on the legal issue seems to be very strong in a case that probably ha no clear legal answer. I don't think the legal issue is a clear cut as you put it. But whether they are realistic or not, the authors have legal concerns, that is what matters, and we must take those concerns into consideration when suggesting a solution.

Regarding limitations with showing information in other skins, Theater view is also just a skin. Why are we assuming that other skins are automatically bad at showing information? Nobody is suggesting making an exact copy of skins, they are just examples of what kind of visual appeal you can get with other solutions. Neither do we have to change the theatre view of today. Keep it in as it is, there is no problem with having several visual looks. (in facts its already implemented in the the other views)

As for me, I don't have that much against doing some configuring, I can do that to get powerful features. Why do people have the perception that things are not possible? could it be a documentation problem? Where do you find the information about setting up stuff in a similar way you have done? I couldn't find any guide in the wiki or any other easy to find source. Could be that people just don't know due to it beeing a bit difficult to get info?

[Daydream]

One problem we have with Theater View is that it must be useable with a mouse, a keyboard, a touchscreen, or a remote, so navigation was extremely difficult to get right, and I'm sure some people feel it still isn't right.

Which proves the limitation of having just one thing to do everything. Of course it's difficult to have one interface/skin to do it all. When a series of skins may catered specifically to certain needs. You would be hard pressed to keep all possible inputs on one skin, especially with touchscreens gaining ground.

Another problem we have is that we can't abandon an interface that is used by tens of thousands of people.  We can't even change it very much.

Aaah, see, we're getting close to the core of the problem. I have a few thoughts on this:
- if presented with a better, more varied alternative what do you think these people will do?
- can we please not cater to the lowest common denominator, something that will work for everybody, cause from my experience that will actually work for nobody in the end. Choices are what matters.
- We probably won't have to cut the cord and alienate people. The current version of Theater View with its engine version (2.x) will be kept in. Whoever likes it, keep on enjoying it. You already had a jump when Theater View, in its current look and feel, was developed as a proper 10-foot interface, from the old, first version type of skins. Why not make another jump? I do not expect this to happen overnight, or in a week, or in month.

DLNA and Theater View are completely different subjects.  Both are important to us.

You pushed DLNA on the last leg of MC 14, in MC 15, in MC16. I understand the business reason and the technical reason (for once in our lifetime we had the major players in the tech/entertainment industry agree to one protocol; I'll drink to that). But I have to wonder by now, how many other things, including what we discuss here, were left on the side, priority 2 or 22, because development resources and time and money are not unlimited.

The biggest problems in satisfying your needs are the legal questions.  I like my life as it is.

You will not hear about that from me. I understand the issue. As far as I'm concerned there are 2 different aspects here:

1) how we display metadata already allowed/had (text, texlists, etc) and other associated resources - graphics generically, from covers, to fanart, to symbols. This is skinning.
2) how do we get what we don't have of either metadata and/or associated resources. JRiver can drive this boat, and besides the current plugin framework may allow say, Python scripting which may be more appropriate for scrapping anything from anywhere. Would that still be a problem for the company? (as I was writing this rick made his own post above, and he addressed the issue/question with some more refinement)

[Daydream]

Rick, I've read your post above and I like it how it is, I'm not gonna slash it with quotes and answers.

We might be heading to a full-on (polite) collision on the principles here. You guys that are very close to MC (beta team or otherwise just really proficient in using MC) you believe you've found the way - the main strategy, not all the minutiae details subject to improvement. You have a long connection with the "method", you've used it for years, and that amounts to a lot of experience and a track record proving that it does what it's supposed to be doing. From that view point a lot of outside critique is just people that haven't tried hard enough, and they should try harder, because try hard enough is not a thing MC has monopoly on it, it's true for every program, so they should give MC a fair chance and actually learn its ways.

The usual outside users they are an unknown quantity, they may come in and ask for features at random just because they've seen 'em somewhere. They will not be prepared to face the answer of an MC wizard, they will most surely be defeated on points because they were not prepared to argue well enough. That does not make them automatically wrong, just as you guys (MC side) are not automatically right.

Then there's the few of us, that actually know both ways. I do not feel anything special, I feel I am in a special position. Let me tell you this: we DISAGREE on the fine points you made, we DISAGREE on principles, we DISAGREE on the very core strategy that was chosen for this interface. We don't blindly disagree, but we disagree nonetheless, and as it a disagreement on principles (and only second on means to reach a final outcome), it's very difficult to nudge somebody in a different direction.

So we asked for the best possible compromise: can we have our way, too? Keep yours if you like, just give us other options. But this is not a perfect world with unlimited resources. So I guess every side will push for what they believe in.

[rick.ca]

We don't blindly disagree, but we disagree nonetheless, and as it a disagreement on principles (and only second on means to reach a final outcome), it's very difficult to nudge somebody in a different direction.

You don't seriously believe I'm going to agree on how we disagree.

The problem with this discussion is it ends up in exactly the same place all similar discussions before it have ended up—nowhere. The OP correctly pointed out two fundamental deficiencies with the program. He and others then vehemently disagreed with any attempt to support the idea these deficiencies should be remedied, or move the discussion closer to what might be viable solutions. "Why can't it just do what XBMC does?" "I don't understand why violating copyright matters." "That's easy for you to say—you know how the program works." Excuse me for being "condescending," but it's all so draining. And it has no chance of influencing the development of the program in any positive direction.

I wasn't just making an argument when I said Theatre View "is an elegantly powerful system that can be configured to display just about anything." The aspects that make it so are brilliant and inspired. For me, this is the sort of thing that makes MC a joy to use and sets it apart from any competition. Yet most of the feedback about Theatre View seems to be negative—apparently because, contrary to what the same people would say in a different context, "just working without any user effort" is valued more than power, flexibility and the quality of meta data used. I'm not saying this preference is "wrong." I'm not sure what the answer is, or it there is one. I do often wonder how the developers do not find this very disheartening.

But I digress. This is the point I wanted to comment on...

So we asked for the best possible compromise: can we have our way, too?

I don't know. Despite the fact you've had lots to say about your vision or core strategy or whatever it is, I've always found it somewhat abstract and beyond my technical understanding. So it may not be fair, but just don't have the ability to understand how some of the things you advocate might ultimately benefit me. There seems to be plenty of evidence it won't. From other programs that support skinning, one thing is clear: I won't be authoring skins. When I look through the many skins that have been produced for some of these programs, I don't find anything that appeals to me. Maybe I would be able to modify some according to my needs, but I'm skeptical. It doesn't seem to be a practical solution for those who just want something that just works "out of the box." Someone who can't be bothered configuring Theatre View to their needs certainly won't want to customize a skin. I have no objection to skinning being better supported, but I'm under the impression this would require significant effort and resources to implement.

I'm unsure, but I doubt that offering a completely separate way is a practical solution. The fact you would suggest it's "the best possible compromise" makes me wonder if there is any reasonable prospect for combining the best aspects of the existing system with those of whatever it is you're envisioning. I can adapt to alternatives that look different, but I can't imagine giving up the existing functionality of a flexible navigation system, information panels that adapt to media types and the various behaviours that allow a view to adapt to the data available for display (e.g., expanding fields). Is there really no prospect for providing a more graphical experience within the current system?

[Daydream]

And it has no chance of influencing the development of the program in any positive direction.

Sometime I wonder what will, if there is any argument/voice or reason/something that can make a difference after all this time.

I wasn't just making an argument when I said Theatre View "is an elegantly powerful system that can be configured to display just about anything." The aspects that make it so are brilliant and inspired. For me, this is the sort of thing that makes MC a joy to use and sets it apart from any competition.

It is elegantly powerful within its own logic, within the borders of its own rules and paradigms. That both you and me have to obey. You happily, me grudgingly.

Yet most of the feedback about Theatre View seems to be negative—apparently because, contrary to what the same people would say in a different context, "just working without any user effort" is valued more than power, flexibility and the quality of meta data used. I'm not saying this preference is "wrong." I'm not sure what the answer is, or it there is one. I do often wonder how the developers do not find this very disheartening.

Very good point there. It also might be kind of confusing to have so many users (probably mostly silent, therefore content) with Theater View as it is, plus the people openly supporting it, and on the other hand other people that vehemently ask - for years - not for something that can be fixed with patches from version .100 to .110, but with something radical. It may just be the point where the famous good choices of JRiver didn't pay up. Instead of a homerun, it's a great divide.

But I digress. This is the point I wanted to comment on...

I don't know. Despite the fact you've had lots to say about your vision or core strategy or whatever it is, I've always found it somewhat abstract and beyond my technical understanding. So it may not be fair, but just don't have the ability to understand how some of the things you advocate might ultimately benefit me. There seems to be plenty of evidence it won't. From other programs that support skinning, one thing is clear: I won't be authoring skins. When I look through the many skins that have been produced for some of these programs, I don't find anything that appeals to me. Maybe I would be able to modify some according to my needs, but I'm skeptical.

Maybe you will author skins, maybe you won't. I'll take that ambiguity any day over the currents status: nobody can.
You say it's too abstract... Jim asks what do I want... what can I do? Design an entire skin engine on paper, with all the outside xml configurations, for all it's possible items, and present it "here, fire up your IDE can this be coded in"? It is a dilemma. There may also be some other considerations: in XBMC its skins are the program, in a visual way. Sure there's a lot of work and code running in the background but that bares little for the user. In XBMC if you don't have a skin you have nothing; the thing doesn't run in command line (well it has parameters but I'm making a point) or in any other kind of abstraction. It needs a skin on top.

Switch to JRiver. Weeeeell, take away the skin. We still have plenty of opportunities to fiddle with the database fields, to re-arrange, to create new ones, to put 5 rows long expressions in them, to think stuff up, and when we're done with that there's another possessed user (named so in the most loving way ) that comes with a new expression to separate media by some even more ubiquitous criteria. In my mind that is a big difference: XBMC encourages you to watch your media in the most pleasant way. MC encourages you to manage your media, not to watch it. The average user will like to watch/listen, not to manage. (at this point if it doesn't become obvious that I'm trying to subliminally speak to JRiver, I don't know what will )

You can value the fields configuration in the rollers to a supreme daze spell, it will be forgotten in a blink of an eye if the ep. I'm watching has cover on right, clearart on left and a nice scroll bar for navigation that informs me between other things, at what time the ep. will end. Meaning this: (it even shows my MKV chapters, what do you know)



Did you just hear that "Oooh-aaaah... hehe" of everybody that laid eyes on this small screencap? What you do is pure math. This, this is magic .

It doesn't seem to be a practical solution for those who just want something that just works "out of the box." Someone who can't be bothered configuring Theatre View to their needs certainly won't want to customize a skin. I have no objection to skinning being better supported, but I'm under the impression this would require significant effort and resources to implement.

In the interest of being honest: there won't be a lot of people to design skins (then again I'll take some over none). But they will make enough skins to have alternatives to pick from. And should you want something tweaked that would just asking about it. It's no different than what has happened with the development of the plugins over here, it's just it'll be that much more transparent since one doesn't need to know programming.

Do you know how many people are publicly involved in XBMC skinning? My guess somewhere around 20. Really good? 5 to 10. Coding for their own needs at home and not publishing - tens. All the rest the massive amount they don't know how to create a skin, and chances are they will never know because it's got really complex. They still love it thou with such fervor, that you hear about it here, while the other way around is not true. What drives these people? My take - they like to watch (I could go on and on that the brain like colors and stuff like that). The beautifully intertwined database fields of MC stand no chance to the reality of a beautiful graphical experience.

I'm unsure, but I doubt that offering a completely separate way is a practical solution. The fact you would suggest it's "the best possible compromise" makes me wonder if there is any reasonable prospect for combining the best aspects of the existing system with those of whatever it is you're envisioning. I can adapt to alternatives that look different, but I can't imagine giving up the existing functionality of a flexible navigation system, information panels that adapt to media types and the various behaviours that allow a view to adapt to the data available for display (e.g., expanding fields). Is there really no prospect for providing a more graphical experience within the current system?

It may come as a surprise but I don't want MC to become XBMC. I want it to be better than XBMC. I want to have XBMC-like feature while maintaining MC's strengths. I want to be able to have a toggle button in my skin's options to trigger 1) scroll within predefined borders 2) extend down max vertical size with ease-in & ease-out speed + trigger animation for the element that was under it, that gets moved if necessary. I get the in-place scrolling because I believe it's the better interface on the principle an event takes place in a predefined placeholder instead of half the screen moving like crazy giving me ADD (see how our interface perceptions differs?) and you get your expandable field if that is the best way for you. I wanna have a way to write both things in.

Providing a more graphical experience for what I'm talking about...? I feel your pain but it would be just as much pain to discuss design in words. I need a tablet and a couple of other things. The tech talk on the previous page is real though, about control over placeholders, conditional visibility, controlled transitions, Windows IDs - that is real and it will probably mean (for the non-programmer in me) taken those items from their hard-coded states as they are, and allowing for outside manipulation (via XML). That may take a a lot more work on the skin code than it is now (as somebody earlier said, coding interfaces is not easy).

[flac.rules]

You don't seriously believe I'm going to agree on how we disagree.

The problem with this discussion is it ends up in exactly the same place all similar discussions before it have ended up—nowhere. The OP correctly pointed out two fundamental deficiencies with the program. He and others then vehemently disagreed with any attempt to support the idea these deficiencies should be remedied, or move the discussion closer to what might be viable solutions. "Why can't it just do what XBMC does?" "I don't understand why violating copyright matters." "That's easy for you to say—you know how the program works." Excuse me for being "condescending," but it's all so draining. And it has no chance of influencing the development of the program in any positive direction.

I wasn't just making an argument when I said Theatre View "is an elegantly powerful system that can be configured to display just about anything." The aspects that make it so are brilliant and inspired. For me, this is the sort of thing that makes MC a joy to use and sets it apart from any competition. Yet most of the feedback about Theatre View seems to be negative—apparently because, contrary to what the same people would say in a different context, "just working without any user effort" is valued more than power, flexibility and the quality of meta data used. I'm not saying this preference is "wrong." I'm not sure what the answer is, or it there is one. I do often wonder how the developers do not find this very disheartening.

But I digress. This is the point I wanted to comment on...

I don't know. Despite the fact you've had lots to say about your vision or core strategy or whatever it is, I've always found it somewhat abstract and beyond my technical understanding. So it may not be fair, but just don't have the ability to understand how some of the things you advocate might ultimately benefit me. There seems to be plenty of evidence it won't. From other programs that support skinning, one thing is clear: I won't be authoring skins. When I look through the many skins that have been produced for some of these programs, I don't find anything that appeals to me. Maybe I would be able to modify some according to my needs, but I'm skeptical. It doesn't seem to be a practical solution for those who just want something that just works "out of the box." Someone who can't be bothered configuring Theatre View to their needs certainly won't want to customize a skin. I have no objection to skinning being better supported, but I'm under the impression this would require significant effort and resources to implement.

I'm unsure, but I doubt that offering a completely separate way is a practical solution. The fact you would suggest it's "the best possible compromise" makes me wonder if there is any reasonable prospect for combining the best aspects of the existing system with those of whatever it is you're envisioning. I can adapt to alternatives that look different, but I can't imagine giving up the existing functionality of a flexible navigation system, information panels that adapt to media types and the various behaviours that allow a view to adapt to the data available for display (e.g., expanding fields). Is there really no prospect for providing a more graphical experience within the current system?

Thats a strange way to view things. Everybody does not have to be in agreement for a discussion to bear fruits and give useful information. There has been a lot of constructive suggestions in this discussion. Whay do you focus only on the negative aspects of the discussion?

I also get that a "nicer look" might not benifit you, that seems pretty clear from your earlier posts. However to me it also seems pretty clear that this is something many people want. Almost none of the features in the program is useful for everyone who owns the program, doesn't mean they shouldn't be there. But this does seem to be something that would be useful for many, and the ability to configure is a sentral strength with MC. As said earlier, i don't have anything against thinkering a bit with configuring personally (I even tried the configuration hell that is meedios), but i don't think the divide between good looks, a easy way to set up a "basic info-gathering" and configurability is as big as you seem to implicate. The program on many fronts already pretty sucsessfully combines "easy defaults" with "advanced configurabilty" (although not on all fronts)

I am not quite sure about what you mean about "the current system" when you want a more graphical experience within that. I see the problem as two-fold, 1. Getting information from the internet is troublesome. 2. The theatre view lacks visual flare. The latter i feel like can easily be fixed and still keep "the current sytem", the former depends a bit, i think that can be handled without loosing the flexibilty you value, but some small changes probably has to be made to make ability to use 3rd-part scrapers easy(?)

[rick.ca]

Thats a strange way to view things.

Two things. First, if you want to make the point my posts are too long, just say so. Quoting the entire thing is unnecessary and annoying. Second, if you going to respond to my post, please do everyone the courtesy of reading it first. Had you done so, you would have seen it was in response to Daydream's suggestion there is no common ground between his perception of my preferences and his idea of how things should be (I still have no idea what he's talking about, or what hallucinogen might help me with that). Because I have no idea what he's talking about, I have to concede he might be right. But I'm certainly not agreeing with him, and I hope he's wrong.

As I said, I don't have the creative or technical expertise to suggest exactly how it might be done, but I believe there must be plenty of room to improve the graphical aspect of Theatre View without radically changing how it works. I'm sure Daydream would have no difficulty making some suggestions along those lines. I had a faint hope I might pry a suggestion or two out of him, but I suppose that would be contrary to his mysterious agenda.

Furthermore, my post was only about how information is presented in Theatre View, and had nothing to do with the issue of obtaining meta data. Had you read my previous posts, you know I've suggested some feasible solutions to the need. Did you miss that, do you believe it was just another case of me focusing on the negative?

[flac.rules]

Two things. First, if you want to make the point my posts are too long, just say so. Quoting the entire thing is unnecessary and annoying. Second, if you going to respond to my post, please do everyone the courtesy of reading it first. Had you done so, you would have seen it was in response to Daydream's suggestion there is no common ground between his perception of my preferences and his idea of how things should be (I still have no idea what he's talking about, or what hallucinogen might help me with that). Because I have no idea what he's talking about, I have to concede he might be right. But I'm certainly not agreeing with him, and I hope he's wrong.

As I said, I don't have the creative or technical expertise to suggest exactly how it might be done, but I believe there must be plenty of room to improve the graphical aspect of Theatre View without radically changing how it works. I'm sure Daydream would have no difficulty making some suggestions along those lines. I had a faint hope I might pry a suggestion or two out of him, but I suppose that would be contrary to his mysterious agenda.

Furthermore, my post was only about how information is presented in Theatre View, and had nothing to do with the issue of obtaining meta data. Had you read my previous posts, you know I've suggested some feasible solutions to the need. Did you miss that, do you believe it was just another case of me focusing on the negative?

I read your post, it says "The problem with this discussion is it ends up in exactly the same place all similar discussions before it have ended up—nowhere. The OP correctly pointed out two fundamental deficiencies with the program. He and others then vehemently disagreed with any attempt to support the idea these deficiencies should be remedied, or move the discussion closer to what might be viable solutions".

I frankly can't see that it's a very strange thing to assume this quote from you is about the entire discussion. If it only was about the disagreement between you and daydream, fair enough, you can disregard that part of my post. But if so I feel the writing is a big of a problem as the reading when it comes to that misunderstanding.

My last pragraph was because it wasn't entirely clear for me how much change you would say was needed before it's not "the current system", what are the core functions you want to kepp for it to be similar to the current system? I would assume a navigation similar to todays theatrevew, and similar information-showing capabilities. If so so I would answer yes to your question, but if ther factors need to be similar too, the answer might be difference. (of course I get that this isn't completly excact, but just to get a rough idea of what "the current system"-concept consits of).

I know you have come with good suggestions earlier in this discussion, but i missed the part where I have claimed otherwise?

[MrHaugen]

Personally I don't see the biggest need for such viewing of Album and artist Meta data for music. I would certainly use it if meta data was easy to get, and the viewing was better though! A thing I DO burn for is series and movies and the displaying of those meta data. And there is similarities here. There needs to bee some more options to view this data as we want. You could tweak the Info panes (adding new view, not redoing old one), positioning of the info page, and the size of it, and Theater View would be a great tool both for Music, videos and images meta data viewing. An even easier solution for Audio only might be to use display view for something like that scrolling review/bios window Mark pointed out in XBMC video.

Rick pointed out the legal issues of getting the Meta Data, and the fact that a plug-in might be a better option. If there is no sources like TheMovieDb or theTVDb that J River can work with, then such an option IS better. Why not investigate if such sources is available first, before it is dismissed? Most people don't love plug-ins. They like things that is built in and maintained by the developers. It's that simple. A plug-in however might be a faster solution though.

Jim points out that the problem viewing this meta data is often that it have to work with all devices like mice, keyboard, remotes and touch. It might not be so simple to just add this and that to the user interface, and I understand that. Elvis touches a partial solution to this problem though. Why do we need one interface to accommodate all of this? Would it not be possible to have a couple of interfaces? One for Remotes/keyboard and one for Touch/mice perhaps? It would solve several problems I think. Of-course, there would be more things to maintain and to develop, but lets face it. Touch is far from compatible with the other control methods, and need some specific UI designs.

[drmimosa]

Interesting thread.

I have a suggestion for displaying additional "Metadata" in Theater View: could the "Links" function, accessible by a right click on an album or track in the regular view, be adapted for use in Theater View?

If "Links" were included in as an option in the "Playing Now" top row, in addition to "Info" and "List", you could potentially use Theater View to search for artist biographies from Wikipedia, view additional live tracks on Youtube, perhaps link to Last.fm biographies.

Navigation could be simple, using the remote or the back-forward-up-down gizmo interface.

I have no legal knowledge regarding metadata rights, but it seems to me that this type of browser link is already present in the software package and therefore would not run into additional legal problems of scripting and storing metadata. The metadata viewed would be a "link" and J River Theater View would just be a fancy "browser."

Currently you can hop over to Youtube on Connected Media and manually enter a search, but streamlining this by making Links directly from Playing Now would make the Theater View interface very powerful!

[Scolex]

Maybe I am part of a small percentage but my preference is an MC app that gives you all of the data management and media handling in the base program.
Things like skinning, meta data, data sources, etc be done at the plugin level whether that be through dll, css, html, jscript, perl, lua, whatever.
I feel that this benefits both the app developer and the user community. The app developer is benefited because they no longer have to be concerned with
copy write infringement and it frees up resources to put toward base program stability and audio/video quality.
The user community is benefited because a lack of base none essential features promotes community based development.
Obviously this type of setup works best with an open source plugin structure and a source repository to reduce the complexity and makes it easier on new developers
because they can look at how a plugin accomplished a task and learn by example. One more benefit is, if you are having trouble you can more easily disable
items as part of a troubleshooting process.
My ideal MC would be J.RMC only have 100% of the UI content be controlled from html, xml, css, jscript, etc so I could place any item I wish anywhere I wish.
All connected media would also be handled in the same manner. There are some pretty straight forward methods to retrieve only the data you wish from virtually any webpage.
Granted you do have to put a little work into determining the page tag/class/id structure but hey anything that doesn't require work is rarely going to meet all your wants/needs.

I have been a J.RMC supporter since 12 and doubt that I will ever use anything else unless someone else comes up with an app that matches it in audio/video quality, data
management, and zone capability. However I would really like to see some aspects become less base program defined.

I do have a couple of questions for the developers though.
Why in the world is Showroom not on by default in Theater View?
Why is it obscure as in you have to name an item Showroom to activate it instead of just having a 3D option.

.02 grab some salt.

[olinbg]

Maybe I am part of a small percentage but my preference is an MC app that gives you all of the data management and media handling in the base program.
Things like skinning, meta data, data sources, etc be done at the plugin level whether that be through dll, css, html, jscript, perl, lua, whatever.

This was exactly my sentiments from earlier, and I'll "+1" this approach/post.

[flac.rules]

This was exactly my sentiments from earlier, and I'll "+1" this approach/post.

I have nothing against that approach in principle. But what can be done to facilitate this? There are few skins svalable today (none for Theatre View?), neither datascrapers. What must change to make this approach workable in "the real world". (I am genuinly curiuos here, must a part of the program change for instance?)

[rick.ca]

I have a humble suggestion for displaying additional "Metadata" in Theater View: could the "Links" function, accessible by a right click on an album or track in the regular view, be adapted for use in Theater View?

Regardless of what and how meta data is added to the database, it would be nice if links could be used in Theatre View. They would be useful for the same reason they're useful in Standard View—they provide access to information we have chosen not to include, or are unable to include in our database. There's no legal issue here—website owners want us to visit their sites.

Pulling just one piece of data (e.g., a review) from a page and displaying it alone is possible, and may not involve the same legal risk. But this amounts to piecemeal scraping. I think we might conclude, if we can specific one piece of data we're interested in and are willing to do the necessary work to get it, we may as well scrape the page. I'm assuming, of course, we have some mechanism for doing so (e.g., we have a scripting engine, and a script for the site). That would be far more efficient and less trouble to maintain. As a practical matter, we would—according to our personal preferences—decide whether to scrape the data or use a link to visit the source webpage as needed. In other words, if I had a choice of scraping a review or visiting the review webpage, would I really need the third option of pulling just the review "on demand"? I don't think the benefit of that would outweigh the cost of creating and maintaining the link that would do so.

As you've noted, to be useful for this purpose, it would be necessary to add at least some basic browsing controls to the embedded browser. One of the essential basic controls would be the ability to zoom pages to an appropriate size for a 10' interface. I suppose even that is not going to work in all cases. I wonder if it might be feasible or practical to use the handheld versions of webpages (where available) for this purpose. Or is that already possible—just by using a different URL?

[Scolex]

I have nothing against that approach in principle. But what can be done to facilitate this? There are few skins svalable today (none for Theatre View?), neither datascrapers. What must change to make this approach workable in "the real world". (I am genuinly curiuos here, must a part of the program change for instance?)

We can't do anything to facilitate it unless they move these items outside of the compiled/private sector of the app.
With as easily as skins, scrapers, etc could be created when done in this manner it would not take long at all as long as when the switch were made there was adequate information on the tags to be used.
There would obviously be a private beta period and I am quite sure that by the time the changes went public the beta testers would have plenty of skins, scrapers, enhancement available.
As it is right now enhancements are difficult to make because they require programming knowledge, the skinning information available is incomplete or just simply can't be changed.

IMHO the best skin environment currently in J.RMC is the mini view format because it is the least locked down but I don't put any time into it due to it's non-sizable window nature.
When I say non-sizable window I mean no click and drag a border or max/restore buttons.

[Daydream]

I think we have enough literature in here so far.

Assuming they had the patience to read through all these, can we hear more from JRiver - what may be considered doable, delayed, not doable, what we need to emphasize more at this point to see if it's worth the trouble? I like the debate between us, but it hit me that the original and subsequent requests were made towards JRiver.

1) We discussed scrappers - as in allowing the users to develop scrapping scripts/tools for more metadata. It has to be done in a way that is trouble-free legally, and anybody that knows one thing or two about these things understands that.
2) We discussed skinning as far as a) real requests (more "graphic art") and b) high concepts and principles that are obviously difficult to illustrate without even more discussions.

So Jim and team, any thoughts, what may sit well with your vision, what needs clarification or something else (a poll, drawings, let's have a beer and forget about all this, etc)?

[JimH]

I must say that this thread has had an impact.  I thought it was bound for the trash a few times, but it turned into something remarkable.  I think you, Daydream, deserve a lot of the credit.  And rick.ca added a lot, as well as many others.

So, against my orders, Matt began working on Theater View again.  

I've just moved a couple of threads out from the Beta board:

http://yabb.jriver.com/interact/index.php?topic=63805.0

If it doesn't work out, we're holding you guys responsible.

[JimH]

Another little known feature of Theater View is that backgrounds can show video.

Here's e-mail Matt sent me today when we were working with a customer:

You can download a sample theme with a movie here:
http://files.jriver.com/accessories/theme/Dynamite.zip

Then use this on the ZIP file above:
Options > Theater View > Theme > Install theme from zip file...

Finally, make sure the theme is selected.

I had to restart to get it working.

[kensn]

Talk about scraping for info...

Ok new custom theme made with video for Theater View..  Now to go find this Showroom thing...

Got it..

Ahhh... very nice indeed...

[sunfire7]

Jim and Matt, I can only say, THANK YOU.  Any improvement on Theatre View will be appreciated and would make JRiver Better than already is.

[)p(]

Indeed thanks Jim for listening. I think a lot of people now use a combination of mc and xmbc/mp and like me would love to change back to use mc exclusively. It will be great that we finally will be able to take advantage of all the artwork out there on all menu levels.

[Scolex]

Since you have stated that we have your attention and development on Theater View has resumed would you PLEASE add an alphabet option to Showroom.
I tried using the standard "Grouping" feature but it doesn't do anything.
I swear there are times that I feel like I am going to wear my finger tips off scrolling through files. It is just too awesome looking of an interface to not use
it even with the seemingly endless scrolling of 17xxx files.
Screen burns suck!

[flac.rules]

Yeah, thanks for feedback Jim. Although i don't get it the way i want every single time, the feedback from developers, and them listening too the community is a really nice thing about MC.

[Daydream]

Sorry it took so long to say thanks Jim, I had to scan some terrabytes of media back into MC from XBMC

I hear you about who's responsible; funny that I was thinking exactly about that yesterday in the middle of the wall of text speech.

[)p(]

Another little known feature of Theater View is that backgrounds can show video.

Here's e-mail Matt sent me today when we were working with a customer:I had to restart to get it working.

I use it...what surpised me is that scrolling is smooth even with a 1080p video as the background.

[darichman]

I'll be interested to see what this turns out. Thank you Rick and Daydream for err... fighting the fight? I miss Theatre View and am definitely glad you're giving it another look this version. *Watches intently*

[olinbg]

Glad to see something came from this thread.  It's been a lot of reading 

[MrHaugen]

[a few personal comments removed by JimH]

*On topic again*
I'm glad this discussion did not turn out dead before it gave some ideas to Matt I'm really looking forward to testing it out!