Forum

sorry to interrupt you guys...I just wonder how the XBian development is going. Our friends over at OpenELEC posted a video a while ago to showcase the big improvements and optimizations made by popcornmix. http://forum.xbmc.org/showthread.php?tid=174485

XBian feels already pretty fast and stable but I'm curious if these newclock3 commits are in some form included in the XBian code (AFAIK it's also included in Raspbmc). Maybe this was already answered..but this thread has 25 pages at the moment and I don't remember if I read it somewhere.

(8th Jan, 2014 10:33 PM)CurlyMo Wrote: [ -> ]

Code:

/usr/local/sbin/xbian-stats: line 294: 512-128
128: syntax error in expression (error token is "128")

your shell interpreter forgot basic math ? )

#294
Output:

(8th Jan, 2014 11:52 PM)freem@n Wrote: [ -> ]sorry to interrupt you guys...I just wonder how the XBian development is going. Our friends over at OpenELEC posted a video a while ago to showcase the big improvements and optimizations made by popcornmix. http://forum.xbmc.org/showthread.php?tid=174485

XBian feels already pretty fast and stable but I'm curious if these newclock3 commits are in some form included in the XBian code (AFAIK it's also included in Raspbmc). Maybe this was already answered..but this thread has 25 pages at the moment and I don't remember if I read it somewhere.

I don't know what the fuss is about. Xbian Beta 2 runs 4G 720p movies on it's standard OC of 840mhz without a glitch. I've also played 8G 1080p without any problems (also a 16G 720p - but can't remember which one). I have also run Xbian without any OC and only noticed a few slight issues.

Running Xbian at the posted OC is about the same as the fasted supplied OC setting "Turbo" which has sdram at 500 rather than 600mhz - Overvoltage is not mentioned for some reason!!!

Xbian is at the bleeding edge, and any improvements will be incorporated as soon as they are available, tested and most importantly do not adversely affect the users RPi.

I'm sure MK will tell us these patches were incorporated into Xbian years ago

However, thanks for bringing it to our attention, nice to know what the other distros are doing..

The funny thing is that XBian could play the Hobbit part 1 (1080p 14G) fluently where the AC Ryan couldn't. The biggest file i tested was Tree of Life (1080p 17G).

@freem@n

I demonstrated XBian with much lover OC, without patched Amber and without patched XBMC during B2 devel to provide the same experience on 1080 resolution and 1080 internal XBMC GUI rendering!!! OpenElec on the screen was 720 gui, using 256mb GPU mem to precache images, images have been crimp-led from 4byte coloring to 2byte. this is not optimization, this is called down sizing. and the HW condition as waste of resources.

Is this not something to be considered as superior? If we post info that in last week patches were super giga ultra optimizations - will that make you happier? will you feel like your RPI is suddenly really so much more responsive?

to answer your question. yes, most of the patches were pulled in. nobody realized. as there was nothing to realize. it is always in people's head. and the MAD OC in the video

according to release notes each month with RaspBMC, it is faster and faster. then you checks hard logs and then you realize no, only background picture is nicer.

---

(9th Jan, 2014 03:00 AM)CurlyMo Wrote: [ -> ]The funny thing is that XBian could play the Hobbit part 1 (1080p 14G) fluently where the AC Ryan couldn't. The biggest file i tested was Tree of Life (1080p 17G).

we have user playing 24-28GB blue rays. he had only to make NFS buffers smaller. DTS was decoded on RPI.

Thanks MK, it supported my thoughts about Xbian.

As always, people are swayed by advertising - this will make you look younger, this will make you more attractive to girls/guys/goats/golams (delete as appropriate), this will allow you loose weight by just lifting a bottle of beer every hour (I wish).

The downside, is that no real information was provided. What was the overvoltage, what type of HDD, what type of USB flash drive, what was the CPU % and more importantly what was the temperature of the core.

I could OC my RPi to 3.3Ghz with 11v overvoltage cooled with liquid difluoroethane and I'm sure Xbian would run like a dream - but I don't need to to. It runs like a dream as it is.

Xbian is Xbian, it doesn't need any cream, additives or herbal rubs. It's fast because of the way it was designed.

@CurlyMo

the issues we are having "sudden breaking of sd/mmc errors":

in october RPI "programmers" have been playing with internal clocking on busses again (both firmware and kernel above 3.10.24+). at first the issues have been explained as user/hw error and again stupid user.

until I yesterday found this:

https://github.com/raspberrypi/linux/issues/467#issuecomment-31073648

I as was joking that maybe this is the SD card corruption fix - it was true. official fix for bad design was fixing one freq to another freq to avoid collisions but somehow they don't think of freq changes on core, they don't consider OC system. for OC system they just made possibility of corruption 2.5x higher, because emmc changed from 100 to 250 (to match vpu) but on such system it is again not 250 (at 420core clock it is 210VPU).

so thanks RPI again. I'm back to firmware 1.4.7. all problems gone and system boots 5s faster.

you can read more here http://forum.stmlabs.com/showthread.php?tid=10756 and then some links .

---

can you maybe just for info post:


this is hacked FW:
mem: frequency(0)=0
core: frequency(1)=420000000
arm: frequency(45)=920000000
h264: frequency(28)=210000000
isp: frequency(42)=210000000
v3d: frequency(43)=210000000
uart: frequency(22)=3000000
pwm: frequency(25)=0
emmc: frequency(47)=250047000
pixel: frequency(29)=74250000
vec: frequency(10)=0
hdmi: frequency(9)=163682000
dpi: frequency(4)=0


this is original: - before the change
mem: frequency(0)=0
core: frequency(1)=420000000
arm: frequency(45)=920000000
h264: frequency(28)=210000000
isp: frequency(42)=210000000
v3d: frequency(43)=0
uart: frequency(22)=3000000
pwm: frequency(25)=0
emmc: frequency(47)=100000000
pixel: frequency(29)=148500000
vec: frequency(10)=0
hdmi: frequency(9)=163683000
dpi: frequency(4)=0

The latest install is finally working without issues anymore. Stupid script kiddies

---

Good or bad news?

Hey mk01 : I sent you a PM about the wifi stuff we have been working on in the past. Let me know how you wish for me to move forward. More than happy to test however you wish!

@darrylb,

you was out so long that in between the support is native in kernel default tree !



but not tested yet by anyone with XBian ) so again you can.

So far so good!

(10th Jan, 2014 08:37 AM)mk01 Wrote: [ -> ]@darrylb,

you was out so long that in between the support is native in kernel default tree !



but not tested yet by anyone with XBian ) so again you can.

Even after latest upgrade 07/01/2014

XBMC will not shutdown from menu.

Just hangs.

Xbmc.log shows

20:07:30 T:3040776736 NOTICE: stop all
20:07:30 T:3040776736 NOTICE: ES: Stopping event server
20:07:30 T:3040776736 NOTICE: stopping zeroconf publishing
20:07:30 T:3040776736 NOTICE: Webserver: Stopping...
20:07:30 T:3040776736 NOTICE: WebServer: Stopped the webserver
20:07:30 T:3040776736 NOTICE: Webserver: Stopped...
20:07:30 T:2788643904 NOTICE: ES: UDP Event server stopped
20:07:30 T:3040776736 NOTICE: stop dvd detect media

....and that is where it hangs.

sudo poweroff works fine.

(9th Jan, 2014 07:40 PM)CurlyMo Wrote: [ -> ]The latest install is finally working without issues anymore. Stupid script kiddies

---

Terminal

for f in core arm h264 isp v3d uart pwm emmc pixel vec hdmi dpi; do echo "$f: $(vcgencmd measure_clock $f)"; done
core: frequency(1)=450000000
arm: frequency(45)=950000000
h264: frequency(28)=0
isp: frequency(42)=225000000
v3d: frequency(43)=0
uart: frequency(22)=3000000
pwm: frequency(25)=98304000
emmc: frequency(47)=249891000
pixel: frequency(29)=0
vec: frequency(10)=108000000
hdmi: frequency(9)=0
dpi: frequency(4)=0

Good or bad news?

this is the one I consider as worse then before this "fix" (emmc pushed to 250 to match core of 250 - which is 450. following RPIs argumentation 100->250 in that case only makes 2.5x higher possibilities of emmc<>core crash. their answer is pushing emmc to 450 as well and bonding core and emmc to the same clock generator with emmc_pll_core=1 . but then we continue to RPI standard on demand governor changing core from 250 to 450 so again not alighned. their answer is force_turbo=1. what with over voltage at this speeds sets warranty bit.

this is really not a way to go.