English > Scripts and Templates
Export to XBMC
rick.ca:
--- Quote ---yep - you can export .nfo and poster next to media but you have to tell PVD where to save the file. (or it will save to last location)
--- End quote ---
No, I don't think you're understanding me. I said, "the whole point of a nearfiles function was to create files "beside" the media file. In other words, typically, the exported files have exactly the same pathname, but a different extension."
The following template, for me, outputs an NFO file with the same pathname (but with an NFO extension) for each movie selected. This is exactly what I would expect a nearfiles function to do.
--- Code: ---%OPTIONS%
nearfiles=".nfo"
%OPTIONS%
<title>{%value=title}</title>
<year>{%value=year}</year>
--- End code ---
I also said I thought we would (in some release of 0.9.9.x) be able to export posters in exactly the same manner. The following template is the simplest I could come up with that would export posters "beside" the media files ("poster.txt" is only there because it seems something must be specified for the text output).
--- Code: ---%OPTIONS%
nearfiles="poster.txt"
imagenameformat="%t% (%y%) poster%ext%"
%OPTIONS%
{%value=poster}
--- End code ---
The posters do end up in the same directory as the media files. But while imagenameformat might make the filename similar to that of the media file, it's not likely to be the same. If it needs to be exactly the same, I don't see any way of doing that.
So the problem, if any, is not with nearfiles. Unless I'm failing to figure out how it's done, the problem is the lack of a function that will to the same thing with image files. From what I've seen, I suppose the same thing could be accomplished if variables for path, filename and full pathname could be used with imagenameformat.
Now, if I put the two templates together, I get this...
--- Code: ---%OPTIONS%
nearfiles=".nfo"
imagenameformat="%t% (%y%) poster%ext%"
%OPTIONS%
<title>{%value=title}</title>
<year>{%value=year}</year>
<thumb>{%value=poster}</thumb>
--- End code ---
...which puts an NFO file (incomplete, of course) "beside," and a poster "almost beside" the media file. While the poster filename is not exactly the same as the media filename, your NFO file points to it with the <thumb> variable (as I've illustrated). Is this not good enough for XBMC?
CAD:
tks Rick.
you are right.
--- Code: ---nearfiles=".nfo"
--- End code ---
This works a treat when file path is populated. :D
i initially never tested with db entries that had this field populated. (and got wierd filepath errors)
after nostra made his changes i assumed a path had to be added for function to work. now i know better what nearfiles does.
THANKYOU. :)
do you know what the default behaviour is if filepath field is not populated or it can be changed??
as a fallback if filepath is is not populated or wrong, would it possible to have files exported to say export folder under preferences/folders and title or something similar as fuile name. pls.
i now have better understanding of how nearfiles is working. i can modify script. 8)
just need to get credits working now :'( . Then i can strat on xbmc export for tv eps :D
stay tuned ;D
rick.ca:
--- Quote ---do you know what the default behaviour is if filepath field is not populated or it can be changed??
--- End quote ---
I'm sure it does nothing at all. The only reason I can think of that you would not have File path filled is there is no media. This is a situation I'm very familiar with. Most of the movies in my database are ones I've seen over the years—I don't have media. My media manager (J. River Media Center), however, only records information about media files. I imagine XBMC is the same. The solution is simple. Just create a dummy file for each movie—named in the same manner as any movie file, but with a different extension, like LOG. (Export a list to Excel and use that to create a batch file to create the dummy files.) I configure both PVD and MC to recognize LOG as a valid file type, and both happily find import these files. I then use PvdImport (a MC plugin that pulls information directly from the PVD database) to import PVD data to MC.
If you're just concerned about excluding moves for which there is no media, filter them out before running the export. I doubt it matters, however. Those without files will just be skipped.
I think it's now nostra's turn to help you with the credits. ;) I hope he'll also tell us if my understanding of how the exporting of posters works is correct.
deazo:
Hi all,
correct me if I'm saying something stupid but from what I have read of your post Rick, you're looking for a way to have the image file saved beside the movie file automatically.
With my test config this actually worked perfectly using CAD's script.
I ended up with posters files right next to my .avi file with the same name.
Unless you meant other types of images? (i.e. not posters?)
rick.ca:
--- Quote ---With my test config this actually worked perfectly using CAD's script.
I ended up with posters files right next to my .avi file with the same name.
--- End quote ---
CAD's scripti includes imagenameformat="%t%%ext%", so the posters are named [Title].jpg. That's fine if the movie file is named [Title].avi, but that's not necessarily the case. I want it to be named [filename].jpg. And as a stand-alone function (i.e., not used with nearfiles), I would like it to be able to do [full filepath].jpg (I'm using ".jpg" just to be clear—it would actually be the result of %ext%).
I should point out, I have no particular interest in XBMC. I would like to see a function that works well generally. I think saving an image "beside" a subject file is a common requirement—just as doing so with a text file is. It's also just a good file management practise. What I was expecting was something like "posternearfiles" where posternearfiles="" would result in [full filepath].jpg, posternearfiles="%t" (%y%)%ext%" would result in a renamed file in the same folder, and posternearfiles="C:\My posters\%fn%%ext%" would put them all in one folder with the same filenames ("fn") as the movies.
I suppose this might be generalized to imagenearfiles where there would be a parameter for specifying the image type. I don't know if there's any interest in exporting screen shots and covers, however.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version