Print

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

[Matt]

Changes in tonight's build described here:
http://yabb.jriver.com/interact/index.php?topic=68476.0

[rick.ca]

But sometimes, that's just what we do here.  It is cool, I like discussing this sort of thing...

I might say the same, now that the others see the light and agree with us. But I think this went way beyond what could possibly be of any use to the developers. At reply #10...

I'm thinking only supporting sidecar artwork for videos (so no Cover Art folder usage) might be the best solution.

One could only hope he had the good sense to do something productive instead of read replies #11 to 48.

This was, essentially about where to save meta data. The program already supports, more or less, media files in any folder structure we care to use. It follows that options for meta data include (1) using the same folders (i.e., saving meta data "sidecar" files "beside" their media files, (2) replicating that same structure in a different location, or (3) creating some other folder structure. Aside from those choices, we arguing about how the program saves it's own data in the file system. Suggesting the developers can't figure out how to name a file or that the results will be "messy" is ludicrous. It's data. Being saved to a file system.

The first priority is that it works. The next (but probably not separate) priority is that it be straightforward, not confuse users and possibly not frustrate the use of the same data by other applications. The first option seems to be the obvious choice, but it seems Matt already knew that. At the same time, there are related questions that have gone unanswered...

Do we need options for other schemes, or would that just create unnecessary issues? The current options for saving cover art in different ways seems to have created more confusion and problems than it's worth. This discussion has failed to identify any good reasons for allowing more than one location.

On the question of whether meta data should be saved in subfolders, we identified one case where another application (Sick Beard) does so (AFAICT, for episode thumbnails only). That's been used as grounds for saving meta data in subfolders generally—when there are many good reasons not to. The first priority for this scheme should be effective support for MC's own meta data system (most of which is not yet implemented), not third party applications. The first question should be whether or not Sick Beard even needs to be supported. It gets data from TVDb, as will MC integrated system. Why would anyone continue to use Sick Beard (for getting meta data) once that's implemented? If it's a matter of supporting Sick Beard (or anything else saving meta data in subfolders), the sensible solution is to have MC look in subfolders for existing meta data, just as it does the root. The meta data it actually uses (whether obtained from a subfolder or downloaded) would be saved in the root.

I'm not completely against the use of subfolders. They might be appropriate for some things that might be supported in the future (e.g., when a meta data retrieval system is in place and the data is readily available). Things like posters and fan art where there can be a number of images (more than a few) pertaining to each item (movie or series). That might work as I suggested above—downloaded series posters, for example, would be saved in a subfolder and the one used saved in the root. Or a subfolder might be the only location—downloaded banners, for example, that are cycled or chosen at random for a particular view. But there's no point discussing this here, as there are no existing features that require subfolders.

True. But I still would prefer if you all would just agree with me in the first place though 

Some of us don't drink as much beer as you.

[JustinChase]

But there's no point discussing this here, as there are no existing features that require subfolders.

You should work where I do, they don't think about the future when making decisions about how to do things either

[rick.ca]

You should work where I do, they don't think about the future when making decisions about how to do things either

Are you suggesting you're employer would benefit from discussions like this? There's nothing wrong with considering the impact of features that might be added in the future to changes being considered now. But that's not what happened. The discussion was sidetracked by vague references to future possible features. Proper consideration of those possibilities would have found they make absolutely no difference to the matter at hand. As a result, relevant issues were missed. Worse, probably none of this was of any use to the developers. As usual, however, they seem to have done some good work while ignoring us.

[JustinChase]

Are you suggesting you're employer would benefit from discussions like this?

ABSOLUTELY!!!!

They do things without thinking at all, then implement changes poorly, then re-do them a day or a week or a month later. Consistently.  All the while, the important things don't get done, because everyone chases their tail trying to recover from the last bad decision.  It's terrible!!

I don't mean to imply that happens at JRiver, not consistently, I don't believe that.

I just know all-too-well what happens when these kinds of discussions don't take place.

For example, the possibilities of how this system may or may not work properly don't seem to have been fully flushed out at JRiver prior to the situation that existed with the cover art being duplicated, which led to this thread in the first place.  Stuff got overwritten, and it caused an issue.  That's not to say it wasn't considered, but the issue wasn't avoided, so something got overlooked it seems.  i.e. the discussion seems to have not been thorough enough to have caught this problem before it occurred.

My point is/was that a thorough discussion taking place PRIOR to changes can often times flush out potential issues, and they can be dealt with in the planning stages, not in the firefighting stage after the problem shows itself in real-world use.

The fact that you think nothing good came from this discussion, because the same decision was reached after the discussion, is inaccurate.  It shows that many possibilities were considered, and the potential issues were addressed (if any) and confirmed the initial decision was likely a good one.  This results in a new system that has a high likelihood of success.  This is, of course, no guarantee that something new won't come up and force a change, but it lets the process move forward with a sense of confidence that the topic won't need to be revisited again soon; because of a problem that could have been avoided.

For example, had this all happened before the change prior to this change, all of this discussion would have been avoided, or at least pulled forward to have happened prior to the first change; which would have at least saved me several hours of having to 'Get Movie & TV Info' on a couple hundred files a second time.

The Season artwork could have been an issue if it had not been discussed, if they had decided to just go with [Season].jpg in conjunction with having all episodes of all seasons in one folder.  That you suggested [Series]-[Season].jpg may have saved that mistake from happening.  Hard to say, but these kinds of discussions DO lead to good ideas, and expanded viewpoints of the process/system as a whole, and generally help avoid unnecessary problems/issues.

There's nothing wrong with considering the impact of features that might be added in the future to changes being considered now. But that's not what happened. The discussion was sidetracked by vague references to future possible features

"There's nothing wrong with considering the impact of features that might be added in the future...discussion was sidetracked by vague references to future possible features."

i.e. considering...features..in the future...was sidetracked by...references to future possible features ?

Proper consideration of those possibilities would have found they make absolutely no difference to the matter at hand

No, proper consideration DID find they (likely) make no difference, in this case.  If the discussion did lead to discovery of a problem, that problem would then have been avoided, and the cleanup of the fallout would also have been avoided.  I consider this a success, and a good use of time.  I spent less time in this discussion than I will spend cleaning up the thumbnail issue the lack of this discussion caused because it wasn't held before the change prior to this one.

As a result, relevant issues were missed

Wait, what?!?  As a result of a lengthy discussion that didn't turn up any serious 'relevant issues', "relevant issues were missed"?!?  What relevant issues were missed, and why didn't you bring them up during the discussion intended to find them?

Worse, probably none of this was of any use to the developers

I'm not so sure about that.  Perhaps not, but if it avoids problems, I would say it was of use to them, even if not readily apparent.

As usual, however, they seem to have done some good work while ignoring us.

Finally; we agree

[glynor]

Some of us don't drink as much beer as you.

I'm in there trying.

Of course, I'm pretty sure you meant to exclude me from the "some of us".   

[rick.ca]

Wait, what?!?  As a result of a lengthy discussion that didn't turn up any serious 'relevant issues', "relevant issues were missed"?!?  What relevant issues were missed, and why didn't you bring them up during the discussion intended to find them?

This is a perfect example of how to make what should be a simple and productive discussion draining and unproductive. Ignore what others are taking care to explain, or assume their comments are for the sole purpose of disagreeing. In this case, I even went to the trouble of providing examples of issues we missed. Fortunately, Matt did not miss one major one—providing an alternate location to support meta data for external media. I've now made some comments on use of subfolders and support of other applications. You've ignored them.

All of my comments have been on the question introduced by Matt. As for the issue that started this topic, it's still unclear to me exactly what is happening, or what bearing the meta data storage location might have on it. The handling of series is something under development and obviously incomplete. Category cover art for series was introduced, and this caused some unexpected (at least by users) behaviour. It's difficult to say whether comments on and discussions about such things are of any use or not. They're probably worth mentioning, in case they're an unintended consequence the developers are unaware of. Otherwise, in the absence of any comments or questions from the developers, it might be best to defer discussion until development has progressed further.

Of course, I'm pretty sure you meant to exclude me from the "some of us".   

No. I was hoping beyond hope someone else was sober.

[JustinChase]

This is a perfect example of how to make what should be a simple and productive discussion draining and unproductive. Ignore what others are taking care to explain, or assume their comments are for the sole purpose of disagreeing. In this case, I even went to the trouble of providing examples of issues we missed.

I was hoping we were done, but it seems not

First, why do you expect this should be "simple"?  Thousands of individuals using a brand new tool, with more expected to follow, in the most customizable software, all wanting different things, and you think it will be "simple"?

How was it instead "unproductive" (excepting these last posts)?

I read every word printed here, and have not ignored anything.  I cannot claim to have understood everything you have written, but not for lack of intelligence, nor trying.  some of it is simply incomprehensible, or just 'rambling' and opinion presented as fact.  I don't say that to be mean, or to "attack" you, it just doesn't make any sense.  here is but one, of many, example(s).

In a folder structure organizing media by type, ending, for example in \Season [Season]\, all files pertaining to a particular season of a series belong in that folder. There's nothing wrong with then adding further folders for different file types, but it's inconsistent with the preceding structure. More importantly, like applications, most users will prefer to see media files along with whatever files are saved "beside" them. That, in fact, is the very purpose of saving them that way.

Why is adding an extra folder to keep related, but different use-case-type files separate from files I will actually use "inconsistent with the preceding structure"?  I see it as a natural extension of that structure, as do others. All of the files still relate to the \Season [Season]\, but if my normal usage is to locate video files I can play by double-clicking, keeping files I can't play separated makes perfect sense, for my usage needs.  It's not inconsistent at all; for my needs.

Then you go on to state that "most users will prefer"...  yet, that's simply your opinion, and I disagree with it, as have many others in various, related threads.

Saving files of different usage/purposes in the same folder is NOT, in fact, the purpose of this structure.  The purpose in my usage is to keep files related to a particular season grouped together to make them easy for me to find, but not to clutter the files I actually intend to use, thus the separation into a separate folder.

In my comments, I have provided several examples of potential pitfalls, and solutions or reasons they turned out to not be pitfalls.  I pointed to your comment as a solution as well, 2 or 3 times actually.  Saying you provided examples of issues we missed is not the same as providing examples.  Where are these examples of things we missed?

I am not the one that appears to assume "comments are for the sole purpose of disagreeing".  If I disagree, I will say so, and if I agree, I will say that also.  If you care to see some examples of this, please re-read this thread, there are plenty to choose from, including some pictures.

I've now made some comments on use of subfolders and support of other applications. You've ignored them.

I addressed them at least twice, previously.  I don't see the point in repeating myself.

All of my comments have been on the question introduced by Matt.

Sticking to one topic, and not thinking about potential issues related to it is not something to brag about, not to me anyway.  Especially in a thread started to discuss another topic.

As for the issue that started this topic, it's still unclear to me exactly what is happening, or what bearing the meta data storage location might have on it

Really?  After all your comments to me about not understanding, and ignoring you, you now tell me you don't understand the topic in question?  Wow.  Maybe that's why your comments don't really address the topic, you don't understand it.  Perhaps that will be a good reason not to hit reply in the future?

The handling of series is something under development and obviously incomplete. Category cover art for series was introduced, and this caused some unexpected (at least by users) behaviour.

As I said, it caused some unexpected behavior exactly because it (seemingly) wasn't thoroughly thought out and discussed prior to implementation.  Thus the reason I tried to include discussion about possible issues that might be introduced in the future, so as to avoid this unexpected behavior in the future.

It's difficult to say whether comments on and discussions about such things are of any use or not. They're probably worth mentioning, in case they're an unintended consequence the developers are unaware of.

NO, not "in case", BECAUSE the developers might be unaware of unintended consequences.

It's clear to me you are not actually reading and understanding what I'm writing, so please, seriously, don't reply.  I'm certain that no one here wishes to see this continue; I certainly don't.

**Sorry Jim, I appreciate all that you folks do, and the complexities of this wonderful software.  I know these last posts haven't been "your cup of tea", but I do think the topic warranted the extra discussion, or I wouldn't have bothered.

I'm going to bed now, and won't be responding to any more comments unless they specifically relate to 'Get Movie & TV Info' issues.

[MrHaugen]

It's hard not to take a side here, but I'll try not to. There IS a lot of assumptions in the last replays though. Let's try to be a little more open minded and not assume to much. I think most contributers here read all replays carefully and write their thoughts because it might help MC17 improve in a direction most users would like. This should be the goal. Not convincing people that your way is what everyone else likes the best.

Let's just leave it at this, take a beer and chill before this thread is locked as well?

[scm]

I'm trying to find where this "screengrab" option is so I can manually select an image from the video file, but I can't find it.  Anyone help?

[JustinChase]

First, make sure you're using Red October Standard (not RO HQ, because it uses MadVR, which doesn't allow for screen grabs.)

Then, play a video, pause when you see the image you want for your cover, while playing, right-click on the playing video, select Window > Use Screen Grab for Thumbnail...

If you want to use the image for something else, you can right-click on the playing video, select Window > Screen Grab to file... to copy it to your clipboard.

Done

[6233638]

First, make sure you're using Red October Standard (not RO HQ, because it uses MadVR, which doesn't allow for screen grabs.)

madVR added screenshot functionality in version 0.84.0 (2012-10-06)
Media Center should be able to support this.