•   
  • 1
  • 70
  • 71
  • 72(current)
  • 73
  • 74
  • 174
  •   
  Thread Closed
OpenELEC Testbuilds for RaspberryPi
Latest RC2 calculates the delay loop wrong and get false bogomips. For example 1033/500/500 force_turbo=1 I get 686.48 bogomips heh. Clocks are ok when measured with vcgencmd.

Edit: another thing I noticed was before RC2 h264 clock was measured as 0 when not playing a movie and if I played a movie it came alive to 250Mhz now it measures 250Mhz constantly.

I'm only talking RC1, RC2 official builds and builds of openelec.thestateofme.com. No personal tweaked or patched builds.
This is not important Xbmc bug.

PS.After update firmware flv test file working well but still not working mov test file.



I know it's not important it is a weird bug still that will get users confused. So (and out of personal curiosity) I was looking for a more constructive answer though to why. And not "this is not important XBMC bug". I know the bug is not even related to XBMC and that's also why I'm asking here and not in a XBMC thread. Smile
It is on OpenElec 3.0 RC2. I sent you a PM with a link to a test file..


(2013-01-26, 14:24)popcornmix Wrote:
(2013-01-26, 13:39)brinka123 Wrote: Still have audio and video sync problems. The delay gets worse the longer the video plays.

Is this with OpenElec 3.0 RC2?
I'll need to see an example file. Can you extract a sample that shows the problem, and post it somewhere (e.g. dropbox).

(2013-01-25, 23:56)tfft Wrote: Here's a bit more info on the standard and ogv,

http://en.wikipedia.org/wiki/Ogg

I've read that ogg (unrestricted, free, etc) is gaining popularity and so it would be nice to have it be supported thus the inquiry. Might be wise to submit a bug report to XBMC about this.
Check out the link popcornmix posted about experimental firmware.
(2013-01-26, 21:47)tuxen Wrote: Latest RC2 calculates the delay loop wrong and get false bogomips. For example 1033/500/500 force_turbo=1 I get 686.48 bogomips heh. Clocks are ok when measured with vcgencmd.

Edit: another thing I noticed was before RC2 h264 clock was measured as 0 when not playing a movie and if I played a movie it came alive to 250Mhz now it measures 250Mhz constantly.

I'm only talking RC1, RC2 official builds and builds of openelec.thestateofme.com. No personal tweaked or patched builds.

I have this issue as well. Has this already been reported? If not, is this a RPi firmware issue or OpenELEC issue?

root ~ # grep -i mips /proc/cpuinfo
BogoMIPS : 597.60
root ~ # vcgencmd measure_clock arm
frequency(45)=900000000
root ~ #
Hmm...

This looking for firmware issues. I thought it only Xbmc display incorrect BogoMibs, but no.



I don't know where to report a bug so I have posted it on the RPi forum.
http://www.raspberrypi.org/phpBB3/viewto...63&t=31281

...also Airplay seems to be broken on OpenELEC 3.0 RC2.
Can't remember if this was also the case on RC1?
Can this be fixed in some way?
XBMC just read the bogomips back like we do. It seems like the bug came with the firmware upgrade yes.

AirPlay works perfect here it also did in RC1. Both from iPad 3 and old iPhone 3GS.
Do you have it on along with zeroconf and are both devices on the same localnet? Might sound stupid I know, but I never had problems with AirPlay.
Yes, Airplay/Zeroconf enabled and all devices are on the same subnet.
Any chance you are on iOS 5.x instead of iOS 6.x like me?
Oh yeah I am for the only jb available for iPad 3. I will borrow another iPad 3 with iOS 6 and try.
I was not thinking of that will report back.
Yes, this is probably because of iOS 6.

I also disabled ipv6 but that did not help either.
http://wiki.openelec.tv/index.php?title=...v6_Support
http://openelec.tv/forum/124-raspberry-p...t=40#56278

BTW
The command itself seems to work...
Code:
root ~ # ifconfig eth0
eth0      Link encap:Ethernet  HWaddr B8:27:EB:B3:3E:AF
          inet addr:192.168.0.123  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::ba27:ebff:feb3:3eaf/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:148 errors:0 dropped:0 overruns:0 frame:0
          TX packets:138 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:13110 (12.8 KiB)  TX bytes:21262 (20.7 KiB)

root ~ # python /usr/lib/connman/set-ipv6-method ethernet_b827ebb33eaf_cable offSetting method off for ethernet_b827ebb33eaf_cable
New IPv6.Configuration:  {'Method': dbus.String(u'off', variant_level=1)}

root ~ # ifconfig eth0
eth0      Link encap:Ethernet  HWaddr B8:27:EB:B3:3E:AF
          inet addr:192.168.0.123  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2275 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1917 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1502367 (1.4 MiB)  TX bytes:332948 (325.1 KiB)

root ~ #
Anyone suffering from corruption of the ext4 (secondary) partition when booting OpenELEC based Pis is probably falling victim to the following problem.

About once every 8-10 boots, the SD card will not initialise correctly.

There is no dmesg available when standard builds of OpenELEC boot initramfs, so I built a custom version with dmesg to see what errors are occurring when the SD card is not initialised correctly - see pastebin for details.

When these SD card errors occur, OpenELEC continues on to mount the ext4 /storage partition which more often than not results in its corruption.

I'm just wondering if Popcornmix can shed any light on these intermittent SD card errors. Admittedly I'm using a pretty crappy micro SD card which pre-dates the Class 2/4/6/10 system, but I'm also seeing the same problem with a more recent full-size Class 2 4GB Transcend. Most of the time the cards work, but each reboot is like Russian Roulette as you never know if the SD card is going to freak out. Even when booting over NFS these SD card errors are still a risk, as when the software auto-updates it tends to write corrupt kernel.img/start.elf/etc files to the FAT partition, leaving the system unbootable.

My solution right now is to try and detect when the SD card is misbehaving and reboot the Pi until it behaves itself (which is usually the next reboot, very occasionally it may take two reboots). Would this suggest its some sort of timing/race issue?

512MB (128MB GPU) Pi, Overclocked 1000/500/600/+4/+2, Transcend 2GB MicroSD (in full size SD adapter), 2A Palm Touchpad PSU.
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.
(2013-01-26, 01:25)popcornmix Wrote:
(2013-01-26, 00:58)tfft Wrote: I read that the gpu_mem is assigned in 8MB steps so we're talking 96 or 104, right ? And in passing, the default is 128 - so why would assigning the GPU _less_ memory improve things as I'm guessing the GPU is what requires more resources compared to the CPU, no ?
I believe gpu_mem works down to 1MB steps.

The memory failure is on ARM side, so giving the GPU less memory is the right solution.
@popcornmix, thanks for the heads-up -- indeed setting gpu_mem to 96 has stopped the freezing and GUI reset which is a huge plus :-) With regard to the step size, according to this Wikipedia article it says the following,

[gpu_mem=xx] dynamically assign an amount of RAM (from 16 to 256MB in 8MB steps) to the GPU

Regarding cachemembuffersize, a few questions,
1. I'm assuming this taps into the 256MB RAM memory, right ? If so whose allotment - the GPU's, CPU's ?
2. With RedBull.tv there seems to be NO cache'ing with their HD content (720 or 1080) - I tried 10MB, 5MB and 2MB and continued to see "cache:0 B" when I pressed 'o' (codec info) not to mention the constant buffering pauses. Is this setting part of the content provider, add-on or ... Why does cache exist in other channels (say aljazeera) while it seems missing from RedBull.
3. The value in advancedsettings.xml is 5282880 when it should be 5242880 (note the 8 vs 4 difference) to note 5MB - typo maybe ?

Am I correct in thinking that the default 5MB cache value gets expanded to 15MB (x3) and is allocated the CPU's RAM dynamically. In other words, the 15MB (or portions there-of) are only consumed if needed and are otherwise there for the CPU to use. The SWAP space (it would be a good idea to include the "swapon" command as "mkswap" is already there by default) will be used when either the CPU and/or the application (ie. XBMC) go beyond their maximum allotments. In other words, if I use gpu_mem=96 and I'm on an RPi-256 the CPU+cache=(256-96)=160 and if the default cache is 5MB (given the typo above is corrected) then the CPU will have (160-(5x3))=145MB. So if the cache goes over 15MB or the CPU needs more than 145MB it will resort to paging out some memory to the swap to free-up some RAM space. Do I have that correctly ?

Lastly, is there any reason why swap isn't enabled by default - it will consume SDCard memory which is plentiful even if someone was using a flimsy 2GB. Why not at a min do 50MB of swap by default - are there any adverse affects ?

Thanks.
cachemembuffersize comes from arm memory. It is multiplied by 3 (there is a file buffer, a "skip back" buffer and a "skip forward" buffer to allow small seeks).
It gradually grows as time elapses until it reached the limit.

Personally I would recommend enabling swap (with a low swappiness value) on a 256M board.
  •   
  • 1
  • 70
  • 71
  • 72(current)
  • 73
  • 74
  • 174
  •   
  Thread Closed
 
Thread Rating:
  • 12 Vote(s) - 4.58 Average



Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi4.5812