Thanks for the updated queries
Are you sure Year "is not automatically modified from the file timestamp if you manually put another value in there"? I haven't actually tested it, but my concern is MC may "detect external changes" (or whatever) and update the field based on a new Date Modified.
I'm not a developer, but this is my understanding (disclaimer: based more on experience than actual knowledge of what's going on under the hood!)
[Date] is filled out automatically from the file stamp on first import of any file, unless the file has an embedded tag which contains date information (eg EXIF for images, ID3 for mp3 etc). Unfortunately with video files, embedded tags aren't well supported by any media players that I know of, so any video you import with MC will use the timestamp as the [Date] field by default. [Date] is made up of [Date (Year)] etc but these can be edited independently. Typically, I clear the [Date] field altogether (to remove date and time values) and then just type in a year. The good thing is, once you clear the date field or replace it with another value (eg the release year for a movie) it's there to stay, as it's stored in the database. The time-stamp of a video file won't really change in most circusmtances - Auto-import etc will not change the [Date] fields once you've put a value in there... I've done this for years now with no issues.
The advantage of using the default date fields over a custom one is that Sort by Date etc works natively with default views/sort options.
It may seem unlikely a media file would change, but maybe the effect would be the same even if the file was just moved.
If a file is moved or renamed, MC loses it's connection to the file. If an auto-import is done or the new file is imported manually, MC will import the renamed/moved file as a new file, as it has no way of knowing that it is related to an existing file in the database. This means all metadata will be blank, apart from the default [Date] (based on timestamp) described above -- the file is essentially a new file. The exception is for files which are taggable (eg MC will detect if tagged mp3s or photos have been moved, although these already contain readable metadata so the point is moot I guess).
This affects all fields, so whether you're using the default date fields or a custom one isn't important.
Production Credits consists of HTML links—have you found a way to use this in MC?
My original idea was to use the information in this field, as is, in a track info template - which is really just a generated html page anyway. Then I remembered that you can't use the track info plugin with video (as the file needs to be playing to see it, and with video files the display will naturally be the... err video. So that was a dead end. I would like to have this information, even just as plain text without the link functionality in an extended note field... but haven't been able to come up with a way to filter out the link stuff. So it's just in there to remind me it still exists. It's ignored by default I think.
How do you use your "Links" fields in MC—particularly URL, which typically contains more than one URL?
My "URL" field from PVD only contains the IMDb link (I use a custom one for AMG) - so I have two corresponding custom fields in MC, both string. People have asked for a new field type, "Link" to be available, which would make custom fields like these launchable (either with the existing internal browser interface, or by launching an external browser window). The other thing I was trying to do was use the inbuilt Links feature (in the top right of any view) to launch the url in these fields - I didn't have any luck with this, as I was only able to get it to search, not open a direct URL. Grr... so, I guess these are in there just for storage at the moment, until I figure out how to get either of the above ideas to work!
How do you use your "Genre / Genre 1 / AMG Genres" fiield?
I still haven't decided which Genre system to use for movies (either IMDb's or AMG's). This accounts for my separate [AMG Genres] and [IMDb Genres] fields. AMG's genres tend to me more strictly defined, so I am using those by default at the moment.
I am only using the default [Genre] field temporarily, as it is bizarrely a string field (not a list)
but at least displays in the current File Info panel in theatre view. Once the file info panel is customisable, this will go away for good
I have detailed my Type and Genre system elsewhere... briefly I have two type fields [Type 1] & [Type 2] and three genre fields [Genre 1], [Genre 2] and [Genre 3] on which my entire media library is based (not just videos). [Genre 1] is my broadest level, and is currently the only level I'm using for movies (although I was thinking of mapping AMG's type field to [Genre 2], as it's really a more specific classification of genre)
[Type 1] and [Type 2] are used as filters for creating all of my view schemes etc. Eg. [Type 1] might be Film , with [Type 2] as Feature Film, Trailer, Soundtrack etc. Both levels are lists so a soundtrack will have a [Type 1] of Music;Film and a [Type 2] of Film Soundtrack. This allows me, for example, to see all media related to a particular movie (music, pictures, sheet music, trailers, special features, screenplay etc as well as the movie itself) when I click on a movie name. Alternatively, I can limit a view to "Feature Film" which would only show me the actual movie files themselves.
It's not clear to me what you think should be included in the default field configuration. I believe we need to be careful not to overwhelm the new user (to PVD, as well as the plugin) by including too many queries they are unlikely to use.
I do not think mine should be the default configuration. I think we should have a default which contains
only the default fields which PVD can grab (ie without any customisation). As you say, exemplary custom field queries could be included at the bottom of the plugin page, ignored by default. This should be the default config file used by PVDImport on a new install.
I also think it's worthwhile including a second config file in the installation folder with an exhaustive list of fields which users can select from. After all, it's easier to delete the ones you don't want than create a million new ones. If this is done, we do need to recognise that no system is the best system and, as you say, people have different preferences for both sources of information and field mappings.
I've made my import plugin (AMG/IMDb) and PVD settings available, as has Rick, so advanced users can replicate our setups if they want to, but I suspect most users will prefer to do things in a way which best suits their individualised needs. Provide the option - a quick, easy default setup which requires little to no customisation, and an advanced option... which would probably require some sort of hand-holding through how the fields need to be set up/imported...
I'd like to post a "MC Users Guide to getting information from PVD using PVDImport - This could include all the steps you mention. I think the key issue is field mapping and this occurs at two levels (Internet Source > PVD ... and.... PVD > MC). There is plenty of opportunity for confusion, especially if the user is overwhelmed with massive spreadsheets/config fields with every conceivable field. I have documented my setup with screenshots etc as well, so it shouldn't be too hard to put something together... time is the issue though
Some feature suggestions, although I have no idea whether the plugin implementation in MC makes these possible or not (or how much work it would take on raldo's end
)
- I think it would be nice if the plugin could detect if fields listed in the McField column are present or not. If test mode could detect this and highlight the fields in red or something, this would tell the user they need to create the corresponding field in MC.
- I like Rick's idea of also showing what field type it is - would assist greatly in mapping fields appropriately
Did I read something about a new import facility? If so, will this have any impact on the plugin, or user's perception of it's usefulness?
No, the change is related to importing files, not metadata (basically detecting folders suitable for import based on a few settings).
Pvd will still retain its usefulness, and will for some time, I'm sure...
Author
Topic: Personal Video Database Import plugin - Test log (Read 76947 times)