[AndyE]

Seems to me that most of the solutions are working on a 'pull' solution. (No I don't mean POLL)....

The assumption is that XBMC, or some script within will either poll/scan for changes, or become observers of the file system and wait for a notification event from the host OS. Polling sucks, and the notification mechanisms vary from OS to OS.... but with both solutions it's XBMC 'pulling' the data somehow.

So, why not turn the thinking around and have an external solution that pushes the change notification in a uniform manner. That is to say, each OS may have it's own technique, and folks can develop whatever 'monitors' they like... OUTSIDE of XBMC. Their only goal should be to notify XBMC that a change has occurred. This then leaves the XBMC code clean and OS agnostic... whilst the
monitors can be as dumb or sophisticated as you like....

Just need an interface to tell XBMC 'Do a scan', or better still 'Do a scan in this path' etc

This then becomes more of a 'push' solution, and in my mind architecturally neater by a million miles (even though I do wish XBMC could do this itself)

Isn't it sort of pointless having architecturally clean code that doesn't actually provide anything?

This solution still means someone has to write the apps that send the inotify and Windows/OSX equivalent notifcations to XBMC. And who is going to write and maintain those?

EDIT:
Just to be clear, my point being if they are considered community apps, community apps with poor quality or performance may reflect badly on XBMC, with the XBMC devs not having any real control over it

[althekiller]

And who is going to write and maintain those?

What makes you think we want to?

[AndyE]

What makes you think we want to?

That's exactly my point

[jmarshall]

If they don't work, we won't distribute them, simple as that.

If a user has to go elsewhere to find something then they already know it's not supported.

[AnalogKid]

The point is, the XBMC team don't really want to do this, not unless there was a totally compelling reason and simple cross platform implementation...

So, as a concession, those that REALLY do want this feature would be free to implement a solution that wouldn't compromise XBMC i.e. Develop their own external monitor.

Should anybody develop a superb monitor that miraculously convinces the XBMC team of the error of their ways, then I am sure they would consider incorporating it into the XBMC core. Until then....

Since I'm not gonna be doing any coding for XBMC, I either put up with what I get, or implement workarounds externally... I don't see why that couldn't extend to folder watching (providing there's enough of a hook to notify XBMC of a change, or force a library update)

For me that's a fair solution

[tronics]

Edit: removed apparently irrelevant info

[althekiller]

That's basically what the current scanner does. Which, consequently, isn't what's being discussed here.

[AnalogKid]

I think for each OS, we know how to detect a change... that's pretty simple, but what we want is a very efficient (preferably 'event driven') solution to detect changes.

External 'watchers' could simulate event driven by polling / regular interval scans... (i.e. XBMC wouldn't know) OR they could utilise the host OS services to know when a change had occurred (or even use both, cos you just can't trust those damn OS folks sometimes!).

The point is, for many reasons, most folks want to offload this work to something outside of XBMC. 90% of users are getting by perfectly well by hitting 'scan'... so the remaining 10% who really need it, or those just who'd just 'like it' can develop their own watchers, however they please. The best ones will rapidly get distributed throughout the community... just like all the other external tools do.

You can always make a case for XBMC doing more... I know I could, but there's a limit too. There's not enough developers and a hard line has to be taken with some features (otherwise XBMC would be incorporating bulk file renaming, web browsers, tea making facilities and even something as mad as playing back media!).

I reckon an external watcher would be a couple of days work for a good one, and half a day for a crude one.... no more than a couple of Kbytes and easily sent around the community... (a heck of a lot easier than building it into XBMC). Eventually it might end up part of XBMC, but for the moment, external's the fastest, quickest route (IMO).

[CrashX]

It does keep the library up to date so I wouldn't say it is total waste.

How about this ?

We merge File View and Library View together to form one unique view. Library view doesn't detect any filie/directory changes but file view does. If file/diriectory is change, it will trigger a library update for that particular file when you are browsing your library. This also handles the case, where directory/file isn't added to the library because no data is available ( Scrapper can't find anything ).

[jmarshall]

That's the plan already, though there's still things like we'd like to be able to shoot up notifications or whatever when a new movie is available.

[pecinko]

We merge File View and Library View together to form one unique view. Library view doesn't detect any filie/directory changes but file view does.

Add to that auto-tagging by subfolders & add to DB by folder/file name in case scraper fails and count me in.

[jmagilto]

as root user

Code:

apt-get install curl
apt-get install cron

as xbmc user
create file /home/xbmc/updtV
contents

Code:

#! /bin/bash
curl "http://127.0.0.1:8080/xbmcCmds/xbmcHttp?        command=ExecBuiltIn&parameter=XBMC.updatelibrary(video)"

make it executable

Code:

chmod 755 /home/xbmc/updtV

create file /home/xbmc/updtM
contents

Code:

#! /bin/bash
curl "http://127.0.0.1:8080/xbmcCmds/xbmcHttp?command=ExecBuiltIn&parameter=XBMC.updatelibrary(music)"

make it executable

Code:

chmod 755 /home/xbmc/updtM

(edit the crontab to schedule these scripts to run)
(these settings update the Video each nite at 12:55am and the Music at 2:55)

Code:

crontab -e

Code:

# Update Video and Music Libraries each nite
55 00 * * * /home/xbmc/updtV
55 02 * * * /home/xbmc/updtM

Voila.
Hope this helps someone

[pashdown]

With an active cache of shows rolling over, repeatedly updating the library and cleaning removed videos out becomes a real chore. Is there a better way to transparently update and audit the library? A different database system, or a centralized database running on NAS?

[pashdown]

Looks like my post got moved to this thread.

I know how to use cron, but that isn't what I'm looking for. Both of my XBMC boxes are suspended when they aren't in use. It would be nice if instead of maintaining two separate unsync'ed library databases, there was an option to run a centralized back-end database (ala mythtv) on my fileserver (which is on all the time) that they both pointed to.

[semi-]

This is not directly related so maybe I should be making a new post, but I have a slightly different approach to this problem:

Updating library on startup works fine for a lot of people, but if you leave xbmc running 24/7 on a HTPC it isnt very useful. Would it be possible to add in a "Scan for updates when coming out of idle" (as in, when the screensaver goes away) feature too?

I know someone else already mentioned doing it while idle which is also interesting, but this seems like the easiest and cleanest way.