[watzen]

copy does. just fine.

I find it easier to do it within the xbmc gui. Actually, rescraping info and thumbs/fanart is not the worst part of a db-loss. What I don't like redoing is marking movies/shows watched/unwatched.

possible solutions(not without cons, just brainstorming):
* suffix/prefix to filename/foldername
* special tag <playcount><user>3</user></playcount> in .nfo
* output [moviename].playcount file with <user>[count]</user>
* have export feature export playcount if profiles=<1
* have scraper read playcount from .nfo if profiles=<1
... feel free to add

[mkortstiege]

AFAIK the playcount has moved to another table recently which won't be touched on a refresh. Please correct me if i am wrong

[watzen]

Is that perhaps the file table as jm stated earlier in the thread?, how about we touch that on a refresh aswell

[xexe]

AFAIK the playcount has moved to another table recently which won't be touched on a refresh. Please correct me if i am wrong

the main problem with the one dbase approach is when something breaks (which admittedly happens pretty rarely now) users are recommended to wipe the whole thing and start again.

This is obviously inefficient since the watched table in this instance would liekly be 100% perfect even if some other table was horribly corrupted.

Thats probably the real crux of the problem and certainly one driving factor in the creation of these external tools.

[RockDawg]

the main problem with the one dbase approach is when something breaks (which admittedly happens pretty rarely now) users are recommended to wipe the whole thing and start again.

This is obviously inefficient since the watched table in this instance would liekly be 100% perfect even if some other table was horribly corrupted.

Thats probably the real crux of the problem and certainly one driving factor in the creation of these external tools.

Also, ease and convenience, not just backups. Like I mentioned earlier, most of us are at the comp to rip/copy/download the video file anyway. It's just as easy or easier to to run Media Companion when I'm done and know that all my files are now correct and whenever I scan them in at any given box they will be right.

Sure, I could copy the db, but that's not nearly as convenient, especially when you have multiple boxes around the house. I'd have to go out of the room and scan in the new movies on one of my HTPC, go and power on the other Xboxes, come back and copy the db to each machine, and then go power down he Xboxes when I'm all done. It's much easier to have nfo file that are correct and just update the library at any given machine the next time I use it.

As for a backup, I don't think anybody is saying you have to restore backups often, but at some point you probably will, and it's hard to backup the db after a hard drive has died. Also, if and when the devs redo the db (as has happened twice before in my years with XBMC) a backup copy of the db is useless. The only thing that serves as a decent backup in that case are nfo files. Sure, you can re-scan everything back in without the nfo files, but not with the watched status maintained and it really sucks having to update the watched status of 100's or 1000's of movies.

[xexe]

So your concern is that you will lose your watched status between the time you have backed up the database and the time the hard drive dies. If you have multiple xboxs surely that means they would all have to break for you to lose the database completely.?

[RockDawg]

I'm not going to keep going on about this with you. If you truly read my posts, you would see I have multiple concerns. You conveniently ignore the whole "what if XBMC changes it's db as it has done before?" and "It's more convenient".

You don't use nfo's and you make it obvious you don't ever plan to. Therefore this doesn't affect you or your multi-user environment. Why are you going on so? I, and obviously others, found keeping the watched status in the nfo very handy. What's the problem?

[xexe]

In all fairness all i can see is "I like doing it this way please change XBMC".

You are correct to point out ""what if XBMC changes it's db as it has done before?"" concern this is something I have raised myself. XBMC devs should not change the database in such a way as to require the userbase to re download all their scrape data. To be fair though this has happened extremely rarely (but it has happened).

But we are not talking about scrape data we are talking about "watched status" data which is a different part of the logic.

Edit: For each user profile within XBMC is there a unique id against it. If there is then the nfo could contain a tag that references that ID. this way you follow the multi user nature of XBMC with the non multi user tools like Media info

[david81]

Edit: For each user profile within XBMC is there a unique id against it. If there is then the nfo could contain a tag that references that ID. this way you follow the multi user nature of XBMC with the non multi user tools like Media info

I was thinking something like this myself.

Perhaps a "User" section of the nfo that could contain user specific data. In a multi-user environment there could be a section for each user with information that would take precedence over default data. This could be used for preferred thumbs, fanart, watched status, etc.

Along those lines, I assume that many multi-user environments may involve children. Could this section also contain a tag to restrict access to certain movies? Say you set up all 500+ of you movies, but you want to remove any R-rated films from the view of the kids account.

Not sure if my logic circuits are working correctly today, so feel free to let me know if I'm way off base here.

[ashlar]

In all fairness all i can see is "I like doing it this way please change XBMC".

In all fairness, I don't. I see legitimate concerns being raised (not only mine).

Edit: Would an option to backup the whole database (including fanart, thumbs, posters, etc.) be easy to implement?

[xexe]

You can do that already by simply backing up the userdata folder like any other folder

[smcnally75]

You can do that already by simply backing up the userdata folder like any other folder

But this can't be done from within XBMC, can it?

[ashlar]

You can do that already by simply backing up the userdata folder like any other folder

Shouldn't we be striving for a "built-in experience"? Furthermore, didn't you state that "XBMC does everything you need"?
It doesn't. Currently it does not offer a complete backup solution from within the program. AFAIK, that is.

[xexe]

http://wiki.xbmc.org/?title=Filemanager

Looks built in to me.

[jmarshall]

You cannot export information and then import it back at a later date without losing the changes that occurred between these times that wasn't exported. It does not matter what form that export takes.

There is no solution to this problem, other than always exporting with every change, which is not an option at present.

If db < nfo, update, else don't touch seems reasonable to me. It addresses the problem in a meaningful way.

For multi-profile users it's simple: Do not write the <playcount> field to an nfo file.

As for export, IMO the best option is for:

1. Single xml output to save playcount information.
2. Individual nfo files should not save playcount information.

This gives a valid way to update your db if the db update can't be performed automatically (we'll change the routine to always backup the db before attempting an update, to guard against dropped db's due to update code gone wrong).

If we absolutely need it, then we can advancedsettings.xml number 2 above, but I don't see a valid reason for doing so at present.

Cheers,
Jonathan