INTERACT FORUM
More => Old Versions => Media Center 16 (Development Ended) => Topic started by: fredphoesh on April 24, 2011, 04:02:49 pm
-
Hello guys,
I have just uploaded a video to youtube demonstrating what I am talking about... please see it here:
http://www.youtube.com/watch?v=5olBkhgziE8 (http://www.youtube.com/watch?v=5olBkhgziE8)
The video is a demonstration made to show the JRiver Media Center developers what I would like their software to include in the current version 16. I bought JRiver 6 or 8 months ago, but switched to XBMC after XBMC developed their fantastic android app, but am now considering moving back... but there are some things XBMC does VERY well in Theatre View.
XBMC offers excellent biography/album review scraping, as well as lyrics and some Fan Art.
JRiver does not have the biography/album review in Theatre View mode, but does a great job scraping google images for fan art, which IMO is better than XBMC's sole reliance on a very spotty database for "fan art".
What I sincerely hope to see soon is JRiver incorporating AllMusic Biographies and Album Reviews into the Theatre View, and perhaps even lyrics too.
Congratulations on your Android app guys, verrrry niiiice!
Please watch the vid, thanks!
Mark.
-
What I sincerely hope to see soon is JRiver incorporating AllMusic Biographies and Album Reviews into the Theatre View, and perhaps even lyrics too.
While some aspects of the XBMC way of displaying information is visually appealing, for the most part, I find it gimmicky and ineffective compared to the how the same thing is done in MC. My Theatre View includes Allmusic biographies, album reviews, lyrics and more—all displayed in a way that's flexible, fast and easy to use. The only shortcoming of MC, as I see it, is the lack of any easy way to acquire the meta data. I doubt anyone would be interested in my solution...I use a modified version of Personal Video Database to download album and artist data from Allmusic (using a modified Allmovie script), and import that using PvdImport.
The problems associated with JRiver providing users access to third party data, and the possible solution of providing a scripting engine were discussed at some length here (http://yabb.jriver.com/interact/index.php?topic=59657.0). I like to think my goofy solution—aside from the fact it works perfectly for me—is a valid "proof of concept." I'm not a programmer, and don't even have much of an aptitude for such things. Nevertheless, with a little effort, I was able to modify a script (written by a programmer) for the Allmovie site to do the same sort of thing for the Allmusic site. Imagine what it would be like if many of us were doing the same sort of thing, and we could share our scripts because they all run on the MC scripting engine. 8)
-
I use a modified version of Personal Video Database to download album and artist data from Allmusic (using a modified Allmovie script), and import that using PvdImport.
Wow, that's really clever - do you import the album tracks into PVD? Did it take much fiddling to get the Allmovie script working with Alllmusic?
-
do you import the album tracks into PVD?
Yes, all tracks for each album are matched to an album record by the file scanner function. That captures the MediaInfo data for the album (# files, total size, duration, codecs, etc.) as well as providing the necessary link for PvdImport. All the data is going to relational album fields, so it's irrelevant the records are albums in PVD and tracks in MC.
Did it take much fiddling to get the Allmovie script working with Alllmusic?
I believe we've touched on this before...My primary programming technique is trial and error. So, yes, it took much "fiddling." There are many things that work, and I have no idea why. ;D
-
I'd love to see more work on MC's Theatre View, for Music is excellent for me (some details have to be added as you mention), but for movies and series is just not good enough compared to XBMC or Media Portal, so my solution is a link on Theatre View to Media Portal. Maybe if J River improves the handle of movies and series, this could change, but now is no competitor to other solutions
-
While some aspects of the XBMC way of displaying information is visually appealing, for the most part, I find it gimmicky and ineffective compared to the how the same thing is done in MC. My Theatre View includes Allmusic biographies, album reviews, lyrics and more—all displayed in a way that's flexible, fast and easy to use. The only shortcoming of MC, as I see it, is the lack of any easy way to acquire the meta data. I doubt anyone would be interested in my solution...I use a modified version of Personal Video Database to download album and artist data from Allmusic (using a modified Allmovie script), and import that using PvdImport.
Hi there Rick and others,
As you say, you had to hack/do special encoding etc to your software in order to get it to do what you would like. XBMC does this with no hacking needed, and that is obviously preferable to the masses who do not want to be needing to do a lot of work to get the bells and whistles ;)
It would really be great if MC would make scripts like yours default so everyone can enjoy them!
Thanks,
Mark.
-
While some aspects of the XBMC way of displaying information is visually appealing, for the most part, I find it gimmicky and ineffective compared to the how the same thing is done in MC. My Theatre View includes Allmusic biographies, album reviews, lyrics and more—all displayed in a way that's flexible, fast and easy to use. The only shortcoming of MC, as I see it, is the lack of any easy way to acquire the meta data. I doubt anyone would be interested in my solution...I use a modified version of Personal Video Database to download album and artist data from Allmusic (using a modified Allmovie script), and import that using PvdImport.
There has been pretty hig demand in the past (at least as far as i can see), about making the theatre view a bit more "flashy", especially when it comes to movies and TV-series. Visually many of the front-ends are ahead of MC, i would really like to see some progress when it comes to this, and also what you mention about accuering metadata.
-
As you say, you had to hack/do special encoding etc to your software in order to get it to do what you would like.
I said nothing of the sort. I used a plugin to import data, just a XBMC does. And I configured Theatre View to display the information I want, exactly the way I want it. I suppose not everyone cares about the power and flexibility of MC, and may be incapable of configuring something according to their needs. They might be better off with XBMC. But it doesn't come close to fulfilling my needs, so I don't see much value in comparisons.
It would really be great if MC would make scripts like yours default so everyone can enjoy them!
My script is native to another proprietary scripting engine. Even if MC included a scripting engine, it wouldn't run my script. The point is, if MC had a scripting engine, users could collaborate in developing and sharing scripts.
I'd love to see more work on MC's Theatre View, for Music is excellent for me (some details have to be added as you mention), but for movies and series is just not good enough compared to XBMC or Media Portal, so my solution is a link on Theatre View to Media Portal. Maybe if J River improves the handle of movies and series, this could change, but now is no competitor to other solutions
I don't understand what you mean. My Theatre View, using exactly the same features, displays even more information for movies and series than it does for music. Whatever it may lack in "flash" (nothing of value, IMO), it more than makes up for in power and flexibility.
-
I said nothing of the sort. I used a plugin to import data, just a XBMC does.
Rick, I think you are taking this a little personally for some reason. This is not a personal attack!
My point is that I would like MC to be able to display all this useful information without one having to jump though hoops and understand all sorts of complicated things to be able to have them displayed.
It would be great if biographies/album reviews/lyrics could all be downloaded automatically and displayed by default in MC.
Cheers,
Mark.
-
It would be great if biographies/album reviews/lyrics could all be downloaded automatically and displayed by default in MC.
So what? For some very good reasons, like...
- JRiver does not own or have the right to distribute any any meta data;
- a wide range of user needs and preferences cannot be satisfied by anything "downloaded automatically and displayed by default;" and
- in most respects, the display model of Theatre View is already vastly superior to that of XBMC and the like.
...this is never going to happen. I thought it might be useful to discuss potential solutions to MC's actual shortcomings. I'm sorry you're not interested.
-
1. Do they have to own rights do download text from the internet? Not in general at the very least. However this can also be solved by having scrapers getting the data as a plugin, but this doesn't exist as of today.
2. Its no worse than having a similar settings as today with for instance cover-art, you can choose to download it if you want.
3. Frankly, its not, look at the evolution theme in meedios for instance, its miles ahead in visual appeal. And similar when it comes to information layout. And this is a serious shortcomming for many, judging from earlier discussions. Im pretty sure this is more or less the only reason people bother with media-center frontends at all when they have MC.
-
So what? For some very good reasons, like...
- JRiver does not own or have the right to distribute any any meta data;
- a wide range of user needs and preferences cannot be satisfied by anything "downloaded automatically and displayed by default;" and
- in most respects, the display model of Theatre View is already vastly superior to that of XBMC and the like.
...this is never going to happen. I thought it might be useful to discuss potential solutions to MC's actual shortcomings. I'm sorry you're not interested.
WOW.
Im not sure, perhaps you had too many cups of coffee today? :)
I started this thread, so it would be useful to converse about the things I was asking about, and I am interested in being able to, by default, get the kind of info XBMC has in it's music playback, by default. Not having these things present by default is, IMO a large shortcoming of MC.
I dont know if XBMC have some special arrangement with Allmusic, I doubt it since their app is free, so I do not think they have had to fork out loads of money for their use of Allmusic's fantastic database... nor the 3 lyrics sites they harness info from.
As I was saying in the first post and in my video, XBMC has everything I want for my listening to music with visual/informational inputs in my lounge, all EXCEPT it does not do a Google Images search like MC does, by default. I have asked XBMC developers to do that, and they said no. I came here to ask if MC could include the fantastic bits I like about XBMC, but I have not heard back from the developers yet.
FWIW, I do not agree MC is superior for Theatre view because as they stand, I choose XBMC.
Still hopeful that for Jim/developers might add the biography/review features...
Mark.
-
...it would be useful to converse about the things I was asking about...
That's what I was attempting to do, but it seems you haven't even read the topic I referred you to. Whether you like it or not, there are constraints to what JRiver can do. It's probably difficult for the developers to choose a path that would be feasible and satisfy all. I like to think user discussions about such things might be of some help and encouragement to them. "I want everything by default" might be an logical starting point, but being stuck there is not helpful.
What is your objection to the solution I suggested?
-
What is your objection to the solution I suggested?
Rick I have no objection to any solution, but have an aversion to working with scripts... just daunting and I am very likely to bugger it up...
If I could copy and paste your whatevers and make it work as easily as that, I would love to try out what you have done, but doing the code myself seems a bit beyond me... that's my only cause to hesitate.
About the default question... MC already has different "views" within Theatre Mode... when you navigate from one view to another, the contents displayed change... so I could see "biograpy view" and "album review view" being very welcome additions to the Theatre View menus.
tx
Mark
-
FWIW Fred, I am in complete agreement with you.
I mentioned this way back in the days of MC13 and got the same hostile response from the "regulars" on here.
You're flogging a dead horse. I came to the conclusion a long time ago that MC is never going to make it easy for you to use the kind of metadata that every other media centre software uses as a matter of course. There may be copyright or contractual reasons why not, but that doesn't seem to impair the other media centres on the market... so who can say. MC16 is a bit better, but still nothing like enough.
It's a real shame, because without that, MC will never be prime time in my living room. I can only use it to tag music these days... which just seems a bit of a waste.
-
I don't understand what you mean. My Theatre View, using exactly the same features, displays even more information for movies and series than it does for music. Whatever it may lack in "flash" (nothing of value, IMO), it more than makes up for in power and flexibility.
rick.ca, I saw your screens and I wonder for your process of obtain metadata for the series, because in other programs, you only have to copy/move to the folder you are "watching" in settings and it will obtain series, season, episode number, sinopsis and backdrop, all this in the background without user interaction, and all shown beautifully on screen, I dont have anything agains the flexibility of MC, I think is a great thing but has yet its limitations. Can't the users (costumers) and devs talk and forge the path of MC's Theatre View?
-
That's what I was attempting to do, but it seems you haven't even read the topic I referred you to. Whether you like it or not, there are constraints to what JRiver can do. It's probably difficult for the developers to choose a path that would be feasible and satisfy all. I like to think user discussions about such things might be of some help and encouragement to them. "I want everything by default" might be an logical starting point, but being stuck there is not helpful.
What is your objection to the solution I suggested?
Everybody knows that everyone can't be satisfied, however I would think you are the minority in this case, not caring about the having a nice polished look for instance probably is a minority opinion (at least among people who actually want to use a theatre view), so is the want to use a 3rd party program and making custom scripts. Although there is a somewhat of a contradiction between flexibility and ease of use, the theatre view has a lot of possible improvement in this case. Meedios for instance is extremely configurable, frankly, hell to setup, however getting metadata and a very nice looking display is easy.
-
One thing I think you guys might be missing is that these other programs are open source/free and as such if the web sites don't like the scraping going on who do they go after to stop it? JRiver as a visible, for-profit company doesn't have the luxury of this "shield".
-
One thing I think you guys might be missing is that these other programs are open source/free and as such if the web sites don't like the scraping going on who do they go after to stop it? JRiver as a visible, for-profit company doesn't have the luxury of this "shield".
maybe devs wants to check it:
http://api.themoviedb.org/2.1
http://thetvdb.com/wiki/index.php?title=Programmers_API
-
One thing I think you guys might be missing is that these other programs are open source/free and as such if the web sites don't like the scraping going on who do they go after to stop it? JRiver as a visible, for-profit company doesn't have the luxury of this "shield".
That may or may not be the case, I don't know for sure, but there are sites one can scrape from, just as MC already scrapes Google Image searches for "fan art", I imagine MC could scrape Wikipedia for biographies and album reviews (in the same way that Mixzing music player does on my Android phone)
For me, having grown up holding album covers in my hands and reading the liner notes while listening, the idea of being able to read biographies and reviews while listening is FANTASTIC, and the google images in the background is a bonus too... It really adds something that got taken away as soon as music was not via a physical disk, but a downloadable, invisible file.
Please guys, please with a big cherry on top, its got to be do-able.
tx
Mark.
-
I have just uploaded a video to youtube demonstrating what I am talking about... please see it here:
http://www.youtube.com/watch?v=5olBkhgziE8 (http://www.youtube.com/watch?v=5olBkhgziE8)
Hey Mark,
Can you shoot me a link to where you got that wireless keyboard your using? ;D
Thanks..
-
Rick I have no objection to any solution, but have an aversion to working with scripts...
I did not suggest what I'm doing as a solution. I made it quite clear most users would consider it impractical. The solution I suggested was that JRiver develop a scripting engine that would allow user-developed scripts to retrieve any data from anywhere. I don't know if that's the proper way to describe what other applications do, but I'd be surprised if that's not exactly what some of them do. I really don't understand your objection to my suggestion the same capability that exists in other applications should be added to MC.
Also the way TMDb and the TVDb API's work is different than "scrapers," a common script engine could accommodate both. To most users, how these things work would be largely transparent. They would just install and configure the components they want, and then their data would be automatically updated.
About the default question... MC already has different "views" within Theatre Mode... when you navigate from one view to another, the contents displayed change... so I could see "biograpy view" and "album review view" being very welcome additions to the Theatre View menus.
As I've already said and illustrated, MC's Theatre View is already perfectly capable of displaying any such information. Unlike some of it's competitors, the information displayed and how it's displayed is not dependent upon the skin that is used—it's available through a user-friendly configuration.
-
I did not suggest what I'm doing as a solution. I made it quite clear most users would consider it impractical. The solution I suggested was that JRiver develop a scripting engine that would allow user-developed scripts to retrieve any data from anywhere. I don't know if that's the proper way to describe what other applications do, but I'd be surprised if that's not exactly what some of them do. I really don't understand your objection to my suggestion the same capability that exists in other applications should be added to MC.
Rick, it is difficult to hear you when you are so constantly annoyed, demeaning and patronising.
I am not against your idea, if it makes it easy to have what I would like, I would welcome it enthusiastically. If it is just a matter of installing something without having to "code" or "script" anything oneself, that would be great!
I hope Jim/dev people move on this... for me the only thing that keeps me from MC, despite having sprung $50 for it a short while ago.
Cheers,
Mark.
-
Can you shoot me a link to where you got that wireless keyboard your using? ;D
Hi there,
the keyboard is great, I have tried 3 before, and this one can take (certain brands of) rechargeable AA batteries, a big plus for someone who wants to be green. (I returned the other two to the shops I got them from because they did not take rechargeable batteries at all, 1.2v vs 1.5v for Alkali)
Keysonic ACK-540 RF
Cheers,
Mark.
-
As I've already said and illustrated, MC's Theatre View is already perfectly capable of displaying any such information. Unlike some of it's competitors, the information displayed and how it's displayed is not dependent upon the skin that is used—it's available through a user-friendly configuration.
On the one and only skin available. For 3 years. That makes the argument kind of funny.
Your screencaps above match the Info panel in XBMC. The metadata XBMC shows while navigating the media is unmatched. And even Info screen for Info screen, I'll ask you about the cd arts, the studio arts, the music label arts and a few things like that - to demonstrate the limitation of metadata in MC. There is no design-with-purpose thought process in MC.
It doesn't matter if you use what I mentioned, even if I used them. It matters that those options are in place and there are many smart people working and improving daily what is shown and how in XBMC. While over here it is 1% freedom (so you can tweak a color here and there in MC) and 99% features lock-down under hard to understand, undocumented design choices.
Where you say gimmicky and ineffective, I say advanced design and freedom.
Weave as you like your dbase fields. That is not IT.
-
There is no design-with-purpose thought process in MC.
Really?
-
there are many smart people working and improving daily what is shown and how in XBMC. While over here it is 1% freedom
Hi there Daydream,
The reason for me coming to this forum is that I had a similar experience on the xbmc forum where I started a thread and was asking some guy there (the chap who actually was responsible for biographies and album reviews to be added to xbmc) if they would consider being able to play Google Image search results in the background as an option to their "Album Art" which is very limited in my experience. I mentioned to him that MC implements this well, and even offered him £40 beer money to add the feature. He said he has no interest in creating eye candy, after the music has been navigated to, he has no interest in visuals while music is playing. I felt it was really difficult trying to put forward to him the case that there are MANY people who love seeing relevant images while listening... anyway, suffice to say that my experience of the xbmc forum has also been one of elitism and a knee jerk negativity to new ideas... perhaps I caught him/them on a bad day.
Dang, bizarre, I want XBMC to have something that MC has and MC to have some things XBMC has... I would gladly jump to a new HTMC softaware if it incorporated all those things.
Mark.
-
And even Info screen for Info screen, I'll ask you about the cd arts, the studio arts, the music label arts and a few things like that - to demonstrate the limitation of metadata in MC.
Aren't you limited to seeing what the "skin designer" thinks you should see? How is this more "freedom" than easily selecting the metadata you want displayed as in MC? And does XBMC provide an easy way to edit and manage this extra metadata?
-
Aren't you limited to seeing what the "skin designer" thinks you should see? How is this more "freedom" than easily selecting the metadata you want displayed as in MC? And does XBMC provide an easy way to edit and manage this extra metadata?
MediaPortal does. And surely, this isn't really the point, is it? In MC, you're "limited" by what the View design says you can see - this is an intended and valued feature.
XBMC, Meedios, MediaPortal... none of them are perfect, but they all have one thing in common which MC doesn't have. The ability to get said metadata automatically and put it in a format that can be used & displayed in the host program by a clever person. And then after that, a dumb person (me).
MC is great at a lot of things. In most things it blows away the competition. But it lacks this extremely significant feature. And that is, for me, and others, a complete show stopper.
If putting in a "scripting language" would let the MP-TVSeries or Moving Pictures plugins for MediaPortal be adapted to work for MC then please bring it on. But my impression is that this isn't JRiver's style and they'd rather keep everything contained in the MC sandbox. So in that instance, the solution (if one were desired on their part...) would be to integrate the metadata gathering & display within the program itself, and provide a UI around it. Frankly, that would be a nightmare for them to implement (ever tried implementing a completely configurable UI? I have) - so I reiterate what I said in my previous post, they'll never make it easy for us to use & show media metadata from an online source.
Shame.
-
Really?
You would probably fight me on the whole application, saying that it is, while I will fight you on the interface, saying that it isn't.
I do not understand that while you accept the help of a lot of smart people around here, to beta-test, write plugins, guides, or simply writing thousands of posts advising others on your behalf, you don't allow us to step in when it comes to the interface. Is there some inherent fear that we will change the applications look beyond any recognition, is the current design so integrated to the core that any external changes will make everything go haywire?
Aren't you limited to seeing what the "skin designer" thinks you should see? How is this more "freedom" than easily selecting the metadata you want displayed as in MC? And does XBMC provide an easy way to edit and manage this extra metadata?
1) The learning process of how and with what to edit the metadata in XBMC is on par (at the very least) with teaching somebody the ways of MC's database and then explain how to build a double roller menu (Theater view) to navigate things that are actually fields in a dbase. Of course there is a learning curve, of course it takes time and effort. But when you draw a line it comes down to this: I can make my own skin (or modify another) and place whatever I want wherever I like it in XBMC. You cannot say the same about MC, where I guess we need a discussion about graphical and interface design.
2) That means selecting the metadata and put in on the screen somewhere is not everything. That's why I wrote that weaving database fields is not "IT". Presentation, style, thoughs about how fast certain something is perceived and how, how pleasant an experience - all these details are lost here. There is information better expressed as text, or as pictures or as symbols. How do you put these things together, the final experience it's what matters. It requires certain abilities, beyond opening Photoshop and saying "now what?". A 95% transparent gradient may almost be invisible when creating the graphics, while once applied in the interface it creates the illusory effect of a faded glow. We just don't talk about things like this in here. You are so entrenched into your whirlpool of everything databases and metadata that I feel compelled to yell every now and then "This are supposed to be made for humans, not robots!"
Collecting metadata is not a purpose per se. You have to have a proper way to show it. MC's way (and yours, all of you arguing the benefits of the current state) is mechanically structured and executed. It lacks wonder.
-
We have benefitted greatly from the advice of many users on every aspect of the program, including the interface.
I'm sorry you feel otherwise. My impression of your posts is that you are often critical, but rarely provide details we can use. Perhaps I've overlooked something.
-
MediaPortal does. And surely, this isn't really the point, is it? In MC, you're "limited" by what the View design says you can see - this is an intended and valued feature.
XBMC, Meedios, MediaPortal... none of them are perfect, but they all have one thing in common which MC doesn't have. The ability to get said metadata automatically and put it in a format that can be used & displayed in the host program by a clever person. And then after that, a dumb person (me).
MC is great at a lot of things. In most things it blows away the competition. But it lacks this extremely significant feature. And that is, for me, and others, a complete show stopper.
If putting in a "scripting language" would let the MP-TVSeries or Moving Pictures plugins for MediaPortal be adapted to work for MC then please bring it on. But my impression is that this isn't JRiver's style and they'd rather keep everything contained in the MC sandbox. So in that instance, the solution (if one were desired on their part...) would be to integrate the metadata gathering & display within the program itself, and provide a UI around it. Frankly, that would be a nightmare for them to implement (ever tried implementing a completely configurable UI? I have) - so I reiterate what I said in my previous post, they'll never make it easy for us to use & show media metadata from an online source.
Shame.
Exactly, 100% agree with you, word by word. In my case I use Media Portal for movies and series, the MP-TVSeries & Moving Pictures Plugins are really, really good, and the way Media Portal shows the metadata and backdrops with the StreamedMP skin are great (you can look on youtube to see what im talking about). Please J River, consider to "copy & improve" this behaviour and you will win the title of BEST HTPC software.
-
We have benefitted greatly from the advice of many users on every aspect of the program, including the interface.
I'm sorry you feel otherwise. My impression of your posts is that you are often critical, but rarely provide details we can use. Perhaps I've overlooked something.
Since I'm keenly aware what I write and how, sometimes I ask myself too, if it doesn't come off as overtly critical for the sake of rhetoric only. However the problem is a bit more complicated, since there are... extenuating circumstances, as in this discussion going on for years, and also that I don't understand most of your strategy for Theater View (may it be just me), and the part I understand - I disagree with.
Sometimes back I came up with this mockup (post here (http://yabb.jriver.com/interact/index.php?topic=53074.msg362177))
(http://thumbnails19.imagebam.com/4371/1f01ff43708528.gif) (http://www.imagebam.com/image/1f01ff43708528)
and that was just on a whim, just Photoshop work, not trying to be original. That was almost 2 years ago.
Then I did Galaxy (http://yabb.jriver.com/interact/index.php?topic=54921.msg373610), which at the time was entirely just a play with color alone. To this day it's still the most... colorful attempt in my book, to do something with Theater View, but I'm biased for obvious reasons and since I took a break from visiting here, I might've missed something new. You guys did something in MC15 to break further skin compatibility, and although on my home system I fixed it, I never published a fix because I don't know how I fixed it. Throw stuff at the wall and see what sticks - that is what I did, 'cause that echoes well enough the documentation on Theater View skinning and the changes its engine went though.
From my experience at the time - since you wondered about specifics - I remember struggling with reused graphical elements (especially the navigational highlight) and wrapping everything in my skin files so I can distribute it. Having common settings for all skins in one file seems backwards to me, if I change that file I affect all skins, not just mine. Seemed at the time that somebody never even considered that some other people may start writing their own skins.
This may come off as just me saying so, since there is no proof - but I had planned to design a new skin - Universe - if skinning was actually developed into a complete framework. Something that would rival and surpass XBMC. I was willing to work on it 3-6 months. The occasion never presented itself so I moved on.
So yes, I'm a die-hard XBMC user now. The flipside of that is that I'm very much aware how MC can be overall better then XBMC. It just seems that you guys don't want to go there. Understandably from a certain angle, the development strategy differs significantly, but not so much from other - a skinable interface should boost the look and feel of the MC generically, regardless if it competes with XBMC or not.
The guy above was right. In MC we want something of XBMC. In XBMC we want something of MC. That is a truth outside of anybody's agenda. In XBMC stuff is designed with flavor and bigger-than-life graphical interfaces and scripts; they dream orange when they fly over Mars. In MC stuff is made with terrific database speed & flexibility, and great audio development. I know you're working and I know they're working on improving. Coincidentally I know in broad strokes some of their plans for their next version, and some for the version after that. I know nothing here. It seems too great a divide right now. But, 2-3 years back, even if in my make-a-lot-of-noise style, I asked here first.
-
Exactly, 100% agree with you, word by word. In my case I use Media Portal for movies and series, the MP-TVSeries & Moving Pictures Plugins are really, really good, and the way Media Portal shows the metadata and backdrops with the StreamedMP skin are great (you can look on youtube to see what im talking about). Please J River, consider to "copy & improve" this behaviour and you will win the title of BEST HTPC software.
For a split second I entertained the though of challenging you with "Media Portal is just an XBMC fork" but that would derail everything to hell :). Focusing instead on the part we agree on, I'll reach for the closest Python book, and we'll see what good scrapping scripts & stuff comes out of it. :)
-
For a split second I entertained the though of challenging you with "Media Portal is just an XBMC fork" but that would derail everything to hell :).
hehehe, I know XBMC is the king and Media Portal is just a great copy of it, but years back when I was trying this kind of soft, XMBC was very slow on my system (some issue with video drivers perhaps) and then I tried Media Portal and was stunned by it. :)
EDIT (I did understand it now)
BTW, your Galaxy skin is my default Theatre View Skin, nice work!
-
We have benefitted greatly from the advice of many users on every aspect of the program, including the interface.
I'm sorry you feel otherwise. My impression of your posts is that you are often critical, but rarely provide details we can use. Perhaps I've overlooked something.
What kind of details do you want? I can try to provide details on what kind of interface and information I would like to see, or at least like to see possible in MC. Although maybe not worded in the nicest way, daydream has a point. We only have one theatre view, no skins(?) and the theatre view is pretty plain looking to be honest. Of course, there are people who likes that the best, but quite a lot also prefer a bit more "bing". I can post some screenshots of nice skins from other programs if you want to.
-
For music and movies the current interface is ok by me. For series its lacking in comparison to the others mentioned here. What I dont understand is that at one point so much work was done on the skinning with backdrops of theaterview and it stopped just before it became really useful for series. As far as I know we still cant associate individual series > seasons > episodes with different backdrops and other graphical elements for each step in the hierarchy. When I use mc for series I use a line up view from the series folder with random backgrounds from the series I watch. For selecting what I want to see it works good...but it just does not compare to xmbc graphical presentation and that without any manual interference for getting the artwork.
-
We have benefitted greatly from the advice of many users on every aspect of the program, including the interface.
I'm sorry you feel otherwise. My impression of your posts is that you are often critical, but rarely provide details we can use. Perhaps I've overlooked something.
Hello Jim
I hope all is well with you?
Let me chime in here.
I did find his posts useful, they were supporting what I was saying, that the scraping of metadata and display in Theatre mode could be improved vastly... that it should not require someone who is a script/encoding boffin to get this data available.
There are many music lovers who are searching for a great HTMP, hence all the ones out there, but the complexity of being able to get this info visible in MC will keep it appealing mostly to a small, elite niche, and drive non-techies like myself to offerings like XBMC where all i need do is find a skin I like and get most of what I want (except google images!!!)
Please be open to these comments, they are valid and I am sure there are many, many who would give MC another look if this kind of metadata was automatically available.
Tx
Mark.
-
I can post some screenshots of nice skins from other programs if you want to.
I believe we tried the screenshot approach, a while back. Way back.
What "we" want is complete control over placeholders, we want conditional visibility, we want 10 types of transitions with x,y,z-order and degree parameters available. We want to texture anything and everything, with stacked layers and transparency. We want windows to have ID designations and configurable triggers. The things we want would make one go nuts.
Also we would NOT have to struggle with the legacy of a game platform. We would be very happy to employ current JRiver tricks where applicable to speed up/cache graphic rendering for covers, fanart and the likes. If the things we want are really scary, the ideas we would spin and brainstorm would be awesome.
What I dont understand is that at one point so much work was done on the skinning with backdrops of theaterview and it stopped just before it became really useful for series.
I have a theory, but well, it's just a theory. Why would one wanna develop a full 10-foot interface, with a lots of tricks and bells, when you can use the most often poor, non-configurable DLNA interface on whatever device you have handy? What do you think it's the key word on what I just said? :)
-
I did find his posts useful, they were supporting what I was saying, that the scraping of metadata and display in Theatre mode could be improved vastly.
I don't disagree. But your suggestions are in an area that is full of possible legal problems. I wish it were simpler. Eventually it may be.
-
I don't disagree. But your suggestions are in an area that is full of possible legal problems. I wish it were simpler. Eventually it may be.
Hi Jim
Ok, I see...
What about Wikipedia, is that also "not free" because my android phone's music software, Mixzing uses wiki for album reviews and biographies, and that is great.
tx
Mark
-
Since I'm keenly aware what I write and how, sometimes I ask myself too, if it doesn't come off as overtly critical for the sake of rhetoric only. However the problem is a bit more complicated, since there are... extenuating circumstances, as in this discussion going on for years, and also that I don't understand most of your strategy for Theater View (may it be just me), and the part I understand - I disagree with.
Sometimes back I came up with this mockup (post here (http://yabb.jriver.com/interact/index.php?topic=53074.msg362177))
(http://thumbnails19.imagebam.com/4371/1f01ff43708528.gif) (http://www.imagebam.com/image/1f01ff43708528)
and that was just on a whim, just Photoshop work, not trying to be original. That was almost 2 years ago.
Then I did Galaxy (http://yabb.jriver.com/interact/index.php?topic=54921.msg373610), which at the time was entirely just a play with color alone. To this day it's still the most... colorful attempt in my book, to do something with Theater View, but I'm biased for obvious reasons and since I took a break from visiting here, I might've missed something new. You guys did something in MC15 to break further skin compatibility, and although on my home system I fixed it, I never published a fix because I don't know how I fixed it. Throw stuff at the wall and see what sticks - that is what I did, 'cause that echoes well enough the documentation on Theater View skinning and the changes its engine went though.
From my experience at the time - since you wondered about specifics - I remember struggling with reused graphical elements (especially the navigational highlight) and wrapping everything in my skin files so I can distribute it. Having common settings for all skins in one file seems backwards to me, if I change that file I affect all skins, not just mine. Seemed at the time that somebody never even considered that some other people may start writing their own skins.
This may come off as just me saying so, since there is no proof - but I had planned to design a new skin - Universe - if skinning was actually developed into a complete framework. Something that would rival and surpass XBMC. I was willing to work on it 3-6 months. The occasion never presented itself so I moved on.
So yes, I'm a die-hard XBMC user now. The flipside of that is that I'm very much aware how MC can be overall better then XBMC. It just seems that you guys don't want to go there. Understandably from a certain angle, the development strategy differs significantly, but not so much from other - a skinable interface should boost the look and feel of the MC generically, regardless if it competes with XBMC or not.
The guy above was right. In MC we want something of XBMC. In XBMC we want something of MC. That is a truth outside of anybody's agenda. In XBMC stuff is designed with flavor and bigger-than-life graphical interfaces and scripts; they dream orange when they fly over Mars. In MC stuff is made with terrific database speed & flexibility, and great audio development. I know you're working and I know they're working on improving. Coincidentally I know in broad strokes some of their plans for their next version, and some for the version after that. I know nothing here. It seems too great a divide right now. But, 2-3 years back, even if in my make-a-lot-of-noise style, I asked here first.
Thank you for the details. I'm sorry I missed them earlier.
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.
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.
DLNA and Theater View are completely different subjects. Both are important to us.
The biggest problems in satisfying your needs are the legal questions. I like my life as it is.
-
I don't disagree. But your suggestions are in an area that is full of possible legal problems. I wish it were simpler. Eventually it may be.
I'm wondering what the "legal problems" you perceive are. So many other (both commercial and freeware) pieces of software cheerfully take metadata from free online databases for music, TV and films - why is MC different? Why would you get sued when the others don't?
Perhaps if we, as users, could understand the scope of your limitations in this we'd know more in future what is and isn't possible.
-
I'm wondering what the "legal problems" you perceive are.
It's not possible to discuss. Sorry. Please ask any attorney why.
If you think I'm paranoid, it's because, as they say, "Even paranoids have enemies." We had a ridiculous patent suit recently that we won, but it cost $60,000 to defend.
Please let me be the judge of what is safe for JRiver.
-
Please let me be the judge of what is safe for JRiver.
Wasn't even beginning to suggest otherwise.
But given the limitations you're obviously working under, it kind of kills the whole thread off anyway, don't you think? :-\
For now, I think it's good to know that you would at least like it to be different. That means there is hope.
-
I've been with MC since I started ripping my first CDs to a computer. v8 I think. Anyway wouldn't trade it and happily pay my for my upgrades but I use XBMC for all my video content.
-
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.
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.
DLNA and Theater View are completely different subjects. Both are important to us.
The biggest problems in satisfying your needs are the legal questions. I like my life as it is.
That is a problem, but thats a problem for all simialr interfaces, and most of them handle it reasonably well, It doesn't seem like somthing that would be impossible to solve even with different skins.
Do we need to abandon the interface of today? Why limit it to only one interface?
If legeal questions is the big hurdle for obtaining meta-data it seem like the best approach would be to make a 3rd-part script/plugin/program interface with MC, and let the given program obtain the data.
-
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. 8)
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*
-
MediaPortal does. And surely, this isn't really the point, is it? In MC, you're "limited" by what the View design says you can see - this is an intended and valued feature.
You can easily show whatever metadata you want for each file type in MC through "Customize file info panel". I understand that you guys want to be able to put the info anywhere on the screen instead of just in a text list form and I agree it would be good to have that flexibility but you are not "limited" in the metadata you can display. You can even create and display custom fields and populate them with your own "scraper".
-
You can even create and display custom fields and populate them with your own "scraper".
Hi cncb and all...
The reason I started this thread was to say this info is missing from MC by default. I am not a coder/tech wiz, so will never be able/willing to do that myself... I want MC to have an option to scrape all this info and display it in Theatre view - automatically. It seems, from what Jim was saying, that there are legal issues with scraping this info. I'm baffled by this since there are so many examples where this info is scraped, but perhaps it is the difference between a paid and non paid app.
Anyhoo, for me it seems like XBMC is still going to be my "Theatre View" of choice.
Thanks for the interesting conversation,
Mark.
-
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. 8)
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.
-
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
-
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.
-
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?
-
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)
-
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.
-
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. ;D
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?
-
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 :D)
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)
(http://i55.tinypic.com/2z5qdrs.jpg)
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).
-
You don't seriously believe I'm going to agree on how we disagree. ;D
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(?)
-
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?
-
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?
-
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.
-
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!
-
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.
-
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.
-
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?)
-
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?
-
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.
-
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)?
-
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.
-
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.
-
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...
-
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.
-
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.
-
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! ;) :D
-
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.
-
Sorry it took so long to say thanks Jim, I had to scan some terrabytes of media back into MC from XBMC :P
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. :)
-
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.
-
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*
-
Glad to see something came from this thread. It's been a lot of reading ;D
-
[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!