Kodi Community Forum

Full Version: Focus on a distributed model
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Regarding the Focus on a distributed model project. Is someone assigned to it?
Can we discuss about it?

I've been thinking of something like a sync service.
For example: you mark a movie as watched on your tablet and if the same movie is also on your htpc it will be marked too as watched during the sync process.
(2013-04-15, 09:38)otzy_007 Wrote: [ -> ]Regarding the Focus on a distributed model project. Is someone assigned to it?
Can we discuss about it?

I've been thinking of something like a sync service.
For example: you mark a movie as watched on your tablet and if the same movie is also on your htpc it will be marked too as watched during the sync process.

are you the one who wants to code it?
Yes. I would like this to be my GSOC project this summer.
I have fixed some bugs in the past, so I am a little familiar with xbmc's code.

https://github.com/otzy007/xbmc
I suggest starting with:

1. Take a quick look through the PRs that went in in April. Hint: There was one related to your idea.

2. Outline your idea here in detail. Highlight which bits XBMC is missing and detail your ideas as to how you might go about adding/fixing them.
Sorry but I didn't found that PR Sad

But let me tell my idea.
I'm thinking of syncing the databases by saving the database changes into files (something like a migration) and sharing those migrations between the machines.
When a machine sees a new migration it will try to merge it into it's own database.

For example: if two machines have the same movie and you finish watching the movie on one of them, it will be marked on that machine as watched and a migration will be generated and shared with the others. The other machine will see the migration and merge it into it's database.
If a third machine doesn't have the movie that the other 2 have, it will simply ignore the migration.

For sharing the migrations we can use the existing upnp server to share the migrations folder.
I believe the PR Jonathan was referring to was this guy: 2547 (PR)
It's kind of the same thing what I've proposed, only that he is sending the information on a central server. I was thinking of storing the information on the machine, making it something like a server and the others getting the migrations from it.

My way every machine will be a server for the others and a client searching for migrations in the network.
The above PR stores the watched information at the source. i.e. if it comes from a upnp server, then you mark it as watched or in progress on the server, so that all clients of that server get that information. If you're playing something on the server, then marking something as watched there will also show as watched on the clients.

Your idea has some sort of common library/database on each machine, with messages being passed between machines to update when any one of them updates?
Something like that. The machines have their own databases. The databases don't need to have the same data.
When something in the database of machine 1 (M1) is modified a file containing that database query is generated and stored into a file , let's call it migration-date-time. (Something like migrations into Rails, only that our migrations will change the data, not the db structure).
All those migrations are stored into a shared folder.
Machine 2 (M2) will get the migrations from M1's shared folder and merge the relevant one.

We can implement also a message passing (MPI like) migration system, but only the online machines will change the database. M2 will apply the migration from M1 but if we start a third machine M3 after the message has been passed it will not receive the migration.
We still need a way to apply the migrations for those machines.

Having a shared folder on M1 and M2, M3 will access those folders and apply all the migrations newer than the last merged migration.

Even the shared folder model has it's down sides. M2 and M3 will not know when M1 generated a migration, unless M1 will broadcast a message to tell them that there's a new migration available.

Maybe the best way is to combine message passing and shared folder, message passing for the online machines and shared folder for the ones that will come online later.
to be honest i as user would rather have the databases talking directly with each other than through separate generated files
@otzy_007: I'll be telling other GSoC candidates this as well, but it would be useful I think for you to get involved in development early by taking a look at the current database and perhaps making some changes.

This will get you used to how XBMC code works, and how the current codebase is setup - it'll help you see some good things with the design and some not so good things, and might then give you some more solid ideas as to how your GSoC project may turn out.

It's unlikely that we'll accept students with no record of contribution to XBMC, or at least effort shown at contributing!

One area which I've suggested to another student as well is to take a look at storing more than one dateadded variable in the database, and allowing both to be returned. This will allow the setting which chooses between the different possible meanings of "dateadded" which currently applies at scan time to apply at runtime instead, allowing the user to easily change it without having to rescan.

See this thread for more: http://forum.xbmc.org/showthread.php?tid=127343

Cheers,
Jonathan
I've contributed in the past with small bug fixes 278 (PR) , 1119 (PR) and other small ones. I know a little how the code is structured. I'll look into the database code and maybe catch a bug Big Grin