mpdPup - Simplified MPD Music Server/Jukebox - v0.9.3
And again I'm replying to myself
Glad to report that the problem is solved!
It was simple, really: the "sound device" (i.e. MyDAC) was rebooting muted!
So, I followed Idolse's recipe from the page 1 of this thread ("No sound after the initial setup/reboot though everything appears to be working"), rebooted - and voila! - sound is coming out as it should
Just one more question: how do I solve this on the future machines that I'll be setting up - without having MyDAC at hand?
Just save the current "asound.state" file somewhere else as a backup for users with MyDAC, and copy it over the existing ("default") one?
Regards,
Denis
Glad to report that the problem is solved!
It was simple, really: the "sound device" (i.e. MyDAC) was rebooting muted!
So, I followed Idolse's recipe from the page 1 of this thread ("No sound after the initial setup/reboot though everything appears to be working"), rebooted - and voila! - sound is coming out as it should
Just one more question: how do I solve this on the future machines that I'll be setting up - without having MyDAC at hand?
Just save the current "asound.state" file somewhere else as a backup for users with MyDAC, and copy it over the existing ("default") one?
Regards,
Denis
It looks to me like ctl value error might be related to alsactl - after you select the soundcard the wizard saves the sound device settings using the command 'alsactl -f /etc/asound.state store'. ALSA automatically loads the asound.state file after reinitiating the sound device.
Did you try booting without the sound device plugged in or unplugging/replugging the device after bootup?
Edit - cross posted. After un-muting type the command above:
alsactl -f /etc/asound.state store
For future devices you could try saving the asound.state file - there is a good chance that will work.
Did you try booting without the sound device plugged in or unplugging/replugging the device after bootup?
Edit - cross posted. After un-muting type the command above:
alsactl -f /etc/asound.state store
For future devices you could try saving the asound.state file - there is a good chance that will work.
Do you mean you have the music library on the HDD on the mpdPup machine?willemoes wrote:Is there a way to add/remove music files on a headless Mpd-machine when using local sata hdd as storage?
It´s connected to a router for using tablet as client over wi-fi.
Also connected to router is a Windows Pc
In that case, without installing samba, etc., you can use Filezilla on the Windows side to copy files.
In Filezilla, enter your mpdPup computer IP address, username "root" and password "woofwoof" (unless you changed the default password), and use port "22".
It should work, and you should be able to connect to mpdPup machine from the Windows PC on the local network. From there you can find the directory where the music library is, and upload (or delete) files there.
Should be rather easy to do, no need for samba or anything else: I just tried it with a Windows machine on a local network: took me about 3-4 minutes to download Filezilla, install it, and then in about 10 seconds I was connected to my mpdPup computer, and sending files to and fro...
Yes; would like to compare SQ between local 2.5 Hdd to musiclibrary over network - as well as have the possibility to bring the machine to friends for listening (have the ability to connect KVM if necessary).DenisP wrote: Do you mean you have the music library on the HDD on the mpdPup machine?
Will check out Filezilla, Thanks
unable to change anything after i type xwin
when i go to xwin normal window pop up and then the mpd is always hanged...
it works perfectly in devices but when i try to go to xwin and try to change anything it is just hanged...
tried multiple usb no change...
any idea why...
V
it works perfectly in devices but when i try to go to xwin and try to change anything it is just hanged...
tried multiple usb no change...
any idea why...
V
More remote issues...
I've got a few cheap Chinese USB remotes from ebay, like the one in the attached image.
After some fiddling, I relized that it does respond - but only when I start X!
Namely, when I turn on the computer, and use console (without starting X), the remote does not respond. "showkey" command shows nothing, empcd with verbose output (empcd -y 9 -f) shows nothing.
However, when I start X, and e.g. open a terminal window, I get the remote recognized, and can configure keys in /etc/empcd.conf.
When I close X and return to console, everything still continues to work, and I can use the remote to control mpd (volume, start/stop, etc. - everything I've configured in empcd.conf).
HOWEVER, if I reboot the computer, the remote again does not work in console.
Basically, I have to start x and close it again for the remote to work...
What am I missing? What should I do in order for the remote to be recognized in console, without having to start X server? I'm trying to run a headless machine, and starting x just to recognize the remote is unnecessary hassle.
NOTE: no lirc necessary, this is a USB remote, and (under X) it sends keypresses, no problem. I haven't fiddled with lirc at all (fresh install). Once recognized (under X), I can use empcd.conf to define keys, and everything works just fine - no hassles at all. BUT, in order for the remote to be recognized at all, I first have to start X (and then close it and go back to console... to avoid unnecessary load on the processor, memory etc.)
Upon booting, the remote is recognized by dev/input, and appears under /dev/input/event4.
Any ideas how to get it recognized in console, without having to start X first (or fiddling with lirc)?
I've got a few cheap Chinese USB remotes from ebay, like the one in the attached image.
After some fiddling, I relized that it does respond - but only when I start X!
Namely, when I turn on the computer, and use console (without starting X), the remote does not respond. "showkey" command shows nothing, empcd with verbose output (empcd -y 9 -f) shows nothing.
However, when I start X, and e.g. open a terminal window, I get the remote recognized, and can configure keys in /etc/empcd.conf.
When I close X and return to console, everything still continues to work, and I can use the remote to control mpd (volume, start/stop, etc. - everything I've configured in empcd.conf).
HOWEVER, if I reboot the computer, the remote again does not work in console.
Basically, I have to start x and close it again for the remote to work...
What am I missing? What should I do in order for the remote to be recognized in console, without having to start X server? I'm trying to run a headless machine, and starting x just to recognize the remote is unnecessary hassle.
NOTE: no lirc necessary, this is a USB remote, and (under X) it sends keypresses, no problem. I haven't fiddled with lirc at all (fresh install). Once recognized (under X), I can use empcd.conf to define keys, and everything works just fine - no hassles at all. BUT, in order for the remote to be recognized at all, I first have to start X (and then close it and go back to console... to avoid unnecessary load on the processor, memory etc.)
Upon booting, the remote is recognized by dev/input, and appears under /dev/input/event4.
Any ideas how to get it recognized in console, without having to start X first (or fiddling with lirc)?
- Attachments
-
- PC-Remote-Controller-S-PRC-0114-.jpg
- ebay PC remote
- (73.65 KiB) Downloaded 1622 times
Again, glad to say that I resolved my cheap ebay USB remote problem
The problem was that I didn't understand how the input is handled....
After some googling, I found out the solution, here:
http://wiki.xbmc.org/index.php?title=HO ... for_Ubuntu
I followed the instructions for finding out to which device the remote was assigned - in my case it was "/dev/input/event4" - it can be found out easily by comparing the output of
BEFORE plugging the USB remote receiver and AFTER plugging it in.
After the remote receiver is plugged in the USB port, you will usually find two new events - in my case those were "event4" and "event5".
The rest was easy, following the above instructions.
What I did is to issue two commands:
- this gave me the Vendor ID and Product code numbers (identified by "Handlers: XXX" line - in my case there were two items, one had line "Handlers=kbd event4" and the other had "Handlers=mouse1 event5".
After that, I issued two commands:
Those gave me the required MINOR and MAJOR numbers, and I was finally able to do:
and then I entered the following:
("Vendor ID" and "Product" codes might be diferent for other devices, though - this worked for mine, after finding WHICH devices those were as described above....)
Saved the file, and then issued
and there it was, after issuing "ls - l /dev/input", I got two new devices:
(those are "irremote0" and "irremote1").
After that, I changed the device in "/etc/empcd.conf" to "/dev/input/irremote0", saved changes to disk, rebooted, and lo and behold, it works!!!!
Hope this helps someone else, too....
Next I'll probably try to do the same for a homebrew serial IR receiver, since I have enough parts to solder several of those....
The problem was that I didn't understand how the input is handled....
After some googling, I found out the solution, here:
http://wiki.xbmc.org/index.php?title=HO ... for_Ubuntu
I followed the instructions for finding out to which device the remote was assigned - in my case it was "/dev/input/event4" - it can be found out easily by comparing the output of
Code: Select all
ls -l /dev/input
After the remote receiver is plugged in the USB port, you will usually find two new events - in my case those were "event4" and "event5".
The rest was easy, following the above instructions.
What I did is to issue two commands:
Code: Select all
cat /proc/bus/input/devices
After that, I issued two commands:
Code: Select all
udevadm info -q all -n /dev/input/event4
udevadm info -q all -n /dev/input/event5
Code: Select all
vi /etc/udev/rules.d/10-irremote.rules
Code: Select all
SUBSYSTEM=="input",ATTRS{idVendor}=="1d57",ATTRS{idProduct}=="ad02",ATTR{dev}=="13:68",SYMLINK="input/irremote0"
SUBSYSTEM=="input",ATTRS{idVendor}=="1d57",ATTRS{idProduct}=="ad02",ATTR{dev}=="13:69",SYMLINK="input/irremote1"
Saved the file, and then issued
Code: Select all
udevadm trigger
Code: Select all
crw-r----- 1 root root 13, 68 2013-05-27 22:16 event4
crw-r----- 1 root root 13, 69 2013-05-27 22:16 event5
lrwxrwxrwx 1 root root 6 2013-05-27 22:16 irremote0 -> event4
lrwxrwxrwx 1 root root 6 2013-05-27 22:16 irremote1 -> event5
crw-r--r-- 1 root root 13, 0 2002-08-31 22:31 js0
After that, I changed the device in "/etc/empcd.conf" to "/dev/input/irremote0", saved changes to disk, rebooted, and lo and behold, it works!!!!
Hope this helps someone else, too....
Next I'll probably try to do the same for a homebrew serial IR receiver, since I have enough parts to solder several of those....
Getting behind on my replies here...
@Denis, Sorry I can't provide tons of help on this remote support - I'll need to pick up some cheap USB sensors/remotes to see if I can figure out what's going on. You were on the right track with the udev rules though. Maybe it's showing up as a slightly different device during the boot process and missing those rules you created - try checking dmesg and lsmod to see what has been loaded after a clean boot. The XWindows bit is mystifying to me - not sure what it's doing to the inputs to 'fix' the system.
@kocozze, Spotify can be listened to but you need to use the command line to do it, it's far from intuitive. It also needs spotify premium to work. I don't believe Grooveshark is supported at all. Generic streaming radio is much easier to deal with.
@thisvv, I'm not sure what's going on, and it's a bit difficult to tell from your description what the problem is. Maybe try making changes from the CLI instead of the command line? What exactly are you trying to change?
@Denis, Sorry I can't provide tons of help on this remote support - I'll need to pick up some cheap USB sensors/remotes to see if I can figure out what's going on. You were on the right track with the udev rules though. Maybe it's showing up as a slightly different device during the boot process and missing those rules you created - try checking dmesg and lsmod to see what has been loaded after a clean boot. The XWindows bit is mystifying to me - not sure what it's doing to the inputs to 'fix' the system.
@kocozze, Spotify can be listened to but you need to use the command line to do it, it's far from intuitive. It also needs spotify premium to work. I don't believe Grooveshark is supported at all. Generic streaming radio is much easier to deal with.
@thisvv, I'm not sure what's going on, and it's a bit difficult to tell from your description what the problem is. Maybe try making changes from the CLI instead of the command line? What exactly are you trying to change?
No Hd sound
Hi Idolse
Thank You or big work and helping .... just a question please:
Mpdpup is working fine on Hiface Two usb soundcard playing 16/44 audio files only. But No Hd audio file (24/88,96,192) is possible to play on MpdPup!
Soundcard and Dac support 24/192 but hd flac files not start. Something went wrong in configuration? Help me please. Regards
Thank You or big work and helping .... just a question please:
Mpdpup is working fine on Hiface Two usb soundcard playing 16/44 audio files only. But No Hd audio file (24/88,96,192) is possible to play on MpdPup!
Soundcard and Dac support 24/192 but hd flac files not start. Something went wrong in configuration? Help me please. Regards
I think I found out what's wrong. Seems like empcd can't (re)start automatically - my event is called "irremote0", and it seems that the path is too long (as it says in the empcd.conf). Once I (re)start empcd manually, everything works.ldolse wrote: @Denis, Sorry I can't provide tons of help on this remote support - I'll need to pick up some cheap USB sensors/remotes to see if I can figure out what's going on. You were on the right track with the udev rules though. Maybe it's showing up as a slightly different device during the boot process and missing those rules you created - try checking dmesg and lsmod to see what has been loaded after a clean boot. The XWindows bit is mystifying to me - not sure what it's doing to the inputs to 'fix' the system.
I'll see what I can do to start empcd manually, by invoking "/usr/sbin/empcd" when the machine is started. What would be the best way? I've tried adding it to "profile", but it seems like it's not a good way
Any other idea about starting empcd automatically (and properly)? I'll try changing the name of my event , or just leaving it as "event4"...
Thanks,
Denis
BTW, Idolse, can you contact me at denple@gmail.com ?
I think I might have a hardware donation for you
Also, I can offer help in documenting the mpdPup project, like writing a manual, etc. (I've already written a manual in Croatian....)
THX,
Denis
I think I might have a hardware donation for you
Also, I can offer help in documenting the mpdPup project, like writing a manual, etc. (I've already written a manual in Croatian....)
THX,
Denis
OK, looks like I sorted out the problem with the remote.
First, I had to add another command to /etc/rc.d/rc.local:
Namely, the default command for starting empcd (file "30.empcd" in /etc/init.d) doesn't seem to work - I'm not sure why...
First command (sleep 10) seems to be necessary - the remote has to wait for MPD to start cleanly, otherwise it won't start properly - this could be even "sleep 15" or "sleep 20", just to be on the safe side.
After finding out which "event" in /dev/input belongs to remote sensor, I was able to see which button does what by using command "empcd -y 9 -f" (prior to that I edited "/etc/empcd.conf" by selecting the proper "event" - in my case it was the line:
After that, I noted the button codes, and edited the "empcf.conf" appropriately, using the key codes I got in the step above.
THEN came the real pain in the behind:
I wanted to make sure the remote sensor is always mapped to appropriate symlinked "event", which I called "ir0".
If I use the default "eventX", it sometimes happens (particularly if I remove or add another USB device, e.g. USB DAC) that the event numbers get shuffled around - so, it's not a good idea to use e.g. "event4" - because it can sometimes be "event5"
After a LOT of reading, and a lot of trial and error, I managed to write a proper udev rule, which now always maps the USB remote sensor to "/dev/input/ir0", regardless whether it is attached to "event4" or "event5" - or whatever. Well, at least it seems to work - most of the time
Took me quite a while to find out the unique string to use as identifier for the udev rule - I finally used "Phys" key, which I got by using command "cat /proc/bus/input/devices"....
To cut the long story short, it was an arduous journey
But, I think I got the USB remotes sorted out now.... mostly... So, if anyone needs help with any particular remote control problem, perhas I could be of help...
It bugs me that it still happens now and then that the remote isn't recognized, and the key presses do nothing: it happens mostly after shuffling the usb devices around, plugging them into different USB sockets... But, it now works relatively reliably - the most important thing is that the remote sensor is recognized and properly mapped to symlink "/dev/input/ir0" - and I edited "empcd.conf" to use "/dev/input/ir0" as the eventdevice...
Also, the remote starts working only after a slight delay (about a minute AFTER the mpd is started....). No big deal... as long as it works OK afterwards
Next I'll also try to use that "power off" button on the remote using the "exec" command in the empcd.conf in order to shut down the system from the remote.
It would also be nice if I could start (power on) the computer using the remote, but that won't be that easy, I guess (from what I managed to deduce so far...).
First, I had to add another command to /etc/rc.d/rc.local:
Code: Select all
sleep 10
/usr/sbin/empcd &
First command (sleep 10) seems to be necessary - the remote has to wait for MPD to start cleanly, otherwise it won't start properly - this could be even "sleep 15" or "sleep 20", just to be on the safe side.
After finding out which "event" in /dev/input belongs to remote sensor, I was able to see which button does what by using command "empcd -y 9 -f" (prior to that I edited "/etc/empcd.conf" by selecting the proper "event" - in my case it was the line:
Code: Select all
eventdevice /dev/input/event4
THEN came the real pain in the behind:
I wanted to make sure the remote sensor is always mapped to appropriate symlinked "event", which I called "ir0".
If I use the default "eventX", it sometimes happens (particularly if I remove or add another USB device, e.g. USB DAC) that the event numbers get shuffled around - so, it's not a good idea to use e.g. "event4" - because it can sometimes be "event5"
After a LOT of reading, and a lot of trial and error, I managed to write a proper udev rule, which now always maps the USB remote sensor to "/dev/input/ir0", regardless whether it is attached to "event4" or "event5" - or whatever. Well, at least it seems to work - most of the time
Took me quite a while to find out the unique string to use as identifier for the udev rule - I finally used "Phys" key, which I got by using command "cat /proc/bus/input/devices"....
To cut the long story short, it was an arduous journey
But, I think I got the USB remotes sorted out now.... mostly... So, if anyone needs help with any particular remote control problem, perhas I could be of help...
It bugs me that it still happens now and then that the remote isn't recognized, and the key presses do nothing: it happens mostly after shuffling the usb devices around, plugging them into different USB sockets... But, it now works relatively reliably - the most important thing is that the remote sensor is recognized and properly mapped to symlink "/dev/input/ir0" - and I edited "empcd.conf" to use "/dev/input/ir0" as the eventdevice...
Also, the remote starts working only after a slight delay (about a minute AFTER the mpd is started....). No big deal... as long as it works OK afterwards
Next I'll also try to use that "power off" button on the remote using the "exec" command in the empcd.conf in order to shut down the system from the remote.
It would also be nice if I could start (power on) the computer using the remote, but that won't be that easy, I guess (from what I managed to deduce so far...).
-
- Posts: 5
- Joined: Thu 14 Feb 2013, 13:08
sound quality mpd + Puppy <-> mpd + Tiny Core
Hi Idolse,
Through your mpdPup-project I learned how good puppy-linux can sound compared too regular mainstream Linux distro’s like Ubuntu Studio etc.
Info on my setup: mpdPup -> ESI-juli@ digital part (separately linear powered) -> Van den Hull optocoupler -> Lavry Black DA10 -> Vovox Direct S -> Klein & Hummel O300.
The very good sound quality coming from mpdPup made me curious what sound quality other puppy’s would deliver.
So I tried various other puppy’s, finally stumbling upon Tiny Core Linux.
Quite too my surprise: Tiny Core Linux + cifs- utils + alsa-dev + DeadBeef (with GAIN + re-& alsa up-sampling disabled) is another significant step-up in sound quality from mpdPup.
Audacity2 sounds equally superb on Tiny Core.
So may be better sound quality might be there because Tiny Core is used.
I know I should compare: mpdPup <-> Tiny Core + mpd.
But being a linux newbie I cant’t manage too setup a working mpd in Tiny Core.
There is a mpd.tcz, but configuring mpd in Tiny core is way too complicated for me.
So here’s my question:
* Have you (or any other inmates) ever tried mpd on Tiny Core?
Just too compare sound quality coming from: mpd + tiny core <-> mpd + puppy ?
Mark
NB I used the words “significant step-up in sound quality
Through your mpdPup-project I learned how good puppy-linux can sound compared too regular mainstream Linux distro’s like Ubuntu Studio etc.
Info on my setup: mpdPup -> ESI-juli@ digital part (separately linear powered) -> Van den Hull optocoupler -> Lavry Black DA10 -> Vovox Direct S -> Klein & Hummel O300.
The very good sound quality coming from mpdPup made me curious what sound quality other puppy’s would deliver.
So I tried various other puppy’s, finally stumbling upon Tiny Core Linux.
Quite too my surprise: Tiny Core Linux + cifs- utils + alsa-dev + DeadBeef (with GAIN + re-& alsa up-sampling disabled) is another significant step-up in sound quality from mpdPup.
Audacity2 sounds equally superb on Tiny Core.
So may be better sound quality might be there because Tiny Core is used.
I know I should compare: mpdPup <-> Tiny Core + mpd.
But being a linux newbie I cant’t manage too setup a working mpd in Tiny Core.
There is a mpd.tcz, but configuring mpd in Tiny core is way too complicated for me.
So here’s my question:
* Have you (or any other inmates) ever tried mpd on Tiny Core?
Just too compare sound quality coming from: mpd + tiny core <-> mpd + puppy ?
Mark
NB I used the words “significant step-up in sound quality
-
- Posts: 13
- Joined: Sat 02 Mar 2013, 12:10
empty folders in mpad
Dear Idolse,
in Mpad I have a lot of empty albums showing in album mode. I can not get rid of them in Mpad, they seem to be in the mpdpup database.
These empty albums were left after I had moved music files to other folders (there are no empty folders on the NAS)
Is there an elegant way of deleting/removing the database or removing these empty folders one by one?
Kind regards,
in Mpad I have a lot of empty albums showing in album mode. I can not get rid of them in Mpad, they seem to be in the mpdpup database.
These empty albums were left after I had moved music files to other folders (there are no empty folders on the NAS)
Is there an elegant way of deleting/removing the database or removing these empty folders one by one?
Kind regards,
Tiny Core
Hi Mark,
Great post!!
unfortunately , the coming period will be very busy and i doubt if i can find the time to try your suggestions and to fiddle with Tiny Core and mpd.
If i get somewhere i will let you know.
If possible, coud you post a small manual of how to create your setup?
Many thanks!
Douwe
ps since i use mpdpup (in stead of cmp2) i spend a lot more time listening to music (in stead of tweaking and repairing the very unstable cmp2)
Great post!!
unfortunately , the coming period will be very busy and i doubt if i can find the time to try your suggestions and to fiddle with Tiny Core and mpd.
If i get somewhere i will let you know.
If possible, coud you post a small manual of how to create your setup?
Many thanks!
Douwe
ps since i use mpdpup (in stead of cmp2) i spend a lot more time listening to music (in stead of tweaking and repairing the very unstable cmp2)
Well I spent some time playing with TinyCore Linux. Got Deadbeef to work, sounds great, did not do any critical listening/comparison between mpdpup though.
Also MPD does not work with TInyCore at the moment with the current rev and mpd. The packages are out of sync. Furthermore I can not compile mpd on TinyCore from scratch.
I also tried to install the Real-time Kernel on TinyCore per instructions dated 2011. That too is out of date with the current rev.
I went back to mpdpup and poked around looking at various process and discovered that about 10 processes not audio related are 'reniced' to the highest priority. These processes like kpsmoused might be great for a standard install because it speeds things up like responsiveness of the mouse etc. but for mpdpup having the highest priority is a waist. So I promptly reduced the processes of everything to 0 except audio related processes.
I really really REALLY do hope that mpdpup will not become your standard abandoned Linux project.
On another note, for anyone interested and has a Nexus 7 or 10 or probably anything with the Android OS that can run JB 4.2.x. There is a new ROM out that enables USB audio and it works with just about every Dac I have tried and have on hand which includes XMOS, VIA [Audiogd], Tenor and a few iBrasso headphone usb-dac-amps. This means that any of the above can be turned into a Squeezebox Touch. I currently have my Nexus 7 assigned to such duties right now. This means for about $140 bucks anyone can go to their nearest Walmart and buy any tablet that runs Android, install the ROM and instantly have a Squeezebox Touch.
Enjoy!
Also MPD does not work with TInyCore at the moment with the current rev and mpd. The packages are out of sync. Furthermore I can not compile mpd on TinyCore from scratch.
I also tried to install the Real-time Kernel on TinyCore per instructions dated 2011. That too is out of date with the current rev.
I went back to mpdpup and poked around looking at various process and discovered that about 10 processes not audio related are 'reniced' to the highest priority. These processes like kpsmoused might be great for a standard install because it speeds things up like responsiveness of the mouse etc. but for mpdpup having the highest priority is a waist. So I promptly reduced the processes of everything to 0 except audio related processes.
I really really REALLY do hope that mpdpup will not become your standard abandoned Linux project.
On another note, for anyone interested and has a Nexus 7 or 10 or probably anything with the Android OS that can run JB 4.2.x. There is a new ROM out that enables USB audio and it works with just about every Dac I have tried and have on hand which includes XMOS, VIA [Audiogd], Tenor and a few iBrasso headphone usb-dac-amps. This means that any of the above can be turned into a Squeezebox Touch. I currently have my Nexus 7 assigned to such duties right now. This means for about $140 bucks anyone can go to their nearest Walmart and buy any tablet that runs Android, install the ROM and instantly have a Squeezebox Touch.
Enjoy!
It's not abandoned, no worries, but it's on hiatus for a while, too much real life in the way. But I maintain it for my own usage too, and don't have any plans to continue using anything but this. I had loftier goals of trying to rebuild the kernel but maybe another release with bug fixes and some of these audio priority tweaks would be sufficient.Dynobot wrote:I went back to mpdpup and poked around looking at various process and discovered that about 10 processes not audio related are 'reniced' to the highest priority. These processes like kpsmoused might be great for a standard install because it speeds things up like responsiveness of the mouse etc. but for mpdpup having the highest priority is a waist. So I promptly reduced the processes of everything to 0 except audio related processes.
I really really REALLY do hope that mpdpup will not become your standard abandoned Linux project.
@RoxGsm - no idea why you can't play hi-rez audio files. Everything up to 96Khz works out of the box for all sound devices. On some sound devices (my own included) you need to unplug/replug the USB device after the system has fully booted to get 176/192Khz working. Other users report no problems with any bitrates from the start.
@DenisP, I'm not really sure why you needed to put empcd in rc.local - the starting with '&' is a bit weird as to being required. Unfortunately I'm a bit loathe to use this as a fix because I used to start some other process with an ampersand and I seem to recall it caused some users problems. Anyway you should be able to tweak the empcd init script to use the ampersand, and it already has the logic to sleep until mpd is alive. /etc/init.d/30.empcd.
I will follow up on email as requested.
@Supersurfer - I have that same problem for a few albums on mPad, no idea what causes it - guessing it's either a subtle flaw in the MPD database that it displays, or purely a bug in mPad - either way it's something to take up with the mPad author - he seems to be fairly responsive to well described problems.
Last edited by ldolse on Sat 22 Jun 2013, 14:55, edited 1 time in total.