2014-08-29, 18:33
As the title says I've noticed an issue with artwork not reloading after the resume status is updated.
On the Raspberry pi Helix Alphas This is happening 95% of the time.
On the PC using 13.1 its 50/50 chance.
Steps to recreate:
1. Start a video from the beginning
2. Watch or skip in far enough that when you stop it will update as part watched (where you get the resume option when selecting in library)
3. Stop the video
The poster will reload but the fanart will not
*On the PC this is less likely to bug*
You can also do the reverse (start by resuming a video, skip back to beginning and stop, it will remove the watch status and bug)
starting the video from the beginning (with no part watched status set) and stopping before a part watched status gets set does not trigger this bug.
Here is a video of how to recreate the Bug (note this is on the Pi)
http://youtu.be/soxos3XDi5I
Log: (note this is from Windows 13.1)
(I retook this debug log as this one behaves exactly the way it should, bugs everytime it could, and doesnt bug when it shouldnt (according to my theory))
http://pastebin.com/BdtwSbyj
I first raised this in the Raspberry pi development builds and here is what the OP had to say on the matter:
On the Raspberry pi Helix Alphas This is happening 95% of the time.
On the PC using 13.1 its 50/50 chance.
Steps to recreate:
1. Start a video from the beginning
2. Watch or skip in far enough that when you stop it will update as part watched (where you get the resume option when selecting in library)
3. Stop the video
The poster will reload but the fanart will not
*On the PC this is less likely to bug*
You can also do the reverse (start by resuming a video, skip back to beginning and stop, it will remove the watch status and bug)
starting the video from the beginning (with no part watched status set) and stopping before a part watched status gets set does not trigger this bug.
Here is a video of how to recreate the Bug (note this is on the Pi)
http://youtu.be/soxos3XDi5I
Log: (note this is from Windows 13.1)
(I retook this debug log as this one behaves exactly the way it should, bugs everytime it could, and doesnt bug when it shouldnt (according to my theory))
http://pastebin.com/BdtwSbyj
I first raised this in the Raspberry pi development builds and here is what the OP had to say on the matter:
(2014-08-29, 17:41)Milhouse Wrote: I believe the watched status is updated in the database by a separate thread, I wonder if this is somehow conflicting with the fanart query. I'm using MySQL, you're using SQLite, so at least it's not a db backend-specific issue. A concurrency issue like this may be more likely on low powered devices, so may be more difficult to reproduce on x86.
My guess is that the in-memory cache used to display library details (including fanart) is being corrupted when the conflict occurs, "losing" the fanart, which is why the problem remains until you exit the library and re-enter (which re-loads the cache).
