Extract Movie Video Database to seperate files
#31
For me saving the file to media location with media name would be fine

but for those unable to then I can see how a few problems may be encountered.

If for example a person wants to keep all of these nfo files local to the xbox - including those that are for files located on a network then this would complicate things greatly.

I think experimentation may be the key here

Once a system of any kind is in place then people will more easily be able to see the problems and possible solutions.

However

For rar files with multiple video files (Messy - Do people actuallly do this)
then how about appending something i.e

rarfilename-1.nfo
rarfilename-2.nfo
rarfilename-3.nfo
rarfilename-4.nfo etc

or allowing xml nfo files to contain more than one item eg

<movie>
<FIlename>content1.avi</FIlename>
</movie>

<movie>
<FIlename>content2.avi</FIlename>
</movie>


For VIDEO_TS then the only way I can think to do it would be to use the parent folder as file name.

For longfilenames on a remote server with the nfo stored local then another table will be needed again (file id) ie lfn001 and (full file name) ie longfilename.avi etc this would remove problems of similar filenames being truncated to the same name

It would be best in my opinion if files were not automatically overwritten at the very least the user should be asked - with perhaps the options - replace all/replace none

As i said above tho - Experimentation may be the key here
Reply
#32
so whatever happened to this feature?
Catchy Signature Here
Reply
#33
Its still sitting on jmarshalls computer waiting to be finalized would be my guess
Reply
#34
Tongue
Catchy Signature Here
Reply
#35
jmarshall Wrote:1. Where to store said files. Should they be next to the movie (most useful for users?) or in a different folder (not so useful - think filename conflicts and so on).
All files should be stored next to the video.
If the share is read-only the user can provide an alternative writable share or have them saved to the same directory structure inside a rar file on the xbox which they can then extract to the share.
Quote:2. Should we prompt for overwrite, or ignore (think backing up when you've just added 10 movies to a 1200 movie collection!)
Wouldnt all nfos need to be read to check for tags anyways?
Would checking then writing as required take that much longer if reading all nfos is required anyways?
Quote:3. Should this functionality also be contained within an optional setting "save nfo file on scan"
IMO Incorrect tagging is far worse than no tags.
Individual movie lookups would solve the updating '10 of 1200 movie collection' situation above. If implimented the looked up tag information should be displayed on screen and a dialog or onscreen button be shown to write .nfo. This gives the user a chance to check the data before it is written.
Full scans are so unreliable I wouldnt give the user the option.

Couple implimentation questions

if a .nfo exists but no tag data is contained inside where is the tag data written? Append to end of the file seems ideal.

I assume your exporting thumbnails as well?
Reply
#36
Is it possible to save a part of a database export as nfo-file?

I have for all my DVD rippes a nfo file with the url of the movie in the ofdb.

For some movies I change the information due to export the database make the changes in the xml and import the xml to the database.

I try to save a part from the database export in a nfo-file for future update of the database information but it didn´t work.

Is it possible, and which scraper must I choose?

Thanks
Reply
#37
http://xboxmediacenter.com/wiki/index.ph..._nfo_Files
Catchy Signature Here
Reply
#38
Currently my nfo files contain only the IMDB links. Although.... if JM impliments his desktop I'll be exporting all that to files and saving them in place of the IMDB links.
Image
Reply
#39
I would also really like to see this implemented. Can it be implemented with "save to media location" as the only option? Then, after more people see how it works, we can work out the problems with saving to a different location.

On the different location problem:
How about parsing the 'filenameandpath' field of the DB and saving to chosen_path\parent_folder\media_file_name.nfo ? The parent folder would need to be created under the chosen path and the .nfo file put there. Then the VIDEO_TS.nfo files would not overwrite each other.

buzz
Reply
#40
yes but what if the media location is not writeable?
Catchy Signature Here
Reply
#41
Quote:yes but what if the media location is not writeable?

Then the feature won't work, which is the same thing that happens for media playback when someone can't get their SMB shares configured.

Of course, if the XBMC developers had decided to allow the issue of "what if the shared media location isn't correctly configured" be a show stopper, none of us would be enjoying XBMC.


I'll be delighted with basic functionality of this feature. I'm sure that as more interested people begin to use it and provide useful feedback, it'll mature.


Would it be unreasonable to check for the presence of an existing .NFO prior to creating a new one and check after creating the .NFO to see if the file exists?

If an old one already exists, perhaps it could be renamed to a .BAK, an exception logged, and some indication that the log file should be checked presented to the user at the end of the process. Or it could just overwrite any existing .NFO. Or it could skip creating an .NFO. It would be nice to set the default behavior prior to running the process.

If the .NFO doesn't exist in the target location after being created, the feature should report the error to the operator, either as the .NFOs are being created, or perhaps at the end of the process in a summary log file.


Of course this sort of thing would slow down the process, but this process will probably only rarely be run against large libraries without .NFOs.
Reply
#42
Did you actually READ the thread before posting? JMarshall is the developer specifically working on this feature and he specifically has said he will not release a patch until it is fully implemented. He posted here to help figure out how the case handling should work. See pages 1 and 2...
Catchy Signature Here
Reply
#43
Quote:Did you actually READ the thread before posting?
Yes. I read every new message in this thread as well as most of the threads in this forum (as well as some others). However, I didn't read the thread in its entirety immediately prior to posting a reply. This thread has been running since late October, and I replied to the most recent reply and tried to speak to what I remembered to be some unresolved issues. My reply wasn't intended to be a comprehensive response to all the issues raised in the thread.

However, having just re-read the thread, I don't feel that my comments are out of line.

JMarshall has expressed concern about handling the "Can't write to the target folder" concern previously, as have others.

As of the middle of November, JMarshall hasn't indicated a final decision about "prompt for overwrite, or ignore".

I suggested a method for addressing your concern as to whether a particular target for a particular .NFO is writable (it's possible that two different folders within the same share would have different permissions set) and a procedure for dealing with the "prompt for overwrite or ignore" issue (set behavior prior to execution and log activity for later review).

Neither of these issues have been closed in the thread.


According to JMarshall, there's another issue to address. In his last response in this thread, he says:
Quote:The problem with rars' is 2 video files in the same rar. Saving using XBMC's internal RAR path is useless to the user.

The problem exists only when saving the .nfo files to somewhere OTHER than where the media files lie. Come up with a solution for that and we're in business
.
SleepyP, I'm sure you'll be delighted to know that I have nothing on the .RAR issue.


Jezz_X suggests that "buyer beware" is a reasonable position to take. XBMC has always been made available as a "buyer beware" product. I'm not going to speak for the community, but I will speak for myself and those I know who use XBMC and say that it's o.k. that some features are rough around the edges, and we don't expect everything to work under every possible scenario (for example putting .NFO files in .RARs with multiple videos or non-writable targets for .NFO files).
Reply
#44
I know this thread has been dead a couple of weeks and I don't want to harass anyone while they are working on more important stuff, but this is a feature I would REALLY like, especially for networked drives.

I'm envisioning a fairly simple sorting program that will create complete NFO files and copy thumbnails.

Ideally, at least for me, a user would copy over his database and thumbs folder from his XBox, run the program, point the program to the movie folders and let the program rename thumbs and create nfo's and drop them into the same folder as the movie / TV show.

This would save me a HUGE amount to time in re-scraping my files after a database crash.

As an example, my videos database is over 10 meg now, even with the new database compression and my Thumbnails folder is over 60 meg. I've got over 1000 movies and about 4000 TV episodes. Last time I had to start over, it took me two weeks, and I still don't have everything correct.
Reply
#45
Me too! Smile
Catchy Signature Here
Reply

Logout Mark Read Team Forum Stats Members Help
Extract Movie Video Database to seperate files3