[lesrhorer]

Preferably from my server.  Did I not make that clear?  It would also be preferable to use something other than the http protocol, but I can live with whatever.

Since KODI can find the artwork when there is no .info file, I would expect it also to find it via some means when the actor is not in the .nfo file.  Certainly that is how I would have written the application.  Either way, I would have expected someone here to say, "Use the <thumb> tag and <fanart> group tag in the .info file".  Is that so difficult?

More to the point of my question, some people here from their comments are using external local databases.  No one, however, has explained how to do that.  Anything that relies in any way on the internet is far, far less than ideal for a very large number of reasons.  Caching the results using under powered CPUs on low storage systems is not a great idea, either

No offense, but I did not ask for your opinion, yet you persist in giving it.  First of all, KODI's scraper is not very good, at all.  Secondly, it is internet based, which is unacceptable.  Thirdly, there are a large number of my videos that will never be found on any external database.  Fourthly, the data quality on the external databases is often quite poor, and not very available for me to easily edit or maintain.  Fifthly, there is absolutely no way in Hell I am going to maintain a second database, let alone convert all the thousands of existing database entries by hand.  Sixthly, KODI is not my primary media client.  It probably never will be.  Seventhly, none of the KODI hardware I have is anything like high powered.  Any one of my servers will run rings around all the KODI hosts put together when it comes o... well, everything, really.  They all have a minimum of 16 processors running at over 4 GHz, with a minimum of 32 GB of memory and 10G fiber links.  Eighthly, running the scrapers whenever a video is playing can often impact the video, or even lock up the KODI host.  I have had this happen repeatedly, so I always have to turn off the library update when we want to watch a video.  Running them continuously on an external server has no impact whatsoever.  Ninthly, it is highly inefficient to have three (as of this time) independent systems searching for the exact same items and storing the results in three unrelated places.  There is more.  Do I need to go on?

So, if need be, I can fairly easily modify my scraper to include results in the .nfo files as links to internet sources.  I can also direct them to resources on my server via http, which is rather better.  Will KODI support an MRL something like

<thumb spoof="" cache="" aspect="clearlogo" preview="">smb://192.168.1.50/KODI/Art/JohnWayne.jpg</thumb>
?
This will do if I can't use an external share directly for the cache.  Adding the lines with my scraper is trivial.

As to the rest, KODI is working well enough right now.  I am not interested in the additional information available to the .nfo file, with the exception of sets, which I intend to investigate a bit later. 
Even doing without the thumbnails would not be a deal breaker.  They are nice, but not at all essential.

[lesrhorer]

Frankly, I fail to see your point.  Either KODI supports .nfo files, or it doesn't.  If it does, then it needs to support them fully.

Just to comment on this particular part, there is no standard for an nfo file. Kodi implements the contents of an nfo file for our purposes. It's a file extension and that's all. Any other program will treat it in the same manner

Yes, I know.  That was not quite what I meant.

[izprtxqkft]

Certainly that is how I would have written the application.

i would like to see your fork of kodi https://docs.github.com/en/get-started/q...ork-a-repo
 

Either way, I would have expected someone here to say, "Use the <thumb> tag and <fanart> group tag in the .info file".  Is that so difficult?

apparently as difficult as following the guide - https://kodi.wiki/view/NFO_files/Movies#nfo_Tags
https://kodi.wiki/view/NFO_files
 

No offense, but I did not ask for your opinion, yet you persist in giving it. 

you did ask when you posted a public question
 

First of all, KODI's scraper is not very good, at all.  Secondly, it is internet based, which is unacceptable.  Thirdly, there are a large number of my videos that will never be found on any external database.  Fourthly, the data quality on the external databases is often quite poor, and not very available for me to easily edit or maintain.

1. opinion
   
2. opinion
   
3. opinion
   
4. contribute if its not up to your standards - https://www.themoviedb.org/bible?language=en-US
   

... and TLDR the rest

[scott967]

First off, for me, I have thousands of movie each in its own folder and I don't find it a management problem at all, but as I wrote previously I use Media Companion tool for scraping and general management.

For data nfo files, you either supply a URN in a thumb tag per actor or Kodi will look in a local .actors subfolder for actor name image files (spaces replaced with underscores in filenames).

scott s.
.

[lesrhorer]

First off, for me, I have thousands of movie each in its own folder and I don't find it a management problem at all, but as I wrote previously I use Media Companion tool for scraping and general management.

For data nfo files, you either supply a URN in a thumb tag per actor or Kodi will look in a local .actors subfolder for actor name image files (spaces replaced with underscores in filenames).

scott s.
.

And how many TiVos do you own?  How many of your systems use VLC or some other video client?  KODI does not run on the majority of my systems; only three of them.  Attempting to browse a database when the supplied tools depend on the organization provided by the OS, rather than a database client like KODI is geometrically more difficult and tiresome the more subdivisions there are.  This is especially true when the client (TiVo - I have four of them) only allows 8 rows per subdivision.  Additionally, I handle essentially all of my management of the database from the BASH command line, and it is more than long enough already.

Telling me one must supply a URN doesn't help a whole lot.  First of all, a URN is not the same thing as a URL or MRL.  All three are URIs, but they are not the same thing, and a URN won't really help in this case.  Uniform Resource Names are maintained by internet authorities who know absolutely nothing of my LAN (or any LAN, for that matter).  What's more, merely reporting an acronym doesn't get me there, either.  It is not enough to know one may employ an MRL or URL.  I need to know what LAN resources are supported by KODI in the locator spec.  I am failing to understand why no one wants to speak up, but I will ask again: Does KODU support network protocols such as SMB (i.e. smb://) in its thumbnail specs in .nfo files?   It certainly does in its source specs, and while that is suggestive, it is by no means conclusive.

"Kodi will look in a local .actors subfolder"

In this context, what constitutes "local"?  Are the source folders considered "local", or does this term only apply to resources on localhost?  To put it another way, I have three video sources defined:

smb://192.168.1.50/Recordings/Movies
smb://192.168.1.50/Recordings/Franchises
smb://192.168.1.50/Recordings/TV Series

The first two are defined for the <Movies> resource and the third for the <TV shows> resource.  Is there somewhere on these three network shares where I can place a .actors subdirectory to be accessed by the KODI clients?  Will the presence of .nfo files for each movie prevent KODI from searching for actors in such a location?  It rather seems to have done so for actor images on IMDB, etc., although a yet no one here has actually come out to report this is in fact the case.

The Wiki is no help at all in this respect.

[lesrhorer]

"i would like to see your fork of kodi https://docs.github.com/en/get-started/q...ork-a-repo"

That is not helpful.  I may or may not have sufficient skills to contribute as a KODI developer.  Certainly I am not a professional developer.  It is not and should not be a requirement for any KODI user.  The point, however, is it is only sensible for an application like KODI to parse the local configuration files and seek external information if it is not available locally.  Indeed, KODI itself suggests this would be the case since it asks whether or not to ignore the local information and only use the internet when looking for movie data.  Why these are the only options and why only when seeking a specific show to update is quite beyond me.

"apparently as difficult as following the guide - https://kodi.wiki/view/NFO_files/Movies#nfo_Tags
https://kodi.wiki/view/NFO_files"

Again, that is not helpful.  In this particular instance, the Wiki is all but useless.  It fails to answer several critical questions. The line:

<thumb aspect="" preview=""></thumb>

Does not cut it.  The information between > and < is every bit as important, proprietary, and arcane as the aspect and preview, which are also very badly under-documented.  The difference (in use cases) between fanart and thumbs is also completely obscure to me.  I understand the use cases may be different from one skin to another, but those details should be documented somewhere, or else the user has no way to know what is being done in the .nfo file.

1. opinion
   
2. opinion
   
3. opinion
   

Yes, they are my opinions, and as the user of my systems, mine is the only opinion that matters for my uses.  I will decide what software to use or not use on my systems based upon my opinions of each piece of software.  The sole purpose of all distributed software is to serve the needs and desires of the users.

"contribute if its not up to your standards - https://www.themoviedb.org/bible?language=en-US"

First of all, what has the details of TMDB to do with the specific internal workings of KODI?  In point of fact, I don't have any particular opinion of TMDB one way or the other.  Why would I contribute to something that seems to be fairly good enough to me.  The scraper I use employs TMDB, and it works well enough for my purposes.

[izprtxqkft]

i dont feel i can explain anything to you, it takes entirely more effort than it should and resources given go unread

if you have a library currently, export the library "to separate files" and inspect how kodi writes everything to your disk, duplicate this and kodi will work for you

do it on a smaller library section from a portable install if you dont want a massive amount of files written side by side your media

[scott967]

It does seem like this use case is better served by plex, emby, or jellyfin where the database/library is managed as its own entity.

scott s.
.

[jbinkley60]

It does seem like this use case is better served by plex, emby, or jellyfin where the database/library is managed as its own entity.

That is being discussed.

Jeff

[lesrhorer]

A simple, "Yes", or, "No" was all that was needed.  Why is that so hard to understand or to provide?  After some experimentation, it appears the answer is, "No".  KODI does not seem to support SMB for its thumbnail targets in the .nfo file.

Your suggestion would never have produced any useful information WRT the main query at hand.  An example of how something has been done in one instance in no way is an exhaustive nor authoritative insight into how things can and cannot be done.  A thorough investigation or an a-priori in depth understanding of the code will do so, but I do not have the latter nor at this point the resources to immerse myself in the former.  That is why I asked the question here.

For the information of anyone viewing this thread:  Empirical methods work very well, so in lieu of obtaining the answer here, I tested to see if the SMB protocol is supported as a thumbnail resource.  Apparently it is not, at least on the KODI hosts I am using.  The XML tag:

<thumb>smb://192.168.1.50/KODI/VideoDB/[actor_name].jpg</thumb>

Does not seem to work, unless I made some sort of error during testing - which is always possible.  I tried several different methods.  The server at 192.168.1.50 of course has an SMB share for KODI defined.  This is how I obtain log files and update resources in the KODI hosts via the KODI file manager.  It also has NFS shares defined, but I did not test NFS for this resource.  Instead,  I decided to create an HTTP target for the resource, which clearly does work.  This was very easy and required literally only a few moments.  For security and other reasons it is not a good idea to use the Apache server on the 1.50 system for this purpose, so I installed Apache 2 on another server and created a symlink to the database directory structure from the /var/www/html directory:

root@Backup:/# apt install apache2
root@Backup:/# ln -s /Backup/Server-Main/KODI/VideoDB/ /var/www/html/VideoDB
root@Backup:/#ll /var/www/html
-rw-r--r-- 1 root root 10701 Jul 26 02:20 index.html
lrwxrwxrwx 1 root root    33 Aug 21 08:58 VideoDB -> /Backup/Server-Main/KODI/VideoDB/

Now all I had to do was insert the following into each actor structure in the .nfo file using my scraper:

<thumb>smb://192.168.1.51/VideoDB/[actor_name].jpg</thumb>

This is extremely fast and effective.  Certainly it is vastly faster, more efficient, and more reliable than those produced by internet based links such as:

<thumb>https://image.tmdb.org/t/p/h632/5KJvQIASIK6PTNQWVWK79CNG12B.jpg</thumb>

Such resources lie somewhere between just barely acceptable and utterly unacceptable.  I certainly recognize my method is a bit of a kludge, but apparently KODI has no built-in capability of directly accessing an externally maintained database.  jbinkley60 has written what looks to be a rather substantial database manager add-on for Mezzmo, and with his help and consideration, I might possibly migrate to that platform at some point.  We shall see.  Meanwhile, here is a snippet of my .nfo file for The Great Race:

    <actor>
      <name>Peter Falk</name>
      <role>Max</role>
      <thumb>http://192.168.1.51/VideoDB/Peter%20Falk.jpg</thumb>
      <profile>https://www.themoviedb.org/person/2314</profile>
      <tmdbid>2314</tmdbid>
    </actor>

One might note I have left the actor profile as an internet based resource.  It is not something of which I will ever make very much use, and I do not expect its inclusion will slow down KODI very much, if any.  If that turns out not to be the case, I can always migrate those resources to a local machine, as well.

[lesrhorer]

It does seem like this use case is better served by plex, emby, or jellyfin where the database/library is managed as its own entity.

That is being discussed.

Jeff

Oh, GAWD no!!!  I have not looked at Emby or Jellyfin, but while KODI so far does not seem all too terrible, Plex is nothing but a steaming, stinking, rancid pile of dyspeptic dog feces.  It is precisely the opposite of what I would ever accept.  Given a choice between not watching any shows or listening to any music and using Plex, I would choose not to watch or listen to anything.  Indeede, it is in a sense the choice I have made and effectively the choice my sister-in-law has made.  I refuse to buy any modern TiVo products in significant measure because one is restricted to Plex, and even though she has a TiVo Bolt - which cost her a pretty penny - she never uses it as anything but a dumb tuner.

I don't understand how I am being so badly misinterpreted.  Plex is start to finish the absolute anathema to anything I find remotely acceptable.  How would I be better served by something I cannot stand and would never, ever use, even if its core policies were in any way acceptable?

[lesrhorer]

It does seem like this use case is better served by plex, emby, or jellyfin where the database/library is managed as its own entity.

scott s.
.

I would like to see it optionally externalized / centralized and optionally not tasked to the KODI box(es), which often lack resources.  A stand-alone KODI host should still be an option.  Allowing the user to specify a shared network resource via SMB, NFS, Zeroconf, etc. for the database library location(s) is step one.  Optionally external caches might not be a bad idea, either.  This is already done for the media libraries.  Allowing an external (possibly / optionally third party) application to manage the database is step 2.  Preferably it should be easy for the user to manage the database manually.  Using HTTP targets in my .nfo files is a usable work-around for the time being, but far from ideal.

Many common operations on my KODI hosts are just far, far too slow.  Bringing up, sorting, and browsing the list of actors in order to select one for viewing takes way too long - nearly a minute sometimes.

[Karellen]

Empirical methods work very well, so in lieu of obtaining the answer here, I tested to see if the SMB protocol is supported as a thumbnail resource.  Apparently it is not, at least on the KODI hosts I am using

Not really sure why you haven't done that from the start. Test first. But I guess it is easier to ask for answers rather than discovering for yourself.
But your conclusions are wrong. smb sources do work for actors. In fact, these are all the network protocols that Kodi supports... https://kodi.wiki/view/File_sharing
I just tested SMB to ensure there were no regressions recently. I used this. You will notice the images of the actors do not match the actors name. That is to ensure I was correctly scraping the images being pointed to by the smb link.

xml:
    <actor>

        <name>Mila Kunis</name>

        <role>Amy Mitchell</role>

        <order>0</order>

        <thumb>smb://HTPC-PC/F/Movies- Sets/Fantastic Beasts Collection/Fantastic Beasts and Where to Find Them (2016)/.actors/Eddie_Redmayne.jpg</thumb>

    </actor>

    <actor>

        <name>Kristen Bell</name>

        <role>Kiki</role>

        <order>1</order>

        <thumb>smb://HTPC-PC/F/Movies- Sets/Fantastic Beasts Collection/Fantastic Beasts and Where to Find Them (2016)/.actors/Katherine_Waterston.jpg</thumb>

    </actor>

Plex is nothing but a steaming, stinking, rancid pile of dyspeptic dog feces.  It is precisely the opposite of what I would ever accept.  Given a choice between not watching any shows or listening to any music and using Plex, I would choose not to watch or listen to anything.  Indeede, it is in a sense the choice I have made and effectively the choice my sister-in-law has made.  I refuse to buy any modern TiVo products in significant measure because one is restricted to Plex, and even though she has a TiVo Bolt - which cost her a pretty penny - she never uses it as anything but a dumb tuner.

This rambling of yours is over the top and completely disrespectful. You trash these products, yet give not a single reason why they are so bad. If you feel the need to discuss your bad experience with another product, then do so maturely with supporting descriptions of the problems you encountered.

I don't understand how I am being so badly misinterpreted.

I don't think you are. From what I have experienced, you ask a question, we give you an explanation, then it seems like you ignore the answers or links provided and become annoyed no-one is helping you. Also the fact that you raise questions for the first time, but act as if you have been asking it from the start and can't figure out why nobody is answering them.

Many common operations on my KODI hosts are just far, far too slow.  Bringing up, sorting, and browsing the list of actors in order to select one for viewing takes way too long - nearly a minute sometimes.

Then your devices are underpowered.
Over 35,000 actors in my db, and the list comes up in two or three seconds.

I would like to see it optionally externalized / centralized and optionally not tasked to the KODI box(es), which often lack resources.  A stand-alone KODI host should still be an option.  Allowing the user to specify a shared network resource via SMB, NFS, Zeroconf, etc. for the database library location(s) is step one.  Optionally external caches might not be a bad idea, either.  This is already done for the media libraries.  Allowing an external (possibly / optionally third party) application to manage the database is step 2.  Preferably it should be easy for the user to manage the database manually.  Using HTTP targets in my .nfo files is a usable work-around for the time being, but far from ideal.

I have no disagreement that there are areas in Kodi that can be improved. Actors being one of them. But don't confuse us with a commercial enterprise selling software. We are not Microsoft or Adobe.
All work here is voluntary. Developers are volunteers, so are the moderators.
You want Kodi to improve? It won't happen by making demands that we do. If you are a coder, pitch in.

[jbinkley60]

It does seem like this use case is better served by plex, emby, or jellyfin where the database/library is managed as its own entity.

That is being discussed.

Jeff

Oh, GAWD no!!!  I have not looked at Emby or Jellyfin, but while KODI so far does not seem all too terrible, Plex is nothing but a steaming, stinking, rancid pile of dyspeptic dog feces.  It is precisely the opposite of what I would ever accept.  Given a choice between not watching any shows or listening to any music and using Plex, I would choose not to watch or listen to anything.  Indeede, it is in a sense the choice I have made and effectively the choice my sister-in-law has made.  I refuse to buy any modern TiVo products in significant measure because one is restricted to Plex, and even though she has a TiVo Bolt - which cost her a pretty penny - she never uses it as anything but a dumb tuner.

I don't understand how I am being so badly misinterpreted.  Plex is start to finish the absolute anathema to anything I find remotely acceptable.  How would I be better served by something I cannot stand and would never, ever use, even if its core policies were in any way acceptable?

I wasn't suggesting Plex itself was being discussed just alternate sharing solutions to centralize your artwork.  It looks like you've moved your artwork handling which is similar to how Mezzmo does it, just without all the knobs, whistles and bells (and Windows   )  Mezzmo just has a local URL for each actor artwork, fanart or other similar artwork.  This is what you are doing.

The question now is how to populate your missing artwork.  Yes, we can discuss adopting my Mezzmo Artwork Checker tool to assist..   One thing to watch out for with your Apache approach may be cluttering up your access_log file due to all the picture fetching from your clients.   It may not be a big issue, just something to watch.  I originally did an Apache approach for hosting local trailers but the streaming logs for every chunk was too much so I just have Mezzmo host then now from a drive map.  


Thanks,

Jeff

[lesrhorer]

Not really sure why you haven't done that from the start. Test first. But I guess it is easier to ask for answers rather than discovering for yourself.

Absolutely, not to mention expert advice is potentially much more reliable.  That is why I go to a doctor to find out if I have cancer rather than running tests on myself.  (Yes, I know it is an extreme example, but I trust my point is made.)  As simple evidence of the paradigm, note my testing failed to find the truth.  I evidently did one or several several things incorrectly (very likely typos - I am a lousy typist), and basically wasted a couple of hours of my time.  Clearly it was a well advised notion to ask here, the fact the correct response came a little late notwithstanding.

By the way, this quoting system still mostly eludes me, and even though the <edit> button now shows up on my screen, it does nothing.  My (many) mistakes are pretty much set in stone at this point.

But your conclusions are wrong. smb sources do work for actors. In fact, these are all the network protocols that Kodi supports... https://kodi.wiki/view/File_sharing
I just tested SMB to ensure there were no regressions recently. I used this.

Thanks. (Now you tell me!)  I would have looked more diligently for where I was making a mistake had I known this for certain, but since I already made the conversion, I don't think I am going to back up at this point.  I still don't know exactly what it was I did incorrectly.  For this use case, I don't think SMB will save much in the way of latency and resources over HTTP.  Let me know if I am yet again mistaken.

By the way, I was never able to get NFS sharing to work for Video sources (I have no idea why), nor was I able to get SMB browsing to work.  I can specify the IP of the server, but using the NetBIOS name did not work, nor did searching for the servers.  I have a number of Linux servers on the LAN, but only 1 Windows host - a desktop system.  The Windows desktop host is the only one that shows up on KODI when I browse the network.  I tried several different changes to SAMBA on the target server, but nothing worked.  I finally just gave up and typed in the IP.

You will notice the images of the actors do not match the actors name. That is to ensure I was correctly scraping the images being pointed to by the smb link.

You lost me, there.  How does that ensure the fact?

I am not manually scraping the files from the internet, so for me the choice is either to use the actor name or else apply some random string of characters.  I greatly prefer the latter.  If at some point I come across one that is wrong, I can easily change it. I will admit I am rather anal, but even I am not going to have a fit over one or two actors out of thousands with the wrong portrait.

This rambling of yours is over the top and completely disrespectful. You trash these products, yet give not a single reason why they are so bad. If you feel the need to discuss your bad experience with another product, then do so maturely with supporting descriptions of the problems you encountered.

That would require many, many pages; certainly dozens and perhaps even hundreds of pages.  Do you really want that?  Many of them are directly involved with fundamental issues requiring in-depth analyses of not only the particular software, but the approaches to software development in general, the search for profit and penetration over quality, the unacceptably high apathy and low intellectual concerns of the average human, the lousy educational systems (in the US in particular), the dreadful business practices that are not only common but even applauded, the monumental stupidity of both elected officials and bureaucrats, and finally the U.S. Constitution.  I think not.

In the mean time, suffice it to say:

1. While KODI is really rather too slow, it looks like a bullet train when compared to Plex.
   
2. While KODI's UI is overly graphic, at least it is not too difficult to bring up text-bearing windows for most of the important functions, including the media lists.  I would prefer it if the home screen had no graphics, but at least it's not hard to dump it off the screen.  Plex is essentially nothing but largely useless and worse than useless graphics.
   
3. KODI has a pleasingly large array of configurable resources.  Plex has... well, it's more like a hammer.  'Not a whole lot of different ways it can be configured.
   
4. KODI's configuration is stored locally.  Plex is stored in the cloud.  The freaking cloud!!!  Are you kidding me?  Although far from the worst thing about Plex, that one thing IMO makes it absolutely unacceptable by any and all means.
   
5. One of the least savory things about KODI is how closely it is tied in some instances to the internet.  In effect, Plex won't even work without functioning internet access.
   
6. KODI in itself requires no logins, accounts, or authorization.  (Even so, there is too much of this nonsense surrounding some of the resources for its features.) Plex requires logins and if I recall, a Google account.  Also completely unacceptable. Worse than #4, really.
   
7. I will be damned if some clueless yuppie V.P. will tell me what to do and how to use equipment I own.  Paternalistic attitudes are rife all across society, and Plex is a great example.  The worst decision TiVo, Inc ever made - among many, many bad decisions - was effectively dumping HMO / HME and foisting Plex on all its users.  Had they chosen to embed KODI (XBMC at the time) while retaining HMO and HME as well as remote transfers, then it would have been very acceptable.  Requiring Plex for video transfers is the main reason (again among many) why I will never buy another TiVo.  Thank gawd my TiVos are too "old" to use Plex.  It would be really nice if there were a KODI port for Series III TiVos.  (Hmm.  I may have to look into that.  'Probably not possible, but...)
   
8. KODI's latency issues are quite problematic.  The latency issues in Plex are totally ridiculous.
   
9. KODI is open source hosted on a git repository.  Plex is proprietary closed source commercial shareware.  Game, set and match, even without all the other garbage associated with Plex.
   

That is the short list.  I could go on.

I don't think you are. From what I have experienced, you ask a question, we give you an explanation

Incorrect or incomplete explanations are not of great value.  That is not a personal criticism, but my first post in this thread made a query about why there were so few actor images in my KODI databases.  The first response (from Hitcher) was:

It's all down to the sites the scraper get the images from ie https://www.themoviedb.org/ and if they don't have them then Kodi can't store them.

Which I am afraid in context is pretty nonsensical.  Then you piled on to that response with the second response:

Like @Hitcher said, it depends on what images are available.

Which merely added to the nonsense, and then added:

I have made a feature request to the scrapers to ignore actors without images.

To me, it is completely and instantly obvious this has absolutely nothing whatsoever to do with my first post.  It is completely irrelevant.  This quite obviously has nothing whatsoever to do with actors who have no artwork associated with them in the internet databases.  This is precisely exemplary of what I mean.  How could anyone believe the popular fan sites are missing that much data?  Or is it that you are assuming I am stupid, and did not bother to check that TMDB is missing more than 95% of its actor's artwork?  Do me a favor and please do not assume either I or anyone else is stupid.

Then when I ask a question that is not answered by the sections of the Wiki I have already read, I get pointed toward the sections I have already read.  To that end, as a matter of fact, the section of the Wiki to which you pointed me does not conclusively answer the question I asked concerning how global the support for the various network protocols is.  On the other hand, the body of your answer to the question was both very thorough and conclusive.  Thank you for that, but then again you and subsequently others go off into non-sequitors on topics completely unrelated.  Is it true the presence of a .nfo file prevents KODI from searching for any info concerning the film?  In and of itself that may not be the best idea, unless it is provided as an option for the user, but in any case, which of the three implied possibilities is true?  Or is it instead that the presence of an <actor> tag prevents KODI from seeking any information related to the actor?  That is even less of a good idea, but if either is the case, why didn't your or someone else say so?  I still do not know the answer, and asking, "So where are the actors images meant to come from?" was just ridiculous.  The patently obvious answer is, "From the Fan web sites, where KODI usually gets its images and other data, unless something prohibits KODI from doing so."  The presence of a link to the specific actor art should again obviously absolutely do so, but otherwise IMO it should not be inhibited in this respect, yet which is actually the case, my opinion notwithstanding?  Presuming for some reason it is, then all you or someone else had to do was say so.  Explaining why would also be nice, but not perhaps essential.

Clearly you and I, as well as others, are not communicating well here, and as I said, I do not understand why.

By the way, I of course read your feature request on git.  I think it is a really bad idea, although allowing it as a configurable option would be OK.  I personally would never enable the option.

Then your devices are underpowered.

That is patently obvious, and I have stated as much repeatedly.  'Complained as much, if you want.  But then I didn't engineer or build these devices, did I?  Profitability adn practicality aside, if I were to have designed them, tey would all have a minimum of 4 RISC cores running at least 5 GHz with at least 8 Gigs of RAM and high reliability SDDs with a minimum of 128 Gis of storage, but that is not the case, is it? Feel free to demand that Sony, Motorola, Samsung, Apple, Amazon, and the vast number of Chinese manufacturers all beef up their TVs and media boxes.  Until then, the market is what it is and we have what we have.  (I do have one Raspberry Pi V4 on which I will likely load KODI at some point.)

Over 35,000 actors in my db, and the list comes up in two or three seconds.

I re-loaded the phone sources only a couple of hours ago, so it only has a comparative handful of actors in the DB as of yet, so it does not have a good sample.  The Sony TV was reloaded a few hours ago, and has 5273 actors.  It took 10.3 seconds with the library scan shut down.  The Android Box was re-loaded last night, and has 19,185 actors so far.  It took 16.7 seconds with the scan shut down.  When switching in and out of the list, that adds up rather quickly, and is considerably worse when the scan is running.

But don't confuse us with a commercial enterprise selling software. We are not Microsoft or Adobe.

I am certainly not doing so.  KODI so far seems to be decent software, not the lousy, bloated, useless pile of crap those companies produce.

How can one tell the difference between a computer virus and a Microsoft software product?  I haven't been able to figure that one out.

You want Kodi to improve? It won't happen by making demands that we do. If you are a coder, pitch in.

We are still not communicating, and you continue to infer things I did not imply.  I did not make any demands.  I merely related the features I would like to see and those I consider absolutely essential to retain - mostly those which IMO should be preserved in the code if it gets updated.  No, I have never been a professional developer.  I am familiar with a number of languages, but not all that much with most of the modern ones.  I can read some code, and spot errors in moderately simple, well documented code.  I am probably not sufficiently experienced to be able to submit much in the way of code for this project, but I am willing to help as much as I am able.  How much I am able or unable to contribute in no way affects the validity of my opinions of this or any other software.  I don't need to have designed either the Ford Pinto or the Ferrari Monza to know which is great and which is a piece of crap.  I will withhold my conclusion on that for the time being, but so far for the record KODI is doing fairly well in my estimation.  I am not going to withhold my opinions concerning what I think would make KODI better or worse as the case may be.