I'd be happy to provide any other fields, but I'm reluctant to start setting a "standard" ahead of what MC supports.
It's not really a matter of "supporting" fields. MC handles fields added by the user equally well. JRiver tries to be helpful by adding stock fields it believes users may need. I import all my video data from
Personal Video Database. More than half the fields used are custom fields—either because there is no equivalent stock field, or the one provided is of the wrong type (e.g., [Genre] is not the list field required). It would actually be easier if they would just add the stock fields needed for essential program functions, and then make it clear to users they may add any number of any type of field they require.
I think these things warrant some discussion about how the information might be used in MC before you consider further development.
By this I meant discussion between yourself and users who are interested in this. JRiver doesn't need to (and won't) pronounce any revision to "standards" to accommodate such things. It's up to you to determine what method serves users best and advise them of the fields to be added to support the service. In making that decision, you should recognize it will generally be best to provide more information than less. And unless you're really sure everyone wants the data to be put in a stock field, it may be better to have them use a custom field anyway. Users can ignore data they don't need, and have all the power of MC at their disposal to manipulate the data that is provided. For example, if you were to provide Actors\Roles in a custom field instead of Actors in [Actors], I could convert that to just Actors, use it as is in a nested list field, or reformat it (e.g., Actor • Role) in a regular list field.
Also, JRiver has already provided the ability to relate a field to [Series]. That doesn't mean they're dictating any standard. It's up to the user to decide whether that's better suited to their circumstances and preferences. So for those fields, you don't really have any choice but to arbitrarily set the field name. If they want the data, users will have to create that field. But they can still decide the field type, assign a display name they find more suitable, or use an expression field to convert it into a different form.
BTW, after a few days, this seems to be working very well. I've got it working with µTorrent, but there are still a few things not yet clear to me...
- I'm not sure if the post-processing (renaming and moving files downloaded by µTorrent) is happening automatically, or only because I'm tinkering with Sick Beard and doing things like Force Full Update.
- Once a sidecar file has been created, I'm not sure if or how it gets updated from the Sick Beard side (e.g., like when a few days after the release date, more information is available). In testing this, I've had to delete the sidecar file before Force Full Update will create another one, but maybe that's just because it knows there has been no change (I haven't attempted to find one where the information at theTVDb has in fact been updated). And, similar to my first point, even if updates do work, it's unclear to me whether or not they happen automatically.
Regardless of those questions, it does seem to be a very good solution for managing episodes. I can continue to use PVD for series information, but this would be an acceptable complete solution for series if it got that as well.
Author
Topic: NEW: MC16 and Sickbeard Integration (Read 21784 times)