2015-12-28, 00:59
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"
vcdbg log msg 2>&1 | paste
cat /flash/config.txt | paste
dmesg | paste
md5sum /flash/overlays/lirc-rpi-overlay.dtb
# uname -a
Linux rpi512 4.4.0-rc6 #1 Sun Dec 27 21:02:29 GMT 2015 armv6l GNU/Linux
# vcgencmd version
Dec 8 2015 14:44:44
Copyright (c) 2012 Broadcom
version e591b5eb05e2cdb1b5ae25512b27d33127d7bee9 (clean) (release)
# lsb_release
OpenELEC (Milhouse) - Version: devel-20151227210141-#1227-g6551bd1 [Build #1227]
# vcdbg log msg 2>&1 | grep DTOK
001697.740: Kernel trailer DTOK property says yes
# Kernel device tree status: Enabled
(2015-12-28, 04:43)Milhouse Wrote: New OpenELEC K* build #1227I believe this is wrong on Pi and needs to be limited to Generic builds.
- Added: [pkg] patch: NoOfBuffers: Use 2 on OE - as we ship TripleBuffers disabled
(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
(2015-12-28, 05:00)menakite Wrote:(2015-12-28, 04:43)Milhouse Wrote: New OpenELEC K* build #1227I believe this is wrong on Pi and needs to be limited to Generic builds.
- Added: [pkg] patch: NoOfBuffers: Use 2 on OE - as we ship TripleBuffers disabled
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-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
(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.
(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.
(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.)
(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.