Porteus-1.1-rc1-x86_64 is ready for testing

New features which should be implemented in Porteus; suggestions are welcome. All questions or problems with testing releases (alpha, beta, or rc) should go in their relevant thread here, rather than the Bug Reports section.
User avatar
francois
Contributor
Contributor
Posts: 4945
Joined: 28 Dec 2010, 14:25
Distribution: kde xfce porteus manjaro kubun
Location: Enfin l'été, le changement climatique attendu: le soleil.

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#46 by francois » 02 Nov 2011, 03:43

I just installed rc1, and will come with some feedback. How come the thread is so calm now?
Voltaire: Le mieux est l'ennemi du bien.

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#47 by Ahau » 02 Nov 2011, 12:00

francois, we were just waiting for our favorite French Canadian tester to show up. Now we're good to go!

Or, maybe it's because fanthom put together a kick-ass release with very few issues :D
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
Hamza
Warlord
Warlord
Posts: 1847
Joined: 28 Dec 2010, 07:41
Distribution: Porteus
Location: France

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#48 by Hamza » 02 Nov 2011, 12:04

PSC is ready for rc2.
Sent source to fanthom.
NjVFQzY2Rg==

User avatar
francois
Contributor
Contributor
Posts: 4945
Joined: 28 Dec 2010, 14:25
Distribution: kde xfce porteus manjaro kubun
Location: Enfin l'été, le changement climatique attendu: le soleil.

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#49 by francois » 08 Nov 2011, 03:53

@Ahau: The first reason you mention sure pleases me. But alas, no doubt that the second reason is the real one. Good for us.

Yet I did not found much, though I did not work with it much. All I found on my hp pavilion 2713ca is that the kde gui when trigerred is cut on the left, preventing return to the previous menu.

Posted after 5 days 10 hours 45 minutes 24 seconds:
Rc1 looks very good and works quite fine. The bcmXX wifi driver works out of the box. If you add this feature the nvidia module of beny, all the needs of my pavilion 2713ca laptop are fulfilled.

However, I found that the lang=ca cheatcode in the menu.lst does not work. This is not the case for porteus rc1 32bit.
Voltaire: Le mieux est l'ennemi du bien.

Kriss
Samurai
Samurai
Posts: 133
Joined: 06 Jul 2011, 07:07
Location: Russia

smplayer/mplayer bug (Porteus 1.1rc)?

Post#50 by Kriss » 12 Nov 2011, 16:22

Hello all!
Actually I'm not sure if this is bug, but it's as follows:
I have a quite old noteboook, Acer Aspire 5100, CPU Turion 64x2 2.3Ghz, 2 cores, 4Gb but it's barely enough for FullHD video (sometimes frames are skipped with CPU usage of ~40-50%, so I need -frameskip option).
Most likely because of videocard ATi x1100 mobile that uses 256Mb of RAM for its needs (I think I'll upgrade it to x1600 soon, but it takes time to change motherboard).
So in WinXP in SMPlayer I use -sndvol-max 2000 if I want to use headphones for everyone to hear (broken integrated soundcard and no way to use notebook's dynamics). Everything's relatively fine here (SMPlayer 3.6.9 SVN-r3611 + Mplayer Sherpya-SVN-r33883-4.2.5)

In Porteus x86_64 v1.1rc1 this setup leads to framerate of... 1 frame per 5 second, sometimes I only see static image (and CPU usage shows its not used at all).
If I uncheck framedrop option, everythin'g back to normal (except video lags behind sound because of lack of computing power).
I've tried to use mplayer alone "mplayer -framedrop -softvol-max 1100 ./video.mkv" with the same result.
GNOME player worked Ok but I wasn't able to make it louder with +60dB option. It just didn't worked.

P.S. Can somebody tell me how mplayer was compiled in 1.1rc1 so I'll try to compile newer mplayer in the same way. Slackware packages had dditional dependencies.

Added: Just checked and got the same results on quad-core computer with Radeon HD 4650... :shock:
Video used: "[Rising Sun] Spice and Wolf II - 01 [1920x1080-H264-FLAC][EA85CA2C].mkv"
Suggestions/corrections/additions are always welcome.

User avatar
fanthom
Site Admin
Site Admin
Posts: 4566
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#51 by fanthom » 12 Nov 2011, 22:58

@Kriss
Merged here as bugs related to developmment versions should be posted in rc threads only.
Just checked and got the same results on quad-core computer with Radeon HD 4650
must be smplayer settings issue so (especially if it works in gnome-mplayer). pleas run porteus in "Always Fresh" mode and make sure that video driver in smplayer is set to 'xv' and not 'x11' or 'gl'.
i have tried on 720p movie trailer (dont have 1080p around atm) and works ok for 'xv' (eating 60% of the CPU).

Cheers
Please add [Solved] to your thread title if the solution was found.

Kriss
Samurai
Samurai
Posts: 133
Joined: 06 Jul 2011, 07:07
Location: Russia

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#52 by Kriss » 13 Nov 2011, 16:04

I'm sorry for confusion I've created over my own stupidity.
Originally I've tried to compare video playback in winXP (I've mentioned versions of mplayer and smplayer before) and this RC of Porteus after you've said that open-source drivers for legacy ATi cards are quite good, but then I got carried away and probably fooled myself with inaccurate tests.
The only thing I'm sure of now is that under windows SMPlayer+ Mplayer (I already mentioned versions I use, optimized for P4 with disabled 3DNow and 3DNowext because originally I had only Intel CPUs) plays video much better than default ones in this rc1 (CPU: AMD Turion with 3DNow and 3DNowext).
I excluded "driver isn't as good as from legacy branch" version because without "-framedrop" option video plays Ok with slowly growing audio/video desynchronisation (same for all players since they use Mplayer).
GNOME Mplayer just didn't honor its +60dB and -framedrop options (results were described above)

So in the end I have video and notebook that's at least VERY close to being able to play this video without problems.
In WinXP it's very hard to notice that some frames were dropped (if they are dropped at all) but it looks horrible in Porteus x86_64 1.1rc1
As I understand this can be because of:
drivers (less likely)
mplayer version differences 32819 vs 33883 (optimizations and fixed bugs)
mplayer build differences (optimizations)
Also I suspect that this version have very bad multithreading capabilities (Only one core of notebook is busy while other one does nothing judging by utility I've mentioned in another thread, besides mplayer don't use more than 49-50%). Although option -lavdopts threads=4 is passed to it

So in the end I just want to ask how did you compile mplayer (what flags, patches and so on) to tinker with it by myself.

P.S. I've tried almost all possible video outputs in smplayer before realized that it makes no difference.
Yes, I've got something similar on quad-core CPU, but I'm not so sure of that right now... I already wrote too much gibberish to explain it =)

P.P.S. It was written somewhere related to mplayer-win builds to always prefer optimized builds over runtime CPU detection (not sure if it's mplayer in general or about windows builds).
Suggestions/corrections/additions are always welcome.

User avatar
fanthom
Site Admin
Site Admin
Posts: 4566
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#53 by fanthom » 13 Nov 2011, 21:20

i have used latest version of Mplayer which supports vaapi from Splitted Desktop site:
http://www.splitted-desktop.com/static/ ... yer-vaapi/
vaapi works great for all i3/i5/i7 systems. this mplayer supports also vdpau. xvba is broken with latest amd drivers so i have removed it.
unfortunatelly this version does not support multithreading due to colliding patches.

here is the config for 64bits:
[codeCFLAGS="-Os -march=x86-64" CXXFLAGS="-Os -march=x86-64" MAKEOPTS="-j2" ./configure --prefix=/usr --mandir=/usr/man --libdir=/usr/lib64 --enable-runtime-cpudetection --yasm=''][/code]
and 32bits:

Code: Select all

CFLAGS="-Os -march=i486 -mtune=i686" CXXFLAGS="-Os -march=i486 -mtune=i686" MAKEOPTS=-j2 ./configure --prefix=/usr --mandir=/usr/man --libdir=/usr/lib --enable-runtime-cpudetection --yasm=''
my proposition:
please compile latest mplayer for both archs with multithread support (and other features if you like) and share it in "Community Efforts" or "xzm modules" section.
i'll test them, compare features and decide if they could be used in official release.

Cheers
Please add [Solved] to your thread title if the solution was found.

Kriss
Samurai
Samurai
Posts: 133
Joined: 06 Jul 2011, 07:07
Location: Russia

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#54 by Kriss » 15 Nov 2011, 11:35

Thank you!
I'm sorry for creating such a fuss instead of just trying to compile latest svn version. I was afraid that I'll end-up installing tons of different codecs and tools first, but lucky for me it's not true in case of mplayer =)
Just tried to compile it and it needed only yasm (improves performance on h264 videos) and git (configure tries to download latest ffmpeg using git).
Default mplayer configuration was enough to play that problematic FullHD video using only a little bit more than 50% of CPU time.

P.S. I'll post modules when I'll create something I won't be ashamed of.

P.P.S. There was a typo in informational message about proprietary ATi driver. It was written properietary IIRC.

Added: Looks like in the past I've run into something similar to bugs, mentioned here (video stops with CPU doing nothing, but sound continued to play) with default Porteus64 1.1rc1 mplayer.
Last edited by Kriss on 17 Nov 2011, 20:02, edited 2 times in total.
Suggestions/corrections/additions are always welcome.

User avatar
libernux
White ninja
White ninja
Posts: 28
Joined: 01 Nov 2011, 17:36
Distribution: porteus v3.1 32bit XFCE
Location: Netherlands

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#55 by libernux » 17 Nov 2011, 08:14

Hi all,

The library libpng is missing in the initial install. I discovered this when i was compiling E17. According to pkg-config libpng is a required library for gdk-pixbuf but because it was missing it did not return any CFLAGS. Can you please fix this. For now I solved it by installing libpng.
I was born with nothing and I still got most of it.

User avatar
brokenman
Site Admin
Site Admin
Posts: 5460
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#56 by brokenman » 17 Nov 2011, 13:34

aaa_elflibs-13.37-x86_64-7 contains the libpng library files. Are you using all base modules? Interesting.

Code: Select all

find /usr/ -name libpng*
/usr/lib64/libpng12.a
/usr/lib64/libpng14.a
/usr/lib64/libpng.so.14
/usr/lib64/libpng.so.3
/usr/lib64/libpng.so.3.44.0
/usr/lib64/libpng12.so.0
/usr/lib64/libpng12.so.0.44.0
/usr/lib64/libpng14.so.14
/usr/lib64/libpng14.so.14.5.0
/usr/include/libpng12
/usr/include/libpng14
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
fanthom
Site Admin
Site Admin
Posts: 4566
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#57 by fanthom » 17 Nov 2011, 14:55

i think it could be cause of missing /usr/lib64/pkgconfig files (had this error during lxde compilation or something..) so i ended up adding full jpg and png packages to the build.
they will be included in the ISO since rc2.

Thanks
Please add [Solved] to your thread title if the solution was found.

User avatar
libernux
White ninja
White ninja
Posts: 28
Joined: 01 Nov 2011, 17:36
Distribution: porteus v3.1 32bit XFCE
Location: Netherlands

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#58 by libernux » 18 Nov 2011, 08:48

Hello,

The language selection tool is not working for me.
If I close the dialog about the kde-keyboard settings I get the following error:
xlanguage-selection-tool line 440: syntax error unexpected eof
Now this script has only 439 lines.
Can you please have a look at this.

After some investigation myself it appears that an "fi" statement is missing at line 277.
I was born with nothing and I still got most of it.

User avatar
brokenman
Site Admin
Site Admin
Posts: 5460
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: Porteus-1.1-rc1-x86_64 is ready for testing

Post#59 by brokenman » 19 Nov 2011, 00:13

I believe the LST is not functional in rc's. This will be available in the final 1.1 release. Please wait a little it s not too far off.
How do i become super user?
Wear your underpants on the outside and put on a cape.

Locked