- June 25, 2015
- 584
- 292
- Home Country
-
United Kingdom
While we are chatting, now get mad, you know that I said I would refactor the database to get rid of any redundancies.
I've done that and have been using the amended system for quite a while now.
Then I got to thinking that it would be great if the client databases could be truly multi-user: i.e. a single database, for each media component, available to many clients.
So, I went through the process of changing the database connections so that 'using' is employed for all database connections. But that still left me having locks on the client databases that prevented other apps, like synchronization, form processing the client databases as changes occurred. The next step was to close database connections whenever the home screen was displayed (unless player was active). This really helped to make my sync app work better for my four clients.
MediaPortal has been developed with so much care to make sure the front-end is pretty much unaffected by the back end that it seemed to me that the best way to achieve a truly multi-user setup was to separate the front-end and back ends as much as possible. However, SQLite.NET is quite old and there are so many advances in database accessing that I thought it might be better to start from the ground up and, since I had already done much of the work developing the sync app, to employ EntityFramework, Linq, Lambda and collections making the database accessing fully object based. To keep the front-end light, I have connected the front-end to lists of each entity in each of the client databases and the front-end uses the lists to keep the data current while the session is running.
But we still have the issue of trying to keep database changes current while there are multiple threads mediating between the front and back ends, without locking the database to other clients. It seems to me that the only real solution was to queue the database changes to a single thread responsible for database updates only (all of the other processing being performed in memory).
This would be okay for a single client with the queue processing being part of the MediaPortal app. It seemed to me that, in order to make the queuing truly multi-user, we would need to queuing system that writes queue entries to a queuing database that is processed by a windows service whose sole job is to write queued updates to the database, across the whole household (a bit like TVService). This would avoid any locking and allow the MediaPortal app to perform optimally with no back-end interruptions.
I am happy just to do this for my own system but want to know whether you would be interested in what comes out of this. I am very nearly there in that the bulk of the donkey work has been coded and I am into detail (and getting the queuing to work). The system is working but I have a lot more testing and debugging to do yet
Are you interested in using what I come up with. If you are, I will undoubtedly have a few questions about why certain aspects of the system are there so I understand what they were intended for (stacking comes to mind). I appreciate that they have real purpose but I don't use them so I may miss something.
I'll understand if you feel this is too risky, but I am seeing the benefit of a truly data synchronized system, within a household, as being worth the effort.
For me there is nothing out there as user-friendly as MediaPortal and hope that it can be made even better over time.
Tony
Here's the first release of the refactored application. Upzip the file to a folder and run RefactorMediaPortal.bat. Your MediaPortal application will be overwritten (well, parts of it). When you run Configuration or MP for the first time it will upgrade two of your client databases. Please check that they have successfully copied your existing data to the new versions. The existing versions will remain. To revert to the standard version of MP, reinstall MP 1.29 in the usual way.
Please let me know if you have any issues. Just because it works for me doesn't mean I haven't missed something about your setups.
I've done that and have been using the amended system for quite a while now.
Then I got to thinking that it would be great if the client databases could be truly multi-user: i.e. a single database, for each media component, available to many clients.
So, I went through the process of changing the database connections so that 'using' is employed for all database connections. But that still left me having locks on the client databases that prevented other apps, like synchronization, form processing the client databases as changes occurred. The next step was to close database connections whenever the home screen was displayed (unless player was active). This really helped to make my sync app work better for my four clients.
MediaPortal has been developed with so much care to make sure the front-end is pretty much unaffected by the back end that it seemed to me that the best way to achieve a truly multi-user setup was to separate the front-end and back ends as much as possible. However, SQLite.NET is quite old and there are so many advances in database accessing that I thought it might be better to start from the ground up and, since I had already done much of the work developing the sync app, to employ EntityFramework, Linq, Lambda and collections making the database accessing fully object based. To keep the front-end light, I have connected the front-end to lists of each entity in each of the client databases and the front-end uses the lists to keep the data current while the session is running.
But we still have the issue of trying to keep database changes current while there are multiple threads mediating between the front and back ends, without locking the database to other clients. It seems to me that the only real solution was to queue the database changes to a single thread responsible for database updates only (all of the other processing being performed in memory).
This would be okay for a single client with the queue processing being part of the MediaPortal app. It seemed to me that, in order to make the queuing truly multi-user, we would need to queuing system that writes queue entries to a queuing database that is processed by a windows service whose sole job is to write queued updates to the database, across the whole household (a bit like TVService). This would avoid any locking and allow the MediaPortal app to perform optimally with no back-end interruptions.
I am happy just to do this for my own system but want to know whether you would be interested in what comes out of this. I am very nearly there in that the bulk of the donkey work has been coded and I am into detail (and getting the queuing to work). The system is working but I have a lot more testing and debugging to do yet
Are you interested in using what I come up with. If you are, I will undoubtedly have a few questions about why certain aspects of the system are there so I understand what they were intended for (stacking comes to mind). I appreciate that they have real purpose but I don't use them so I may miss something.
I'll understand if you feel this is too risky, but I am seeing the benefit of a truly data synchronized system, within a household, as being worth the effort.
For me there is nothing out there as user-friendly as MediaPortal and hope that it can be made even better over time.
Tony
Here's the first release of the refactored application. Upzip the file to a folder and run RefactorMediaPortal.bat. Your MediaPortal application will be overwritten (well, parts of it). When you run Configuration or MP for the first time it will upgrade two of your client databases. Please check that they have successfully copied your existing data to the new versions. The existing versions will remain. To revert to the standard version of MP, reinstall MP 1.29 in the usual way.
Please let me know if you have any issues. Just because it works for me doesn't mean I haven't missed something about your setups.
Last edited:
