Kodi Community Forum

yes, in config.txt I put in the string "dtoverlay=lirc-rpi"

(2015-12-28, 00:59)bollstedt Wrote: [ -> ]yes, in config.txt I put in the string "dtoverlay=lirc-rpi"

Please paste the output from the following commands:

New OpenELEC K* build #1227: RPi / RPi2
(Supercedes previous build)


Based on tip of OpenELEC master (6551bd11, changelog) and tip of XBMC master (818dc38c, changelog) with the following modifications:

• Includes newclock5 patches
  
• Excludes the OpenELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-4.4.y
  
• Default setting for "Show RSS Feed" changed to disabled (new installs only) [patch details]
  
• Disabled "Total Duration" in Confluence (see build #0221 for details)
  
• Includes latest dcadec master (3a8b58ed, ahead +138)
  
• Includes latest kodi-platform master (45d6ad19, ahead +1)
  
• Includes latest libcec master (2f625959, ahead +40)
  
• Includes latest libnfs master (034c277c, ahead +26)
  
• Includes latest p8-platform master (cce6a497, ahead +10)
  
• Includes platform master (a1e59058, ahead +8)
  
• Includes latest addons: adsp.basic (cb56e0eb, +4), adsp.biquad.filters (d63d8ac6, +6), adsp.freesurround (08b691d3, +1), asplib (2fac1bf3, +2), pvr.argustv (86a8058a, +2), pvr.demo (e6f4d317), pvr.dvblink (1cbc6dc1), pvr.dvbviewer (03ed8718), pvr.filmon (e74e9714), pvr.hdhomerun (070aca3b), pvr.hts (43288dbf, +10), pvr.iptvsimple (eda38ccf), pvr.mediaportal.tvserver (93de38e2), pvr.mythtv (0499bfaa, +2), pvr.nextpvr (0547ce53), pvr.njoy (eac0f6fc), pvr.pctv (2ca34f92), pvr.stalker (9400b421), pvr.vbox (5571c04b), pvr.vdr.vnsi (668b0f40, +1), pvr.vuplus (42b2af59), pvr.wmc (4e291de2)
  
• Includes commits from service.openelec.settings/, ahead +1 (OpenELEC)
  
• Exclude [env] libcec-01-add-repeating-keypress.patch: Already merged upstream
  
• Exclude [env] libcec-02-fix-crash-on-some-systems.patch: Already merged upstream
  
• Exclude [env] libnfs-master.patch: Already merged upstream
  
• Include [env] compare: Disable Tearfree & Triple Buffering; Bump Intel video, include completion signal
  
• Include [env] compare: EGL/4K/HEVC, Use Limited Range by default, bump xf86-video-intel; linux cleanup
  
• Include [env] patch: Add p8-platform package
  
• Include [env] patch: Clean Kodi view cache on startup
  
• Include [env] patch: Fix OE SIGTERM after platform move
  
• Include [env] patch: Add ffmpeg dependency and includes for HEVC optimisations
  
• Include [env] patch: Add experimental splash video
  
• Include [env] patch: Enable pvr addons, disable pvr updates
  
• Include [env] PR:4500: kodi: update to 17.0
  
• Include [pkg] patch: Fix libcec RPi platform detection (libcec)
  
• Include [pkg] patch: NoOfBuffers: Use 2 on OE - as we ship TripleBuffers disabled
  
• Include [pkg] PR:7030: CNetwork - implement IPv6
  
• Include [pkg] PR:8254: FIX: Only handle 3D bitmap subs in TAB
  
• Include [pkg] PR:8645: [video] Add season/TV show artwork to episodes/seasons even if they have their own fanart.
  
• Include [pkg] PR:8676: [jsonrpc] CEpgInfoTag: fix serialization of "runtime" as an integer (in minutes) instead of as a string
  
• Include [pkg] PR:8677: webserver: properly handle too long HTTP POST requests
  

Build Highlights:

1. Bump Python API to 2.25.0 - see announcement
   
2. VideoPlayer updates
   
3. Episode artwork, runtime and webserver POST request fixes
   

Build Details:

1. XBMC:
   • bump python api for kodi k*** (PR:8505, 1 commit, 2 files changed)
     
   • VideoPlayer: fix dvd menus (PR:8666, 7 commits, 10 files changed)
     
2. pvr.argustv:
   • Fix #34 time_t cannot be null (PR:37, 1 commit, 1 file changed)
     
   • Sync enum representation of char_class_e in struct traits with definition (PR:35, 1 commit, 1 file changed)
     
3. newclock5:
   • New commits in this build:
     • VideoPlayer: handle exceptions when for cases a/v players do not signal started (ea4f9560)
       
     • VideoPlayer: fix message queue signal level of zero when not empty (66454ecf)
       
     • VideoPlayer: msg queue cosmetics (cf9c8688)
       
     • VideoPlayer: cosmetics (29e4ebfd)
       
     • VideoPlayer: video - refactoring, cleanup, minor fixes (9b91bf45)
       
     • drop method RenderNoPresent, it only has a singel function call (92d8ad32)
       
     • drop BeginPaint and EndPaint - no need for grabbing the gfx lock (fa9a4ece)
       
     • make sure not to hold gfx lock while rendering gui and video (9ef475c0)
       
     • VideoPlayer: add setting for double/triple buffers (8a2bab77)
       
     • fixup build (de1abe1a)
       
     • fixup! [settings] Add settings option to enable MVC and frame packing support (785c651a)
       
     • squash video (ae24babb)
       
   • Commits no longer in build:
     • VideoPlayer: start players if audio is ready and video is just a still frame (874f0865)
       
     • VideoPlayer: fix busy loop in audio if stream is stalled (95af140f)
       
     • VideoPlayer: do not wait for msg queue to get drained on close, if stream players are no in sync (f385285b)
       
     • VideoPlayer: fix dvd menus (16a94aca)
       
     • VideoPlayer: flag pvr demuxer streams as realtime (58202fc0)
       
     • VideoPlayer: change some debug hostile coding style (e86246e8)
       
     • VideoPlayer: preserve speed of a/v players when close/open them (7cae9582)
       
     • videoplayer: Protect null demuxer access (297ee42a)
       
4. Additional commits/pull requests/changes not yet merged upstream:
   • Added: [pkg] patch: NoOfBuffers: Use 2 on OE - as we ship TripleBuffers disabled
     
   • Added: [pkg] PR:8645: [video] Add season/TV show artwork to episodes/seasons even if they have their own fanart.
     
   • Added: [pkg] PR:8676: [jsonrpc] CEpgInfoTag: fix serialization of "runtime" as an integer (in minutes) instead of as a string
     
   • Added: [pkg] PR:8677: webserver: properly handle too long HTTP POST requests
     

(2015-12-28, 04:43)Milhouse Wrote: [ -> ]New OpenELEC K* build #1227

• Added: [pkg] patch: NoOfBuffers: Use 2 on OE - as we ship TripleBuffers disabled

I believe this is wrong on Pi and needs to be limited to Generic builds.
AFAIK 3 buffers are used unless gpu_mem < 128 (64?).
(Technically on Pi it's not even configurable, so it can be hard-coded in the same place where double buffering is forced.)

(2015-12-28, 04:43)Milhouse Wrote: [ -> ]

• Additional commits/pull requests/changes not yet merged upstream:
  • Added: [pkg] patch: NoOfBuffers: Use 2 on OE - as we ship TripleBuffers disabled
    

@popcornmix - not sure if this patch is required for RPi or not, picked it up from @fritsch so could be x86 or even Intel specific (hopefully not, but will drop if not required).

(2015-12-28, 05:00)menakite Wrote: [ -> ]

(2015-12-28, 04:43)Milhouse Wrote: [ -> ]New OpenELEC K* build #1227

• Added: [pkg] patch: NoOfBuffers: Use 2 on OE - as we ship TripleBuffers disabled

I believe this is wrong on Pi and needs to be limited to Generic builds.
AFAIK 3 buffers are used unless gpu_mem < 128 (64?).
(Technically on Pi it's not even configurable, so it can be hard-coded in the same place where double buffering is forced.)

Aha, just seen your post after I queried this.

OK will drop the patch forcing double buffering from the next build, but will leave it up to popcornmix/FernetMenta how best this option should be handled for RPi, ideally it shouldn't be visible at all to RPi users. Thanks.

(2015-12-26, 19:43)bill_orange Wrote: [ -> ]Additional Information:

I thought of another test this morning. The results were interesting. I loaded up the latest build #1225. I tested for the lock-up by moving from one album to another in Music >> Album . The lock-up occurs when leaving the album and the mouse is in the .. at the top of the list. I got the usual lockup, as I expected. I then removed the drive containing all the music and repeated the test. Of course, I got an error message on each track I attempted to play, as expected. Upon navigation out of an album, I got the usual lock-up. This occurred with the external drive containing the MP3 and all information stored with them removed. From this I infer that the problem is on the data base structure in build #1207.

Does this make sense?

Bill

Are you using MySQL or SQLite for your Music library (your logs have all expired so I can't check)? Can you upload your Music database somewhere - if it's not dependent on the media then maybe the lock up can be reproduced just by installing the db. I've tried enabling ".." (I normally have parent folders disabled) and attached a mouse but no luck reproducing any lock up while using the mouse. Perhaps your Music database has become corrupt somehow, did you say you had tried re-scanning the library from scratch? If not then that might be worth a shot, although it would be nice to get to the bottom of this.

(2015-12-28, 06:04)Milhouse Wrote: [ -> ]

(2015-12-26, 19:43)bill_orange Wrote: [ -> ]Additional Information:

I thought of another test this morning. The results were interesting. I loaded up the latest build #1225. I tested for the lock-up by moving from one album to another in Music >> Album . The lock-up occurs when leaving the album and the mouse is in the .. at the top of the list. I got the usual lockup, as I expected. I then removed the drive containing all the music and repeated the test. Of course, I got an error message on each track I attempted to play, as expected. Upon navigation out of an album, I got the usual lock-up. This occurred with the external drive containing the MP3 and all information stored with them removed. From this I infer that the problem is on the data base structure in build #1207.

Does this make sense?

Bill

Are you using MySQL or SQLite for your Music library (your logs have all expired so I can't check)? Can you upload your Music database somewhere - if it's not dependent on the media then maybe the lock up can be reproduced just by installing the db. I've tried enabling ".." (I normally have parent folders disabled) and attached a mouse but no luck reproducing any lock up while using the mouse. Perhaps your Music database has become corrupt somehow, did you say you had tried re-scanning the library from scratch? If not then that might be worth a shot, although it would be nice to get to the bottom of this.

A logical strategy, as always, Milhouse. Here is a log file which will hopefully show which version of Sequel is being used.

This log file also includes the 'lock-up' Artist >> ZZ Top >> Recycler >> play a track >> play another track >> mouse click out of Recycler >> mouse click on ".." >> lock-up!

http://xbmclogs.com/pw56bg3xo

Here is a link to my exported XML music database.

https://onedrive.live.com/redir?resid=F1...file%2cxml


Thanks for working on this. I am surprised others have not reported the same problem. Maybe few people are testing with a large music library.

Bill

You're using SQLite, can you upload your /storage/.kodi/userdata/Database/MyMusic58.db file in its current and original form - an exported database may not allow the problem to be reproduced.

(2015-12-28, 19:17)Milhouse Wrote: [ -> ]You're using SQLite, can you upload your /storage/.kodi/userdata/Database/MyMusic58.db file in its current and original form - an exported database may not allow the problem to be reproduced.

Okay. There were several other MyMusic files. I only did MyMusic58.db

https://onedrive.live.com/redir?resid=F1...older%2cdb

thanks,

Bill

(2015-12-28, 05:00)menakite Wrote: [ -> ]I believe this is wrong on Pi and needs to be limited to Generic builds.
AFAIK 3 buffers are used unless gpu_mem < 128 (64?).
(Technically on Pi it's not even configurable, so it can be hard-coded in the same place where double buffering is forced.)

That is correct for GL, but we no longer render video with GL. MMAL has its own renderer.
I believe 2 is the correct setting on Pi, and yes, it would be better for setting option to be hidden.

I'll restore the "Use 2 on OE" patch until there's a better fix.

picked up a new PI2 today and tried to get up to the latest 1227 from a clean install, which is not possible. I installed OE 6.0 official booted it, let it do some updates, then copied 1227 millhouse build to update. update goes ok, hangs on reboot.

update - I just tried 6.0 to 1220 and it hangs also.

any ideas?

i just wanted to start a nice clean install from a newer nightly.

Yet again my question about library version ;-) If I read the wiki right, Kodi 17 has seen an update (100). iven there are no OSX nightlies out yet, I will have to abstain from the latest OE as well?

(2015-12-28, 20:10)dukester Wrote: [ -> ]picked up a new PI2 today and tried to get up to the latest 1227 from a clean install, which is not possible. I installed OE 6.0 official booted it, let it do some updates, then copied 1227 millhouse build to update. update goes ok, hangs on reboot.

update - I just tried 6.0 to 1220 and it hangs also.

any ideas?

i just wanted to start a nice clean install from a newer nightly.

Hang on reboot is a known issue with systemd mounts so instead mount using autostart.sh until there's a fix.