Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - rick.ca

Pages: 1 ... 103 104 105 106 107 [108] 109 110 111 112 113 ... 118
2141
Support / Re: Problem with advanced search
« on: April 01, 2009, 01:47:48 am »
Quote
And I still see tons of shorts in the list... Am I doing anything wrong?

You're not doing anything wrong. I'm not sure whether to call this behavior a bug, limitation or "that's just how it works." It seems the search condition applies to each item in a multiselect list field. So a movie that you think should not be included because one Genre list item contains "short" is included because other Genre list items do not contain "short." :P

Here's a quick and dirty fix: "Loan" your Shorts to a borrower named "Shorts," then use the loan filter to exclude them. If you don't use the filter, they will also be colored differently, which you might also find useful.

A less goofy solution is to use a custom select list field (where only one item can be chosen) to differentiate such items. I use one called "Work type." It's populated by AllMovies, but that's beside the point. It categorizes items into Animated, Documentary, Feature (film), Performance (concert video), Series, and Television. So, I can use it in Advanced search to show only Features, or to exclude Documentaries.

Quote
I find names of actors in the "Genre" section.

This, of course, is not right. I hope the error that caused this is not something likely to recur. Tools - Optimize database should remove the names from Genres. Or, you can remove them manually using Preferences - Lists.

Quote
when I view a movie that I have searched using keywords

In general, if the any filter or search set in movie view is hiding the movie you are selecting using a link, then it can't be displayed (and effectively defaults to the movie last selected). Yes, this can be frustrating—especially since it's simultaneously doing what you told it to do, and not doing what you want it to do. ;) 

It would be nice if the behaviour would be more "forgiving" in this situation—and display the movie selected by the link anyway. It could put it at the top of the list so it's clear it's outside current filter/search settings—just like the behaviour for a newly added movie.

2142
Feature Suggestions / Re: TheMovieDB.org
« on: March 31, 2009, 02:43:45 am »
Websearch:

Movies: http://themoviedb.org/search/movies?search[text]=%s%u
People: http://themoviedb.org/search/people?search[text]=%s%u
  Both: http://themoviedb.org/search?search[text]=%s%u

The /movies or /people part takes you directly to the Movie or People results page, rather than the catch-all "Popular Results" page.

2143
Quote
I can't tell for sure what they are using, but it is in fact the best way to achieve good performance in managing big datasets is to use a relation database. I think the MC guys are using one as well.

That's the interesting thing. They're not using a relational database. Following is a comment from the lead developer. It's from years ago, but I'm sure he would say the same thing today.

Quote
The buzz about using a "relational database" on Interact is mostly misguided.  MC uses a system highly-tuned for storing the kind of data that's thrown at it.  That same system would allow relational artist and album tables, but this isn't something we think makes sense in the UI for most users.

I think this means they've decided it best it look and behave like a flat file database, but if some part of it needs to be handled as a relation for performance reasons, they will do so. The result is very impressive. It apparently handles very well with databases having 100,000's records.

Raldo, this make me think of something we should probably clarify. I've always wondered why MC developers bother asking what fields they would like to see added to the database, when users can easily add their own custom fields. One reason might be so they can consider the optimal handling of each that is added. So, for example, perhaps the existing Genre and People are handled in a relational way, so they can be used for movie genre and actors. But maybe if custom fields are added for category, actors, director, etc., those would just be handled as regular flat file fields. So the mapping of PVD fields to standard fields provided for the same or similar purpose in MC may be important. I've added a question to your New default video database fields topic at the MC forum.

2144
Quote
At some point, If JRiver decide to make a metadataview, you coud use their language (smart lists) to pick actors, key grips, etc., directors

You're right. I'm too used to thinking about from a relational database point-of-view, which MC is not. So an actor is not related to a movie via a role in MC—it can only search selected fields for the text of the actors name. This also means my idea of using one list field for all credits is not a good one. MC would not be able to simple things like list movies of a particular director—you would have to search for "[name] - Director" in Credits, rather than "[name]" in Director.

Quote
That'll "refresh your package" and make it easier for others to get into your train of thought.

It would help if I had a train of thought that goes in one direction.  ;D

Quote
Yes, one's balancing a thin line between ease of use and flexibility.

The main idea behind my view is to use PVD to collect the data in an organized and controlled fashion. Having done that, all that's required is a way to dump it all into MC in some reliable fashion (i.e., data going into the correct field type, no conflicts with existing field use, etc). Once it's there, the user can decide what to display and make use of. I have no problem with the idea of providing default field mappings for the sake of ease of use, but at the same time, I believe the whole thing needs to be fully configurable. Mapping Director onto Director and Genre on to Genre is reasonably safe. Title is pretty obvious, but some will think "the title is the title," while others understand there are titles, original titles and AKA's. And despite what many may think, there is no standard meaning for things like Category and Tag—you can't even say for sure what field type is required. All the potential for confusion is removed if all the database design decisions are made in PVD, and then the plugin preserves that in the transfer to MC.

But I'm getting ahead of myself. I have no idea how difficult it is to create a plugin that might do things like this. Do you think it feasible to make one that lists PVD fields (and their types), offers default mappings to compatible field types and offers to create additional custom fields if necessary? Or were you thinking of something considerably more basic than this?

Quote
Open PVD, search folders and export... Done.

If, in the end, you can say the same sort of thing about a plugin, I'm sure you would make many MC users very happy. Most who are interested probably don't have the time or inclination for anything that's not quick and efficient. Once they realize MC is not going to collect the data automatically for them, they'll appreciate the solution: "Configure PVD to get whatever data you want. Install the plugin. Done!"

2145
Quote
Do you mean the annoying reordering of lists into alphabetical order?

Yes. It's critical that lists of credits remain in credits order.

Quote
I don't understand the syntax "[name] - [role]/[function]". Is this a new field type?

Yes. That's just my way of describing a generic format for all credits. More specifically, it would be "[name] - [role]" for actors, and "[name] - [function, position or job title]" for production credits. It could then be used for any type of credit. For example, you could chose not to have a separate Director field, saving "[name] - Director" in a Production Credits field, along with "[name] - Key grip", etc.

Quote
Do you want to start a new thread on this in the MC forums? The timing is correct now...

I think I've already expressed my views in the thread I mentioned. But if you have something to say, I'll probably find it impossible not to add my 2 cents. ;)

Quote
I was just suggesting a generic approach ("New Plugin Type") but a simpler solution may work as well.

I'm sure I don't understand all the technical ramifications, but if you can write a MC plugin that accesses the database directly and doesn't need PVD running as a server, that has to simplify the task considerably. On the other hand, if it's simplified too much, it doesn't do much more than the export-import approach. :-\

Quote
I imagine this would be something that would necessarily determine all the fields used in a particular PVD database, and facilitate the mapping of any or all those fields to fields in a particular MC database.

What I was leading to with this half-thought is that what most users need help with is the configuration, which is largely a field mapping exercise. Maybe a plugin would be most helpful to the extent it made that as painless as possible. Starting with the premise users are able to configure PVD to get exactly the information they want, imagine this: Your plugin reads their database and sets out all the fields used. For each field, it lists the fields available in MC for mapping, or the option of creating a custom MC field—of the appropriate field type. It would revisit this mapping configuration whenever it detects a field has been added, renamed, changed in type or deleted in PVD. It might even create a default Library View—to arbitrarily display all the fields being populated from the PVD database. I think something like this would be a big help to the "average" user in configuring and maintaining the integration of the two applications.

2146
Quote
I work as a programmer, and I'd be interested in trying something like this.

I'm having trouble keeping up with you... I should think anyone willing to augment our overworked Development Division is most welcome. ;)

Excuse me if I'm clueless about such things, but wouldn't your MC plugin just access the Firebird database directly? Why would you need a plugin on the PVD side? To enable the update of PVD from MC, I suppose. Would it be possible to defer this aspect if nostra is to busy to do anything immediately on this end? Could it still be a two-way update—as long as PVD is not running at the same time? And I don't know if there are any meaningful parallels, but have you looked at Kroozbox - PVD to media theatre solution?

I imagine this would be something that would necessarily determine all the fields used in a particular PVD database, and facilitate the mapping of any or all those fields to fields in a particular MC database. Right?

2147
Quote
Yeah, I guess I can live with some extra semicolons.. Since the MPL file can be reimported, I guess I can do it all over again if those semicolons start bothering me!

You could just use two templates—one for list fields, one for other. Now that you got the export/import down to one automated step, surely it would be twice as gratifying to run two of them! ;)

Quote
I'm pretty sure they'll come around with a proper list of meta data for movies. As far as I understand, they're also working on theater view meta display view for movies.

Yes, they've made it clear they will come up with something for Theater View. But when it comes to making changes to handle different types of data (e.g., ordered lists of [name] - [role]/[function] for credits) and they ask for a list of fields needed for movies, I have to wonder if they really understand the unique requirements for movies. MC already allows custom fields, so we don't really need them to add any "standard" fields for movies. What we need are a few new field types that do not currently exist.

Quote
It'd be interesting to know how the various online databases overlap and differ wrt. meta data. Has anyone done a survey?! The intersection between these services + some of the "Good differences" I guess should be the standard for what they end up with...

Actually, my primary concern is many MC users, and the developers, may think this is what needs to happen. My experience here tells me that approach will only satisfy those who don't really care much about the information, as long as it "appears" automatically. I wouldn't bother arguing that is "wrong," as a majority of MC users may be quite happy with that. But my interest is in collecting and maintaining my own personal set of information about movies. It comes from several sources, and I'm sure it's substantially different than what anyone else is collecting. And it's the only information I'm interested in seeing in MC. My hope is more MC users will come to appreciate using something like PVD—even if just as a tool for collecting the meta data—is a better solution than any one-size-fits-all approach. Then, maybe they'll find a way to accommodate both approaches.

2148
Quote
I assume you're talking about semi colon (after replace in output script) delimited fields?

Yes. I see you just replace all commas with semi colons. I used a separate export to do that only for list fields—so it wouldn't replace commas in fields like Description.

Quote
It'll be interesting to see if for example "Director" (MC) will be changed to accommodate this.

I attempted to explain here some new field types that would be required to properly handle movie information, but there's no sign yet they "get it."

Quote
I've found a solution which works...

Well done! So, does this achieve a level of integration you're satisfied with, or do you think there might be a better solution?

I hope the 0.9.9 export function is completed/fixed soon—I'd like to give this a try. Or at least be ready when MC gets around to providing the field types we need.


2149
Quote
It's a pity because I have a setup that's relatively simple to use now.

That's slick. Would you like to share your routine? I'm also curious about how you handle the list fields.

Quote
What, would you say, is the possibility of somehow more closely integrating PVD with MC?

Except for the problem you mention, it sounds like you've come pretty close to an ideal. Even if it has to be done manually, it only takes a few minutes. Beyond that, I can only offer some conflicting thoughts...

Since PVD uses a Firebird database, there's a possibility of the data being pulled directly from the database. This would probably be child's play for MC developers, but they're not going to do it for a handful of users using PVD.

Most people willing to make the effort to collect the information are going to use custom fields, use standard fields for other uses, and have differing preferences as to how data elements are handled in PVD and MC. Accommodating all the possible variations makes closer integration more difficult. In fact, with this in mind, the flexibility of exporting to XML starts to look pretty good.

A user with sufficient programming knowledge could write an application that reads the database and writes a MPL file. The advantage of that is it could be scheduled to run at regular intervals, and MC could be configured to import it regularly. The fact that both the export and import would run automatically would make it seem the two applications were integrated.

While it doesn't seem like a big deal, there is user data created in MC (e.g., date played, rating) that has no way of being recorded (automatically) in PVD. As a practical matter, I suppose the best way to deal with such things is to import the PVD counterparts into separate fields—for comparison to the MC values. In MC you would have the choice of displaying one, the other, or a calculated result, and would be able to report at any time what needs to be updated in PVD to bring it in sync.

Regardless of the integration issues, I'm convinced MC will never have an information gathering ability of it's own that will come close to what PVD can do. So, hopefully, we can work through the integration issues. Meanwhile, I'm enjoy using PVD with my "Theater View" skin to "collect, organize and play" my movies. ;)

2150
Quote
Why?

No reason, now that I remind myself the export function doesn't yet work in the 0.9.9.4 (it needs to be updated in respect of how fields are now referenced by name). I knew there was some reason why I hadn't done this in a while. :-\  It seems to be a snail's race between that getting done, an MC improving Theater View so the data is actually worth having there.

Quote
It would be a lot of manual work, though.

It would require a text editor that uses regex, and the regex for finding and deleting the text between the first "|" and "</" of the filename tag.

2151
Support / Re: PVD Wiki is now online!
« on: March 25, 2009, 10:28:13 pm »
Quote
The Forum will be specific to PVD Wiki support and I will be sure to indicate this in the first sticky post.

If a discussion strays from Wiki support, I suggest you simply "move" it to the appropriate forum here. That is, start a topic here quoting the relevant dialog, and then post a "Moved to PVD forum" link to the Wiki topic. The obvious exception to this rule would be where the forum is necessarily being used to facilitate a discussion between users of different languages. In that case, it might be appropriate to post invitations to join the discussion to the English and Russian PVD forums.

2152
Quote
Is there a way using export templates to output multiple export records where each record represents only one file?

It's been a while since I've done this, but I have a vague recollection I had to edit the export file to deal with this. I suppose the easiest way to do that is to eliminate all but the first file reference—perhaps it's not necessary to tag all the files of a multiple file movie in MC.

BTW, what version of PVD are you using? Are you using darichman's script, or have you updated for use with 0.9.9.4?

2153
Support / Re: PVD Wiki is now online!
« on: March 25, 2009, 01:15:01 am »
You just don't appreciate how easy it is...

1. Make up a story about the logo.
2. Incorporate.
3. Offer shares to the public.

The story has to be a very good one, of course. Perhaps something about seeing the future. Back it up with a plugin that gets information about movies not yet made. ;)

2154
Support / Re: PVD Wiki is now online!
« on: March 25, 2009, 12:26:17 am »
If you were a graphic designer, you'd make up a story—and then charge yourself a $10,000 fee. ;)

2155
Support / Re: PVD Wiki is now online!
« on: March 24, 2009, 11:17:39 pm »


So is there a story behind the new logo? Is that a wave, or spermatozoon doing a somersault? ???

2156
Support / Re: PVD Wiki is now online!
« on: March 24, 2009, 05:28:28 am »
Quote
asking for a volunteer to create a like structure in Russian would be most appreciated

You see? If we had a multilingual forum, you could do that. 8)

Quote
Anybody in particular you have in mind?

Yes. That guy right there. The one who's lurking, but hasn't yet made up his mind. We've got his IP address, of course, but we should be polite and wait for him to volunteer. ;)


2157
Support / Re: PVD Wiki is now online!
« on: March 23, 2009, 07:39:57 pm »
Quote
No maintenance involved whatsoever...

That's good news. Except if users want it changed again, you can't plead "too much trouble." ;)

I don't know if the theme is at fault, it looks like there's a glitch with numbering in the "top users" module.

Quote
Also, TikiWiki fully supports integrated Forums...i.e. with full multi-language support as well.

I would be concerned forums at the Wiki would reduce activity here. But there may be use for this—facilitating communication between the two user groups. I've been looking for SMF solution, but haven't found one. I asked about inter-forum posting in the SMF Forum, and the response so far suggests that if there is a solution, it's not an obvious one. Maybe we should establish one simple forum at the Wiki—for the limited purpose of discussing all things wiki. It would serve a purpose we can't fill here, and would provide a demonstration of a different kind of forum—for consideration of options for the future.

Quote
But perhaps I should make it available to all registered users, or at least a select few.  What do you think?

I think it unlikely anyone is going to spontaneously help with something like that, just because they have permission to do so. As you point out, even if someone wanted to help, they would have to be concerned about messing up your structure. If you want help, it would probably be more effective to ask for it, then give permission and instructions to those who step forward. It would be a good task for your yet-to-be-named Assistant Editor-in-Chief. ;)


2158
Quote
I'd like that extra info too...

I figured analyzing the tag URLs would be a good way to figure out what information is there and how it's organized. See attached bookmarks file (remove the .TXT and open in browser and/or import bookmarks). I gave up after 1,555 (tag numbers up to 2,200). Still no sign of Region::)

Note many of the URLs have no information other than the name of the tag. Others have a brief description, definition or instruction. Many are to lists of movies with the tag—so the link to those can be useful. You know, when you just have to have direct link to movies made in Albania... ;)

[attachment deleted by admin]

2159
Scripts and Templates / Re: AllMovie.com (movies)
« on: March 22, 2009, 04:44:13 am »
Quote
We feel like a humiliated noob!!!

Well, don't. You solved a mystery for me. Next time I post something, maybe I'll explain, "Here a great script, but you can't have it, or even see it, until you log in!" ;D

2160
Support / Re: PVD Wiki is now online!
« on: March 21, 2009, 09:45:03 pm »
Quote
The only thing that makes me worry a little bit is that the server seems to be pretty slow

It seems "normal" to me. But it's geographically close to me and far from you. Might that be it? Come to think of it, I experience regular slow downs and time-outs with this site. Maybe having two locations is a good way to achieve a global balance. ;)

Pages: 1 ... 103 104 105 106 107 [108] 109 110 111 112 113 ... 118
anything