Recommendations regarding Text Data that is Not Plot (eg, Bonus Feature descriptions)

[funwithmedia 352]

As I'm transitioning from my old (non-Emby) arrangement, I'm noticing I've got about 500 records of textual data regarding associated bonus features for given videos.

 

A lot of these are indicators of Audio Commentaries present on individual TV episodes. I haven't begun my experiments with seeing how Emby handles TV episodes, or additional audio tracks, so I don't know yet how that might impact things.

 

But a number of these items are listing the bonus features present on my VIDEO_TS folder rips (ie, the original DVD structure, menu and all). I know that many people advocate re-ripping everything to individual files. I may do that in a few instances regarding my movies, and I'm definitely considering it for my TV episodes (I can see the most benefit to that). But in general I plan to leave most (if not all) of my movie VIDEO_TS DVD folder rips as-is (in part because it would take quite a bit of time to segregate out each bonus feature to it's own file).

 

So I'm trying to figure out where in the existing metadata structure I could place this textual data regarding DVD bonus features, and thus far I'm not seeing anything that makes sense. Overview and Short Overview seem to be the primary largish text fields, and those don't seem like an appropriate place for this data (unless I append it to the end, and lock the Overview field from further updates, but I'm not crazy about that route).

 

Any thoughts on this, or is there anything in the pipeline that might work for this?

[Luke 36992]

Hi, right now the Overview is your only option I would think.

[funwithmedia 352]

Thanks for confirming. That is too bad, but very understandable.  I may experiment with appending my "Bonus Feature" data to the plot data (which I already have in my database from IMDB and/or other sources), and then lock the Overview field so that it doesn't get overwritten.

 

Do you know if locking Overview also locks Short Overview and Tagline? I could understand if it does. But the irony in this instance is that I'd like to benefit from any metadata Emby would pull from the internet for those two, while protecting the Overview field. My hunch is I won't be able to do both, but it depends on what the Overview Lock covers.

 

An additional thought I've had is that I may also (in conjunction with the above) export my Bonus data into a custom field in the XML of the NFO file. I won't be able to do anything with it currently, but if at some point in the future Emby evolved to have a metadata field where that data would make sense I would have a better chance of programmatically parsing through all of my NFO files to extract that or copy it to the appropriate XML field to get picked up by Emby. My recollection is that Emby will ignore XML fields it doesn't recognize.  But wait, it just occurred to me that if I make any edits in Emby, it will overwrite the local NFO file and Emby probably doesn't have any way of storing the XML field data it doesn't recognize, and thus no way of writing that data back to the NFO upon a record change. So, that's probably a bust (though please correct me if I'm wrong!).

[Luke 36992]

No, it just locks the main overview.

[funwithmedia 352]

Excellent! That's promising then.

 

What about the other question: I just did a test of creating a custom XML field in a NFO file, and then did a manual Refresh of the item in Emby (which, per my settings, results in Emby writing data to the NFO file), and the custom field and data was preserved (though moved to the end of the XML file, which is totally fine, and actually helped visually confirm that the file had been written to). So should any custom field data in my NFO XML be safe (baring unexpected bugs, etc.)? ... Well, I just was testing something for the below, and it looks like my custom field is gone now...

 

A few other questions: My Bonus feature text data uses some rudimentary html (mostly just <br> tags for line breaks). How might those get handled (in general) in the various interfaces of Emby? I just did an experiment with adding some of that content to the Overview field in my NFO file (and I enclosed it in a <![CDATA[ tag, so as to keep the XML valid), and it did come through safely to Emby Theater. Any thoughts, recommendations, cautions on this route?

 

One thing I did notice is that in a test before that one I made a change first within Emby of adding a few <br> tags, and those actually were not saved to the NFO. But then I just did another test now and I see that regular Carriage Returns are saved to the NFO file, so maybe I should just convert my <br> tags to Carriage Returns (or probably CRLF, Carriage Return Line Feed), and skip the <!CDATA[ tag altogether.  Thoughts, recommendations?

[funwithmedia 352]

Crap. I just checked in Emby Theater (Windows Desktop) and the CRLF is not honored/displayed in that currently (I was testing via browser for the prior test) -- it all is just one continuous line. Might that be something that will change though (as the data is still stored in the Overview field with CRLF's)?

[Luke 36992]

Html is not allowed in the overview contents. You could try the carriage return character.

[funwithmedia 352]

Cool, will do.