mpdPup - Simplified MPD Music Server/Jukebox - v0.9.3
My plan for the next release is to move the default music folder location to something like /var/music, and then all the different mounted locations will be sym-linked to that directory. This will allow numerous mountpoints to co-exist easily. Updating the wizard to allow a user to define multiple mountpoints might take a bit longer, but I'll get there eventually.
Tuning for sound quality
Hi all
I have been away for a while building amps. MPDPUP was working well, so I have not checked in for a while.
I just got caught up and it looks like there was a bit of a rally to tune for sound when Dynobot came in. Jrling was on some good paths, but it appears to have dropped.
Have you given up or gone underground.
Any update on which threads to prioritize?
What about a list of things to delete?
We need to form an organized effort at sound quality. Not just take other people's wild ideas. Need to test on MPDPUP and then report to Ildose what works so he has a list of priority items to put in 9.4.
I played around with buffer size. I had been using 8192 and load 100% before start. I tried larger sizes and seemed to loose air getting that congested sound. So I went the other extreme and tried smaller and smaller. If I am not mistaken, I believe I am getting detail and air at 512 buffer size and very small 1% load before play. Running Alix 3d2.
Anyone else running Alix care to try this? Takes only a moment. Am I imagining this? Let me know.
Walter
I have been away for a while building amps. MPDPUP was working well, so I have not checked in for a while.
I just got caught up and it looks like there was a bit of a rally to tune for sound when Dynobot came in. Jrling was on some good paths, but it appears to have dropped.
Have you given up or gone underground.
Any update on which threads to prioritize?
What about a list of things to delete?
We need to form an organized effort at sound quality. Not just take other people's wild ideas. Need to test on MPDPUP and then report to Ildose what works so he has a list of priority items to put in 9.4.
I played around with buffer size. I had been using 8192 and load 100% before start. I tried larger sizes and seemed to loose air getting that congested sound. So I went the other extreme and tried smaller and smaller. If I am not mistaken, I believe I am getting detail and air at 512 buffer size and very small 1% load before play. Running Alix 3d2.
Anyone else running Alix care to try this? Takes only a moment. Am I imagining this? Let me know.
Walter
Sound tweaks
From my experience with CMP minimizing threads and processes that are not needed does help. MPDPUP is already very lean, but clearly there are system specific items that can be killed.
Alix users, with just a quick glance it is clear we can kill off bluetooth, video, line printer etc. As a teaser try the following. You'll see a nice relaxed clarity in the highs.
killall avahi-daemon
modprobe -r btusb
modprobe -r r8169
modprobe -r uvcvideo
modprobe -r ppdev
modprobe -r lp
modprobe -r videodev
modprobe -r ath9k
killall lxmd-binary
Alix users, with just a quick glance it is clear we can kill off bluetooth, video, line printer etc. As a teaser try the following. You'll see a nice relaxed clarity in the highs.
killall avahi-daemon
modprobe -r btusb
modprobe -r r8169
modprobe -r uvcvideo
modprobe -r ppdev
modprobe -r lp
modprobe -r videodev
modprobe -r ath9k
killall lxmd-binary
Re: Sound tweaks
Hi Wlowes, always interested in tweaks - The areas Dynobot and Jrling were discussing were interesting, and I'm sure there is some value in some of them, but no consensus was reached. We were also playing with re-nicing and re-prioritizing a number of processes.wlowes wrote:From my experience with CMP minimizing threads and processes that are not needed does help. MPDPUP is already very lean, but clearly there are system specific items that can be killed.
Alix users, with just a quick glance it is clear we can kill off bluetooth, video, line printer etc. As a teaser try the following. You'll see a nice relaxed clarity in the highs.
killall avahi-daemon
modprobe -r btusb
modprobe -r r8169
modprobe -r uvcvideo
modprobe -r ppdev
modprobe -r lp
modprobe -r videodev
modprobe -r ath9k
killall lxmd-binary
Regarding the modules you're removing above - I didn't think the Alix had any of that hardware. Note modprobe -r won't have any affect unless the kernel actually loaded the module, and without the actual hardware I don't think they will be loaded. Use 'lsmod' to see what is actually loaded on your system. I'm curious to see what is loaded by default on the Alix hardware, so please report back - there may be some obvious modules to remove.
For the most part deleting files will save a bit of RAM because the filesystem is in memory, which is important on a RAM compromised system like the Alix, but I don't believe it should make any difference in sound quality.
I believe jrling has defected over to Windows - but the last set of attempts he sent me are below - which I believe originated from Soundcheck's squeezebox tweaks. Note I'm not specifically endorsing any of these specific settings (and some are more specific to a Squeezebox touch), but I think some of this may be on the right track
Code: Select all
#!/bin/bash
renice -20 3
renice -20 9
renice 2 -p $(pidof loop0)
renice 2 -p $(pidof loop1)
renice 0 35 #psmouse -may be slight improvement
renice 0 16 #ata-sff HDD support - Indiscernable but not worse
renice 9 -p $(pidof xfs_mru_cache)
renice 9 -p $(pidof xfslogd)
renice 9 -p $(pidof xfsdatad)
renice 9 -p $(pidof xfsconvertd)
renice -19 -p $(pidof mpd) #sometimes doesnt work
chmod 666 /sys/module/ehci_hcd/parameters/log2_irq_thresh
echo 6 > /sys/module/ehci_hcd/parameters/log2_irq_thresh
chmod 666 /sys/module/ehci_hcd/parameters/park
echo 3 > /sys/module/ehci_hcd/parameters/park
#echo 999999999 > /sys/bus/usb/drivers/usbhid/module/parameters/mousepoll
echo 1 > /proc/sys/vm/dirty_ratio
echo 40 > /proc/sys/vm/dirty_background_ratio
echo 5000 > /proc/sys/vm/dirty_writeback_centisecs
echo 0 > /proc/sys/vm/swappiness
echo 2048 > /proc/sys/kernel/msgmni
echo 65535 > /proc/sys/kernel/msgmax
echo 65535 > /proc/sys/kernel/msgmnb
echo 40960 > /proc/sys/fs/file-max
echo 50 > /proc/sys/vm/vfs_cache_pressure
echo 0 > /proc/sys/net/ipv4/tcp_app_win
#echo "2000 2048000 1024 4096" > /proc/sys/kernel/sem #doubled suggested values for 4GB RAM awful
echo 2147483648 > /proc/sys/kernel/shmmax
modprobe -r ir_lirc_codec
modprobe -r lirc_dev
modprobe -r ir_sony_decoder
modprobe -r ir_jvc_decoder
modprobe -r ir_rc6_decoder
modprobe -r ir_rc5_decoder
modprobe -r imon
modprobe -r ir_nec_decoder
modprobe -r rc_core
modprobe -r rtc
modprobe -r power_supply
modprobe -r serio_raw # serio ports, whatever those are
modprobe -r i2c_i801 # temp sensors
modprobe -r 8250_pnp # serial driver
modprobe -r processor
modprobe -r snd-seq-oss
modprobe -r snd-pcm-oss
modprobe -r snd_seq_dummy
modprobe -r snd_seq_midi
modprobe -r snd_seq_midi_event
#modprobe -r snd_rawmidi
modprobe -r snd_seq
#modprobe -r snd_seq_device
killall lighttpd
killall avahi-daemon
blacklist snd_pcm_oss
Hi Walter
It is partly true that I have defected to Windows! I have been testing (actively) an optimised C++ 'hair shirt' player for a keen coder SBGK over on AA.
He has come up with a render loop coding that is of magnificent sound quality and to my surprise overcoming the enormous bloat and overhead of Windows 7.
TBH Idolse, I am eagerly awaiting 9.4 as there were some tweaks put forward by Dynobot that need kernel code changes beyond my abilities and which you are going to provide in that release.
I feel that through Dynobot's and Soundchekk's advice, I have gone about as far as I can go SQwise with 0.9.3, so was taking a break elsewhere!
Dynobot seems to have have gone quiet too?
Idolse - the code of mine you have quoted - I sent it to you and Dynobot on request for feedback. Any time to try it? I don't by any means hold the code out as the answer... it works well on my D510 dual core Atom board, but the Alix boards are much lower power and therefore one might expect different parameters will work better on Alix.
It is partly true that I have defected to Windows! I have been testing (actively) an optimised C++ 'hair shirt' player for a keen coder SBGK over on AA.
He has come up with a render loop coding that is of magnificent sound quality and to my surprise overcoming the enormous bloat and overhead of Windows 7.
TBH Idolse, I am eagerly awaiting 9.4 as there were some tweaks put forward by Dynobot that need kernel code changes beyond my abilities and which you are going to provide in that release.
I feel that through Dynobot's and Soundchekk's advice, I have gone about as far as I can go SQwise with 0.9.3, so was taking a break elsewhere!
Dynobot seems to have have gone quiet too?
Idolse - the code of mine you have quoted - I sent it to you and Dynobot on request for feedback. Any time to try it? I don't by any means hold the code out as the answer... it works well on my D510 dual core Atom board, but the Alix boards are much lower power and therefore one might expect different parameters will work better on Alix.
Cool!
Jrling
Really great to hear you are keen on continuing to push the envelop on mpdpup. The base that Ildose provide is a great jumping off point. I am going to take a while to catch up to you and Dynobot. On the Voyage site, a juy named Jan has built mods to mpd 0.17 that allows real time priority setting etc. I found voyage required just too much linux knowledge for my level. I do wonder if we could apply his mods to mpd .17 in mpdpup tho.
Remind me, on what hdw platform do you run mpdpup?
Ildose.. Thank you so much for this sampling of all the stuff Dynobot and Jrling were pursuing. It will give me days and weeks of research and tinkering.
The processes running (after killing the ones previously posted are:
1 ? 00:00:02 busybox
2 ? 00:00:00 kthreadd
3 ? 00:00:00 ksoftirqd/0
5 ? 00:00:00 kworker/u:0
6 ? 00:00:00 migration/0
7 ? 00:00:00 cpuset
8 ? 00:00:00 khelper
9 ? 00:00:00 sync_supers
10 ? 00:00:00 bdi-default
11 ? 00:00:00 kblockd
12 ? 00:00:00 ata_sff
13 ? 00:00:00 khubd
15 ? 00:00:00 kswapd0
16 ? 00:00:00 ksmd
17 ? 00:00:00 fsnotify_mark
18 ? 00:00:00 xfs_mru_cache
19 ? 00:00:00 xfslogd
20 ? 00:00:00 xfsdatad
21 ? 00:00:00 xfsconvertd
23 ? 00:00:00 scsi_eh_0
24 ? 00:00:00 scsi_eh_1
25 ? 00:00:00 kworker/u:1
27 ? 00:00:00 kpsmoused
433 ? 00:00:00 loop1
536 ? 00:00:00 loop0
767 ? 00:00:00 udevd
994 ? 00:00:00 kworker/0:2
1010 ? 00:00:00 kworker/0:3
1460 tty1 00:00:00 sh
1462 tty2 00:00:00 getty
1463 ttyS0 00:00:00 getty
1555 ? 00:00:00 avahi-daemon
1556 ? 00:00:00 avahi-daemon
1568 ? 00:00:00 sshd
1588 ? 00:00:00 dhcpcd
1612 ? 00:00:00 udevd
1616 ? 00:00:00 udevd
1644 ? 00:00:00 cifsd
1654 ? 00:00:00 mpd
1711 ? 00:00:00 sshd
1716 ? 00:00:00 flush-8:0
1717 pts/0 00:00:00 sh
1802 ? 00:00:00 kworker/0:0
1843 pts/0 00:00:00 ps-FULL
#
Really great to hear you are keen on continuing to push the envelop on mpdpup. The base that Ildose provide is a great jumping off point. I am going to take a while to catch up to you and Dynobot. On the Voyage site, a juy named Jan has built mods to mpd 0.17 that allows real time priority setting etc. I found voyage required just too much linux knowledge for my level. I do wonder if we could apply his mods to mpd .17 in mpdpup tho.
Remind me, on what hdw platform do you run mpdpup?
Ildose.. Thank you so much for this sampling of all the stuff Dynobot and Jrling were pursuing. It will give me days and weeks of research and tinkering.
The processes running (after killing the ones previously posted are:
1 ? 00:00:02 busybox
2 ? 00:00:00 kthreadd
3 ? 00:00:00 ksoftirqd/0
5 ? 00:00:00 kworker/u:0
6 ? 00:00:00 migration/0
7 ? 00:00:00 cpuset
8 ? 00:00:00 khelper
9 ? 00:00:00 sync_supers
10 ? 00:00:00 bdi-default
11 ? 00:00:00 kblockd
12 ? 00:00:00 ata_sff
13 ? 00:00:00 khubd
15 ? 00:00:00 kswapd0
16 ? 00:00:00 ksmd
17 ? 00:00:00 fsnotify_mark
18 ? 00:00:00 xfs_mru_cache
19 ? 00:00:00 xfslogd
20 ? 00:00:00 xfsdatad
21 ? 00:00:00 xfsconvertd
23 ? 00:00:00 scsi_eh_0
24 ? 00:00:00 scsi_eh_1
25 ? 00:00:00 kworker/u:1
27 ? 00:00:00 kpsmoused
433 ? 00:00:00 loop1
536 ? 00:00:00 loop0
767 ? 00:00:00 udevd
994 ? 00:00:00 kworker/0:2
1010 ? 00:00:00 kworker/0:3
1460 tty1 00:00:00 sh
1462 tty2 00:00:00 getty
1463 ttyS0 00:00:00 getty
1555 ? 00:00:00 avahi-daemon
1556 ? 00:00:00 avahi-daemon
1568 ? 00:00:00 sshd
1588 ? 00:00:00 dhcpcd
1612 ? 00:00:00 udevd
1616 ? 00:00:00 udevd
1644 ? 00:00:00 cifsd
1654 ? 00:00:00 mpd
1711 ? 00:00:00 sshd
1716 ? 00:00:00 flush-8:0
1717 pts/0 00:00:00 sh
1802 ? 00:00:00 kworker/0:0
1843 pts/0 00:00:00 ps-FULL
#
Results of these changes - wow
So much for measured scientific process. I just put in all the changes listed above in Ildose's post.
Sound is very good. At this point the best I have had on this system. I still will play around with buffers etc, but this worked very well for me. Quieter background, continued great sound stage, not quite so pushed back in the distance. I have had sharper detail with more air around things, but this is the most natural. The biggest change is more base and a warmth across the spectrum. Tons of detail and great midrange, just more warmth. Well implemented Windows tends to a pleasing warmth where linux tends to be analytical. This is a fine balance of both. I spent some time building tube amps and this is what I was looking for. Lots of texture and weight but still crystal clear detail. (pic below)
After the changes, this is what MPDPUP looks like on the Alix..
Mem: 250940K used, 4232K free, 0K shrd, 3076K buff, 224516K cached
CPU: 1% usr 0% sys 0% nic 97% idle 0% io 0% irq 0% sir
Load average: 0.07 0.04 0.01 2/44 2080
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND
1654 1 root S < 55416 22% 0 1% mpd
1644 2 root SW 0 0% 0 0% [cifsd]
2080 1850 root R 2628 1% 0 0% top
1845 1568 root S 6688 3% 0 0% sshd: root@pts/1
1711 1568 root S 6688 3% 0 0% sshd: root@pts/0
1568 1 root S 4104 2% 0 0% /usr/sbin/sshd
1850 1845 root S 3156 1% 0 0% -sh
1460 1 root S 3152 1% 0 0% -sh
1717 1711 root S 3152 1% 0 0% -sh
1462 1 root S 2348 1% 0 0% /sbin/getty 38400 tty2
1463 1 root S 2348 1% 0 0% /sbin/getty -L 19200 t
1 0 root S 2344 1% 0 0% /bin/busybox init
1588 1 root S 1904 1% 0 0% dhcpcd -d -I eth0
15 2 root SW 0 0% 0 0% [kswapd0]
1802 2 root SW 0 0% 0 0% [kworker/0:0]
536 2 root SWN 0 0% 0 0% [loop0]
433 2 root SWN 0 0% 0 0% [loop1]
3 2 root SW< 0 0% 0 0% [ksoftirqd/0]
2 0 root SW 0 0% 0 0% [kthreadd]
5 2 root SW 0 0% 0 0% [kworker/u:0]
6 2 root SW 0 0% 0 0% [migration/0]
7 2 root SW< 0 0% 0 0% [cpuset]
8 2 root SW< 0 0% 0 0% [khelper]
9 2 root SW< 0 0% 0 0% [sync_supers]
10 2 root SW 0 0% 0 0% [bdi-default]
11 2 root SW< 0 0% 0 0% [kblockd]
12 2 root SW< 0 0% 0 0% [ata_sff]
13 2 root SW 0 0% 0 0% [khubd]
16 2 root SW 0 0% 0 0% [ksmd]
17 2 root SW 0 0% 0 0% [fsnotify_mark]
18 2 root SWN 0 0% 0 0% [xfs_mru_cache]
19 2 root SWN 0 0% 0 0% [xfslogd]
20 2 root SWN 0 0% 0 0% [xfsdatad]
21 2 root SWN 0 0% 0 0% [xfsconvertd]
23 2 root SW 0 0% 0 0% [scsi_eh_0]
24 2 root SW 0 0% 0 0% [scsi_eh_1]
25 2 root SW 0 0% 0 0% [kworker/u:1]
27 2 root SW< 0 0% 0 0% [kpsmoused]
1010 2 root SW 0 0% 0 0% [kworker/0:3]
Sound is very good. At this point the best I have had on this system. I still will play around with buffers etc, but this worked very well for me. Quieter background, continued great sound stage, not quite so pushed back in the distance. I have had sharper detail with more air around things, but this is the most natural. The biggest change is more base and a warmth across the spectrum. Tons of detail and great midrange, just more warmth. Well implemented Windows tends to a pleasing warmth where linux tends to be analytical. This is a fine balance of both. I spent some time building tube amps and this is what I was looking for. Lots of texture and weight but still crystal clear detail. (pic below)
After the changes, this is what MPDPUP looks like on the Alix..
Mem: 250940K used, 4232K free, 0K shrd, 3076K buff, 224516K cached
CPU: 1% usr 0% sys 0% nic 97% idle 0% io 0% irq 0% sir
Load average: 0.07 0.04 0.01 2/44 2080
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND
1654 1 root S < 55416 22% 0 1% mpd
1644 2 root SW 0 0% 0 0% [cifsd]
2080 1850 root R 2628 1% 0 0% top
1845 1568 root S 6688 3% 0 0% sshd: root@pts/1
1711 1568 root S 6688 3% 0 0% sshd: root@pts/0
1568 1 root S 4104 2% 0 0% /usr/sbin/sshd
1850 1845 root S 3156 1% 0 0% -sh
1460 1 root S 3152 1% 0 0% -sh
1717 1711 root S 3152 1% 0 0% -sh
1462 1 root S 2348 1% 0 0% /sbin/getty 38400 tty2
1463 1 root S 2348 1% 0 0% /sbin/getty -L 19200 t
1 0 root S 2344 1% 0 0% /bin/busybox init
1588 1 root S 1904 1% 0 0% dhcpcd -d -I eth0
15 2 root SW 0 0% 0 0% [kswapd0]
1802 2 root SW 0 0% 0 0% [kworker/0:0]
536 2 root SWN 0 0% 0 0% [loop0]
433 2 root SWN 0 0% 0 0% [loop1]
3 2 root SW< 0 0% 0 0% [ksoftirqd/0]
2 0 root SW 0 0% 0 0% [kthreadd]
5 2 root SW 0 0% 0 0% [kworker/u:0]
6 2 root SW 0 0% 0 0% [migration/0]
7 2 root SW< 0 0% 0 0% [cpuset]
8 2 root SW< 0 0% 0 0% [khelper]
9 2 root SW< 0 0% 0 0% [sync_supers]
10 2 root SW 0 0% 0 0% [bdi-default]
11 2 root SW< 0 0% 0 0% [kblockd]
12 2 root SW< 0 0% 0 0% [ata_sff]
13 2 root SW 0 0% 0 0% [khubd]
16 2 root SW 0 0% 0 0% [ksmd]
17 2 root SW 0 0% 0 0% [fsnotify_mark]
18 2 root SWN 0 0% 0 0% [xfs_mru_cache]
19 2 root SWN 0 0% 0 0% [xfslogd]
20 2 root SWN 0 0% 0 0% [xfsdatad]
21 2 root SWN 0 0% 0 0% [xfsconvertd]
23 2 root SW 0 0% 0 0% [scsi_eh_0]
24 2 root SW 0 0% 0 0% [scsi_eh_1]
25 2 root SW 0 0% 0 0% [kworker/u:1]
27 2 root SW< 0 0% 0 0% [kpsmoused]
1010 2 root SW 0 0% 0 0% [kworker/0:3]
Adding to rc.local will mostly work but is not really a recommended approach. The better approach is to put it in /etc/init.d and give it an alphabetical name so that it's processed after all the other scripts. This way it will re-nice all the daemons like mpd and kill avahi/lighttpd. Remember to run chmod +x on the file to make sure that it's executable.wlowes wrote:Ildose
I may have answered my own question. Rather than create a startup script, I added the commands to rc.local. It appears to work. Parden my inexperience.. Is this a proper approach?
Walter
I'm loathe to just include a script like this into the official release because there is very little documentation regarding any of this. A lot of these commands don't do anything if run individually because they are tied to the Squeezebox Touch operating system as well.
I am thinking to use a system where a script like this can run and grab the kernel parameters and re-nice values from another configuration file. At the moment the plan is to stick with configuration files - I don't see the value in adding to the wizards unless there are some clear explanations as to the how a parameter could affect audio. Some of the kernel modules being removed are things I'm looking into permanetly removing/blacklisting.
@jrling, glad to hear the defection may not be permanent I did try out your script but as I noted earlier I don't think my own system is as revealing as some others - it sounded good but I couldn't be sure if it was dramatically better or what variables had more affect than others.
Idolse - great to hear your plan for 0.9.4 which sounds like a good one.
Mostly 'my script' is Dynobot's. Where are you Dynobot?!
It made significant improvement to my system and I am sure that there is more to come. But as always YMMV. That's the trouble with OS like Windows and Linux too - however cut down they are made. The slightest change to parameters can have a big effect on SQ - mostly adverse!
Neither OS were designed for audiophile listening. Never were, never will be.
My Windows experience recently with a coder who really really knows what he is doing [SBGK on Audio Asylum], is that even changing one priority setting for the render loop, can ruin SQ. Conversely, getting it 'right' can really improve matters. But no amount of logic can predict which way it will go.
Being 'away' another reflection - albeit a statement of the bleedin' obvious - is that Idolse is just providing the most optimal OS for MPD to run in. But what we are left with is MPD 0.17 as the process that is rendering the music stream - for better or for worse.
So IF MPD 0.17 is not optimal, no amount of good work by Idolse will be able to break through that barrier.
SBGK is an experienced Squeezebox coder so knows his Linux. mpdPup is the most brilliant minimised version of Linux for audio that I know. His rendering code (written in C++) together with mpdPup would make an unbeatable combo. So far, he has resisted porting to Linux, as his code on Windows works so well, there is no incentive; however, the experience I have had of listening to its development, has taught me that the rendering code has by far the biggest impact on SQ rather than optimising the underlying OS.
Hope that I won't get flamed!
Mostly 'my script' is Dynobot's. Where are you Dynobot?!
It made significant improvement to my system and I am sure that there is more to come. But as always YMMV. That's the trouble with OS like Windows and Linux too - however cut down they are made. The slightest change to parameters can have a big effect on SQ - mostly adverse!
Neither OS were designed for audiophile listening. Never were, never will be.
My Windows experience recently with a coder who really really knows what he is doing [SBGK on Audio Asylum], is that even changing one priority setting for the render loop, can ruin SQ. Conversely, getting it 'right' can really improve matters. But no amount of logic can predict which way it will go.
Being 'away' another reflection - albeit a statement of the bleedin' obvious - is that Idolse is just providing the most optimal OS for MPD to run in. But what we are left with is MPD 0.17 as the process that is rendering the music stream - for better or for worse.
So IF MPD 0.17 is not optimal, no amount of good work by Idolse will be able to break through that barrier.
SBGK is an experienced Squeezebox coder so knows his Linux. mpdPup is the most brilliant minimised version of Linux for audio that I know. His rendering code (written in C++) together with mpdPup would make an unbeatable combo. So far, he has resisted porting to Linux, as his code on Windows works so well, there is no incentive; however, the experience I have had of listening to its development, has taught me that the rendering code has by far the biggest impact on SQ rather than optimising the underlying OS.
Hope that I won't get flamed!
Turn of autostart of MPD wizard when starting X?
Eh, perhaps a stupid quesiton:
whenever I start X, the MPD wizard starts automatically...
How/where do I turn this behavior off (i.e. I don't want the wizard to start automatically)?
Tried searching in config files that I could find, but to no avail
THX
whenever I start X, the MPD wizard starts automatically...
How/where do I turn this behavior off (i.e. I don't want the wizard to start automatically)?
Tried searching in config files that I could find, but to no avail
THX
Re: Turn of autostart of MPD wizard when starting X?
Found it!DenisP wrote: How/where do I turn this behavior off (i.e. I don't want the wizard to start automatically)?
It's set in: /usr/sbin/delayedrun
Found it while searching through some other threads: I never would have stumbled upon it myself - I'm more used to .xinitrc and other more traditional config files
Hi DenisP.
I don't use the application in question, but have you looked for a script in /root/Startup/?
I think /usr/sbin/delayedrun is used for several purposes, so it is maybe a file you should be careful about modifying, unless you know exactly what you do...
tallboy
I don't use the application in question, but have you looked for a script in /root/Startup/?
I think /usr/sbin/delayedrun is used for several purposes, so it is maybe a file you should be careful about modifying, unless you know exactly what you do...
tallboy
True freedom is a live Puppy on a multisession CD/DVD.
I've checked the "Startup" folder, it's not there...tallboy wrote: I don't use the application in question, but have you looked for a script in /root/Startup/?
I think /usr/sbin/delayedrun is used for several purposes, so it is maybe a file you should be careful about modifying, unless you know exactly what you do...
As for modifying something that I don't know, I don't think there's much danger in this case.
This line of script automatically invokes the "MPDwizard", which is a script for setting up the MPD server - which is exactly what I want to avoid (i.e. I don't want it to start automatically!).
It's not like I'm disabling the automatic start of the MPD server... Wizard is a different thing, and I can start it whenever I want, by just entering "mpdwizard" on the command line.
So, if I disable its automatic start, the system still functions without any changes.
A couple of suggestions for Idolse:
I see you're "slurping" neompc and web10mpc from your site during installation, so perhaps you could add/change the following:
in neompc, when used on some smartphones, e.g. iphone, the volume slider doesn't work. I've found a patch online, and it enables you to "tap" the volume bar to change volume. A bit clumsy, but better than nothing. Here is the additional code - goes towards the bottom of the "neompc.js" file in "/var/www/neompc/lib/js":
Also, it would be nice if the web10mpc came already set for showing the volume on the page - it is changed in "control.ini.php", in "var/www/web10mpc/include"
it says:
Just change it to "true"... I guess most of the people who use smartphone GUI also want to have the volume control
I see you're "slurping" neompc and web10mpc from your site during installation, so perhaps you could add/change the following:
in neompc, when used on some smartphones, e.g. iphone, the volume slider doesn't work. I've found a patch online, and it enables you to "tap" the volume bar to change volume. A bit clumsy, but better than nothing. Here is the additional code - goes towards the bottom of the "neompc.js" file in "/var/www/neompc/lib/js":
Code: Select all
// this addition takes care of volume slider problems on some smartphones, e.g. iPhone
$('#slider_container').click(function(event){
ajax_control('volume', pos_to_volume(event.pageY-($('#volume_slider').outerHeight()/2)-$('#slider_container').offset().top));
});
// end of addition for smartphones
it says:
Code: Select all
show_volume_controls = false
I think there's something amiss with client175 configuration.
Having installed client175 using mpdwizard, I was surprised that it did not start automatically (see my question above).
After some searcing, I found an entry for "client175" in /etc/init.d:
it's under "37.client175" - but its size (and contents) are the same as for "30.empcd" - which is obviously not as it should be - and is the obvious reason why "client175" is not actually autostarting.
Could someone provide a valid /etc/init.d file for client175?
Idolse?
Thanks!
Having installed client175 using mpdwizard, I was surprised that it did not start automatically (see my question above).
After some searcing, I found an entry for "client175" in /etc/init.d:
it's under "37.client175" - but its size (and contents) are the same as for "30.empcd" - which is obviously not as it should be - and is the obvious reason why "client175" is not actually autostarting.
Could someone provide a valid /etc/init.d file for client175?
Idolse?
Thanks!