Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy
Hi, Fred.fredx181 wrote:Here's for testing gnome-mplayer-1.0.4_i386.deb:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
And mplayer2-9d6b188_i386.deb:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
Tested the packages on three computers with jwm version after uninstalling the default gmplayer. CPU PIII 600, 650 and 933 Mhz. gnome-mplayer needs dbus-x11 small dependency. Same result as in my previous post. I think enable_cache mplayer2 option is the problem. I can't make mplayer2 work on my hardware.
I read something similar solved here:
http://forum.porteus.org/viewtopic.php?t=1460&p=10303
http://forum.stmlabs.com/printthread.php?tid=11589
Toni
Hi, Fred.
In the last separate gnome-mplayer package I see some libs in /op/lib
The libs are from Debian Wheezy, Squeeze or other linux repository?
Isn't it possible to replace for example libnotify.so.1.2.3 with symlink to /usr/lib/i386-linux-gnu/libnotify.so.4.0.0 and the same way for other libs in /opt/lib?
Otherwise mplayer2 and gnome-mplayer separate packages can be compressed to 4,1Mb squashfs module which is very good.
Toni
Just to make this clear- inside both packages:fredx181 wrote:It depends on what you call "non-debian-wheezy libs"1. Which one is the package you mean? This one:
http://smokey01.com/saintless/Fredx181/ ... -1.0.4.deb
Both packages will add around 30 non-debian-wheezy libs
They are not installed through apt-get on DebianDog but for sure libs from debian-wheezy.
(ok, just wanted to mention this)
I see for example libnotify.so.1.2.3 which is not debian wheezy. Am I wrong? We have already debian wheezy installed with apt-get /usr/lib/i386-linux-gnu/libnotify.so.4.0.0Here's for testing gnome-mplayer-1.0.4_i386.deb:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
............................
http://smokey01.com/saintless/Fredx181/ ... -1.0.4.deb
In the last separate gnome-mplayer package I see some libs in /op/lib
The libs are from Debian Wheezy, Squeeze or other linux repository?
Isn't it possible to replace for example libnotify.so.1.2.3 with symlink to /usr/lib/i386-linux-gnu/libnotify.so.4.0.0 and the same way for other libs in /opt/lib?
Otherwise mplayer2 and gnome-mplayer separate packages can be compressed to 4,1Mb squashfs module which is very good.
Toni
Tested on my Fujitsu Siemens Amilo laptop, which has Pentium M 1.6GHz CPU and 1 GB RAM.mcewanw wrote:Just about to download your latest Openbox version Fred as well as the mplayer2 and gnome-mplayer deb for testing.
As per always on this machine (including with Puppy linux) I had to first blacklist module snd_intel8x0m in /etc/module.d/alsa-base-blacklist.conf to avoid a video freeze with mplayer. Also, per usual, I needed vo=x11 in mplayer config or video wouldn't play.
Result thereafter in latest openbox debiandog:
mplayer2 worked fine with my test video. Also gnome-player worked fine with same video. Finally, I also noted that mplayer consumed less CPU when running via gnome-player (presumably because of the vo=vdpau in the gnome-player section of the config file). However that CPU load improvement wasn't as great as you experienced Fred - maybe 30% improvement. However, the overall CPU load wasn't much different to vo=x11 with zoom=1 for mplayer alone, presumably because gnome-player itself uses a fair amount of CPU. I checked the overall CPU load simply by looking at CPU idle figure when running top.
I also tried mplayer2 in current jwm debiandog on same machine after first purging gmplayer-portable per Toni's instructions. Once again, on this Pentium M machine, mplayer2 worked fine - exactly the same for me as in Fred's openbox distribution - no extra libs were required and that was on a clean jwm installation. I haven't tried gnome-mplayer there this time.
I also FINALLY solved the mystery of why DpupWheezy mplayer appeared to be using half the cpu of even the one in Fred's distribution. I don't know if my brain simply wasn't working the last two weeks, but suddenly I thought "could it be a side effect of cpu frequency scaling?" and it was...
I hadn't set up any cpu frequency scaling in DpupWheezy so my cpu was running at full performance 1.6GHz. In Fred's openbox debiandog I opened a console and changed dir to /sys/devices/system/cpu/cpu0/cpufreq/. I then entered cat scaling_cur_frequency whilst mplayer2 was running and found it was 600,000 MHz. cat scaling_governor revealed that the governor was correctly set to ondemand. I temporarily changed that to 'performance' mode by entering: echo performance > scaling_governor
That made the cpu run at full 1,600,000 MHz instead of low speed 600,000 MHz. Note that the mplayer cpu load percentage is of course proportional to the cpu current frequency. You actually NEED to check your cpu current frequency when doing these mplayer performance tests or you are likely to get misleading results like I previously did! :-)
NOTE WELL however, that the mplayer currently used in jwm debiandog (the gmplayer included one) uses even more cpu than I thought on my computers. It uses so much cpu that the cpu actually scales (with scaling governor ondemand) to its max 1.6GHz frequency whilst that mplayer is playing so the apparently double cpu load I previously experienced is actually almost three times worse than that, so maybe five or six times more cpu than the mplayer (or the new mplayer2 or Debian's official mplayer) in Fred's openbox version - since it is giving that bad proportional result at 1.6GHz, whereas the others were being tested proportional to 600,000 MHz cpu frequency. If scaling governor 'performance' had instead been used in all such tests (meaning max cpu freq 1.6 GHz on my computer), then Fred's mplayers or the Debian official mplayer use only around 10% CPU, whereas jwm gmplayer's mplayer uses around 50% CPU, which is terrible... Personally I'd remove it unless a fix can be found (I believe it may be missing, albeit non-essential, libraries, rather than the mplayer itself but haven't been able to confirm that).
So, in summary, Fred's mplayer2 works excellently on this machine. I'm sure it will work on my other machine too (which isn't so fussy). The existing mplayer in jwm version uses five or six times more cpu (not just double).
github mcewanw
Note that the improved vdpau result might have been expected from:
http://www.mplayer2.org/differences/
Except, that vo=vdpau doesn't seem to work when just used in mplayer2 config file (it is working for the gnome-mplayer part of that config file). So my question would be - how to get vdpau working (fullscreen for example) with mplayer2 alone. I don't use gnome-player myself, since I prefer to control mplayer itself simply via the keyboard. I also note, Fred, that you say that you didn't compile in any vdpau support (unless that is there by default, but why only working with gnome-mplayer???).
EDIT: The --zoom in the Mplayer tab of gnome-mplayer didn't seem to do anything though. Video didn't start in fullscreen mode by default but it did go into fullscreen mode if I pressed keyboard F whether --zoom was there or not.
EDIT2: on openbox version I just discovered that vo=xv in mplayer config seems to be working on this machine afterall; the colours look fine and I get fullscreen using mplayer2 alone (without gnome-mplayer) - sleep time here now so will double-check tomorrow. This Pentium M machine has some old radeon graphics card. From /var/log/Xorg.0.log:
[ 30.923] (--) RADEON(0): Chipset: "ATI Radeon Mobility 9600 (M11) NR (AGP)" (ChipID = 0x4e52)
http://www.mplayer2.org/differences/
Except, that vo=vdpau doesn't seem to work when just used in mplayer2 config file (it is working for the gnome-mplayer part of that config file). So my question would be - how to get vdpau working (fullscreen for example) with mplayer2 alone. I don't use gnome-player myself, since I prefer to control mplayer itself simply via the keyboard. I also note, Fred, that you say that you didn't compile in any vdpau support (unless that is there by default, but why only working with gnome-mplayer???).
EDIT: The --zoom in the Mplayer tab of gnome-mplayer didn't seem to do anything though. Video didn't start in fullscreen mode by default but it did go into fullscreen mode if I pressed keyboard F whether --zoom was there or not.
EDIT2: on openbox version I just discovered that vo=xv in mplayer config seems to be working on this machine afterall; the colours look fine and I get fullscreen using mplayer2 alone (without gnome-mplayer) - sleep time here now so will double-check tomorrow. This Pentium M machine has some old radeon graphics card. From /var/log/Xorg.0.log:
[ 30.923] (--) RADEON(0): Chipset: "ATI Radeon Mobility 9600 (M11) NR (AGP)" (ChipID = 0x4e52)
github mcewanw
Hi, William.
I would not remove gmplayer because it works very well on my hardware and the test results from my hardware are much different than yours. And because gmplayer2 does not work at all on my hardware. And because the other alternatives will add not only more size but also non official wheezy libs.
"So, in summary" looks much different and even opposite to me. And with so easy option to remove gmplayer and install different one I don't know why is important to discuss this again and again. If the user doesn't like gmplayer it is easy to change it.
Toni
It is a mirracle with 5-6 times more CPU usage gmplayer plays video at all on my hardware...mcewanw wrote:Personally I'd remove it unless a fix can be found (I believe it may be missing, albeit non-essential, libraries, rather than the mplayer itself but haven't been able to confirm that).
....................
So, in summary, Fred's mplayer2 works excellently on this machine. I'm sure it will work on my other machine too (which isn't so fussy). The existing mplayer in jwm version uses five or six times more cpu (not just double).
I would not remove gmplayer because it works very well on my hardware and the test results from my hardware are much different than yours. And because gmplayer2 does not work at all on my hardware. And because the other alternatives will add not only more size but also non official wheezy libs.
"So, in summary" looks much different and even opposite to me. And with so easy option to remove gmplayer and install different one I don't know why is important to discuss this again and again. If the user doesn't like gmplayer it is easy to change it.
Toni
Last edited by saintless on Fri 16 May 2014, 14:51, edited 1 time in total.
Hi Toni and everyone,
Haven't tested much yet, here's one little annoyance, that I wanted to report earlier and it strikes me in the eye in this release too. It must be JWM specific, when the desktop emerges on bootup, the drive icons have a white rectangular bakground, which subsequently disapears, or gets replaced with the wallpaper. The desktop drive icons setting has an option 'show frame around icons', even though it's not checked, the white rectangle on bootup precisely coincides with the frame, if I select it. Don't know if the following is related:
Haven't tested much yet, here's one little annoyance, that I wanted to report earlier and it strikes me in the eye in this release too. It must be JWM specific, when the desktop emerges on bootup, the drive icons have a white rectangular bakground, which subsequently disapears, or gets replaced with the wallpaper. The desktop drive icons setting has an option 'show frame around icons', even though it's not checked, the white rectangle on bootup precisely coincides with the frame, if I select it. Don't know if the following is related:
Code: Select all
** (desktop_drive_icons:2863): WARNING **: Couldn't get background image, transparency won't work
** (desktop_drive_icons:2863): CRITICAL **: desklet_paint_fake_bg: assertion `self->wallpaper' failed
** (desktop_drive_icons:2863): CRITICAL **: desklet_paint_fake_bg: assertion `self->wallpaper' failed
Here's something for ultimate stripping:sfs wrote:gnome-mplayer , mplayer not strippedfredx181 wrote:First, new DebianDog-Porteus-openbox_xfce-beta.iso:
http://ip-208-109-22-214.ip.secureserve ... 96d#583032technosaurus wrote:you get a smaller binary with:
strip -s -R .note -R .comment *
or for libs
strip --strip-unneeded -R .note -R .comment *.so*
Yes, it is specific for every WM. It is long ago discussed timing issue and I think Fred was the last one reported similar behaviour.anikin wrote:... I wanted to report earlier and it strikes me in the eye in this release too. It must be JWM specific...
Open /root/startup-jwm and you will see 3 different combinations. The last one worked for Fred and I left it as default. The problem is drive icons appear before the wallpaper (rox pinboard).
To fix this try to put sleep 2 before desktop_drive_icons line:
Code: Select all
# test configuration 3
/usr/bin/rox -p ${HOME}/.config/rox.sourceforge.net/ROX-Filer/pinbd &
/opt/bin/start-up &
frisbee-tray &
volumeicon &
sleep 2
desktop_drive_icons &
Toni
Hi, Fred.
Small bug (maybe) in desktop drive icons in both versions.
Eject optical drive from desktop icon does not work. See the picture.
gives the same output error if the drive is mounted, but same command in Puppy unmounts and eject the CD without errors.
The only command that works in DebianDog is:
Toni
Small bug (maybe) in desktop drive icons in both versions.
Eject optical drive from desktop icon does not work. See the picture.
Code: Select all
eject -T
The only command that works in DebianDog is:
Code: Select all
eject
RSH made a right click utility to convert a directory into a *.deb file.
Do you think this might be useful to adapt to Debian Dog?
http://murga-linux.com/puppy/viewtopic.php?t=93801
Do you think this might be useful to adapt to Debian Dog?
http://murga-linux.com/puppy/viewtopic.php?t=93801
Hi, Dan.
Actually DebianDog has something very similar from Fred called redeb. It creates deb package from folder and it is included as right click option for every file manager.
I just tested this extracted pet, made sfs and loaded and it works in DebianDog. It creates example control file with GUI for edit which redeb does not. Maybe Fred will test it as well and share his thoughts.
I would think of using this pet to convert pet to deb files but unfortunately it is not safe for DebianDog. If some converted pet to deb package replace existing files after uninstalling this package the replaced files will be removed and the system will be broken. Also pet packages do not have dependency information and most of them will not work proper and apt-get will not auto-solve the dependency problem since there is no dependency infornmation inside pet packages. The only way to fix dependencies for converted pet package is to search them one by one from terminal output errors.
I think redeb to extract, edit and repack deb packages is all we need.
Toni
Actually DebianDog has something very similar from Fred called redeb. It creates deb package from folder and it is included as right click option for every file manager.
I just tested this extracted pet, made sfs and loaded and it works in DebianDog. It creates example control file with GUI for edit which redeb does not. Maybe Fred will test it as well and share his thoughts.
I would think of using this pet to convert pet to deb files but unfortunately it is not safe for DebianDog. If some converted pet to deb package replace existing files after uninstalling this package the replaced files will be removed and the system will be broken. Also pet packages do not have dependency information and most of them will not work proper and apt-get will not auto-solve the dependency problem since there is no dependency infornmation inside pet packages. The only way to fix dependencies for converted pet package is to search them one by one from terminal output errors.
I think redeb to extract, edit and repack deb packages is all we need.
Toni
Hi Toni,
The first thing I did when I got home tonight (and reading your message) was making a new remaster with the previous mplayer included.
Not very clever of me to include something that is not tested yet, so again... Sorry!
A few MB's less space is nice but it should work alright of course.
It should work with all computers, specially yours
So here's new iso with working mplayer:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
I'll reply later on your other messages, to tired now.
William, thanks for testing thoroughly, I'll come back later on the details.
Fred
Yes, forgot to write that "apt-get -f install" is neededTested the packages on three computers with jwm version after uninstalling the default gmplayer. CPU PIII 600, 650 and 933 Mhz. gnome-mplayer needs dbus-x11 small dependency. Same result as in my previous post.
The first thing I did when I got home tonight (and reading your message) was making a new remaster with the previous mplayer included.
Not very clever of me to include something that is not tested yet, so again... Sorry!
A few MB's less space is nice but it should work alright of course.
It should work with all computers, specially yours
So here's new iso with working mplayer:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
I'll reply later on your other messages, to tired now.
William, thanks for testing thoroughly, I'll come back later on the details.
Fred
Thanks, Fredfredx181 wrote:It should work with all computers, specially yours
So here's new iso with working mplayer:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
It works, but... puppy account does not have wallpaper and gnome-mplayer does not play video from puppy account. Same state=0 message:
Code: Select all
puppy@dog:~$ gnome-mplayer
in media state change with state = 0
Replacing /home/puppy/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml with the one from /root/.config... and chown /home/puppy, exitX and startx does not make wallpaper to appear for puppy user.
For root gnome-mplayer and mplayer work and all looks fine.
I will wait for your word to replace the iso on the site.
BTW pfileserach is included in pfind and pburn debs. No critical to have pfiesearch two times but it is good to know where it came from. I will try to check all packages on the site this weekend. Some should be removed and some need to be edited I think.
Toni
Hi Toni,
About, the gnome-mplayer error I think I know what's the problem but about the wallpaper I'll have to look at it.
So, yes, wait with new iso upload and I'll probably upload new one again tomorrow.
Edit:
Strange, wallpaper shows for me on puppy account and btw, I didn't change anything for that in latest iso and also not in previous iso.
Can you check again?
Edit2: Can you try with this content of xfce4-desktop.xml (in /home/puppy/.config/...../...):
Fred
UGH , thanks for noticing.It works, but... puppy account does not have wallpaper and gnome-mplayer does not play video from puppy account. Same state=0 message:
About, the gnome-mplayer error I think I know what's the problem but about the wallpaper I'll have to look at it.
So, yes, wait with new iso upload and I'll probably upload new one again tomorrow.
Yes, but I think it can't do any harm do leave it like it is.BTW pfileserach is included in pfind and pburn debs. No critical to have pfiesearch two times but it is good to know where it came from.
Edit:
Strange, wallpaper shows for me on puppy account and btw, I didn't change anything for that in latest iso and also not in previous iso.
Can you check again?
Edit2: Can you try with this content of xfce4-desktop.xml (in /home/puppy/.config/...../...):
Code: Select all
<?xml version="1.0" encoding="UTF-8"?>
<channel name="xfce4-desktop" version="1.0">
<property name="backdrop" type="empty">
<property name="screen0" type="empty">
<property name="monitor0" type="empty">
<property name="image-path" type="string" value="/usr/share/backgrounds/xfce/desktop.jpg"/>
<property name="last-image" type="string" value="/usr/share/backgrounds/xfce/desktop.jpg"/>
<property name="last-single-image" type="string" value="/usr/share/backgrounds/xfce/desktop.jpg"/>
<property name="brightness" type="int" value="0"/>
</property>
</property>
</property>
<property name="desktop-icons" type="empty">
<property name="icon-size" type="uint" value="32"/>
<property name="tooltip-size" type="double" value="64.000000"/>
<property name="use-custom-font-size" type="bool" value="true"/>
<property name="font-size" type="double" value="9.000000"/>
<property name="file-icons" type="empty">
<property name="show-trash" type="bool" value="false"/>
</property>
<property name="single-click" type="bool" value="true"/>
</property>
</channel>
Last edited by fredx181 on Fri 16 May 2014, 22:13, edited 2 times in total.
Hi Toni,saintless wrote: "So, in summary" looks much different and even opposite to me. And with so easy option to remove gmplayer and install different one I don't know why is important to discuss this again and again. If the user doesn't like gmplayer it is easy to change it.
Toni
As I said, "Personally" I would remove it, and will; as I said before I accept that it may be different on your machine and understand your comments about the debian libraries. For Fred and anyone else who had results similar to my own, I raised the matter yet again because it was important new information regarding CPU frequency scaling and the importance of taking that into account when testing anything - during testing should turn off CPU frequency scaling or change governor to 'performance'. If I discover some improvement on my machine regarding the gmplayer version, which I'm still looking into, I will let others know about that again too but only in case the information is useful to someone else. ;-)
I'm the one who found that gmplayer version and I like it because of its small size, and would prefer to keep it, so I'll be happy at least to hear that it works well on others' computers should they test it bearing in my my cpu frequency scaling comments. Some old machines won't do cpu frequency scaling so the results obtained will be at full performance anyway.
github mcewanw
For those who prefer numbers to words, here is my test of mplayer2 on Fred's latest openbox release. The Pentium M cpu on my machine can be scaled to any of the following running frequencies. I ran it at each frequency in turn, and using 'top', measured mplayer2 CPU usage percentage whilst running a video of size 480x360 (which used video encoding h264; audio encoding aac). I made the measurement at exactly the same point in the running video. I only made one run of results, whereas an average of many would be better (due to some variation resulting from variable scheduling and background processes), but these are representative and hopefully show the proportionality (almost constant CPU kHz usage by mplayer2 no matter the CPU running frequency):
The results suggest to me that should this mplayer2 work on another machine, it should perform very efficiently, using only 25.8% (i.e. 154800 kHz) of CPU, for similar video on a machine whose CPU is running at only 600000kHz (i.e. 600MHz CPU). Owing to the nice priority of processes, I imagine the amount of CPU mplayer could ever use will be limited on lower performing machines to a max allowed cpu fractional load percent so the proportionality would be lost for such cases. I could be completely wrong in my understanding of the above of course, so any feedback from others making similar measurements would be appreciated! :-)
William
Code: Select all
CPU running frequency(in kHz): 600000 800000 1000000 1200000 1400000 1600000
mplayer2 Proportion of CPU used: 25.8% 19.2% 15.9% 13.6% 12.2% 10.6%
mplayer2 CPU usage thus (in kHz):154800 153600 159000 163200 170800 169600
William
github mcewanw
Hi, Fred.
This works to show wallpaper for puppy account:
This works to show wallpaper for puppy account:
Tonifredx181 wrote:Code: Select all
<?xml version="1.0" encoding="UTF-8"?> <channel name="xfce4-desktop" version="1.0"> <property name="backdrop" type="empty"> <property name="screen0" type="empty"> <property name="monitor0" type="empty"> <property name="image-path" type="string" value="/usr/share/backgrounds/xfce/desktop.jpg"/> <property name="last-image" type="string" value="/usr/share/backgrounds/xfce/desktop.jpg"/> <property name="last-single-image" type="string" value="/usr/share/backgrounds/xfce/desktop.jpg"/> <property name="brightness" type="int" value="0"/> </property> </property> </property> <property name="desktop-icons" type="empty"> <property name="icon-size" type="uint" value="32"/> <property name="tooltip-size" type="double" value="64.000000"/> <property name="use-custom-font-size" type="bool" value="true"/> <property name="font-size" type="double" value="9.000000"/> <property name="file-icons" type="empty"> <property name="show-trash" type="bool" value="false"/> </property> <property name="single-click" type="bool" value="true"/> </property> </channel>