[Torben]

Hi.

What exactly is "XFILE::CFileFactory" and why is it bothering me?
Alternatively: "What exactly is 'Inputstream' and why is it bothering me?

Where
In a plugin, I return a really simple list of items. [ (Image, dbid)... ]
I don't want/don't need an URL for anything as the items are just images and I handle the onclick with another script that gets all the necessary details.

How
It looks more or less like this:

Code:

for item in l:
    li = xbmcgui.ListItem(label=item[1], label2=item[0], iconImage=item[3])
    li.setInfo('audio', { 'year': item[2] })
    li.setProperty('mimetype', 'video/x-msvideo')        # No effect?
    li.setProperty('IsPlayable', 'False')                # No effect?
    li.setProperty('IsFolder', 'False')                  # No effect?
#    url = 'track-top10.php?s=%s' % (urllib.quote_plus(search_string.encode("utf-8")))         # saw this in another thread.. might need the urllib thingamagicky someday..
#    url = unicode(sys.argv[0] + '?f=ff')                # Testing.. something hates "plugin" as a "protocol" tho..
    url = ''                                             # Seems to be the best not-working "solution"
    listing.append((url, li, False))

xbmcplugin.addDirectoryItems(addon_handle, listing)
xbmcplugin.endOfDirectory(addon_handle)

I have tried setting the entire xmbcplugin to .. "do not scan items" (at work, cannot remember the term) but with no effect.

What
It works, but something is fishy:

1. If I set the URL to anything I get the XFILE::CFileFactory::CreateLoader error.. One line in the log for each item in the list. with +4000 it gets really ugly.
2. if I leave out the URL, I get the InputStream: Error opening, error.. All the errors in a single line in the log, but still a lot of failing!

The latter seems to be the "fastest" of the two errors, but something is turning the system sluggish and finally all contact to the DB is lost... Kodi restart takes care of that, but it happens way to fast to be ignored.

The errors look like this in case you want to see them..

My error of choice as it is (but it seems to take some time to complete the failing?) :

Code:

19:36:59 T:6856   ERROR: InputStream: Error opening,
19:47:26 T:6012   ERROR: Previous line repeats 1336 times.

And the other type (actually fails faster I think, If the log is any hint?):

Code:

22:07:06 T:2456 WARNING: XFILE::CFileFactory::CreateLoader - unsupported protocol(plugin) in plugin://plugin.video.mymovielist/
22:07:06 T:2456   ERROR: InputStream: Error opening, plugin://plugin.video.mymovielist/
22:07:06 T:2456 WARNING: XFILE::CFileFactory::CreateLoader - unsupported protocol(plugin) in plugin://plugin.video.mymovielist/
22:07:06 T:2456   ERROR: InputStream: Error opening, plugin://plugin.video.mymovielist/
.... repeat ad nauseum ...

Kodi (16.0-BETA2 Git:20151115-07f691e)

[Torben]

I am not surprised to see no answers. Since that is what I saw on most questions on "XFILE" on this forum.
Anyways, I seem to have bypassed the ordeal by setting my plugin to files instead of something more exotic like video or audio.

Code:

<extension point="xbmc.python.pluginsource" library="mediaListMaker.py">
    <provides>files</provides>
  </extension>

I added the code xbmcplugin.setContent(addon_handle, 'files') to the top of the .py, and listitem.setContentLookup(False) to each of the list items but they also seem to do absolutely nothing.

[ironic_monkey]

why are you adding a bunch of invalid items? plugin:// items are either folders or playable. since you add them as files they have to be playable. so kodi tries to extract video thumbs and such and fails miserably because plugin:// urls cannot be opened directly by the XFILE virtual filesystem.

make up your mind on just what you are trying to return, and return those items. not something randomly molested together like the items you return here.

1) if you want to return other plugin:// folders return that (listitem constructor needs isFolder=True)
2) if you want to return playble items, you either
- return a directly playable url (e.g. a http:// url). in that case your url's are all wrong, you don't want to append shit to sys.argv[0].
- or return a plugin:// items and mark it playable, then deal with the resolve of the url using setResolveUrl on callback from ui. this means you have to encode the information needed to resolve the real media url in the plugin:// url returned earlier.

actually i think it's the last bit here you are missing. remember, a plugin is a virtual filesystem entry. it can do two things;
- list a directory
- open a file. the latter being interpreted as forwarding to some actually-readable url (e.g. http).

just read any random plugin to see examples.

[Dimitriss]

why are you adding a bunch of invalid items? plugin:// items are either folders or playable. since you add them as files they have to be playable. so kodi tries to extract video thumbs and such and fails miserably because plugin:// urls cannot be opened directly by the XFILE virtual filesystem.

make up your mind on just what you are trying to return, and return those items. not something randomly molested together like the items you return here.

1) if you want to return other plugin:// folders return that (listitem constructor needs isFolder=True)
2) if you want to return playble items, you either
- return a directly playable url (e.g. a http:// url). in that case your url's are all wrong, you don't want to append shit to sys.argv[0].
- or return a plugin:// items and mark it playable, then deal with the resolve of the url using setResolveUrl on callback from ui. this means you have to encode the information needed to resolve the real media url in the plugin:// url returned earlier.

actually i think it's the last bit here you are missing. remember, a plugin is a virtual filesystem entry. it can do two things;
- list a directory
- open a file. the latter being interpreted as forwarding to some actually-readable url (e.g. http).

just read any random plugin to see examples.

Hi, is there a way to disable thumbnail extraction etc from a plugin (python or xml) ?
Thanks

[ironic_monkey]

probably not currently. i'd argue it trying is a bug in the first place..

[Torben]

Hi ironic_monkey,

I do need to get my lists from somewhere? Should I get them some other way?

I use the "plugin.." to list movies, albums, songs and so forth.. all of it, how I want it, mixed and with just the data I need. (In one case I needed the albumDBID together with the song, and the actual lalbumcover, not the in-file thumbnail).

I use the "plugin" because it seems to fit nicely in a <content> and I just have to set a few home.properties and the lists load the content I want it to load.

I handle the queueing, playing, shuffle/random, display of details, playlists etc., when needed - on "my own" since Kodi provided too little control of that. (see other threads if you are so inclined). I don't need filenames in my lists, and I don't need Kodi poking about doing "magic stuff".

I saw no alternative but to roll a plugin to provide the information I needed (which btw, is very very little compared to passing descriptions, genres, cast and whatnot with every listitem). I have a feeling I'll end up doing a thumbnail-thingy also, as it seems the covers used by Kodi are very, very large (I just need about 200x200).

I don't understand why I would need some unknown black-box doing "stuff" to the list?
I don't understand why I shouldn't use a plugin/what I should use instead?

I don't want to return a path at all. I don't want Kodi to "fill in the blanks". I just need to list the items with the info I choose.
I handle the action in a onclick script based on the dbid.

peace..

This is the in-log-errorfree add items code I ended up with as the rest did not do anything - for me. List is pre-sorted:

Code:

    for item in l:
        li = xbmcgui.ListItem(label=item[1], label2=item[0], iconImage=item[3])
        listing.append(('', li, False))
    xbmcplugin.addDirectoryItems(addon_handle, listing)
    xbmcplugin.endOfDirectory(addon_handle)

p.s. You might know more about the mystery that is "XFILE::"? Is there a place to read all about it, or would you care to explaining it in more detail, so I can understand what it is/work with it instead of against it?

[ironic_monkey]

Why ask when you are not going to read the answer?

[Torben]

I do read the answers here. I do more searching and reading than asking questions. I speak english fairly well, and I speak "Kodi".. well, not so much. Also, there is little info on this "XFILE" error message.
I apologize for not being clearer on my goal in the first post: I aim to return a list of items to the skin, that bypasses Kodys desire to mess with the returned data. I don't want all the labels filled with god knows what - by god knows what. I don't want thumbnail extraction. I don't want any lookups and magic stuff.. I just want the sparse data returned for me to display and handle as I see fit.
I will not apologize for presenting a post containing what I believe is a working solution. If you - or any Kodi forum members - think it is shitty code, or know of a reason it will not work as expected in the long run I will appreciate the feedback... as it seems to be working just fine. Surely you cannot expect me or anyone to know of all the odd bits and quirks of this long running engine!

why are you adding a bunch of invalid items?

I am not the one who claims to be the expert here. I add "invalid items" because that's the best I know.

plugin:// items are either folders or playable. since you add them as files they have to be playable. so kodi tries to extract video thumbs and such and fails miserably because plugin:// urls cannot be opened directly by the XFILE virtual filesystem.

The reason I chose to set the plugin to be return "files" was because that was the only way to get the errors to go away. If I choose audio or video, or both, I would get the aforementioned errors filling up the log. When set to files, there are no visible errors in the log. To me - no errors - indicates that I am on the right track and I believe that way of developing for Kodi is encouraged. If this is causing other errors in the nooks of this engine, they don't show in the log.

make up your mind on just what you are trying to return

I am pretty clear on what I want to return. A list of items for the user to choose from. Just a dumb list to be shown in a panel container. I want to handle the onclick action myself. If there is a better way of doing it, then I want to do that, obviously. I have no need for the list to contain descriptions, genres, cast and a bunch of other information. I just need an icon and the dbid. The details I need are retrieved at a later stage when needed. And contains more information than "normally" provided, eg. discography.

1) if you want to return other plugin:// folders return that (listitem constructor needs isFolder=True)
2) if you want to return playble items, you either
- return a directly playable url (e.g. a http:// url). in that case your url's are all wrong, you don't want to append shit to sys.argv[0].
- or return a plugin:// items and mark it playable, then deal with the resolve of the url using setResolveUrl on callback from ui. this means you have to encode the information needed to resolve the real media url in the plugin:// url returned earlier.

As far as I can tell, I don't want to return playable files, and I don't want to return folders. I don't want to return to my plugin again, and I don't want to activate the scrapers/auto-label-info-fillers. If I need to use "folders" as a workaround for a lack of a better option, I'll gladly do that. Is that what you recommend?

I marked all the listitems with "isFolder", but I see no difference in performance. Should I "mark" the plugin as something special also? I noticed there is a "path" parameter in the listitems, but I don't know what it is used for.. Keep in mind here that the goal is to simply list a "bunch of (invalid) items" and bypass all of Kodi's build in.. features.

actually i think it's the last bit here you are missing. remember, a plugin is a virtual filesystem entry. it can do two things;
- list a directory
- open a file. the latter being interpreted as forwarding to some actually-readable url (e.g. http).

I guess returning items from the library (mixed up and filtered as I see fit) would count as listing a directory?

just read any random plugin to see examples.

It might be "just" to you, but I haven't spend a decade here.. yet! I just wanted a nice GUI for my media is all.

[ironic_monkey]

so what you want is to return a list of actual folders? then do that. just make sure to set the url to the folder url, not something derived from sys.argv[0] - that has the form plugin://<yourid>/ - and thus you create items looking like plugin://<yourid>/<something>.

[Torben]

so what you want is to return a list of actual folders?

You ask if I want to return folders. Again, I don't see how this has anything to do with folders. Unless folders is Kodi-slang for items that are not playable. Then, yes, I want to return folders.

just make sure to set the url to the folder url, not something derived from sys.argv[0] - that has the form plugin://<yourid>/ - and thus you create items looking like plugin://<yourid>/<something>.

I don't know what a folder url is, in my language, a folder is a path on the HDD. From your answer I deduct that it is the path to the plugin, using the Kodi "Plugin" protocol, and you are saying to set the url of each item to "Plugin://[mypluginpath]/whatever". Is that correct?

Why do I need to set it if I have no plans on using the url for anything? To prevent Kodi from "processing" the files?

Thanks for your patience.

[ironic_monkey]

again, the plugin is a virtual filesystem entry. a call to the plugin is like listing a directory. the directory can contain either files or folder, each of which can be of 2 types.

files:
1) a normal file item, pointing to some file path. this can be a real file on your hdd, or a http stream. this shall have a url of any type != plugin://, and have the folder flag set to false.

2) a virtual file. this is used to allow plugins to resolve the actual url to some stream when the user clicks an item in the GUI. this is needed for two reasons;
-a lot of online stream urls are very short-lived so you cannot resolve them when listing the directory
- resolving the actual playback url for a stream can be time consuming and you do not want to do this for every stream upon listing the directory.
these shall have a url of the type plugin://<addon id to call for resolving url>/<parameters needed to encode which items we are to resolve the url for>, the fileitem needs to be marked playable and the folder flag shall be false. when the user clicks the item in the GUI, we re-call your plugin with the url of the item you assigned to the virtual playable fileitem. the plugin shall then do the resolving and return the final playback URL using setResolvedUrl()

directory:
1) a normal item, pointing to some directory on e.g your hdd. this shall have a url of any type != plugin://, and have the folder flag set to true.
2) a subfolder of your plugin's virtual filesystem. this shall be of the type plugin://<your addon id>/<parameters encoding the subfolder of the plugin's virtual filesystem> and the folder flag shall be true.

[Torben]

Thanks for trying to answer my questions.

So, to recap: To list items from the library, a plugin is the way to go. If these items are not to be played, scraped, have thumbnails extracted, have extra information included automatically but simply return a dumb list of items with only the parameters set within the plugin - to a container where the action is handled onclick in the skin - the plugin (be that music, video or whatever, doesn't matter) must simply return items with isfolder=true and isPlayable=false and the url must be set to "plugin://sys.argv[0]/some_dummy_string".

There are still many questions left unanswered btw.

[ironic_monkey]

no. what you describe is file, point 2!

[Torben]

Except I don't want the plugin recalled?!

[ironic_monkey]

you said you wanted the item to be processed onclick. if not, then it's just normal files aint it ?