2010-01-15, 19:03
There was JUST a thread on this last week where the pros and cons were layed out. Please search.
2010-01-15, 19:20
althekiller Wrote:There was JUST a thread on this last week where the pros and cons were layed out. Please search.
Are you referring to this thread:
http://forum.xbmc.org/showthread.php?tid...t=Watchdog
Last I heard you guys were looking for way cross platform way to do, so that is why I started this development thread.
2010-01-15, 21:37
There are some pretty good ideas on this thread for using python scripts to update the library on a timer. One towards the bottom even has it set to run at a time (like 6pm) rather then a countdown timer. This might work even better for most people so you can set it to a time when you know XBMC won't be in the middle of another task (like watching something) and the library can update then.
http://forum.xbmc.org/showthread.php?tid=64893&page=2
http://forum.xbmc.org/showthread.php?tid=64893&page=2
2010-01-16, 01:37
CrashX Wrote:Anyone know how to do this linux ?
Inotify. Not sure if there's a successor to this but it does what you're after.
2010-01-16, 01:57
I think there's a different thread where I explained the more ideal solution...maybe it was on trac, I get all of this internet shit mixed up.
We aren't looking for anything, we know whats out there and everything is a pretty crappy solution. The cross platform thing isn't that big a deal since we can "just" abstract what we need in a wrapper class. The bigger problem is that none of this stuff is guaranteed to behave the same on all file systems. This is especially the case for network file systems, which, let's face it, is all that really matters.
We aren't looking for anything, we know whats out there and everything is a pretty crappy solution. The cross platform thing isn't that big a deal since we can "just" abstract what we need in a wrapper class. The bigger problem is that none of this stuff is guaranteed to behave the same on all file systems. This is especially the case for network file systems, which, let's face it, is all that really matters.
2010-01-16, 18:10
This is an essential feature that almost every other htpc frontend has. This prevents me from using the library feature very often because I never know if it's up to date. I think a filesystem watcher is the way to go. I've dealt with Meedio and it's library updating on a schedule and you still end up with items not being sure if that new episode or movie was downloaded before the last library scan happened.
In regards to issues people see with implementing this I pose the question of how are all the other htpc apps doing this and who has the best solution?
In regards to issues people see with implementing this I pose the question of how are all the other htpc apps doing this and who has the best solution?
2010-01-16, 23:31
havix Wrote:This is an essential feature that almost every other htpc frontend has. This prevents me from using the library feature very often because I never know if it's up to date. I think a filesystem watcher is the way to go. I've dealt with Meedio and it's library updating on a schedule and you still end up with items not being sure if that new episode or movie was downloaded before the last library scan happened.
In regards to issues people see with implementing this I pose the question of how are all the other htpc apps doing this and who has the best solution?
Most media centres are not cross platform
Most media centres are not efficient over the network or do not watch directories over the network. In fact, if you say that most htpcs have this feature, please show us one with a good directory watcher that works with SMB sources
2010-01-17, 00:19
althekiller Wrote:I think there's a different thread where I explained the more ideal solution...maybe it was on trac, I get all of this internet shit mixed up.
We aren't looking for anything, we know whats out there and everything is a pretty crappy solution. The cross platform thing isn't that big a deal since we can "just" abstract what we need in a wrapper class. The bigger problem is that none of this stuff is guaranteed to behave the same on all file systems. This is especially the case for network file systems, which, let's face it, is all that really matters.
Yup you correct the api probably won't work too well with network sources. Another way I can think of is to let xbmc update library during these conditions:
1) Idle
2) Playing video
Both conditions, the cpu is pretty much doing nothing anyways.
2010-01-17, 01:02
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)
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)
2010-01-17, 01:16
You'd still want filtering (before sending the info to XBMC?) of the paths that you'd monitor, though one presumes that an external app could potentially ask XBMC for that information if it wanted to.
In any case, some sort of independent utility/service seems the way to go, I agree.
Cheers,
Jonathan
In any case, some sort of independent utility/service seems the way to go, I agree.
Cheers,
Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
2010-01-17, 01:25
jmarshall Wrote:You'd still want filtering (before sending the info to XBMC?) of the paths that you'd monitor, though one presumes that an external app could potentially ask XBMC for that information if it wanted to.
In any case, some sort of independent utility/service seems the way to go, I agree.
Cheers,
Jonathan
I agree, but the complexity of that then pretty much lies in the hands of the external utility (nice if it read the sources.xml file but not mandatory). The utility can reside on the same machine, or on a remote server... we don't care, so long as we are prodded at the right time)
A use the term 'we'... of course it means 'you' :-)
2010-01-17, 01:35
Right...like I already said here... http://forum.xbmc.org/showpost.php?p=479...stcount=21
