• 1
  • 232
  • 233
  • 234(current)
  • 235
  • 236
  • 355
v18 LibreELEC Testbuilds for x86_64 (Kodi 18.0)
Here is the first Debug log as requested with Kodi set to 108060P
 http://ix.io/18xX

Here is the link after reboot which made it switch back to 4k30P

http://ix.io/18xX

The links looks the same?

I followed your steps
(2018-05-24, 01:14)atoulmin Wrote: Here is the first Debug log as requested with Kodi set to 108060P
 http://ix.io/18xX

Here is the link after reboot which made it switch back to 4k30P

http://ix.io/18xX

The links looks the same?

I followed your steps

Ah yes... step 5 is incorrect and there needs to be a step 6:

5. Assuming Kodi starts in 4K/30Hz, login with ssh and run systemctl stop kodi (this flushes any new/modified settings to disk)
6. Run cat /storage/.kodi/userdata/guisettings.xml | pastebinit and paste the link.

I'm assuming there will be a difference between the two guisettings.xml, although what that would mean I'm not entirely sure right now...
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
I have compared the limited colour range between LibreELEC 8.2.5 and Build#0522. You can find the results here: https://imgur.com/a/NLZzuqq. Compare '8.2.5-limited-colour-range-on' with '0522-limited-colour-range-on' and you will find that there is quite a difference between them. The test image is a 0-255 grayscale pattern.
I think this was the first message about too dark GUI: https://forum.kodi.tv/showthread.php?tid...pid2657925
So what happened after build #1002 ?
(2018-05-24, 07:03)TimoJ Wrote: I think this was the first message about too dark GUI: https://forum.kodi.tv/showthread.php?tid...pid2657925
So what happened after build #1002 ?
 I installed build #1002. Now limited range works correctly: GUI is not dark anymore and when I select limited range in the display settings, picture gets brighter (not darker like it does in newest builds, even after the fix). And that test picture I used earlier is now showing all black boxes down to level 4.
Did more tests, it's actually build #1004 that is the last one that shows correct brightness. Builds from #1005 have too dark GUI and limited selection darkens the GUI. So what happened in build #1005 that caused this?
(2018-05-24, 17:02)TimoJ Wrote: Did more tests, it's actually build #1004 that is the last one that shows correct brightness. Builds from #1005 have too dark GUI and limited selection darkens the GUI. So what happened in build #1005 that caused this?

Most likely:
(2017-10-06, 19:55)Milhouse Wrote:
  1. XBMC:
    • OpenGL: move away from fixed function pipeline (PR:12841, 25 commits, 75 files changed)
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2018-05-24, 17:20)Milhouse Wrote:
(2018-05-24, 17:02)TimoJ Wrote: Did more tests, it's actually build #1004 that is the last one that shows correct brightness. Builds from #1005 have too dark GUI and limited selection darkens the GUI. So what happened in build #1005 that caused this?

Most likely:
(2017-10-06, 19:55)Milhouse Wrote:
  1. XBMC:
    • OpenGL: move away from fixed function pipeline (PR:12841, 25 commits, 75 files changed)

Thx! Fernet spotted the additional issue.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
(2018-05-21, 14:38)TimoJ Wrote:
(2018-05-20, 00:48)username145 Wrote: Also noticed that anytime I seek forwards/backwards during playback, the screen will go black for a split-second, I think to display the buffering overlay. This is a little jarring, especially when it happens on locally stored files, maybe it should only appear after some small delay?
I also have this same problem when I skip or switch to play from FF. Black flash after each skip. Not sure when it started, I was using #0504 before and it didn't have this problem.    
Tested this and #0504 is the last build that is free from the black flash. All builds after that have the same problem. Using Intel Haswell graphics.
Build #0505 added this change, is that the cause for this problem:
VideoPlayer: flush renderManager when hiding video (PR:13824, 2 commits, 1 file changed)
I'm struggling with subtitles in the later builds, using #0522 now and the problem is as follows:

- I can download subs with any subs plugin and these work for the current session, but they are not saved to disk anymore. Hence I have to redownload them when restarting/resuming a video.
- If external subs are present and aptly named next to the video, it is not picked up anymore, I cant even find them when browsing for them.
- In addition (might be related) state (resume point, play state, audio track etc) is no longer saved when stopping the video.

I think I have ruled out NFS access issues, and when running vanilla Leia Alpha 1 on a WIN10 computer against the same library (NAS NFS share + mySQL) all of this works fine.
Any clues?

Wish
(2018-05-25, 07:10)TimoJ Wrote:
(2018-05-21, 14:38)TimoJ Wrote:
(2018-05-20, 00:48)username145 Wrote: Also noticed that anytime I seek forwards/backwards during playback, the screen will go black for a split-second, I think to display the buffering overlay. This is a little jarring, especially when it happens on locally stored files, maybe it should only appear after some small delay?
I also have this same problem when I skip or switch to play from FF. Black flash after each skip. Not sure when it started, I was using #0504 before and it didn't have this problem.     
Tested this and #0504 is the last build that is free from the black flash. All builds after that have the same problem. Using Intel Haswell graphics.
Build #0505 added this change, is that the cause for this problem:
VideoPlayer: flush renderManager when hiding video (PR:13824, 2 commits, 1 file changed) 
 That's by intention ... so that for livetv the stream starts with the picture itself and that not the old pic stays on screen.

For the Limited GUI issue: https://github.com/xbmc/xbmc/pull/13934
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
(2018-05-25, 14:10)fritsch Wrote:
(2018-05-25, 07:10)TimoJ Wrote:
(2018-05-21, 14:38)TimoJ Wrote: I also have this same problem when I skip or switch to play from FF. Black flash after each skip. Not sure when it started, I was using #0504 before and it didn't have this problem.     
Tested this and #0504 is the last build that is free from the black flash. All builds after that have the same problem. Using Intel Haswell graphics.
Build #0505 added this change, is that the cause for this problem:
VideoPlayer: flush renderManager when hiding video (PR:13824, 2 commits, 1 file changed)   
 That's by intention ... so that for livetv the stream starts with the picture itself and that not the old pic stays on screen.

For the Limited GUI issue: https://github.com/xbmc/xbmc/pull/13934  
But that ruins skipping during playback of videos. Sometimes I skip 2-3 times in a row and now I get 2-3 black flashes.. Maybe it should be active only during livetv?
(2018-05-25, 14:10)fritsch Wrote: For the Limited GUI issue: https://github.com/xbmc/xbmc/pull/13934

Is the calculation in the pr correct?
:
fragColor.rgb *= (235.0-16.0) / 255.0;
fragColor.rgb += 16.0 / 255.0;

You changed the same calculation on your last commit Fixed for Limited Range
Code:
- m_col[0] = (235 - 16) * m_col[0] / 255 + 16.0f / 255.0f;
- m_col[1] = (235 - 16) * m_col[1] / 255 + 16.0f / 255.0f;
- m_col[2] = (235 - 16) * m_col[2] / 255 + 16.0f / 255.0f;
+ m_col[0] = (235 - 16) * m_col[0] / 255 + 16;
+ m_col[1] = (235 - 16) * m_col[1] / 255 + 16;
+ m_col[2] = (235 - 16) * m_col[2] / 255 + 16;
Yes, it is correct. uniform values between 0 and 1.0 are here the input!
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
(2018-05-25, 14:10)fritsch Wrote:
(2018-05-25, 07:10)TimoJ Wrote:
(2018-05-21, 14:38)TimoJ Wrote: I also have this same problem when I skip or switch to play from FF. Black flash after each skip. Not sure when it started, I was using #0504 before and it didn't have this problem.     
Tested this and #0504 is the last build that is free from the black flash. All builds after that have the same problem. Using Intel Haswell graphics.
Build #0505 added this change, is that the cause for this problem:
VideoPlayer: flush renderManager when hiding video (PR:13824, 2 commits, 1 file changed)  
 That's by intention ... so that for livetv the stream starts with the picture itself and that not the old pic stays on screen.

  
This is not correct. Check description of https://github.com/xbmc/xbmc/pull/13824 I'll try to use DiscardBuffers instead. That keeps the frame on screen.
  • 1
  • 232
  • 233
  • 234(current)
  • 235
  • 236
  • 355

Logout Mark Read Team Forum Stats Members Help
LibreELEC Testbuilds for x86_64 (Kodi 18.0)24