Release 'music player daemon'-package (mpd+mpc+ncmpc)


Yours does not sound stupid. I'm not sure right now what causes this.


Usually, when starting the pnd and running mpd.sh the first time (e.g. by pressing 2 in the menu), the file "./.mpd/mpd.conf.orig" should be copied over to "./.mpd/mpd.conf". This is done because some path-settings are automatically assigned to suit your system. After that - during all my tests - I was able to modify "./.mpd/mpd.conf" with my favorite editor without any problems. Please try the following:


- start the pnd


- press 6 to open a terminal with it's current path being located in the mpd-folder. To be sure type "pwd" and tell me the output.


- type "ls -l .mpd/"


- if you can not see a "mpd.conf", but only see a "mpd.conf.orig" (beside other files), then run "./mpd.sh", after that try "ls -l .mpd/" again. was the file created? if not, then tell me


- after doing "ls -l .mpd/" study the output. The file "mpd.conf" should show "-rw-r--r--" followed by a "1" and after that your username twice. If not, then tell me.


- if everything is right, then you should be able to edit the configuration by running "mousepad .mpd/mpd.conf".


What filesystem are you using? ext? fat? Did you try to remove the appdata-folder of mpd-package completely and start over again?
 
Last edited by a moderator:
hm, after updating to SuperZaxxon today, I am experiencing some issues myself. First time mounting the pnd works, but mounting it a second time does not. Seems like for some reason the unmount-process is not running cleanly. When I run "ls /mnt/utmp/mpd-package/" after running the pnd and leaving it again, I get the message


"cannot access /mnt/utmp/mpd-package: Stale NFS file handle"


Edit: I searched the forum for the error-message and came upon a thread where the reason for the above error was a corrupted SD-Card. I will try if that is the reason for me, too. So this might not be related to the mpd-package.pnd
 
Last edited by a moderator:
- press 6 to open a terminal with it's current path being located in the mpd-folder. To be sure type "pwd" and tell me the output.
/mnt/utmp/mpd-package
- type "ls -l .mpd/"
no "mpd.conf" file is appears

- if you can not see a "mpd.conf", but only see a "mpd.conf.orig" (beside other files), then run "./mpd.sh", after that try "ls -l .mpd/" again. was the file created? if not, then tell me
executing "./mpd.sh" gives me

after executing mpd.sh the error: "./mpd.sh: line 11: .mpd/mpd.conf: Operation not permitted
Failed to open .mpd/mpd.conf: No such file or directory

What filesystem are you using? ext? fat? Did you try to remove the appdata-folder of mpd-package completely and start over again?
I'm using it on a fat32 formatted card, removed the mpd-package appdata folder completely, without any noticable difference


good thing, that I can still use the pre pnd version (I use it daily) - so thanks again for your work
 
That would be due to a bug in aufs. If a sub folder already exists in the base fs (the PND) it will not be created in the overlay, (ie appdata) so any attempts to write to it without specifically creating the folder in the overlay will fail.


Basically, It can't write to the file unless the .mpd folder already exists in the appdata dir.


I'd suggest adding something like this to the run script:



Code:
mkdir -p $APPDATADIR/.mpd


- Neelix
 
Ah, that sounds like it could work. Thanks, Neelix.


I will try to pack an updated pnd tomorrow, with the following changes:


- fix the bug by adding Neelix solution


- add Soundcloud support, which I managed to compile in by now.


- continue to work on the implemented documentation.
 
Last edited by a moderator:
I've been struggling with correctly packing a new pnd for the whole day and ran from one problem into the other. Quite frustrating when you start with the impression that you're nearly done. I'll quit for today. The results:


- documentation has been extended


- start-script has been modified get rid of the bug mentioned before


- mpd-binary and libary with soundcloud-support was added


- new problems with PXML-validation after updating "/usr/pandora/scripts/PXML_schema.xsd"


- noticed that mid-playback does not work from within the pnd. mpd crashes without further notes. When I run everything from my pnd-build-directory (not packed into a pnd) it works.


- adding nsf-songs takes AGES, no matter if run from pnd or before packing it into one.


No idea when or how I will fix that and release an update.
 
Last edited by a moderator:
I uploaded a new version. Unfortunately it is released as new PND and not as an update to the old PND, due to some changes I made in the PXML.xml.


I edit the first post with a list of known issues, since I didn't mange to solve the problems mentioned in the previous post. The NSF-song issue seems to be a flaw in libgme and also appears on my desktop-pc. The MID-problem is somehow related to the PND-system.


But hopefully the bug which lastgui suffered from is hopefully gone.
 
How to start ?


The good news is, that the editing the config file now works.


The bad news is, that I'm not able to start or better use mpd. Pressing "2" in the menu does (at least) nothing (visible) leading to ncmpc not beiing able to connect to localhost:6600. Starting mpd via a terminal session (Option "6") works though, but leaving the menu afterwards via "c" leads to a blank screen (with a visible and movable mousepointer), that I cannot escape (except through reset). Escaping it is only possible when leaving the menu with "7" and afterwards pressing the Pandora button for a couple of seconds.


One other thing: Killing mpd with option 3 is also not possible ("pid file not found")
 
That's a very strange issue. For me it works fine on both - the old HF6 and SuperZaxxon1.51. Could you try to delete all mpd-appdata-folders that might exist on your system? I can think of three possible locations, but they do not necessarily need to exist for you:


- in your home-directory: /home/<your_username>/.mpd/


- for the old mpd-pnd-version: if you installed the pnd on a SD-card in the appdata-folder on that card: /<path_to_your_sd-card>/pandora/appdata/mpd-package/


- for the new mpd-pnd-version: if you installed the pnd on a SD-card in the appdata-folder on that card: /<path_to_your_sd-card>/pandora/appdata/mpdpackage/


You can check for these directories if you open a terminal and write for example:



Code:
ls -ld /home/<your_username/.mpd/



and remove them by using





Code:
"rm -Ir /home/<your_username>/.mpd"





The following part is a bit complex, but maybe you manage to get the idea behind what we are doing and learn from it. Check if mpdpackage.pnd is not mounted anymore:





Code:
 mount | grep mpd



You should see no output. If you see a line starting with "none ...." then the pnd is still mounted. In that case try:





Code:
sudo umount /mnt/utmp/mpdpackage



You can try it multiple times, until you get the "...not mounted"-message. If this didn't work then mpd might still be running. You can kill it by typing:





Code:
killall mpd



You can also get a list of commands that are still running and occupying /mnt/utmp/mpdpackage by typing.





Code:
lsof | grep mpdpackage



If nothing helps, then try to restart the pandora, although this will leave your sdcard from being cleanly unmounted.

In any case, after that you should see no line with "/mnt/utmp/" when running "mount". (You can of course also use "mount | grep utmp" to check). If so and you are thus sure that you are running no pnd, then go on with the next steps:



List the content of "/mnt/utmp/" and remove and directory that is still left. These directories are left over from pnds that were not cleanly unmounted.





Code:
ls -1 /mnt/utmp/



Code:
rmdir /mnt/utmp/<name_of_a_leftover_directory>



Then list the the content "/mnt/pnd" and remove any file left in that directory. These files are links that were left over, pointing to the empty directories we just deleted:





Code:
ls -1 /mnt/pnd/



Code:
rm -i /mnt/pnd/<name_of_a_leftover_file>


So now everything should be cleaned up. If running mpd still makes problems, then let me know. It's hard to track down an issue which i am not experiencing myself. If things still won't work and you are willing to test more, then I will explain to you how you can extract the content of the pnd to an empty directory on your SD-card for another test-run. If you haven't got the patience then I can understand that as well.
 
Last edited by a moderator:
That's a very strange issue. For me it works fine on both - the old HF6 and SuperZaxxon1.51. Could you try to delete all mpd-appdata-folders that might exist on your system? I can think of three possible locations, but they do not necessarily need to exist for you:


- in your home-directory: /home/<your_username>/.mpd/


- for the old mpd-pnd-version: if you installed the pnd on a SD-card in the appdata-folder on that card: /<path_to_your_sd-card>/pandora/appdata/mpd-package/


- for the new mpd-pnd-version: if you installed the pnd on a SD-card in the appdata-folder on that card: /<path_to_your_sd-card>/pandora/appdata/mpdpackage/
tried it on a "fresh" card, so no former appdata Folder was present (second SD slot was empty). Tried again making sure beforehand that no appdata folder is present, same result.


Also there was no ".mpd" folder present in the home directory both times

The following part is a bit complex, but maybe you manage to get the idea behind what we are doing and learn from it. Check if mpdpackage.pnd is not mounted anymore:



Code:
 mount | grep mpd
no mount point leftovers



Code:
lsof | grep mpdpackage

no related processes left either

List the content of "/mnt/utmp/" and remove and directory that is still left. These directories are left over from pnds that were not cleanly unmounted.


Then list the the content "/mnt/pnd" and remove any file left in that directory. These files are links that were left over, pointing to the empty directories we just deleted:


So now everything should be cleaned up. If running mpd still makes problems, then let me know.
deleted all leftovers in "/mnt/utmp" and "/mnt/pnd" but with no effect - it behaves as descirbed in my last post

It's hard to track down an issue which i am not experiencing myself.
Maybe you could fetch an (old) spare card, format it with fat32 ?

If things still won't work and you are willing to test more, then I will explain to you how you can extract the content of the pnd to an empty directory on your SD-card for another test-run. If you haven't got the patience then I can understand that as well.
I'm happy that I'm of any help for once - so if you want me to test/try anything else, I'll be your humble servant.
 
Maybe you could fetch an (old) spare card, format it with fat32 ?

Yeah, good idea. I managed to get my hand on one. And I think I know the root of the problem: FAT32-cards are being mounted with the wrong rights. I'll write in detail what I did.


After creating the fat32-filesystem on the card, I mounted it and wanted to create the directory structure for the pnds, which didn't work as user. I had to create them as root:



Code:
sudo mkdir /media/fat32/pandora

sudo mkdir /media/fat32/pandora/appdata

sudo mkdir /media/fat32/pandora/apps

sudo mkdir /media/fat32/pandora/menu

sudo mkdir /media/fat32/pandora/desktop



That was already suspicious and so I looked at the permissions of the fat32-mountpoint:





Code:
ls -ld /media/fat32/



That showed the following permissions: "drwxr-xr-x 3 root root"

So the user of the mountpoint is "root" and the group for it is set to "root" as well (the second "root"). The sequence "drwxr-xr-x" is to be read from left to right like this:



d -> file is a directory

rwx -> user (root in this case) has the right to read, write and execute files in this directory

r-x -> group (root in this case) has the right to read and execute but not to write

r-x -> all other users that do not own the file or belong to the group are allowed to read and execute but not to write



I tried to run my mpd anyway and of course it did not work correctly since the scripts in the mpdpackage.pnd, which run with normal user-rights, are not allowed to write changes to the card. After running the pnd you can see the errors in the pnd-log-file, which is located at "/tmp/pndrun_mpdpackage.out". Try:





Code:
mousepad /tmp/pndrun_mpdpackage.out


That's something I should have recommended to do much earlier ;) and is always useful when having problems with PNDs. Here with mpd-package.pnd I guess you will see several error-messages saying "mkdir: cannot create ... Permission denied".


If that is the case, then we need to adjust the permissions. To be honest I am not sure what's the proper way of doing it (there are several ways). Also I would like to know why this does not seem to be an issue for everyone. I asked one guy on IRC named THB and he couldn't remember that he made any modifications. For him the card is being mounted as root:root with "rwx" for all three groups (user/groups/others). I will search for more information on that topic.
 
Last edited by a moderator:
thatgui: uhm ... If the permission-problem is really the source of the problem for you. How are you mounting the sdcards? Are you maybe using my mount-menu-pnd? It seems to have a bug which causes the permission-problem. I uninstalled it and now the fat32-card is mounted correctly.


So either you use mount-menu too or your issue is not caused by the above problem.
 
thatgui: uhm ... If the permission-problem is really the source of the problem for you. How are you mounting the sdcards? Are you maybe using my mount-menu-pnd? It seems to have a bug which causes the permission-problem. I uninstalled it and now the fat32-card is mounted correctly.
The tests of your pnd happend right after I flashed Firmware 1.51 so no extra/special mechanisms are used to mount the cards


I tried it another time => took option '2' and right after that I opened (via option '6') the pnd_run...out file. But there is no error recorded (except "(terminal:2584): Terminal DEBUG: D-Bus reply error: Name "org.xfce.Terminal4" does not exist ..." directly after the "Starting the application..." line)
 
Last edited by a moderator:
Also try to comment out the following line in mpd.conf by writing a # in front of the line. So in the end it should look like this:



Code:
#bind_to_address		 "<some_path>/.mpd/socket"


The other bind_to_address-line with "any" in it should be ok the way it is.
 
Last edited by a moderator:
Also try to comment out the following line in mpd.conf by writing a # in front of the line. So in the end it should look like this:



Code:
#bind_to_address		 "<some_path>/.mpd/socket"


The other bind_to_address-line with "any" in it should be ok the way it is.
Success !! (well at least to some extent)


After commenting out this line I was able to start mpd.


There is however a minor problem - but I did not find the time to investigate a lot:


Option 'c' seems not to work as intended. If i start mpd and then immediately leave the menu via 'c' Sonata is not able to connect to mpd (and lsof doesn't show any mpd instance). But if mpd is already playing before I leave via 'c' I can connect with Sonata afterwards (t also takes at least two minutes before I'm returned to minimenu after pressing 'c')
 
Time for my doublepost:


As getting out a fully working pnd is now "a piece of cake" :D how about some additions ?

  • putting in the possibility to open the mpd.conf in an external editor directly. Either using a "built" in command line editor or a graphical one (like mousepad) or give both options. I suggest before starting a commandline version to give a brief introduction to most important key assignments (like edit/insert, save, quit) and waiting for a keypress before actually starting the editor
  • put some indicator in the menu showing wether mpd is started or not - after choosing option '2' there is always some uncertainty left wether mpd has started or not
  • Add a second "application" to the pnd - a script that just starts the mpd deamon



Thanks again for all your efforts
 
I made some tests about minimenu. At first I had the same behaviour as you had (mpd not running afterwards and system hanging when closing). The reason for this is the basic default-concept of minimenu: When you choose an application then minimenu is being ended, the pnd mounted, the application run. Once you close the application, the pnd is unmounted and minimenu is launched again.


The problem here is that the pnd can not be unmounted for as long as any process from it is still running (in this case "mpd"). So it waits and waits and waits and after some time obviously kills all processes blocking the pnd - in other words: mpd is being killed. That leads to the hanging and the fact that mpd is not running afterwards.


Solution: I found an option in minimenu (select -> Configure Minimenu -> General Options -> scroll down to "Live (not exit) on app run" -> yes) that changes the above behaviour.


After enabling the option, minimenu is not being ended when you launch an application and also minimenu does not wait for the pnd being unmounted. With this option the mpd-package.pnd works the way it is supposed to work.


General note about this mechanism: You just have to remember to kill mpd yourself before changing the sdcard with the pnd on it, because otherwise the pnd was not unmounted and you can not unmount the sdcard.
 
Last edited by a moderator:
I'll upload a new version in a moment:


Changes in mpd-package 0.4.0:


- made some changes to the mpd.conf: I disabled logging by specifying /dev/null as log-file to save SDCard-space and commented out one of the "bind_address"-line sine it lead to problems in some situations.


- the terminal-menu was slightly modified. Pressing key "2" now toggles between starting and stopping mpd. Also a bit more feedback is shown what's going on.


- modified the ncmpcpp-keys to skip forward/backward a song you can now use "," and "." while "<" and ">" now jumps to the next search-result. "p" now toggles play/pause and not "P". I find this more suiting as I dislike using SHIFT for commands that i frequently use.


- added a self-compiled terminal-info-configuration to make the HOME/END keys work in ncmpcpp. Now you can jump to the beginning/end of the playlist by using them


- the scrollbar of the terminal-menu is now hidden, leaving more space for e.g. ncmpcpp


- changed a part in the documentation: to disable scanning of metatags you can set it to "none" instead of setting it to "".


- eliminated the dbus-errormessage showing in the runpnd-log by adding "--disable-server" when calling "terminal" in the scripts.- added a not to the initial-forum-thread that unicode does not work in ncmpcpp due to PandoraOS-configuration


!!! Remove the old appdata-folder to apply the changes !!!


Unfortunately I didn't manage to fix the mid-support yet. I'll try to get some help on this.
 
Last edited by a moderator:
Finally, I got some small window to test the new release, and it seems to run fine - had a weird issue with segfaults first, but after restarting the Pandora everthing was fine.


Merging the menu entries for start and stop into one and presenting to current status of mpd was a nice idea
 
Back
Top