2015-07-27, 18:22
I'm not home. Will test it 2 hour later.
(2015-07-27, 13:58)popcornmix Wrote:(2015-07-27, 13:24)MrNice Wrote: At first I had the issue with #0714 then I installed the #0726.
So this is older but I don't know from when.
Install the Leopold OE updater addon and find the first build with the problem. You can probably do this in fifteen minutes. With this information you are much more likely to get a fix.
(2015-07-27, 21:53)noggin Wrote: Trying to test the latest build in this thread, and having real difficulties getting the TV Headend PVR client to work. The server is installed and running OK, and has done a full channel search, but when I try to enable the pre-installed TV Headend PVR client it really doesn't want to play ball... Is this a known thing or am I doing something wrong?
# uname -a
Linux rpi512 4.1.3 #1 Mon Jul 27 21:02:35 BST 2015 armv6l GNU/Linux
# vcgencmd version
Jul 24 2015 14:44:13
Copyright (c) 2012 Broadcom
version 0f482c5017ad4526a6beb77fe39c93189c664fd4 (clean) (release)
# lsb_release
OpenELEC (Milhouse) - Version: devel-20150727210148-#0727-gc37b5a7 [Build #0727]
# vcdbg log msg 2>&1 | grep DTOK
001561.802: Kernel trailer DTOK property says yes
# Kernel device tree status: Enabled
(2015-07-28, 15:19)tomov Wrote: Can anyone confirm this is being worked on http://trac.kodi.tv/ticket/15918 ? Thanks
(2015-07-28, 15:37)popcornmix Wrote:(2015-07-28, 15:19)tomov Wrote: Can anyone confirm this is being worked on http://trac.kodi.tv/ticket/15918 ? Thanks
PR:7407 was one of the components required for a fix.
But I believe there is still more plumbing needed and add-ons need to be updated.
(2015-07-28, 18:05)illiac4 Wrote: Same freeze as reported few days ago.
http://pastebin.com/mHWJKG0u
(2015-07-27, 19:58)MrNice Wrote:(2015-07-27, 13:58)popcornmix Wrote:(2015-07-27, 13:24)MrNice Wrote: At first I had the issue with #0714 then I installed the #0726.
So this is older but I don't know from when.
Install the Leopold OE updater addon and find the first build with the problem. You can probably do this in fifteen minutes. With this information you are much more likely to get a fix.
I did some tests, all with the same process, no setup change:
Directory in SD with inside 7 audio files (see post #276)
Install new build with add-on, go to the directory in the SD, move the selection on the file, wait 15 seconds, read value from ssh/top, move to the next file.
Results:
Build | low CPU% (good files) | High CPU% (bad files)
#19852 (date: 22/Dec) | 15 | 66
#19882 (date: 01/Jan) | 15 | 65
#20173 (date: 01/Feb) | 15 | 69
#0301 | 15 | 70
#0401 | 67 | 69
#0501 | 66 | 81
#0601 | 59 | 62
#0701 | 64 | 64
#0401 | 63 | 66 (again to be sure)
#0726 | 09 | 95 (again to be sure)
My conclusion as a user:
2 type of files
Builds #0501 and #0726 have higher values.
I'll try to find the last change between #0701 and #0726
(2015-07-28, 18:13)popcornmix Wrote:(2015-07-28, 18:05)illiac4 Wrote: Same freeze as reported few days ago.
http://pastebin.com/mHWJKG0u
Do you have poor signal from aerial? (i.e. visible errors in video?)
Can you capture the hang from a TV recording? If so a sample file would be useful.
(2015-07-28, 19:35)MrNice Wrote: I found the starting build:
Build | low CPU% (good files) | High CPU% (bad files)
#0712 | 64 | 65
#0713 | 72 | 95
Even there is a difference between "bad" and "good" file (I don't know why) there is also a difference between builds.
I'll try to find out why the difference between files.