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

[ajs]

Is anyone using this option and what is it for (and what is it expected to do if you don't store your movies in separate folders in the first place)?

Once I used it, it is convenient, there is less visual garbage when browsing the catalog. But that was a long time ago, here you need to look at the Media Portal code and the code of all grabbers.

 

[TLD]

I use it because when you use the create .nfo command in video GUI the .nfo file along with cover and fanart are all in the same folder with the movie.

 

[Anthony Vaughan]

I use it because when you use the create .nfo command in video GUI the .nfo file along with cover and fanart are all in the same folder with the movie.

Okay.

The reason I asked this question is because, when this option is selected, the fetch processing uses the folder name instead of the movie name, in the grabbers, to find a match. Therefore, if you select this option, but actually put all of your movies in a single folder (as I do), the grabber returns a list of matches to all of your movies (up to the limit you have set).

This had me thrown until I looked at the code. Why the processing uses the folder name, when you've already got the movie name is a mystery to me.

I think this code needs to be changed to always use the movie name because the current behavior is really confusing to the user - including me.

I now notice that the configuration app has an option to 'Prefer video filename for movie search'. I suggest that this option should default to ON because, in my view, it is by no means obvious what it's implications are until you get some weird behavior as I explained above.

 

[Anthony Vaughan]

I don't know English well, but I repeat once again, it takes me a few seconds to get a complete list of actors, which grabber do you use? And you can log with debug information where you can see that getting the list takes a lot of time. Well, one more thing, the grabber is engaged in obtaining the list of actors, information on the actors, and not the Media Portal, recording to the database is generally instantaneous.

I removed all of the actor information processing to check your hypothesis that it is getting the actor info that is slow - it made no difference.

I'll have a look at the actor retrieval process again to see if there is any unnecessary processing going on there. I think the problem is in the getting of all actors for a movie. I don't think it is anything to do with the grabbers, but I'll check. I suspect it is an iteration issue.

 

[Anthony Vaughan]

I don't know English well, but I repeat once again, it takes me a few seconds to get a complete list of actors, which grabber do you use? And you can log with debug information where you can see that getting the list takes a lot of time. Well, one more thing, the grabber is engaged in obtaining the list of actors, information on the actors, and not the Media Portal, recording to the database is generally instantaneous.

Well, I finally got there. It was your hint about actor info that led me to the solution.

I think there is a little confusion with terminology as well that can lead to confusion. In the GUI, the settings refer to actor 'details' and in the column heading in the configuration app it says actor details:

In the database this information is held in a table called 'actorinfo' and other screen objects refer to this as actor info, which is really the same as actor details.

When you want actor details, the grabber and MP apps have to do a lot more work, which I mistook for being caused by looking for all actors in a movie when it was actually getting actor details/info. When the grabber doesn't do all of the iterations (the extra work), the actor info table gets very little information. It may be worth looking at why it needs so much extra work to get the full actor info because I suspect there is a way to get that data without all of the extra processing.

In the meantime, I'll change the wording on the screen (configuration) to make it clear that it is actor details that will be optional.

Thanks for helping me to finally get this sorted out.

 

[TLD]

Okay.

The reason I asked this question is because, when this option is selected, the fetch processing uses the folder name instead of the movie name, in the grabbers, to find a match. Therefore, if you select this option, but actually put all of your movies in a single folder (as I do), the grabber returns a list of matches to all of your movies (up to the limit you have set).

This had me thrown until I looked at the code. Why the processing uses the folder name, when you've already got the movie name is a mystery to me.

I think this code needs to be changed to always use the movie name because the current behavior is really confusing to the user - including me.

I now notice that the configuration app has an option to 'Prefer video filename for movie search'. I suggest that this option should default to ON because, in my view, it is by no means obvious what it's implications are until you get some weird behavior as I explained above.

I think you may run into problems with multi part movies if not using the folder names to search.

 

[ajs]

When you want actor details, the grabber and MP apps have to do a lot more work, which I mistook for being caused by looking for all actors in a movie when it was actually getting actor details/info. When the grabber doesn't do all of the iterations (the extra work), the actor info table gets very little information. It may be worth looking at why it needs so much extra work to get the full actor info because I suspect there is a way to get that data without all of the extra processing.

Getting information about the actor depends on the grabber, whether the actor has an IMDB ID and on the method of getting this information, if you use API, it's almost instantaneous, but there is a minimum of information. If IMDB site is used, then for each actor we get about 3 pages of text, which need to be processed, parsed, and given to MP1. This takes time. And it depends on the computer, internet, and connection time to the IMDB site.

I think this code needs to be changed to always use the movie name because the current behavior is really confusing to the user - including me.

There are many nuances, DVD images, DB images, here the file names will be the same. Also movies consisting of parts, etc., etc. Or with a common name.
Movies\The Think (1998)\movie.mkv

 

[framug]

@Anthony Vaughan, if I can :
You propose many things, wich is good.
Therefore, maybe should/could you separate ?
Example (but not limited one) .
One for DB improvment, handling the multi clients concurrency.
Second, for actor informations/processes.
Actually, I'm not sure your entire solution could be integrated easyly...
Just my 2 cents...

 

[ajs]

Small steps towards a big goal...

 

[framug]

Yep,
An example :
Same for TimeShift buffer display delay integrated but, without all demands for another Team member...
But since it's working during many release without users complain, discuss could be reopened.
But, this is another story...
To summarize : make it simple at the first stage