View Full Version : kissdx 0.13-7 is out - with picture pre-loading feature
The four people (I was the first) who said yes can download kissdx 0.13-7 to have their wishes come true :-)
http://www.vidartysse.net/kissdx/
Changes in 0.13-7:
New feature: When serving pictures, kissdx will now pre-cache the next picture to be displayed. This will speed up sequential picture browsing (e.g. slide-show) significantly on slower devices.
New feature: It is no longer necessary to restart kissdx for configuration file changes to take effect. Instead, just browse for servers and re-select kissdx on your KiSS player.
Fixed: make install didn't work - has now been verified on Ubuntu.
0.13-7 has a problem with picturecachesize = -1 in kissdx.conf (cache will be disabled).
0.13-7a fixes this.
Great work Vit - as usual! :)
What are your development plans now? Mayybe you hav plans to support FLAC audio files? With this kissdx would be IMHO very close to ideal :)
There is FLAC package for NSLU2 with libraries so maybe my dream would come true .... :)
Strange - after playing some MP3 files from NSLU2 (with Unslung 6.8) I noticed that load average is over 5.00 and all resources are eaten by 4 processes of kissdx. I started only one process and without players connected everything was OK.
I switched from 0.11-3 release which was waorking 100% OK all the time.
What's wrong? My config is taken from package - I've changed only dirs with multimedia files.
Strange - after playing some MP3 files from NSLU2 (with Unslung 6.8) I noticed that load average is over 5.00 and all resources are eaten by 4 processes of kissdx. I started only one process and without players connected everything was OK.
I switched from 0.11-3 release which was waorking 100% OK all the time.
What's wrong? My config is taken from package - I've changed only dirs with multimedia files.
Strange indeed. I don't see that here (Unslung 5.5).
Are the processes still using CPU after you stopped MP3 playback?
Are they using lots of memory still?
Great work Vit - as usual! :)
What are your development plans now? Mayybe you hav plans to support FLAC audio files? With this kissdx would be IMHO very close to ideal :)
There is FLAC package for NSLU2 with libraries so maybe my dream would come true .... :)
That looks interesting, but now I really should devote some time to try getting subtitles / multiple audio files working with DVD playback. That's first on my list, so don't fill my head with these tempting thoughts of FLAC playback... ;-)
gordansket
17-11-06, 16:57
I have to tell you this - I bought my Kiss DP-600 to be able to watch photos from computer on my TV (I only have wireless connection) and until now the whole package just wasn't usefull! With kissdx (and specially latest functionality) this is possible practically.
Strange indeed. I don't see that here (Unslung 5.5).
Are the processes still using CPU after you stopped MP3 playback?
Are they using lots of memory still?
During MP3 playback one kissdx takes over 90% of CPU (92-99%). Strange - for such simple task so much? But only 3% of MEM.
But it's strange - after each song one kissdx process is created (and main process still runs). So right now it's my 3-rd song and there are 4 kissdx processes. And now 2 processes take about 49% of CPU each and 3% of MEM each. Other two are OK - 0% CPU and 3% MEM. Load over 3.
Next song (4th) and next kissdx. Now 3 kissdx take 33% CPU and 3% MEM each. Other 2 stay "normal". Load 4.42. I can say that pauses between songs a much longer than with other servers. Maybe it's problem closing "slave" kissdx from master one and new slave is started without it? Also playback starts to freeze sometimes - naturally mu NSLU2 is doing only this so it should work without problems.
Next song (5th) and next kissdx. Now 4 kissdx take 24.5% CPU and 3% MEM each. Other 2 stay "normal". Load 6.45. OK - I'll stop it - it's repeatable. :(
The same thing with dp500serv 0.9 gives me load 1.03 and dp500serv takes 0.3% CPU, 6% MEM.
UPDATE: Ally my tests were with kissdx-0.13-7a. Now I've tested it with previous versions and kissdx 0.13-5 works OK. But 0.13-6 works the same way like 0.13-7a. So problem is in code added after 0.13-5.
I found and fixed one problem introduced in 0.13-7, but your last post indicates that may not be the problem you are seeing. Still, give this a spin: http://kissdx.vidartysse.net/kissdx-0.13-7b-beta1.zip
And if it doesn't solve it, try to disable the picture caching and picture scaling in turn so see if / when the problem goes away. First disable caching:
#picturecachesize = 200
If no cure, disable scaling:
#picturetargetwidth = 1280
#picturetargetheight = 720
#picturemaxzoompercent = 20
Thanks for working with me on this.
BTW: Big, can you reproduce the problem by just playing a few seconds of each track and then skipping to the next one with the remote?
I just can't seem to reproduce it here, with NSLU2/Unslung 5.5 and a DP-600. If the 7b beta fixes the problem that means that the DP-600 is more forgiving than your player with slow response from the server.
BTW: Big, can you reproduce the problem by just playing a few seconds of each track and then skipping to the next one with the remote?
I tried this to speed-up testing but no way. Files should be played entirely. So for test best files are short ones. :)
And if it doesn't solve it, try to disable the picture caching and picture scaling in turn so see if / when the problem goes away. First disable caching:
#picturecachesize = 200
If no cure, disable scaling:
#picturetargetwidth = 1280
#picturetargetheight = 720
#picturemaxzoompercent = 20
I had to disable this to test 0.13-5 since errors in config file were reported (unknon commands). So tests with 0.13-7a were with it but tests with 0.13-6 done after tests with 0.13-5 were done without it.
Thanks for working with me on this.
As we say in Poland - whole pleasure is on my side. :) Maybe you will think stronger about my FLAC dreams ;) :D
Sadly your beta works the same as 0.13-7a . As I see in "top" kissdx with high CPU usage starts exactly when there is silence between tracks.
All what's in my config file:
audiopath = /public/Music
videopath = /public/Movies
picturepath = /public/Pictures
audiofileextensions = mp3,ogg,wma,wav
videofileextensions = mpg,mpeg,vob,avi,wmv,ts,mp4
picturefileextensions = jpg,jpeg,png,bmp
kmlurl = http://tinystocks.com/k/kiss.php
I'm sorry 7b didn't help.
More questions then:
1. Does the problem appear when you just let the player play without touching the remote, or is it only if you navigate and list folders while playing?
2. Do you play a playlist, or just MP3 files in a directory?
3. Are you playing from the [Recently used] folder?
... I tried this to speed-up testing but no way. Files should be played entirely. So for test best files are short ones. :)
Good, I'll put on some Randy Newman then :-)
Big, in my tests I only found a similar problem when playing ogg files but that also happens with 0.13-5 so it's not the same thing. I think that's actually a bug in the DP-600: It opens a connection that it never closes.
So I think I have to ask you to create a log file for a kissdx session that produces the problem. BUT do that with a newer beta, which produces better log files: http://kissdx.vidartysse.net/kissdx-0.13-7b-beta2.zip
In a telnet window, do this:
killall kissdx
/your-path-here/kissdx -v >kissdx-mp3play-Bigbug.log 2>&1
When you have finished playing a couple of songs:
1. Press Stop on the KiSS remote.
2. In a SECOND telnet window, list all kissdx processes: ps aux|grep kissdx
3. Press Ctrl-C to stop kissdx and close the log file.
4. Mail the log file and the output of the ps command to kissdx@vidartysse.net.
Let's hope this can give me some clues.
I think that's actually a bug in the DP-600: It opens a connection that it never closes.
Sorry that I never mentioned this - I've DP-1500 so all tests are done with it.
I hope I'll do tests today evening or tomorrow.
UPDATE: Tests done and you have your files in mailbox. Good Luck!
I confirm the problem spotted by Big occurs also on my Ubuntu box while serving mp3s to a Kiss DP500.
$ ps -A|grep kiss
4670 ? 00:00:00 kissdx
12281 ? 00:01:03 kissdx
12434 ? 00:00:00 kissdx
$ ps -A|grep kiss
4670 ? 00:00:00 kissdx
12281 ? 00:01:11 kissdx
12434 ? 00:00:06 kissdx
12588 ? 00:00:00 kissdx
$ ps -A|grep kiss
4670 ? 00:00:00 kissdx
12281 ? 00:01:53 kissdx
12434 ? 00:00:48 kissdx
12588 ? 00:00:06 kissdx
12680 ? 00:00:00 kissdx
I confirm the problem spotted by Big occurs also on my Ubuntu box while serving mp3s to a Kiss DP500.
gf, since you're on a proper Linux box, maybe you can give me some more info. Post the output of these commands when you are seeing the problem:
ps aux|grep kissdx
netstat --inet -anp|grep kissdx
Thanks,
ps aux|grep kissdx output:
root 4666 0.0 0.0 3792 488 ? S 17:34 0:00 /home/gf/kissdx/kissdx -d
root 5939 30.0 0.1 3792 620 ? R 17:48 2:08 /home/gf/kissdx/kissdx -d
root 6029 17.8 0.1 3792 620 ? R 17:50 0:46 /home/gf/kissdx/kissdx -d
root 6115 0.0 0.1 3792 620 ? S 17:53 0:00 /home/gf/kissdx/kissdx -d
gf 6195 0.0 0.1 2812 760 pts/0 R+ 17:55 0:00 grep kissdx
gf@Media-Server:~$ ps aux|grep kissdx
root 4666 0.0 0.0 3792 488 ? S 17:34 0:00 /home/gf/kissdx/kissdx -d
root 5939 30.2 0.1 3792 620 ? R 17:48 2:27 /home/gf/kissdx/kissdx -d
root 6029 20.5 0.1 3792 620 ? R 17:50 1:05 /home/gf/kissdx/kissdx -d
root 6115 3.6 0.1 3792 620 ? R 17:53 0:06 /home/gf/kissdx/kissdx -d
root 6226 0.2 0.1 3792 620 ? S 17:56 0:00 /home/gf/kissdx/kissdx -d
gf 6230 0.0 0.1 2820 776 pts/0 R+ 17:56 0:00 grep kissdx
netstat --inet -anp|grep kissdx output, had to run it as root to get results
$ netstat --inet -anp|grep kissdx
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
$ sudo netstat --inet -anp|grep kissdx
Password:
tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN 4666/kissdx
tcp 0 0 192.168.0.4:8000 192.168.0.5:3371 ESTABLISHED6226/kissdx
tcp 1 0 192.168.0.4:8000 192.168.0.5:3369 CLOSE_WAIT 6115/kissdx
tcp 1 0 192.168.0.4:8000 192.168.0.5:3367 CLOSE_WAIT 6029/kissdx
tcp 1 0 192.168.0.4:8000 192.168.0.5:3365 CLOSE_WAIT 5939/kissdx
udp 0 0 0.0.0.0:8000 0.0.0.0:* 4666/kissdx
Problem has been found and fixed. So probably Vit wil release new version tomorrow or in next few days.
Problem has been found and fixed. So probably Vit wil release new version tomorrow or in next few days.
That's right. See announcement. (http://www.mpcclub.com/modules.php?name=Forums&file=viewtopic&t=10633)
vBulletin® v3.8.4, Copyright ©2000-2010, Jelsoft Enterprises Ltd.