XBMC Community Forum
Directory Watchdog - Background file monitor service to initiate auto update library? - Printable Version

+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: Feature Suggestions (/forumdisplay.php?fid=9)
+--- Thread: Directory Watchdog - Background file monitor service to initiate auto update library? (/showthread.php?tid=66348)

Pages: 1 2 3 4 5 6 7 8


- robweber - 2010-11-19 15:58

Robotica Wrote:You are right about the cross platform solution. What I ment is to handle a file-write as an event. And then think about the solution I described above.

Extra examples: finished download triggers library update, incoming call triggers pause, 07:00 in the morning triggers scrapers, etc.

I understand what you meant, it is watching for the file-write event within XBMC that is the problem. An event driven system to carry out specific tasks is a fine idea although I'm not quite sure it merits being part of XBMC directly. There are several other fine programs (such as EventGhost for Windows) that do a great job at this and can launch XBMC commands once their events are triggered.


- evlo - 2011-01-15 18:00

The-Boxhead Wrote:Why all this would work the best way to do it would be that XBMC
had this "built in" in feature rels.

Regular users dont expect to setup scripts, mapping custom keymaps, hacking skins or whatever.

There should be some kinda "monitor" functions on all sources added. When
XBMC senses a change in any of the sources it updates them, and movies / music or whatever is automaticly scanned into the library.

Most "library" programs on PC/MAC has this functions and users are used to it.
Yup, lack of something like ntfs background monitor and updater service as seen in medibrowser for example is one of the few main thing that i hate in xbmc.

Clicking library update and then waiting for library to update and compress to see newly added movies on fileserver is really not comfy, so while using xbmc i use directory browser rather then library \:.


- HenryFord - 2011-01-17 16:34

evlo Wrote:Yup, lack of something like ntfs background monitor and updater service as seen in medibrowser for example is one of the few main thing that i hate in xbmc.
The problem - as mentioned before - is the multi-plat-solution.
"NTFS Background Monitor" (which is more like a background monitor in general, because it does not depend on the file-system (you could use FAT as well - ext not so much, because there is no Windows support) utilizes the Windows API to watch for file changes (the Windows API can raise events everytime a file is changed/moved/renamed/created/etc.). For XBMC it is just not possible to include such a scanner, because it would depend on the Windows API and therefore wouldn't work on other platforms.
Why don't you go ahead and use EventGhost for Windows? It is perfectly capable of doing what you want: Watch for changes and notify XBMC about them.

Or you use the Library Updater in the Addon-Rep.. It will update the library with a shedule, just set it to 15/20 minutes to get new files almost instant (max 19,59min late with a 20min shedule)


- GJones - 2011-01-18 06:23

The push method is the correct one. You should know when you add new content and tell XBMC to do an update. The update is run very simply from any platform by using curl. If you copy files over, run curl. If you have a program that copies them over, have it run the curl script at the end of the copy (as most torrent programs have this option).

I have an automated script to transcode newly ripped content. Its last step is to copy over the new (smaller) file and call the library update (with clean enabled in advanced settings) function.

No pointless inode-monitoring. No resource-wasting infinite loop.


- topfs2 - 2011-01-18 06:37

HenryFord Wrote:The problem - as mentioned before - is the multi-plat-solution.
"NTFS Background Monitor" (which is more like a background monitor in general, because it does not depend on the file-system (you could use FAT as well - ext not so much, because there is no Windows support) utilizes the Windows API to watch for file changes (the Windows API can raise events everytime a file is changed/moved/renamed/created/etc.). For XBMC it is just not possible to include such a scanner, because it would depend on the Windows API and therefore wouldn't work on other platforms.
Why don't you go ahead and use EventGhost for Windows? It is perfectly capable of doing what you want: Watch for changes and notify XBMC about them.

Or you use the Library Updater in the Addon-Rep.. It will update the library with a shedule, just set it to 15/20 minutes to get new files almost instant (max 19,59min late with a 20min shedule)

The problem is not that we can't use the windows specific API's but more that we want to add a crossplatform abstracted way to deal with the events. This is somehting which needs a bit of alterations in the vfs abstraction to do this correctly. When it is abstracted the windows implementation of the vfs could easily implement and transform windows events to xbmc events which would allow even windows specific feature to work. (linux has a similair which would obviously be wrapped in a similair manner). For those vfs which does not have such a notification method we could resort to a scheduled search (smb afaik should have events, not sure if libsmbclient expose them though). If done properly it should be ok for most users.


- takoi - 2011-01-18 10:34

As already mentioned there is a java library that implements both linux's inotify, the windows api, and the osx api. So when the java addon is done this can be used.


- GJones - 2011-01-18 19:22

ventech Wrote:As already mentioned there is a java library that implements both linux's inotify, the windows api, and the osx api. So when the java addon is done this can be used.

And it will still require more system resources than taking responsibility for knowing when you add content to your own system.


- topfs2 - 2011-01-18 19:27

ventech Wrote:As already mentioned there is a java library that implements both linux's inotify, the windows api, and the osx api. So when the java addon is done this can be used.

Going out and using java would probably be overkill. Adding this for linux, windows and osx should be more than possible when the actual abstraction is in place.


- takoi - 2011-01-18 19:28

GJones Wrote:And it will still require more system resources than taking responsibility for knowing when you add content to your own system.
Its event based

topfs2 Wrote:Going out and using java would probably be overkill. Adding this for linux, windows and osx should be more than possible when the actual abstraction is in place.
not saying its the best but its a solution. Also some of the code can probably be reused as the website say most of it is in c++


- topfs2 - 2011-01-18 19:45

ventech Wrote:Its event based

not saying its the best but its a solution. Also some of the code can probably be reused as the website say most of it is in c++

Ah, look at that, yeah thats reusable.

Cheers,
Tobias


- takoi - 2011-01-28 19:23

In case anyone else misunderstood i just want to make it clear that any event based solution will not work over network using smb, nfs or any kind of distributed file systems.


- topfs2 - 2011-01-28 19:30

ventech Wrote:In case anyone else misunderstood i just want to make it clear that any event based solution will not work over network using smb, nfs or any kind of distributed file systems.

samba is ntfs over network essentially, it should work according to specs.

And any eventdriven solution will work if the protocol exposes it, for those protocols which doesn't a watchdog would obviously be a fallback. Which is also why we want to do a proper abstraction for it where the protocol implementation either implement the events or it fallbacks to watchdog


- takoi - 2011-01-28 19:51

what protocol expose it?


- topfs2 - 2011-01-28 20:19

ventech Wrote:what protocol expose it?

Any protocol which expose it will be instant and nice, local files and hopefully smb. Not sure about others, uPnP perhaps and maybe nfs? I am not sure as said. At any rate, those which does not support it would still have a nice shared fallback technique, which is exactly what is proposed here, but alot more future proof


- takoi - 2011-01-28 21:14

well i cant seem to find anything about how to do this over smb...

btw. just noticed that jdk7 will implement a watch service which does exactly what you explained, fallbacks to polling: http://java.sun.com/developer/technicalArticles/javase/nio/#6
Maybe you could take something from the api or code. If this isnt finished til the language refactor and java7 then at least an addon should be easy to produce