[herg]

...and one more test case.

A source with two paths on different machines such as the following:

Code:

<source>
            <name>Movies (Unwatched)</name>
            <path>smb://192.168.1.101/disk1/Movies/</path>
            <path>smb://192.168.1.102/disk2/Movies/</path>
        </source>

This also works fine.

It's only with more than one SMB path to the same machine that I see the problem.

[Gamester17]

Nice work rodalpho, ...however I already clearly said that there is no such thing as a "release candidate" for an alpha release (nor for beta releases either for that matter). There can however be internal testing for a SVN revision so to speak before that specific revision is given an alpha status, so rather just refer to a specific SVN revision as the next 'potential' alpha each time instead of giving it a release candidate version like you did.
http://en.wikipedia.org/wiki/Software_re...life_cycle
http://en.wikipedia.org/wiki/Image:Develstages.svg

So please respect the standard software release life cycle naming-convention in the future.

Thanks

[StuLove]

There's a performance bug that a couple of us have noticed in the svn (and also in this tagged version). It seems that when running in 1080p, the framerate is capped at 20fps. 720p yields 30fps and 480p gives 60fps. Details are in this thread:

http://forum.xbmc.org/showthread.php?tid=32084

A bit more information: when the "blank screen" screensaver kicks in, the framerate goes up to 60 and similarly when on the "calibrate screen" display in video settings. Has anyone else noticed this?

[snappz]

This bug as noted here is also apparent in this version.

Debug from rev 12195 is here

Fresh install with only 1 network share added.

Thanks for the great job.

snappz

[BLKMGK]

When attempting to play a DVD that has been ripped with VOB/IFO files ala DVDShrink playback occurs in a small window in the lower left corener of the XBMC interface. This behavior has been present for some time, a thread about it is linked in my signature that includes additional information. Here's a pastebin from just now with this new release. The interface on the XBOX acts similiarly except that just before the video actually begins to play it goes fullscreen, not so in the Linux port. You can see the same behavior on the XBOX version by switching to the menu while a movie is playing, the movie continues to play in the corner, the issue I see plays it in the same place.

Not sure how better to describe this but will try. Probably easiest to just rip a DVD with DVDShrink and try to play it. As I've got 600 of them ripped this way switching isn't exactly an easy thing and I'm sure I'm not the only one. Would be helpful if someone could confirm this behavior on another install too.

Thanks!

[snappz]

I just tried and dvdshrink ripped disc and can confirm this bug also in rev12195. I noticed that with a current svn build you dont even get the small window playing.

[BLKMGK]

I just tried and dvdshrink ripped disc and can confirm this bug also in rev12195. I noticed that with a current svn build you dont even get the small window playing.

Odd, I got the window when I tried earlier this evening:confused2: Perhaps there's a new rev, I'm watching a show right now so cannot check:p

This has toggled a few times though, it used to do nothing but I knew something was going on because I'd lose UI sounds and could see a video listed in "now playing". Depending upon how you try to play the video I've seen slightly different behavior too but I cannot recall the second way I used to try and play - from the info screen maybe? The little window seems most prevalent though.

Thank you for double checking me on this! This is the one thing keeping my XBOX in the living room still, well that and games. An XBOX emulator one day would rock!

[stuartmarsden]

This works fine on amd64 ubuntu by using this method:

Download the deb, install by forcing both architecture and dependencies.

now run:

Code:

sudo getlibs /opt/xbmc/XboxMediaCenter

if you do not have getlibs then just do this first:

Code:

sudo apt-get install getlibs

This will check which 32bit libraries are needed download and install them.

Now it can be run as normal. This is my first run of XBMC on linux and I am very impressed. I have been using XBMC for neraly 4 years and linux for about 8 so glad to see the two coming together.

This runs really stable on my setup and all the functionality I need is in place. Thanks to all those involved.

By the way why does the package depend on lots of dev packages. It is a binary and no compilation is being done so they should be unnecessary. My method above did not pull in any dev packages and it is running just fine.

[rodalpho]

Very cool! Maybe we don't need to maintain a 64bit version, then? Do you have a list of required libraries on a clean 64bit system? The extra dependencies are unnecessary and will be removed in later packages.

I was out of town for Easter; now that I'm back I'm focusing on getting a proper source package working and submitted to the PPAS so it can be added to sources.list and installed via "apt-get install xbmc". More to come.

[rodalpho]

Also IMO we should focus on getting the 3 major confirmed bugs fixed (ISOs not playing, resolution slowdowns, and multi-path SMB thumbnail corruption) then release 2.1a1pa2 (2.1 alpha 1 potential alpha 2, using gamester's terminology). Then bang on that for a week and if it looks clean release 2.1a1 final.

Only question is if 2.1a1pa2 should be the 2.1a1 twig with specific patches backported and applied to 12195 or the dailies (>12282). Ideally the former but I don't know if the devs are really willing to do that kind of diligence at the alpha stage.

Thoughts?

[spiff]

we will surely do the former.

it sounds like a plan, only other diffs we want to include are diffs for allowing ~/.xbmc

[BLKMGK]

Also IMO we should focus on getting the 3 major confirmed bugs fixed (ISOs not playing, resolution slowdowns, and multi-path SMB thumbnail corruption) then release 2.1a1pa2 (2.1 alpha 1 potential alpha 2, using gamester's terminology). Then bang on that for a week and if it looks clean release 2.1a1 final.

Only question is if 2.1a1pa2 should be the 2.1a1 twig with specific patches backported and applied to 12195 or the dailies (>12282). Ideally the former but I don't know if the devs are really willing to do that kind of diligence at the alpha stage.

Thoughts?

Whoa! ISO do not seem to be an issue, it's the IFO/VOB rips that are an issue. So far as I know no one has had issues with ISO unless I missed it. They actually DO play it's just that they do not go full screen and instead play in a little corner of the menu Grab a copy of DVDShrink, rip a DVD to a folder, then from the top of the folder press PLAY in XBMC and you shoudl have no issues reproducing this.

[wattazoum]

Hello,

I am wattazoum and am new to this forum. I am posting to propose my help on packaging XBMC for debian based system ( well, I am actually an ubuntu user ) and to help in putting the packages on the team-xbmc PPA. I hope you will accept my help .

Fisrt I would like to thanks Rodalpho for the work he made and the interest that work has created on the impact of the packging to the code.

Here is some comment I have on the packaging in linux in general :

1. Usually if we want to install something "a la windows" we install it in /opt ( ~= Programs Files). That's what has been done in the deb package. It's not wrong but usually we would not use the deb format to do that. I would be done via an install script. But as XBMC, if I understood well, won't be split all over the system we can used the trick that consist in installing the full package in /usr/share/xbmc ( or /usr/local/share/xbmc if we use "make install").

2. The system binary ( launcher ) should be in /usr/bin (if the installation is made from a deb) . /usr/local/bin is used if the installation is made via "make install". Here start the impact on the source code. Can the binary be away from the other files ?
A solution is to create a launcher script to put in the $BIN dir to call the binary in /usr/share/xbmc . That might permit to avoid modification of the code and will match a recommendation that is to not have very big binary in the $BIN dir.
The launcher script :
http://bazaar.launchpad.net/~team-xbmc/x...ne25m8df-2

3. The user rights problem : That is the problem that some have called "chown problem" in this thread. After an install, no other user but the root might be able to run the application cause they won't have the right to write in the install directory. The only correct solution is to make those writable location be in the user's $HOME dir. This mainly concerns "UserData" IMHO. There is no need to move the skins and visualisations there unless the skins settings are set in the skin diretory. This is the biggest problem to deal with.

4. Optional but nice to have : allow the users to install skins for themselves. This will need some changes in the code to make xbmc manage 2 skins directory aat the same time. The system skins directory (/usr/share/xbmc/skins) and the user skin directory ($HOME/.local/share/xbmc/skins : this path is the one to use if we want to be compliant to the XDG specification). This is not a packaging issue. It's just informative.

5. Usually, for a big application like XBMC, we make multiple packages out of a single source folder. Then we use meta-package to assemble it. See an example of control file that I made for XBMC. This allows to have a default installation package, with a default skin, a default set of python scripts , of visualisation and so on. Then if someone else wants to make another skin package ( let's take XTV for instance : xbmc-skin-xtv.deb) he can and the installation of this skin won't requires the installation of the default skin ( the package should only depends on xbmc-datas ) . This will also permit the creation of different flavour of XBMC package ( eg. with XTV skin; special set of scripts, other visualisations .... ).
The debian control file :
http://bazaar.launchpad.net/~team-xbmc/x...i7vfpj3g-5

The work I have done is available on BZR on launchpad :
My debian directory :
http://bazaar.launchpad.net/~team-xbmc/x...i7vfpj3g-1

As for the installation, I used the Build.sh script from SVN and sets some options to avoid having issues.
The debian rules file :
http://bazaar.launchpad.net/~team-xbmc/x...7vfpj3g-25

To manage blueprints like this one, you can use launchpad
See https://blueprints.edge.launchpad.net/xb...bmc-on-ppa

I also propose the debian directory to be put on a VCS so that they are available for everyone and the changes in them are trackable.

Thank you to have read this long post and hope this help. I am available for any help need.

PS : I would like to thanks Gamester17 to have told me about this thread

[rodalpho]

Wattazoum, it sounds like you have infinitely more experience in creating debian packages than I do. I approached it more like a RPM, which I've done before, but they're not really analagous. If you'd like to donate your time to take over packaging duties I certainly have no objections handing it off. This was very much a learning experience for me. As for your points:

1) If /usr/share/xbmc is a more standard location for monolithic installs we should be putting it there, agreed.

2) If that's the standard way to do it and it can be done without causing the devs to segment out the application and preserve the monolithic install, definitely go for it. The devs don't want to put libraries in /usr/lib, bins in /usr/bin, etc, as XBMC is cross-platform and that would complicate development. At least not yet.

3,4) Everybody agrees with you there, and the devs are already planning to put user modifyable stuff in "~/.xbmc". The UserData directory at first but later the skins dir, scripts dir, etc, also.

5) Sure, if thats the standard way to do it, makes sense to me.

As for putting the debian directory in SVN (they don't use CVS) that makes sense too, I was going to suggest that once I smoothed out all the rough edges. As of yesterday I was still stuck on building the source package properly so that PPAS would accept it.... it needs to be _exactly_ correct in every way or the damn thing rejects it every time. But anyway yeah, definitely submit the debian dir as a patch if the devs agree.

Thanks, and cheers!

[wattazoum]

well, actually I didn't mean CVS but realy VCS as for Version Control System .
It would make sense if the developpers doesn't accept a debian directory patch on SVN as this is not really part of the application. I will start the work on a branch on launchpad and I'll keep you informed on how well it's going.

Cheers