OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0) - Printable Version +- Kodi Community Forum (https://forum.kodi.tv) +-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33) +--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111) +---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166) +---- Thread: OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0) (/showthread.php?tid=192380) Pages:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
RE: OpenELEC Testbuilds for RaspberryPi Part 3 - da-anda - 2014-04-29 (2014-04-28, 17:19)delinend Wrote: Sorry.. Have not tested many of the lastest builds. But have now tryed #0427, and see some "none smooth" playback of DVD/ISO PAL25, that are interlaced.Thanks for that pointer. I also have random issues with PAL25 DVDs but never thought about checking deinterlacing. Will do so in my next testing round. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - User 99401 - 2014-04-29 (2014-04-29, 00:34)popcornmix Wrote:(2014-04-29, 00:21)Shanyel Wrote: That's my cmdline.txt oops didnt notice that thanks! RE: OpenELEC Testbuilds for RaspberryPi Part 3 - SSC_Jarod - 2014-04-29 (2014-04-29, 00:09)popcornmix Wrote:(2014-04-28, 23:56)SSC_Jarod Wrote: I watch a strange behaviour in 3D picture quality since the release from 30th March r18050. Hi Popcornmix, Will try from that build from 30th March on, but as i remember was the following build not as good in picture quality. Think i do it on weekend and give response ... Thx J. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - postdeath - 2014-04-29 (2014-04-17, 17:40)postdeath Wrote:(2014-04-17, 17:28)popcornmix Wrote:(2014-04-17, 17:21)postdeath Wrote: I have had horrific performance problems in the recent past using Gotham builds on my original 256 Pi - is this something that can/will be fixed, or are the older Pi's just unable to run Gotham smoothly? Frodo still works perfectly (usb+sd, w/oc: 1000). A little later than promised, but I finally worked out what my problem was - I was manually importing my old config.txt after each install, and it appeared to have an accidentally uncommented conflicting gpumem command in there. I feel dumb as hell, but it's all working now. Thanks! RE: OpenELEC Testbuilds for RaspberryPi Part 3 - tuxen - 2014-04-30 (2014-04-29, 09:42)da-anda Wrote:I connected a DVD drive and went through my collection, I can confirm the same.(2014-04-28, 17:19)delinend Wrote: Sorry.. Have not tested many of the lastest builds. But have now tryed #0427, and see some "none smooth" playback of DVD/ISO PAL25, that are interlaced.Thanks for that pointer. I also have random issues with PAL25 DVDs but never thought about checking deinterlacing. Will do so in my next testing round. PAL interlaced is not smooth. I only had one though. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - tuxen - 2014-04-30 (2014-04-29, 00:34)popcornmix Wrote:You got a spelling error more in there if you have not noticed quite should be quiet.(2014-04-29, 00:21)Shanyel Wrote: That's my cmdline.txt Why the noram "disk" if I may ask? RE: OpenELEC Testbuilds for RaspberryPi Part 3 - Milhouse - 2014-04-30 (2014-04-30, 01:58)tuxen Wrote: Why the noram "disk" if I may ask? By default OpenELEC will load the whole of SYSTEM into RAM (ram disk) if there is enough free memory available, which there will be on a 512MB Pi with gpu_mem <= ~140. The difference this makes in terms of performance is, IMHO, negligible, and I think you're better off adding "noram" and not having SYSTEM loaded into RAM, which results in about 110MB extra physical memory being made available to XBMC and the rest of the OS. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - tuxen - 2014-04-30 Yeah I know the limit is actually 368MB so you can have 144MB GPU mem. And I get by fine with no fonts crashes or screwed up fanart, and even running the transmission service and tried pressuring it with all sorts of stuff, and never ran out out mem . I have not experimented much with this but sdram is surely faster than the sdcard. I do not see a major performance boost no but still there is some, so I was wondering why not utilize what you can. Also skins such as amber if you use the widget bar addons is not restarted but kept running in mem and I never had trouble with this to. (I expect other confluence does the same there are just no way to return to them running other than creating a favorite. What can you imagine use that much ram on a XBMC system only? 372MB minus 110MB is quite a lot, and in line with 256MB, and beyond what I can imagine anything using. It seems to me it gains more from some extra GPU mem if you set it higher than 128 (or 144) but again I see no trouble. Please don't misunderstand I'm just curious. Ps. Naturally I do not use swap. I'm gonna do some more experimenting though. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - Milhouse - 2014-04-30 SDRAM will be faster than SD card, but Linux will also cache the SD card file accesses so in my opinion you'll get similar performance with "noram" thanks to OS file caching, but without dedicating a fixed chunk of memory to load the entirety of SYSTEM into RAM Linux will use whatever RAM is available for file caching, and give that memory back when a program needs it, whereas dedicating 110MB+ of RAM to a ram disk is memory that can't be used for any other purpose. Bear in mind also that a significant proportion of SYSTEM is made up of code that most users won't ever be using, for instance the WiFi modules and drivers will all be sat in your RAM disk even if you don't have any wifi hardware. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - tuxen - 2014-04-30 Sorry for my edits Danish is hard to translate properly into English. I see your very valid points but still I have not seen this go above 252MB or is it me not testing properly, will play some more with this. So would you say a noram is better than 256/256 GPU split if you do not have gfx errors. Or is GPU mem utilized in a "similar way". Thanks in advance.. Edit: do you have some tips on measuring these things? RE: OpenELEC Testbuilds for RaspberryPi Part 3 - Milhouse - 2014-04-30 (2014-04-30, 07:58)tuxen Wrote: I see your very valid points but still I have not seen this go above 252MB or is it me not testing properly, will play some more with this. Everyone is different, if you're not starved of memory then there's no reason to change. Adding "noram" is simply an option if you want a bit more physical memory for the ARM CPU. (2014-04-30, 07:58)tuxen Wrote: So would you say a noram is better than 256/256 GPU split if you do not have gfx errors. Or is GPU mem utilized in a "similar way". If you've got a 256/256 gpu split then effectively you're already using "noram" as there isn't enough free memory to load SYSTEM. "noram" only has an effect if your gpu_mem is 140-160MB or less, as with "noram" added you won't be dedicating 110MB+ of physical RAM to a ram disk. (2014-04-30, 07:58)tuxen Wrote: Edit: do you have some tips on measuring these things? Not particularly, just try it and see if you can tell any difference in terms of performance. Obviously anyone that has programs that are running out of memory, then making another 100MB of memory available with the addition of "noram" should give a very obvious benefit. RE: OpenELEC Testbuilds for RaspberryPi Part 3 - carmenm - 2014-04-30 (2014-04-27, 15:17)bagofcrap24 Wrote:Thanks i will reactivate samba then(2014-04-27, 15:00)carmenm Wrote: Hi , RE: OpenELEC Testbuilds for RaspberryPi Part 3 - whiffyfuzzball - 2014-04-30 (2014-04-27, 12:12)popcornmix Wrote:(2014-04-27, 08:38)whiffyfuzzball Wrote: I have a single USB device installed - an official Microsoft media center remote control receiver. Nothing else, I never use USB storage, everything is played via NFS. Shared library using MySQL. OK, I have it borrowed down to this so far: Works OK: OpenELEC-RPi.arm-devel-20140330204313-r18050-g2d44624 Doesn't work: OpenELEC-RPi.arm-devel-20140402115943-r18083-g960b3b5 I'm working through the builds in between but downloads are a little slow for me right now. Once I have it narrowed down to a single build I'll try the USB test. I've also set debug mode to 1 in advancedsettings.xml and got this log file from the last pause: 13:04:01 11041.151367 T:2694837328 DEBUG: Pause -0.05,4.67 (A:10 V:01) EOF:0 FULL:0 T:1.60 13:04:01 11041.151367 T:2694837328 DEBUG: OMXClock::OMXSetSpeed(0.00) pause_resume:1 13:04:01 11041.275391 T:2226123856 DEBUG: Received request to serve unknown md5 '' 13:04:02 11042.358398 T:2694837328 DEBUG: Resume 1.63,8.86 (A:01 V:01) EOF:0 FULL:0 T:1.60 13:04:02 11042.361328 T:2694837328 DEBUG: OMXClock::OMXSetSpeed(1.00) pause_resume:1 14:11:53 15113.094727 T:2694837328 DEBUG: Pause -3562.94,-3558.96 (A:10 V:10) EOF:0 FULL:0 T:3.20 14:11:53 15113.132812 T:2694837328 DEBUG: OMXClock::OMXSetSpeed(0.00) pause_resume:1 14:11:53 15113.882812 T:2008020048 DEBUG: Received request to serve unknown md5 '' 14:11:55 15115.297852 T:2694837328 DEBUG: Resume 3.23,10.10 (A:01 V:01) EOF:0 FULL:0 T:3.20 14:11:55 15115.302734 T:2694837328 DEBUG: OMXClock::OMXSetSpeed(1.00) pause_resume:1 14:11 is when the video started up again. Paul RE: OpenELEC Testbuilds for RaspberryPi Part 3 - whiffyfuzzball - 2014-04-30 devel-20140401220047-r18074-gfa2d8e0 not OK. Downloading http://netlir.dk/rbej/builds/MilhouseVH/OpenELEC-RPi.arm-Milhouse-20140401195740-r18074-gfa2d8e0.tar now but only getting 2kb/sec so could be a while... RE: OpenELEC Testbuilds for RaspberryPi Part 3 - carmenm - 2014-04-30 @MilhouseVH: i have a question about your xbmc builds. Do you build TexturePackager? Could you package the TexturePackager with it? It appears that skin are A LOT faster when compiled. I would like to automate that on my pi but i would need TexturePackager for that. Thanks |