Solved Mark as watched/Mark as unwatched issue outside of library
#16
Just to know if there is a last chance to fix this, I retry portable mode

Here is what I did:

-install latest kodi 64-bits nightly in portable mode (only the installation path has been changed during installation)
-open kodi
-add the "clip" folder as source with content type set to "none"
-put on debug logging
-close kodi

At this point, I'm ready for testing:

-open kodi
-access my source through the "video" section (don't forget that the cotent type of this source is "none")
-start playback of one of the video
-seek to the middle of the file
-stop playback

At this point, the file is marked as "in progress":
Image

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

BUT if I open again the context menu, I now have the option "marked as unwatched" which should tell that the file has been marked as watched:
Image

You can even see I still have the option to resume playback...

Here is the log (should not show anything more than the previous one: https://pastebin.com/0rW6DTBj
Moanbag is in da place!
Reply
#17
Ok ya got me....

Quote:(don't forget that the cotent type of this source is "none")

I missed the trick of adding a source, with no content type set. I get a partial the file is marked as "in progress" but the image in T! offers more than one look as to indicate 1/4, 1/2, 3/4 Note: I checked all this behaviour with both Estuary and T!, so it's not skin exclusive.

Both unwatched and watched are ineffective. So I'm pretty close to replication of your issue. Changing the content to movies, then indicate local scraper and no scrape, brings on the partial indicator but overlays the check mark on the partial for watched. (yes two icons over top each other) , marked as unwatched, the partial icon remains. As noted, all this works as designed in library mode or file mode if the source is specified. Suspect some sort of cache or video cache fetch (could be gfx card mem related).

Image

Suggestion: If you're determined to use Kodi as a stand-alone media player without the library, just use windows explorer with the 'open with' method or better still explore the add-on 'Last Played'. Personally, I don't regard this as a hard bug, nothing I would dare put in the bugtracker, we have bigger fish to fry ATM.
Reply
#18
Not a killer bug for me neither

I use library mode for all my movies/TVshow/music

Just got one or two folder with content type set to none because it is either personnal video or some music video that absolutly no scraper will have info about

Just a guess: in file mode, marking as watched or marking as unwatched does not delete the "in progress" info from wherever kodi store those

So just take a little time to look at it when it will be possible
Moanbag is in da place!
Reply
#19
Issue still there on today's nightly
Moanbag is in da place!
Reply
#20
(2017-09-04, 14:28)Gracus Wrote: Issue still there on today's nightly


Sure, because nobody worked on it. ;-)
Reply
#21
(2017-09-04, 17:42)ksooo Wrote:
(2017-09-04, 14:28)Gracus Wrote: Issue still there on today's nightly


Sure, because nobody worked on it. ;-)

Yeah!

That's what I understand from your post in the 64bit kodi thread

I will just stop "bumping over and over" as you said (or maybe someone can simply close this thread once and for all)
Moanbag is in da place!
Reply
#22
Do you remember roughly when you first started seeing this behaviour? and is it only with Leia nightly builds? so is Krypton v17.4 ok? This would help narrow down range of possible PR's since I don't know the code area this behaviour would come from and I don't see anything obvious at the moment in the list of closed PR's from just before you made this post, looking back further this could be a possibility https://github.com/xbmc/xbmc/pull/11115
Reply
#23
(2017-09-10, 18:22)jjd-uk Wrote: Do you remember roughly when you first started seeing this behaviour? and is it only with Leia nightly builds? so is Krypton v17.4 ok? This would help narrow down range of possible PR's since I don't know the code area this behaviour would come from and I don't see anything obvious at the moment in the list of closed PR's from just before you made this post, looking back further this could be a possibility https://github.com/xbmc/xbmc/pull/11115

I created this thread as soon as I saw the issue and was able to reproduce it on 3 or 4 nightlies in a row

As I almost use kodi in library only (except for some video I watch once in a while), I can not tell exactly when it start

If It could help I can try to reproduce the issue on kodi 18 to get a new log and on kodi 17.4 to see if the issue is there too and post a log if it is

EDIT: If I found the issue with 17.4, I could also try with older 17.x releases to try to narrow down when it first occured
Moanbag is in da place!
Reply
#24
(2017-09-10, 18:41)Gracus Wrote: I created this thread as soon as I saw the issue and was able to reproduce it on 3 or 4 nightlies in a row

So my follow up questions, is that when you first started using v18 nightlies? or had you been using them prior to that? in other words do you remember using a v18 nightly that didn't have the issue?
Reply
#25
(2017-09-10, 18:54)jjd-uk Wrote:
(2017-09-10, 18:41)Gracus Wrote: I created this thread as soon as I saw the issue and was able to reproduce it on 3 or 4 nightlies in a row

So my follow up questions, is that when you first started using v18 nightlies? or had you been using them prior to that? in other words do you remember using a v18 nightly that didn't have the issue?

I switch to kodi 18 in February when Guilouz release his skin for kodi 18 (first 32bits and then 64bits)

I only saw the issue when, after I made a brand new kodi installation in June, I launch a video to make the video/sound/subtitle settings

This time I use a video outside of library mode instead of using one of my movies like I always did before

Seems I mostly find this issue "luckily" but will try to narrow it down with all the kodi releases I can find now: kodi 18 nightly 64bits, kodi 17.x latest nightly, kodi 17.4 and kodi 17.3 (seems older releases are no more available)

Just need the time to make all those tests and I will provide the log for each one of them
Moanbag is in da place!
Reply
#26
@jjd-uk we know exactly what caused this problem - it's fallout from porting the video window context menu items to the new context menu item system, in early Leia times. Unfortunately, the author of that port seems not interested in fixing this and also it seems that nobody else is able/willing to do this.
Reply
#27
(2017-09-10, 19:55)ksooo Wrote: @jjd-uk we know exactly what caused this problem - it's fallout from porting the video window context menu items to the new context menu item system, in early Leia times. Unfortunately, the author of that port seems not interested in fixing this and also it seems that nobody else is able/willing to do this.

Thanks for your answer

Will mark the thread as solved
Moanbag is in da place!
Reply
#28
(2017-09-10, 19:55)ksooo Wrote: @jjd-uk we know exactly what caused this problem - it's fallout from porting the video window context menu items to the new context menu item system, in early Leia times. Unfortunately, the author of that port seems not interested in fixing this and also it seems that nobody else is able/willing to do this.

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.
Reply
#29
(2017-09-11, 13:12)Razze Wrote:
(2017-09-10, 19:55)ksooo Wrote: @jjd-uk we know exactly what caused this problem - it's fallout from porting the video window context menu items to the new context menu item system, in early Leia times. Unfortunately, the author of that port seems not interested in fixing this and also it seems that nobody else is able/willing to do this.

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.
Reply
#30
(2017-09-11, 13:19)ksooo Wrote:
(2017-09-11, 13:12)Razze Wrote:
(2017-09-10, 19:55)ksooo Wrote: @jjd-uk we know exactly what caused this problem - it's fallout from porting the video window context menu items to the new context menu item system, in early Leia times. Unfortunately, the author of that port seems not interested in fixing this and also it seems that nobody else is able/willing to do this.

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 Smile
Reply

Logout Mark Read Team Forum Stats Members Help
Mark as watched/Mark as unwatched issue outside of library0