•   
  • 1
  • 81
  • 82
  • 83(current)
  • 84
  • 85
  • 119
  •   
RaspBMC Kodi/XBMC test builds
(2014-04-30, 13:42)miappa Wrote: Hehe, yes... XBMC 14 has now opened up for new features, this is not for Gotham.
Up until now Master (Helix since a while) and Gotham has been pretty much identical since there has only been bug fixes.
So, if you want Gotham you should install Sam´s builds (from Gotham) as those are quite stable and not much will change until release.

Of course it makes sence to stick with master, development must go on. Wink
And Gotham builds (beta/RC etc.) you can easily install either from Raspbmc settings.

From now on the test builds from me will be Helix only, Gotham ”test” builds will be provided through official channels.
So count on more buggy builds from here... but the last one seems very stable though.
Ah I understand. I had the idea that you were building test builds for Gotham up until release, (due to Sam being MIA for so long last year) I didn't realise you were continuing to make builds from master after Gotham was released...

I think I'm on your second to last build (will have to check at home) and it is very stable with no outstanding issue that affect me, especially after popcornmix's great work squashing recent bugs. In short, it works great. I was mainly running early Gotham builds because Gotham is so much better on the Raspberry Pi than Frodo (especially performance) that it was a no brainer despite being beta/alpha code.

My concern is what do I switch to after this build, because Sam is not nearly as forthcoming on exactly what goes into his builds and what they're based on, and I'm not really wanting to venture out into Helix territory at the moment...

If I switch to one of Sam's builds I don't know how many of popcornmix's fixes I'll be loosing for example - a lot of what makes your build so good is the bleeding edge commits from newclock3.

So I guess I'll stay on the current build until Gotham is final and Sam releases his version of it, and then give that a try. (Hopefully there won't be too many regressions from being a plainer build) I've annoyed the household with far too much testing on the Raspberry Pi recently, (which is normally on the main TV) so it's probably best if I lie low for a while and stick with my current build for now. Big Grin
Kodi 15.2 - Mid 2007 Mac Mini, 4GB, 2TB HD, OS X 10.7.5.
Kodi 15.2 - Raspberry Pi Models B, B+, Pi 2. OSMC.
Kodi 15.2 - Fire TV Stick.
Reply
(2014-04-30, 13:28)DBMandrake Wrote: Seems like a big change to make to a core component after RC1 - or is this only going into master and not getting merged into the Gotham branch ?

Does it still make sense for you to make builds from the master branch instead of the Gotham branch if they are starting to diverge this much ? What branch will Sam likely use when he makes an official Gotham release I wonder ?

Questions, questions. Smile

ffmpeg 2.2 is master/Helix only. Not coming to Gotham.

Up until a few days ago master was in feature freeze and was functionally identical to gotham branch. Now master is open and lots of commit are going in.
gotham_rbp_backports contains about 75% of commits from newclock3 - the ones believed to be clearly beneficial and without suspected bugs.

I expect official raspbmc to use Gotham + gotham_rbp_backports.

So, for the most part, official raspbmc gotham will be very similar to the last miappa build.

But, development happens on master (with occasional backports to gotham), and there are a lot of commits now going into master (after a six month feature freeze).
This will include upstreaming the promising newclock3 patches.

From my part, I will continue supporting:
Gotham + gotham_rbp_backports
master + newclock3

In general xbmc features and improvements to master won't appear in Gotham. Serious bug fixes will be ported to Gotham.

I'll port pi specific features, improvement and bug fixes from newclock3 to gotham_rbp_backports where possible.
New features may rely on xbmc master features that aren't present in gotham, so may not be possible.

miappa has confirmed he will continue building master+newclock3. Milhouse is doing the same for openelec.
If you want gotham+gotham_rbp_backports then use official raspbmc or openelec.

So, which should you use?
If you only came here because these builds had better performance and some new features, then you should be able to switch to official raspbmc (when final is released) and be happy. That will be the more stable choice.
If you are here to help with testing, and enjoy getting bug fixes and new features early, and are willing to deal with the inevitable (hopefully only occasional) breakages, then please continue using the test builds. Having a decent number of testers on these builds helps to make the stable releases more stable.
Reply
(2014-04-30, 13:42)miappa Wrote: @popcornmix
Thank, did delete them and it´s running fine.
I have the config log but could only see a couple of "debug" mentioned where it seemed to be enabled...

Yes, debug was enabled, which is undesirable. I think you want:
"Configuration" to be set to "Release"

which file was that in? If Configuration is not set to Release then there may be other libraries build as debug, so you want to fix the problem at that point.
Reply
The config file is from ffmpeg located in …/tools/rbp/depends/ffmpeg/rpi
It will only exist after running make from…/tools/rbp/depends/ffmpeg and that will only work after ’sh tools/rbp/setup-sdk.sh’.

All this is first step (except for some patches) and prior running XBMC configuration ('make -C tools/rbp/depends/xbmc') as that will not work beforehand (exiting with error ’configuration: checking ffmpeg: no blabla exiting…).

It feels like a chicken and egg situation…?
Reply
Edit: Sorry, the configuration/release part is from the make file located in …/tools/depends/ffmpeg. Here is the complete file: Makefile
Reply
(2014-04-30, 15:13)miappa Wrote: Edit: Sorry, the configuration/release part is from the make file located in …/tools/depends/ffmpeg. Here is the complete file: Makefile

Can you:
Code:
make Configuration=Release
got ffmpeg?
Reply
Yep, that seems to have done it.
Still running, but I could see --disable-debug last in the configuration before it started to compile.

Thanks a lot... and sorry for my noobness... Wink
Reply
(2014-04-30, 14:27)popcornmix Wrote: [...]
I'll port pi specific features, improvement and bug fixes from newclock3 to gotham_rbp_backports where possible.
New features may rely on xbmc master features that aren't present in gotham, so may not be possible.

miappa has confirmed he will continue building master+newclock3. Milhouse is doing the same for openelec.
If you want gotham+gotham_rbp_backports then use official raspbmc or openelec.

So, which should you use?
If you only came here because these builds had better performance and some new features, then you should be able to switch to official raspbmc (when final is released) and be happy. That will be the more stable choice.
If you are here to help with testing, and enjoy getting bug fixes and new features early, and are willing to deal with the inevitable (hopefully only occasional) breakages, then please continue using the test builds. Having a decent number of testers on these builds helps to make the stable releases more stable.
Thanks for the very clear explanation of what to expect and what is being supported. It sounds like Sam's Gotham + gotham_rbp_backports build when it comes out will do me fine for a while.

I did originally start running the beta's because the performance and usability improvements of Gotham on the Raspberry Pi are so huge, but I do also like to test software and help with the testing/debug process, especially when a new release is imminent and final bugs need to be squashed.

Unfortunately I only have one Raspberry Pi at the moment which resides on the living room TV, a lot of my testing has required me to take it away from the TV and then have to explain why its not there when it's discovered to be missing. Wink I'm also a little bit burnt out at the moment as far as testing goes after several weeks solid spent debugging that HTTP seek issue.

But I do plan to get another Raspberry Pi so I have one for testing, when I do and I've had a bit of a break I'll be back. Smile
Kodi 15.2 - Mid 2007 Mac Mini, 4GB, 2TB HD, OS X 10.7.5.
Kodi 15.2 - Raspberry Pi Models B, B+, Pi 2. OSMC.
Kodi 15.2 - Fire TV Stick.
Reply
(2014-04-30, 16:24)DBMandrake Wrote: Unfortunately I only have one Raspberry Pi at the moment which resides on the living room TV, a lot of my testing has required me to take it away from the TV and then have to explain why its not there when it's discovered to be missing. Wink I'm also a little bit burnt out at the moment after several weeks spent debugging that HTTP seek issue.

But I do plan to get another Raspberry Pi so I have one for testing, when I do and I've had a bit of a break I'll be back. Smile

Yes, that sounds ideal - a stable build for the family and a test build you can mess around with.
And good job with debugging the HTTP seek issue - I'm sure a lot of people will benefit from that work.
Reply
NB!
XBMC 14 (Helix) is now open for new feature commits so test builds from here might be more buggy.
If you want a more stable Gotham build and try out the release candidates I recommend that you install/stay on Sam´s official builds (from Raspbmc settings).

If you want to keep help testing new features and fixes in Helix, here we go. Wink

Build has been updated with some additional commits from same date, new build called *-nc3b.

Updated Gotham build, XBMC master from Apr 30 + newclock3 commits.

Some info:
• Master: ffmpeg bump version to 2.2
• Master: Libdvd* updated
• Master: Introduce SWCodec
• Master: Several updates and cleanups regarding gui, skin, epg etc.
• NC3: Updated commits (for ffmpeg update) and rebased
Updated build (*-nc3b):
Master: Fix some coverity scan issues
NC3: paplayer: dvdplayercodec - check if seek is possible before trying to seek
NC3: ActiveAE: correct time of buffered samples by resample ratio

Firmware from April 29 included

Additional info and testing (DVDPlayer etc.), see post #1

To install XBMC build, SSH to Pi:
Code:
wget -O xbmc-14-20140430-nc3b.tar.gz http://goo.gl/XqMf1m --no-check-certificate
pv xbmc-14-20140430-nc3b.tar.gz | tar xzf - -C /home/pi/.upgrade
sudo cp /home/pi/.upgrade/xbmc-14-20140430-nc3b/{fixup_x.dat,start_x.elf} /boot
ln -sfn /home/pi/.upgrade/xbmc-14-20140430-nc3b/xbmc-bcm /home/pi/.xbmc-current
sudo reboot
Reply
As there was a bigger change in the last build, I only want to report that it seems to work without any problems. I was able to install it according to your instructions and I was able to play some video files and video addons. Great work miappa!

As it seems that we have a new development cycle a short question - especially to Dom:
One big remaining problem is the "Scrolling" problem. So as soon as you have any scrolling text/element (RSS feed, long titles, descriptions, movie plots etc) the CPU gets hammered to 100% as the complete screen is constantly newly build. You can also see it when you get any Loading icon/animation used by some skins - especially while using video addons.
Any options to solve this issue?
Reply
(2014-04-30, 19:45)namtih Wrote: As it seems that we have a new development cycle a short question - especially to Dom:
One big remaining problem is the "Scrolling" problem. So as soon as you have any scrolling text/element (RSS feed, long titles, descriptions, movie plots etc) the CPU gets hammered to 100% as the complete screen is constantly newly build. You can also see it when you get any Loading icon/animation used by some skins - especially while using video addons.
Any options to solve this issue?

Amber and Aeon Nox 5 use "Working..." animations that update slowly, which doesn't cause this issue.
You can mod Confluence fairly easily: https://github.com/popcornmix/xbmc/commi...9e32ad5e95

Some skins have an option not to scroll long text. E.g. Aeon Nox 5 has "Enable auto scrolling for plot and review".
Ideally someone would mod a skin to avoid that (or only do it when selected) which would help.
Reply
But many skins don't support such options.
So do you see any realistic chances to get rid of this issue?
Reply
Just installed miappa's build (30th april)

Got bluetooth audio working with alsa, but it's really tinny with very little bass and slightly distorted.

Can some one with a usb soundcard confirm if it sound's ok?

Thanks
Reply
Hi, since the two latest builds or firmware updates the screen calibration is lost after a reboot.

Any one experiencing similar problems?

I do not have the problem with Sam's recently release.
Reply
  •   
  • 1
  • 81
  • 82
  • 83(current)
  • 84
  • 85
  • 119
  •   
 
Thread Rating:
  • 15 Vote(s) - 4.4 Average



Logout Mark Read Team Forum Stats Members Help
RaspBMC Kodi/XBMC test builds4.415