pidof: not found

[mvanloon]

Hi,

I almost succeeded installing ron’s latest build on my Maxtor Shared Storage device. Here’s what I did:

First I installed the latest openmss firmware 2.6.2-openmss1-rc2 (download).

I then followed the instructions from this thread http://www.openmss.org/forum/viewtopic.php?t=413

Next I downloaded ron’s mipsel build and tried to install it. I downloaded his ipkg, copied it to a shared folder on the MSS and then navigated to that folder:

# cd /shares/mss-hdd/Mathieu

# ipkg install ./mt-daapd_svn-1404-1_mipsel.ipk

Here’s what you get back:

ERROR: Cannot satisfy the following dependencies for mt-daapd:

libogg libvorbis ivorbis-tools flac sqlite2 bash alac-decoder sqlite

#

Hmm, not very good. We need some source that can provide the required packages. Ron suggests the unslung feed from NSLU2. So I did the following:

# echo src nslu2_unslung http://ipkg.nslu2-linux.org/feeds/unslung/wl500g/ >> /opt/etc/ipkg.conf



# cat /opt/etc/ipkg.conf

src openmss http://ipkg.openmss.org/testing

src openmss_testing http://ipkg.openmss.org/testing

src nslu2_unslung http://ipkg.nslu2-linux.org/feeds/unslung/wl500g/



# ipkg update

(I know openmss and openmss_testing point to the same feed. It couldn’t be bothered to remove one of them and it doesn’t seem to matter).

Second try:

cd /shares/mss-hdd/Mathieu

ipkg install ./mt-daapd_svn-1404-1_mipsel.ipk

More luck this time:

An error ocurred, return value: 1.

Collected errors:

ERROR: Cannot satisfy the following dependencies for mt-daapd:

ivorbis-tools

Rats. ivorbis-tools is available from the NSLU2 feeds, but only the ARM build and not the MIPSEL build… I can’t find a MIPSEL build of the ivorbis-tools package anywhere 🙁

Ron, do you have a mipsel build for the ivorbis-tools package available?

Cheers,

Mathieu

[mvanloon]

Wait a minute. The changelog for mt-daapd from 14 April 2005 says that the ivorbis-tools package is a patched version of vorbis-tools and that firefly may revert back to the official vorbis-tools release.

vorbis-tools is available as a mipsel package from the nslu2 feed.

Does anyone (Ron?) know whether the ivorbis-tools package can be reverted to the official release (yet)? That would make life considerably easier…

[rpedde]

@mvanloon wrote:

Wait a minute. The changelog for mt-daapd from 14 April 2005 says that the ivorbis-tools package is a patched version of vorbis-tools and that firefly may revert back to the official vorbis-tools release.

vorbis-tools is available as a mipsel package from the nslu2 feed.

Does anyone (Ron?) know whether the ivorbis-tools package can be reverted to the official release (yet)? That would make life considerably easier…

I know all the status of those, I contributed the ivorbis-tools package. 🙂

For small boxes like the slug (and the mss) without a FPU, it can’t use the stock vorbis decoder — it decodes at something like 4x realtime. So you can’t transcode ogg.

The ivorbis-tools package uses the “tremor” integer decoder (no floating point) so it can transcode in realtime. My thought was that there was no real reason for the vorbis-tools package, since the ivorbis-tools package worked as well (and better because it could actually *play* ogg files), so there was no reason to have vorbis-tools. But I never pushed it hard upstream so it ended up staying a separate package. No loss, really.

It might be that I compiled the vorbis-tools package with ARM optimization, which make it not run on mipsel.

I’ll try and build an ivorbis-tools package without the arm optimizations, and we’ll see if it’s fast enough to transcode oggs.

— Ron

[mvanloon]

Did I understand you correctly in that an arm build may work on the mipsel architecture as long as there’s not arm specific optimization in there? The el part of mipsel is about the endianess of the arch isn’t it? are they compatible?

Just to be sure I tried installing the arm version from the /unslung/unstable/ feed at ipkg.nslu2-linux.org

Didn’t work, here’s what I got back:

# ipkg install ivorbis-tools_1.0-1_armeb.ipk

Clearing state_want and state_flag for pkg=ivorbis-tools (arch_priority=0 flag=1

6 want=2)

Nothing to be done

An error ocurred, return value: 4.

Collected errors:

Cannot find package ivorbis-tools.

Check the spelling or perhaps run 'ipkg update'

[rpedde]

@mvanloon wrote:

Did I understand you correctly in that an arm build may work on the mipsel architecture as long as there’s not arm specific optimization in there? The el part of mipsel is about the endianess of the arch isn’t it? are they compatible?

Nope, as you found out.

I have ivorbis and friends here:

http://ipkg.fireflymediaserver.org/mipsel

These are compiled with the 3.2.3 hnd-tools. I’m pretty sure the unslung feeds are done with 3.0.

I can’t get this crap to work right (i.e. run) with the 3.2.3 tools. I sure wish maxtor realeased the stuff necessary to compile something for the mss. Jerks.

Anyway, I may make another pass with 3.0, so they are compatible with the unslung stuff. Probably won’t be compatible with the other stuff floating around, but it will at least play nicely with the unslung optware feeds.

— Ron

[mvanloon]

hmm the ivorbis-tools package at http://ipkg.fireflymediaserver.org/mipsel is still the arm version (at least the filename ends with armeb.ipk). The libvorbisidec package is also armeb (libvorbisidec_cvs-20050221-1_armeb.ipk). The rest is all mipsel.

Is it a lot of trouble for you to post them as mipsel builds? I don’t have a buildchain set up (i haven’t run linux on my workstation in ages to be honest) so I can’t compile them myself.

thanks,

mathieu

[rpedde]

@mvanloon wrote:

hmm the ivorbis-tools package at http://ipkg.fireflymediaserver.org/mipsel is still the arm version (at least the filename ends with armeb.ipk). The libvorbisidec package is also armeb (libvorbisidec_cvs-20050221-1_armeb.ipk). The rest is all mipsel.

Hrm. They really are mipsel. I think the package builds are just bad because they’ve never been compiled for anything other than arm, so they are still using the old build scripts with the bad names. I’ll fix those.

Is it a lot of trouble for you to post them as mipsel builds? I don’t have a buildchain set up (i haven’t run linux on my workstation in ages to be honest) so I can’t compile them myself.

It was a mild pain, but there really isn’t much difference between slug and mipsel, so once we get it going, it’s virtually free to dump out the mipsel builds.

Obviously might take some time, though. 🙂

— Ron

[rpedde]

@mvanloon wrote:

hmm the ivorbis-tools package at http://ipkg.fireflymediaserver.org/mipsel is still the arm version (at least the filename ends with armeb.ipk). The libvorbisidec package is also armeb (libvorbisidec_cvs-20050221-1_armeb.ipk). The rest is all mipsel.

Okay… they are fixed.

Here’s my quick notes:

Install openmss 2.6.2

Use web interface to turn off media sharing or whatever (Shared Folders -> Manage Digital Photos etc -> Disable Media Server)

telnet to slug and start installing packages:

# cat src nslu2 http://ipkg-us-dyoung.nslu2-linux.org/feeds/optware/mss/cross/unstable > /opt/etc/ipkg.conf

# cat src firefly http://ipkg.fireflymediaserver.org/mipsel >> /opt/etc/ipkg.conf

# ipkg update

# ipkg install mt-daapd

# ipkg install nano

# LD_LIBRARY_PATH=/opt/lib /opt/bin/nano /opt/etc/init.d/S60mt-daapd

change the line that reads:

/opt/sbin/mt-daapd….

to:

/opt/bin/ld.so.1 /opt/sbin/mt-daapd…

Once this is done, turn off the built-in bonjour advertising:

# LD_LIBRARY_PATH=/opt/lib /opt/bin/nano /shares/mss-hdd/__bonjour/etc/rendezvous.conf

Find the lines for _tcp._daap and get rid of them (3 lines or something).

save the file, restart. /opt/etc/init.d/S60mt-daapd and it should fire right up with no songs. Go to the web interface and configure mp3 dirs and whatnot… (/shares/mss-hdd/Public/Our Music, maybe?)

I’m listening to music streaming off mine right now…

— Ron

[mvanloon]

Almost there. It turns out you need the broadcom toolchain else you won’t have the required libraries in /opt/lib (see this thread)

I unpacked the toolchain (hndtools) on my windows machine and copied the lib folder to my MSS. That didn’t help, apparently because the soft links to the libraries aren’t there.
there’s no ld.so.1 and no libc.so.6; I copied ld-2.2.5.so to ld.so.1 and libc-2.2.5.so to libc.so.6. That seemed to help.

mt-daapd will now start when I invoke /opt/etc/init.d/S60mt-daapd, and it will show up in the process list (ps), but I can’t cannot to it through :3689 nor can I see it in my iTunes client. The config file is fine as far as I can tell.

sigh. You would think this shouldn’t be so tedious. I may just go back to vinyl…

anyway I’ll try to dig up a knoppix cd, unpack the hndtools tar (hopefully with soft links then) and recopy the libraries. I suspect that will help.

cheers,

mathieu

[mvanloon]

I’m at a loss here. It seems the mt-daapd is starting alright but I can’t make a connection to it. Is there a logfile somewhere that would tell me what is going wrong?

[Author]

Posts