[dylanh724]

Man this isn't in the wiki or any article I've seen -- I'm going crazy trying to find this ..

[wrxtasy]

Exported to the locations you used what you connected your video shares to your Library via XBMC > Video > Files > Add Videos.

This can span multiple location / drives / networks if you have scraped all your videos and added them to the XBMC Library.

[olarf]

Good question! Kodi ask where you want to safe the complete one but for the separated ones it just start and save them wherever. This bug should be fixed, it is a final release now at least.

[DaVu]

This bug should be fixed, it is a final release now at least.

This is not a bug....and it wasn´t one

This is normal behaviour. Normally, if you add your sources, the files are in folders. A folder structure can be look like this:

D:\movies\avatar\avatar.mkv
D:\movies\187\187.mkv
and so on

If you export your library to sperate files, it will safe those nfo-files under the folders matching to the video beside the *,mkv files (or whatever container you use). So it looks like this:

D:\movies\avatar\avatar.mkv
D:\movies\avatar\avatar.nfo
D:\movies\187\187.mkv
D:\movies\187\187.nfo

If you decide to export the fanart and the poster as well, it will look something like this:

D:\movies\avatar\avatar.mkv
D:\movies\avatar\avatar.nfo
D:\movies\avatar\poster.jpg
D:\movies\avatar\fanart.jpg
D:\movies\187\187.mkv
D:\movies\187\187.nfo
D:\movies\187\poster.jpg
D:\movies\187\fanart.jpg

This is normal behaviour since XBMC 9.x Camelot. So, olarf, stop talking about issues or bugs, if you don´t know how XBMC works , tbh

If you don´t have your movies in sperate folders matching the movie name, the nfo file, which is created by exporting the library, will be safe in the home folder of the movie files

If you got a network source added (from a NAS or another PC using NFS or SMB), the files will be exported to the source directly, either in the homefolder of the movie files or in the seperate folders matching the movie file names (depends on your structure),

Greetings

[scott967]

If you export music library, files of the name "artist.nfo" will be created in the parent folder to the one containing the music media files. That means you will only have one artist per album when you export.

scott s.
.

[dylanh724]

Freaking a.. so how do I import 100's of random "tvshow.nfo" files .. ? This seems archaic if it's not a bug

Or wait... import library is looking for an XML, not nfo's... so now im confused

[DaVu]

The import of those nfo files is done by the scraper....

Lets imagine you have a NAS and one client which gets its data from there, you have a similar folder structure like i mentioned above, you let the scraper do all its work and have all infos properly scraped. Then you export the info to seperate files. The nfo-files will be saved at the locations I said in the posting above (depending on he stucture).

Then you get a new htpc kodi client and don't want to scrape all those 135873 movies stored on 1000TB NAS online again. So you have to set up the source matching to the path to your NAS and select any scraper you like. Even if a scraper is selected (you can set i to nfo only) kodi will first check if an nfo file is available and add the info from this file to your library...done.

Greetings

[Ned Scott]

As David said, the NFO files are used when you scan files into the library. The "Import" button is a bit confusing because it is only used for "single-file" exports. A library scan is needed to import multi-file NFOs.

[upuv]

I just performed an export. I have to say this design needs a few changes. Nothing earth shattering.

A export should not intermingle with the content. The export files are simply not needed for the normal operation Kodi. This can be solved very easily with a simple addition to the export paths for each library.
I'll use the linux example:

If I have content in a Movie library Root of:
/media/Video/Movies
And I have for what ever reason broken up my Movies in folders start with the first letter of the Movie Name. So I have
/media/Video/Movies/A
/media/Video/Movies/B
/media/Video/Movies/C
/media/Video/Movies/...

The current export multiples files option dumps .nfo and .jpg files into the Folders of A B C and any sub folders if I have content in them as well. Right along side the movies them selves. All of a sudden in a regular OS listing of these folders I now have many times more files in the folder. Making it much harder locate individual movie files for what ever purpose I have.

Also this has some rather nasty problem with file permissions. Every location must be writable by kodi. Every single folder now must have write permissions. If some don't then you get a partial failed export of the library. ( Note I intentionally change the perms of my folders so that they can't be written to. I also create sub folders for extrafanart and extrathumbs that are writable. The reason I do this is so that if I get a ransom malware encryption virus I won't lose my content. The content is readable so are master folders but not writable. )

If however the export process did this instead.
1. It creates the master export folder of
/media/Video/Movies/.export/
2. For each piece of content being exported it creates the appropriate sub folders under that path.
/media/Video/Movies/.export/A
/media/Video/Movies/.export/B
/media/Video/Movies/.export/C
/media/Video/Movies/.export/D
3. The export process no writes everything under the tree .export.

Now this structure can be replicated with all the various content roots you add to your kodi install.

This solves a number of issues.
1. Disk Clutter
2. Ensures a complete backup is possible.
3. Makes it easy cleanup if so required. Only 1 simple delete.
4. Much easier to document.
5. Enables future changes to export contents thus more than just .nfo and .jpg files could be possible.
6. Enables an estimate of how long it will take to import as folder size and IO speed can allow the estimate to be calculated.
7. Reduces the risk of accidental content loss by those that wish to clean up a library export.

[scott967]

I can see your use case, but I don't see it solving general "issues". ISTM most of what you want you can accomplish with a single file export.

scott s.
.

[upuv]

The major problem is that all the thumbs and extra content get dumped. A Single file dump does not include .jpg for example.

Because there are currently other file types in the multi export and in the future I would expect this to grow in complexity I would promote the idea of a new location sooner than later. Before the code gets to spagetified.

[trogggy]

The whole point of 'Export to separate files' is that the data is exported to sit with your media. That way you can move media about as much as you want, re-scan and still retain your data.
It's not hard to delete all those exported files via command line if you really need to.

There's currently a problem with exporting to a single file (with artwork, I'm pretty sure it's referenced in the wiki) - export to separate files works exactly as it should.

[upuv]

The whole point of 'Export to separate files' is that the data is exported to sit with your media. That way you can move media about as much as you want, re-scan and still retain your data.
It's not hard to delete all those exported files via command line if you really need to.

There's currently a problem with exporting to a single file (with artwork, I'm pretty sure it's referenced in the wiki) - export to separate files works exactly as it should.

Which is why I said put the dump at the "root" of the library. So that a scan can pick it up.

Granted I made the assumption that each device will choose the same root folder from the sharing source. I assume the reason for the disk spam on multi file export is to accommodate client that do not choose the same root folders on the share source for the library selection point.

[trogggy]

The whole point of 'Export to separate files' is that the data is exported to sit with your media. That way you can move media about as much as you want, re-scan and still retain your data.
It's not hard to delete all those exported files via command line if you really need to.

There's currently a problem with exporting to a single file (with artwork, I'm pretty sure it's referenced in the wiki) - export to separate files works exactly as it should.

Which is why I said put the dump at the "root" of the library. So that a scan can pick it up.

Granted I made the assumption that each device will choose the same root folder from the sharing source. I assume the reason for the disk spam on multi file export is to accommodate client that do not choose the same root folders on the share source for the library selection point.

You can't make that assumption. People move media around within their folder structure - there are often good reasons for doing so.

[jjd-uk]

I assume the reason for the disk spam on multi file export is to accommodate client that do not choose the same root folders on the share source for the library selection point.

No it's because most of us find it easier to have one folder containing both the video file and all it's metadata so everything is in the one place, your system would introduce lots more complexity to the code. In addition when it comes to removing the movie, instead of a simple 1 folder deletion it would require 2 folders to be deleted.