[mk01]

@all

it can happen with stable (as well) in case there is regression (kernel -> xbian-config and copy problems), new bug or ugly hacking by upstream devels (firmware -> altering arm/core clock inside firmware code without user interaction).

function by function comprehensive testing (specially on upstream STABLE packages) is completely out of reach.

@min

by turbo mode you mean "force turbo" or only turbo overclock? if the latter then this are the symptoms of messing with firmware. after 2months RPI documented a parameter to config.txt to force internal fw works as before the change. it is as default parameter in testing fw 1.4.13-1 (xbian-package-firmware). i can confirm that my RPI's are again stable as before.

after we realized fw be a problem all newer versions than October were took down but the changes in fw were joined with others in kernel too. that's why 3.10.x tree is now completely abandoned by XBian.
testing 3.12.x with patched btrfs to fix the freezes is in devel too (1.3-6.10) but should go to staging (or even stable) in next moments/days (the fixes to btrfs are 3months old, but were not merged to RPI tree).

not very nicely managed by RPI last weeks.

if users using staging/devel can catch such problems, we know about them. if not, than it is unfortunately going to public.

---

(25th Jan, 2014 01:52 AM)IriDium Wrote:  Just noticed that the xbmc-repository is not working.

Looks like it is pointing to the old server.

Terminal

15:48:32 T:2735772736 ERROR: CCurlFile::CReadState::Open, didn't get any data from stream.
15:48:32 T:2735772736 ERROR: Open - failed to open source <http://ivka57.dyndns-ip.com/xbian-xbmc-repository/addons.xml.md5>

yes, it was moved very long ago / with new definitions (new version) on old server also few days/week. no big deal, re-install this actual .zip.

http://xbian.brantje.com/xbian-xbmc-repository/repo.xbian.xbmc/repo.xbian.xbmc-1.0.4.zip