[da3dsoul]

The watched status displays correctly assuming there is no cached value generated by ToggleWatched. Everything works in Jarvis, that's not the issue. In Jarvis we can proactively prevent a user from marking an item as watched, so long as they don't press w. The ideal situation is to allow a plugin to intercept the built in mark as watched, so if the user presses w or uses the context menu, it works.

[User 342716]

It is still sad to be forced to use specific items. This feels like a real like a bad step in removing customization. And as a user i hate seeing a screen filled with useless context menu items. I was never a fan of the hide all approach either though. Personally id prefer an option to include a list of items you want to keep that are in the default. If this is the path you want to follow then at least add the option to replace all and replace non standard. When i wrote my plugin i know i wanted to remove all but favorites, but this was not an option so i had to build favorites from scratch. Is it safe to assume this will break all custom UI's since users will be stuck wtih context menu that does nothing even if the dev did not program one, or does this only affect standard UI's?

[bigretromike]

It is still sad to be forced to use specific items. This feels like a real like a bad step in removing customization. And as a user i hate seeing a screen filled with useless context menu items. I was never a fan of the hide all approach either though. Personally id prefer an option to include a list of items you want to keep that are in the default. If this is the path you want to follow then at least add the option to replace all and replace non standard. When i wrote my plugin i know i wanted to remove all but favorites, but this was not an option so i had to build favorites from scratch. Is it safe to assume this will break all custom UI's since users will be stuck wtih context menu that does nothing even if the dev did not program one, or does this only affect standard UI's?

As I understand why they want to handle this the way they does they should honor some of the user base also. One of many big advantages that Kodi has was that it was more open than any other media center platform.

I could only image how hard would be debuging crash report when someone used some item from context menu that was added by one of 2000 plugin that the user had installed, but please dont close the ability to customize option... Removing deprecated function is ok, but some of plugin developers would love to have ability to use newer function that is given to us while removing the deprecated ones.

Give us something... overwrites to default build-in function, relinking items in context menu, hidding build in items, set order for items... anything...

Assume nothing is done: end user see that the context menu have big list of items some with ( ) including name of plugin or any other marks so he know which one is what... what that use would think ?
He can think of two things:
1. Developer of the plugin he use don't know how to make one, so he try another plugin with similar functionality if there is one available
2. Kodi is to "noisy" and throw large menus for something simple as "add this to ..." and have very negative and not true image of kodi as whole

What developers could do ? :
1. Stay on deprecated version so in the end there would be 2 user base (newest version of kodi, and the one that plugin developer suggest)
2. Move to other platform

Also:

@Wintermute0110, as the "PLAY" is useful with our (mine and @da3dsoul) project. add to favorite is not. Also problem is that the top item isn't "Play" but its the item that is added to context menu, Mark as watched - as I wrote before also is doubled (mine - the one that send data to metadata server, then mark the item on list etc..) and the build-in that mark it in database (that we dont use) and mark it on list view. So if you would use context menu just to play item there would have to be another (redundant) play just because it should be at the top of context menu (so mine play, mine play without mark (as thats also item that we use), other items that we use and then play, add to favorite and anyother build in item).

Now you see why any added feature for this would resolve problems, if not modify or hiding items a simple sort order would be great (imo). hiding, or hiding and sorting would be ultimate solution if the 'old legacy' way is no-go.

[poppy_pl]

Did something came up from this thread ? Did Team-Kodi left this as is ?

[matthuisman]

Looks like the bug where "Play" "Mark as Watched" "Play from Here" is still being added to list items that are not playable.
A non-playable list item should only have "Add to favourites" (same as a folder).

Update:
Actually, it was because i was setting "plot" to my list item.
If you set any "video" info, then KODI will think it's playable - regardless of the IsPlayable.
I was doing this to get rid of the "No information" by setting this to the label.
Another gotcha when testing is that KODI will cache that video info for that plugin path.
So, even if you fix it - if the video db is not cleared - KODI will keep thinking it's playable.

[bigretromike]

or you can simple add items to context menu you want and fill rest of items with '' resulting with moving the default ones in non visible spot (you can always move down to them), sadly this create a bit unnecessary longer context menu.
Its nightmare for plugins that serve videos with all plots/info etc but want to use custom functions for 'mark as watched', 'play'. Play can be easily overwrite by extending xbmc.Player(), but sadly not the 'mark as watch' or 'Informations'

[enen92]

Its nightmare for plugins that serve videos with all plots/info etc but want to use custom functions for 'mark as watched', 'play'. Play can be easily overwrite by extending xbmc.Player(), but sadly not the 'mark as watch' or 'Informations'

That's a feature for plugins. Plugins should not use xbmc.Player() but rely only on setResolvedUrl

[bigretromike]

It was pointed out by other Team-Kodi members that using Player().play have it own use (disable 'watch' mark or resume)
But that's not the issue here.

How using

python:
setResolvedUrl

resolve issue with default context menu showing up ? Please elaborate because I don't know.
or maybe you refer to overwriting "mark as watched", "information", "play" from default context menu ? How using setResolvedUrl resolve this issue because I would gladly use it...

Currently you can make your own player

python:


class MyPlayer(xbmc.Player):

    def __init__(self):

        ....

    def onPlayBackStarted(self):

        .... handle what to do when play started

        .... inform server that user started to watching movie etc...



    def onPlayBackEnded(self):

        .... inform server that video was watched and handle marking on server side

        .... this way when you return { } with items we will know which were watched and which ain't so we can sync watch state across all clients.



    def custom_function_that_manipulate_player(self, parameters):

        ... do your stuff

    def play(self):

        ... custom ...

But you can't overwrite 'mark as watched' when you dont want Kodi to mark you videos because that is handle by external server.

And Im not sure how setResolvedUrl can help here ?!

[bigretromike]

Its nightmare for plugins that serve videos with all plots/info etc but want to use custom functions for 'mark as watched', 'play'. Play can be easily overwrite by extending xbmc.Player(), but sadly not the 'mark as watch' or 'Informations'

That's a feature for plugins. Plugins should not use xbmc.Player() but rely only on setResolvedUrl 

 I forget to quote you.

[enen92]

It was pointed out by other Team-Kodi members that using Player().play have it own use (disable 'watch' mark or resume)
But that's not the issue here.

Maybe I was not clear enough. xbmc.Player() has its own uses however certainly NOT to disable watch or resume marks. It is used to monitor player events (reacting accordingly) or used in scripts (not plugins) to create custom player instances which often rely on skinning.

You can also use xbmc.Player().play() to trigger playback in plugins if that fits your use case but... in this case...you have to point play() to a plugin:// path which resolves the stream using setResolvedUrl. The problem with Player().play() in plugins is related to the fact Kodi internally stores each played file with the path provided to the player. If you send a stream url that was the result of a resolving process (do not confuse with setResolvedUrl) to the play() method:

shell:


HTTP get

Parse result headers

Another get Request

Final stream url

xbmc.Player().play(Final stream url)

the resulting stream may not be unique and will change each time you request playback (e.g. aditional query arguments on the stream url) although your listitem is the same. Plugin:// paths that will SetResolvedUrl are unique regardless of the final stream url (dynpath). In this case, kodi will store only 1 item in the database independently of the amount of times you play an item.

Context menu items and resume/watched marks are functionalities provided by the core that every plugin should take advantage of. If you see something happening that in your opinion should not (ex: a realtime stream should not have resume points, watched marks or context menu items to resume) this is likely a fault in the core itself which needs to be addressed. It's better to simply report the issue with examples than relying on hacks to achieve the same functionality.

In case you need to report playback to an external server you have to rely on xbmc.Player() to monitor playback. This should be handled by a service extension point in your addon and not by a plugin extension point. Both can coexist in the same addon.

I'll try to have a look into the issues you point out.

Cheers

[poppy_pl]

It was pointed out by other Team-Kodi members that using Player().play have it own use (disable 'watch' mark or resume)
But that's not the issue here.

...

In case you need to report playback to an external server you have to rely on xbmc.Player() to monitor playback. This should be handled by a service extension point in your addon and not by a plugin extension point. Both can coexist in the same addon.

...

 Hey, I never read anywhere on kodi wiki that you can mix type of plugins/addons. I always thought that If you need to monitor Player you would make separate 'script.module.xyz' that build on top of Player class and just yous your Player() that have additional functions like raporting to server  or make a service outside your main `plugin.video.xyz' and just import it. Is that something new or its not important if you keep service with plugin and can be ignore when you push addon to kodi-official-repo ?

[enen92]

It is a good practice to separate them into individual addons and simply set them as dependencies of the main addon. But there is no problem in bundling them under the same addon as long as you name the addon id as the first extension point you define (the main one). Addons like netflix set a service and a plugin in the same addon (two extension points). I have a screensaver which is a screensaver, a service and also a plugin (that I hope to simplify soon)

[poppy_pl]

...

I'll try to have a look into the issues you point out.

Cheers 

 I'm also curious about this. Because there is a lot of DIY/Docs that sometimes are outdated.

It would be awesome if using

python:
xbmcplugin.setContent(files)

would resolve issues but then again from what other people write and from my own experience setting something like PLOT will overwrite the content type by adding ContextMenu that is liked with Video even when Content is set to FILES. One would speculate why would you setContent when you can skip it in the long run.

[enen92]

...

I'll try to have a look into the issues you point out.

Cheers 

 I'm also curious about this. Because there is a lot of DIY/Docs that sometimes are outdated.

It would be awesome if using

python:
xbmcplugin.setContent(files)

would resolve issues but then again from what other people write and from my own experience setting something like PLOT will overwrite the content type by adding ContextMenu that is liked with Video even when Content is set to FILES. One would speculate why would you setContent when you can skip it in the long run.  

 Fernet addressed the root cause of this properly in https://github.com/xbmc/xbmc/pull/14322 after my failed attempt. It should likely be available in Leia.
Basically, the ability to create bookmarks is determined after you play the file. If the video is a livestream or the videoplayer cannot create bookmarks, resume points will not be set. Hence, in Leia if you create a playable listitem in your addon and the player detects it can't be resumable, context menu items and the resume marks will not be shown in the gui. There is nothing to document in this case as nothing changed in the python api.

If you have any other issues please report with proper use cases and examples. That's the only way Kodi can move forward, not relying on hacks everywhere. Same goes for outdated documentation/wiki, its impossible to keep an eye on everything.

[matthuisman]

@enen92 

That sounds great.
How can we set a listitem as a live stream?
Set the totaltime to 0?

Oh, just found isrealtimestream after seeing a reference in that commit.
I'll give that a shot

Oh wait, that wasn't commited.

Just tried latest nightly and works great.
Even while playing a live stream - no longer do you see the total time (YAH!)
It also doesn't let you try to rewind etc.
Much nicer.

Only small "annoyance", is that "Mark was watched" is still a context menu item.
It also marks streams as watched.
For Live this doesn't seem to make sense to me - but isn't too big a deal.

Anyway, happy!
No more ".pvr" hack!