[ksooo]

I think we can fix this via the same thing I we now do for reseting resume points. We need to do the call to update the gui probably best done near the database change request.

No, this is completely different. It's not at all about notifying changes. We have no clue how to identify the right folders as obviously not all folders should get the context menu items in question. That's the actual problem.

Okay, but not so sure about that. That would mean that the availability of resume points is also not correct and should not be handled by estuary like that?
I somehow still think, it might be two bugs crossing each others path. But that's just a feeling, can't say anything concrete and you seem to have looked at it, so you're probably right

No, these are two completely unrelated stories. The problem discussed here is solely about the visibility condition for mark watched / unwatched.

And I do absolutely not get what Estuary should have to do with that. Core context menu items are 100% coded in c++, no skin xml involved.

[Razze]

No, this is completely different. It's not at all about notifying changes. We have no clue how to identify the right folders as obviously not all folders should get the context menu items in question. That's the actual problem.

Okay, but not so sure about that. That would mean that the availability of resume points is also not correct and should not be handled by estuary like that?
I somehow still think, it might be two bugs crossing each others path. But that's just a feeling, can't say anything concrete and you seem to have looked at it, so you're probably right

No, these are two completely unrelated stories. The problem discussed here is solely about the visibility condition for mark watched / unwatched.

And I do absolutely not get what Estuary should have to do with that. Core context menu items are 100% coded in c++, no skin xml involved.

Correct, but I would think that the visible conditions in the c++ context menu are off for this case and that we don't refresh the ui correctly.
See:

I then try to use the context menu and select "mark as watched" but the file still appear as "in progress":

[ksooo]

Okay, but not so sure about that. That would mean that the availability of resume points is also not correct and should not be handled by estuary like that?
I somehow still think, it might be two bugs crossing each others path. But that's just a feeling, can't say anything concrete and you seem to have looked at it, so you're probably right

No, these are two completely unrelated stories. The problem discussed here is solely about the visibility condition for mark watched / unwatched.

And I do absolutely not get what Estuary should have to do with that. Core context menu items are 100% coded in c++, no skin xml involved.

Correct, but I would think that the visible conditions in the c++ context menu are off for this case and that we don't refresh the ui correctly.
See:

I then try to use the context menu and select "mark as watched" but the file still appear as "in progress":

@Razze may I suggest to concentrate on fixing the "visibility" bug first. Mixing unrelated problems together only increases complexity and makes people not talking straight to the point and increases chances for not understanding each other. ;-)

[Razze]

So "Mark as watched" does not work because "ClearBookmark" get's called with an empty path variable here https://github.com/xbmc/xbmc/blob/8ddffa...ob.cpp#L99

Because we think we have a VideoInfoTag here: https://github.com/xbmc/xbmc/blob/8ddffa...ob.cpp#L96 and overwrite the valid path with an empty one. VideoInfoTag is not nullptr like it should be and seems to only have resume populated.

I don't think there is a visibility bug as far as I can tell now. It's just that played count get's changed but the bookmarks not.

[ksooo]

So "Mark as watched" does not work because "ClearBookmark" get's called with an empty path variable here https://github.com/xbmc/xbmc/blob/8ddffa...ob.cpp#L99

Because we think we have a VideoInfoTag here: https://github.com/xbmc/xbmc/blob/8ddffa...ob.cpp#L96 and overwrite the valid path with an empty one. VideoInfoTag is not nullptr like it should be and seems to only have resume populated.

I don't think there is a visibility bug as far as I can tell now. It's just that played count get's changed but the bookmarks not.

Sorry, we're talking about different things. Don't know how to explain it with better words. I'm out.

[ksooo]

By reading the OP I just realized that I mixed up threads here and I was talking all the time about an issue reported in another thread.

I do very sorry for the confusion I might have caused.

So yeah @Razze your are probably completely right with what you're writing here.

[Gracus]

Big Thanks to Razze!

His fix has finally been merged and all works perfectly now

[mabnz]

I'm seeing this precise issue. Is there anything I can do to help fixing the problem? It's really annoying..

[waclaw66]

Hi,
it seems that the problem with watched mark persists even in Kodi 18 RC3.
When I open series list there is no watched mark, but episodes are watched already.
There is a trick to show those marks. When I go to the left menu and select "Go to the track list" and then back, marks appear.

https://youtu.be/ZrGGN1BIli8

Regards
Waclaw

[Razze]

Hi,
it seems that the problem with watched mark persists even in Kodi 18 RC3.
When I open series list there is no watched mark, but episodes are watched already.
There is a trick to show those marks. When I go to the left menu and select "Go to the track list" and then back, marks appear.

https://youtu.be/ZrGGN1BIli8

Regards
Waclaw

Did you report this on the bug tracker?

[Martijn]

https://github.com/xbmc/xbmc/pull/14992