[Swifty]

Hi All,

This may be a little off whack, as I'm not sure of the technical details on how XBMC scans folders when doing library updates currently - but in my head I guess it works something like this ;

When a library update is initialised XBMC goes through every single folder present in a media source and looks compares each file with what's in the library.

My proposal is some sort of 'Quick Scan' option which can be used to maintain updates to the library once it's initially set-up (A library update currently takes around 4 minutes for my ~2.5TB worth of videos)

When this option is selected then XBMC could look at modify dates of folders (or compare against some sort of checksum) for the top level folders (ie. Show XYZ\Season 01) if the modify date hasn't changed then it can safely assume nothing has altered and move on.. I guess this would be much quicker than looking at every single file within a folder?

Anyway, as I mentioned that could be totally crazy.. but I was just thinking how I can keep the library up to date but not have to wait for library updates each time I wake the PC..

[spiff]

this is exactly how update library works. except the hash is based on the timestamps of the files in the folder, cause folder mod dates doesn't work on all filesystems (i'm looking at you windows).

[Swifty]

Hmm.. interesting thanks for the reply.

I guess the next question then is are update times of ~4 minutes normal ?

I have ~2.5TB in total, around 650 albums and around 500 videos.
Working from remote linux based NAS over SMB with gigabit network (client is XBMC Camelot (also tried various SVN's with similar times) on ubuntu 9.10).



BTW. Close this topic if you like, or move to support.

[GJones]

The more relevant question might be "how often are you scanning your content directories?" If the scan time (which to me seems completely within a normal range for the amount of data) is too long for you, it might make sense to schedule it for a time that is less intrusive. I use XBMC on Linux so using cron makes this simple.

[kraqh3d]

Moved to support...

I'd say that 4 minutes to run "update" without any true updates doesn't seem bad. Remember, Xbmc is doing a ton of network based directory content fetches.

During the update, Xbmc is recursively fetching the contents of just about every folder on your media filesystem. (Really, its fetching the contents of all folders in the path table for each media type.)

It's then computing an md5 hash for the contents of each folder. The hash is computed from filename, filesize and filedate of everything in the folder. The computed hash is then compared against the last known hash stored in the database to determine if there are any changes.

[GJones]

Hmm.. interesting thanks for the reply.

I guess the next question then is are update times of ~4 minutes normal ?

I have ~2.5TB in total, around 650 albums and around 500 videos.
Working from remote linux based NAS over SMB with gigabit network (client is XBMC Camelot (also tried various SVN's with similar times) on ubuntu 9.10).



BTW. Close this topic if you like, or move to support.

Are the client and server both Linux based? If so, NFS might help a bit with the performance, but it would be incremental. SMB is a pox upon network efficiency through no fault of XBMC or Linux.

[Swifty]

Thanks guys.

Yes the NAS and all clients are linux based so maybe I will take a look at NFS if it will offer better performance?

I did consider using cron, but the problem is my XBMC clients sleep (S3 standby) when not in use so I have XBMC set to update the library each time I wake the machine (since usually I may have added some videos or music while the client was off).
This poses a little problem when waiting for the library to update after waking so that new videos can be watched via the library method.

[kraqh3d]

Xbmc should still be usable from files view while the update is running. You don't have to wait for it to finish. Library view though could be a bit wonky as the database gets locked.

(Actually, I found an annoyance that's likely related to the database locking. I need to verify with a fresh svn build though. When playing a video playlist, the items dont get marked as watched. I suspect theres a lock clash between the code that pulls the settings for the 'next' video and the code that marks the 'previous' one as watched.)