[DJVege]

Thought I'd post a thought I had up for discussion.

One issue with exporting your library to separate files so that the info is stored with the media files is that you need to do this regularly or it will be out of sync.

What about an option whereby after watching/listening to media (whether you stop it halfway or finish it), xbmc will write the data to the separate file there an then. What delays/speed issues might implementing this introduce? Obviously xbmc will be updating the database AND be writing this out to file(s). If it does introduce speed issues / delays, is it possible to run it in a separate thread so that the user can continue to use xbmc?

I see possible issues with starting and stopping multiple files in quick succession (depending on how long updating the library and external files might take)....

But anyway, thoughts?

[AnalogKid]

Thought I'd post a thought I had up for discussion.

One issue with exporting your library to separate files so that the info is stored with the media files is that you need to do this regularly or it will be out of sync.

What about an option whereby after watching/listening to media (whether you stop it halfway or finish it), xbmc will write the data to the separate file there an then. What delays/speed issues might implementing this introduce? Obviously xbmc will be updating the database AND be writing this out to file(s). If it does introduce speed issues / delays, is it possible to run it in a separate thread so that the user can continue to use xbmc?

I see possible issues with starting and stopping multiple files in quick succession (depending on how long updating the library and external files might take)....

But anyway, thoughts?

I can see merit in this, but:

I think XBMC's fundamental philosophy is that the database is king. The NFO files are an aid to scraping / importing and useful for export, but there are 'supplemental' to core XBMC and that you already have the lastest information saved and stored... in the database. There's nothing to 'sync' with.

All of that said, I suspect I'm a little like you:
I don't trust the database. I wipe it regularly. I treat my NFO files as master! I keep my fan art and my thumbs in the highest resolution I can and let XBMC 'pull them' from my media. So ideally, I'd like my NFO files always up to date. This really is kinda like treating the NFO files as the database! (which is wrong).

The reason I behave this way (as many others do) is that I'm never 100% sure WHAT xbmc is going to do with my files. If I scrape a movie cover, I don't always know what resolution that image is, and I can't be sure of what XBMC will do to the image file if I 'export' my image files... will it reduce the resolution? will it re-encode an already lossy jpg?... I just don't know. So I download the covers myself (or with other tools). This makes me feel in control of my media and I just let XBMC 'read it' (never write it).

Until XBMC can overcome my fears, I'm not going to change my behaviour!

[isamu.dragon]

Thought I'd post a thought I had up for discussion.

One issue with exporting your library to separate files so that the info is stored with the media files is that you need to do this regularly or it will be out of sync.

What about an option whereby after watching/listening to media (whether you stop it halfway or finish it), xbmc will write the data to the separate file there an then. What delays/speed issues might implementing this introduce? Obviously xbmc will be updating the database AND be writing this out to file(s). If it does introduce speed issues / delays, is it possible to run it in a separate thread so that the user can continue to use xbmc?

I see possible issues with starting and stopping multiple files in quick succession (depending on how long updating the library and external files might take)....

But anyway, thoughts?

I can see merit in this, but:

I think XBMC's fundamental philosophy is that the database is king. The NFO files are an aid to scraping / importing and useful for export, but there are 'supplemental' to core XBMC and that you already have the lastest information saved and stored... in the database. There's nothing to 'sync' with.

All of that said, I suspect I'm a little like you:
I don't trust the database. I wipe it regularly. I treat my NFO files as master! I keep my fan art and my thumbs in the highest resolution I can and let XBMC 'pull them' from my media. So ideally, I'd like my NFO files always up to date. This really is kinda like treating the NFO files as the database! (which is wrong).

The reason I behave this way (as many others do) is that I'm never 100% sure WHAT xbmc is going to do with my files. If I scrape a movie cover, I don't always know what resolution that image is, and I can't be sure of what XBMC will do to the image file if I 'export' my image files... will it reduce the resolution? will it re-encode an already lossy jpg?... I just don't know. So I download the covers myself (or with other tools). This makes me feel in control of my media and I just let XBMC 'read it' (never write it).

Until XBMC can overcome my fears, I'm not going to change my behaviour!

Ditto, plus you never know when XBMC may corrupt your database (Hasn't happened to me since Babylon). And like you I keep all my images locally, so that they are uniform throughout my network.

[Bstrdsmkr]

A service addon could do this, and I doubt you'd notice the performance impact. The addon would listen for the onPlaybackStarted event. When it hears that event, sleep for 30sec (to reduce the possibility of stacking up a bunch of threads for stop/starting in quick succession), then write the info out during playback.

[DJVege]

My thinking was it serves as a great backup in case your database gets corrupted; in case an upgrade fails and you have to start your library from scratch; in case you want to move to a centralised database etc... You will always be able to get your database back via an "Update library".