Database: Refactor MP1 database for multi seat usage (2 Viewers)

[ajs]

So, I think actorinfomovies and IMDBMOvie are pointless. I've written the code to populate IMDBMovie and, for 12 Years a Slave it returned 349 movies related to participants in the movie, but then the system didn't use that data anyway.

As far as I remember, they are filled in afterwards, I can look at my database if I don't forget.
But do not forget that you look it in the Configurator, and in the Configurator not everything works. Full-fledged information with the filling of data occurs only in the GUI Media Portal.

 

[ajs]

 

[framug]

I am thinking that it is too easy sometimes to get so deeply involved with a project that the overall picture is forgotten.

I see MP as a media application that enables users to view videos, music and pictures and record TV programs. It provides enough information about a video to be able to know what it's about.


all you need to do is click the link to give users the ability to view the entire IMDB database for the movie and all of its participants. Why would we want to overwhelm MP with all of that responsibility when there is already a fund of information available online? I think the data shown at the moment is good and that it is simply unnecessary to add any more. And then it turns out that the code isn't using that data anyway.

Would someone please make a decision about this? I'm trying my best to make MP work more efficiently as well as to be more user-friendly when I see a case of lack of clarity about functionality. I appreciate that I don't have a deep knowledge of the history of MP and that there will be a lot of aspects of the system that I don't fully understand. I need a clear indication of what the product is meant to do and be given some trust that I do have some idea about what I am doing . I have, after all, worked out pretty well everything I know about MP from scratch will very little help.

I am happy to use my refactored code for my own use. I am also willing to share that code and support it for you. But, it is starting to feel like I am pulling teeth to get the information I need to get things right.

I don't blame you if you decide to stick with what you have. That's a perfectly understand position to take. But if you want to go down the road of change, then there will need to be a level of trust and commitment at your end for this to work.

I hope you understand my position. I feel it is better to be frank and clear from the start about who is responsible for what and how much freedom and trust I am going to be given.

It seems that you know what you do with DB, as a professional.
But as you explained, the weakness is that you don't know all the story with MP.
Then, if I can give you an advice (OFC, without negative things or something like that) :
BE PATIENT !!!
Instead of trying to push all the walls by proposing many changes, maybe will it be better to propose little changes along the water...

Believe me, sometimes, even modifying one character in MP1 code take long time.

This is because of missing devs and testers ressources for that and, since MP is not in Beta stage since long time, make huge changes without insurance of "bad side effect" and fast repair (if needed) will not be easyly possible.

The goal is not to make MP unusuable for all MP users all over the world.

I hope you will understandand my POV....

 

[ajs]

The actorinfomovies table is empty, but if my memory serves me right, the fields can be filled in by the grabber. Just because it's not happening now, doesn't mean absolutely nothing. It may happen in the future. My opinion, you should not delete the current fields, even if they are empty now.

 

[ajs]

all you need to do is click the link to give users the ability to view the entire IMDB database for the movie and all of its participants. Why would we want to overwhelm MP with all of that responsibility when there is already a fund of information available online? I think the data shown at the moment is good and that it is simply unnecessary to add any more. And then it turns out that the code isn't using that data anyway.

I don't use the Configurator, I use the Media Portal. And when I'm interested in information, I want it here and now. Not google on my phone, or ask Google Assistant.

Would someone please make a decision about this? I'm trying my best to make MP work more efficiently as well as to be more user-friendly when I see a case of lack of clarity about functionality. I appreciate that I don't have a deep knowledge of the history of MP and that there will be a lot of aspects of the system that I don't fully understand. I need a clear indication of what the product is meant to do and be given some trust that I do have some idea about what I am doing . I have, after all, worked out pretty well everything I know about MP from scratch will very little help.

Each user has his or her own cases of using the Media Portal. Everyone has different preferences, etc. The part that concerns actors, information about actors, information about all the movies in which the actor starred. Made in its infancy. It can be expanded in the future. And the grabbers have full access to the database. So delete what is not worth it. Change the structure, perhaps, but I do not see a problem in the structure of this part.

I don't blame you if you decide to stick with what you have. That's a perfectly understand position to take. But if you want to go down the road of change, then there will need to be a level of trust and commitment at your end for this to work.

No one is against change, but if the change will lead to a deterioration in functionality, then I don't see the point in this change. In order to change what is already there, and what can be in the future, it is necessary to understand the full picture of the functionality of the MP. If you do not use this feature, it does not mean that it is not used by a couple of thousand people around the world. I know of several features in MP that are most likely used by just a couple of people. Or functions in plugins that no one uses. But that doesn't mean they should be removed. Maybe tomorrow thousands of people will use them.

There are no hard feelings or prejudices here. This is a healthy discussion. We added one Pragma directive back in the day, and it ended up causing problems with less than 1% of users not being able to work. We removed it because the loss of even 1 user is a loss.

 

[doskabouter]

Just did a quick scan of your code changes...
That is quite a lot of work you put into that and hard to understand all its changes, but I'll give it a deeper looking into soon.
Don't know if this is still feasible but do you think when you're making your final pull-request, you could split up your commits into these kinds:

• refactoring code
• renaming variables/methods
• improve/add/remove logging
• fixing typos
• unifying whitespace
• actual relevant code/functionality changes

Preferably with clear commit-messages? (And preferably without too much noise like moving down "using MediaPortal.Database;" a couple of lines)
Ofcourse this is isn't a list set in stone, more of a general idea...

That will make it much easier to grasp the gist of your changes and for people in the future to trace back what actually happened.

Some other tips:

• please avoid empty catch blocks, at the very least log a warning in it.
• Did you think of the usecase where a new video is added to your video folder somewhere and that multiple clients are going to fetch all the details/thumbs/etc of that video? Or was that covered by assuming no 2 clients are going to go to that updated folder in the same time?

I don't really use the databases that had changed by you (Only ones I use are movingpictures, onlinevideos, picturedatabase very rare, and videodatabase only for keeping track of which episodes of series I have watched), so I can't give you much insight/help with determining and testing functionality unfortunately

 

[Anthony Vaughan]

Some other tips:

• please avoid empty catch blocks, at the very least log a warning in it.
• Did you think of the usecase where a new video is added to your video folder somewhere and that multiple clients are going to fetch all the details/thumbs/etc of that video? Or was that covered by assuming no 2 clients are going to go to that updated folder in the same time?

I don't really use the databases that had changed by you (Only ones I use are movingpictures, onlinevideos, picturedatabase very rare, and videodatabase only for keeping track of which episodes of series I have watched), so I can't give you much insight/help with determining and testing functionality unfortunately

The whole point of the changes I have made to MP were so that you have one central configuration, when you have multiple clients, including the client databases. You won't appreciate the benefits of my system when you work with a single client - albeit that my system is a lot faster in MP and a bit faster when doing scans. Its real strength is when you have multiple clients.

With your system, you have to have a different database for each client because MP locks the client databases while a client is running. So you have to have a separate set of client databases for each client installation. You then have to synchronize your client databases across the different machines in your household so that when you watch a video on one client machine and then resume watching it on another machine, you resume where you left off - not a simple task to get right. MPSync didn't work for my setup - four client machines, centrally configured. So I wrote my own real-time synchronization windows service to handle multiple clients. It worked, but was extremely complicated and I had to keep checking that the different sets of client databases were in-line with each other - requiring code to check that the databases were consistent.

I thought a far better would be to stop MP locking the client databases in the first place. That was when I finally started to look at the code in depth.

Under my system, MP doesn't lock any client databases so you can have all of the client databases for a household in one location, shared by all client machines, as well as all of the thumbs and scraper fanart images (using MediaPortalDirs.xml in the user documents folder). I implemented this solution by queuing all database updates in a separate thread, checking whether a movie exists by doing a name comparison. If another client has already added a movie during the session, the queue processing picks that up. This is what allows multiple sessions to work at the same time and removes the need for any synchronization. In my household, no-one has lost their place in their watching of a video. I have also been able to ensure that when you delete a movie, using MP, all databases records associated with that movie are also deleted and whenever you enter a folder, using MP, database records for non-existent videos are also deleted. That code now takes into consideration stacked movies. The resume position and the duration for each stacked movie, as well as the total duration for the movie stack, are kept in-line whenever you navigate to a folder containing stacked movies.

This all happens in a separate thread so does not affect the front-end performance.

This is why I developed my version of the app.

I have come to the conclusion, after trying to make it work, that I am encountering too much of an uphill struggle to make the effort of moving my code to your setup worth-while. I think I am better off just working alongside your version. The way I have developed the refactor is to install the refactored version over the main version, having integrated the code. It takes me three to four hours to do an upgrade. I am happy to do that for my household's satisfaction. I have nothing to prove to anyone but myself.

Thanks for all of your help and should want to be apprised of what I am doing I will always be willing to let you know how I'm getting on and will share my code should you decide to go in that direction.

Tony

 

[doskabouter]

Don't get me wrong, I'm all up for refactoring and improving Mediaportal, and I really appreciate the work you're putting into it.
What I wanted to say is just that it would be nice if commits were sensible and that I don't use that much functionality that I can really can be of help with testing.
Getting a better user-experience when dealing with multiple clients is indeed something a lot of users are caring for.

As for struggling getting your changes approved: I know it's a very fine line you have to walk between keeping current users happy and moving forward with things but you shouldn't just give up because of that...

 

[Anthony Vaughan]

As for struggling getting your changes approved: I know it's a very fine line you have to walk between keeping current users happy and moving forward with things but you shouldn't just give up because of that...

I am not altogether convinced that everyone feels that way. As I said, getting information was like pulling teeth. It really seemed to me that it was bordering on being obstructive. I can take a hint.

It wasn't really about getting changes approved. It was about someone being able to make a decision. I'm not trying to change any functionality - I'm only interested in making what functionality we have work more effectively and efficiently - and, truth be told, making the database design at least come near to obeying the rules. In reality, I expect non-technical users will be completely unaware that anything has been done at all and that will be proof of how well I've done my job.

I fully understand that people can become risk averse, which is why I don't think is going to work.

I've a lot more I want to do to make MP work faster and better. I think I am better off doing that, and enjoying the results, with the freedom to get on with it. If others want to try that out in the future then I am happy to share.

If you want I will keep in touch.

 

[Anthony Vaughan]

I hope you will understandand my POV....

Understood, completely.