SQLite Prob on NSLU2

[POI]

I’m still having no luck after quite a bit of troublehooting. Still get the ‘scanned 0 songs in 3 seconds’ on startup of the daemon. Would perms on the files themselves be a problem? I am unable to change settings for the actual mp3s for some reason.

The perms for the files are:

-rwxrw—- 1 guest everyone 51240 Apr 2 13:13 01 Stupid Daniel.m4a

[rpedde]

It probably is permissions on the songs.

Try turning on logging on mt-daapd. Add a log file in your config file. I usually use “/share/hdd/public/mt-daapd.log”, because that sits right in the DISK 1 share, and it’s easy to get to from a client.

Then change /opt/etc/S60mt-daapd and add “-d5”, so it looks like:

/opt/sbin/mt-daapd -d9 -c /opt/etc/mt-daapd/mt-daapd.conf

then run mt-daapd and look at your logfile. It should tell you why it’s not finding anything.

[POI]

This is weird, the log shows very little…

2005-05-18 18:28:10: Starting rendezvous daemon
2005-05-18 18:28:10: Starting signal handler
2005-05-18 18:28:12: Initializing database
2005-05-18 18:28:12: Full reload…
2005-05-18 18:28:12: Starting mp3 scan
2005-05-18 18:28:12: Starting web server from /share/hdd/data/public/conf/opt/share/mt-daapd/admin-root on port 3689
2005-05-18 18:28:12: Registering rendezvous names
2005-05-18 18:28:12: Scanned 0 songs in 2 seconds

[rpedde]

Assuming that’s really at debug level 5 (guess I should print the debuglevel at startup, huh?) then the only problem can be that there aren’t any files in the mp3_dir.

Otherwise it should be printing errors about why it couldn’t scan them.

Are you sure that your mp3_dir is pointing to where your mp3 files are?

[POI]

Yup, I’ve checked and double-checked the settings for the music folder (along with everything else) I’m really at a loss. It’s interesting that even when I specify level 5 debug, there’s no difference in the output! Makes me wonder if it’s even taking that parameter.

It doesn’t help that I’m fairly new to Linux but I get the idea of it. I’ve been administering apps on Slackware for quite some time. Figured if I could handle that distro, I could handle anything. Guess not…

[rpedde]

Well, this is also the deep end of the pool. 🙂

Experimental version of the software on a hacked-together distro on an unsupported hardware platform… yeah… it’s gonna be bumpy.

Just to make it easier to see what’s going on, I’m going to add a “debug” parameter to the config file so it can be set there, rather than having to mess with the startup script. I’ll also add the stuff to print the debug level on boot.

I’m taking the day off tomorrow (yay!) so I can finish up the xml stuff. I’ll roll out fresh nightlies tomorrow, and we can see where that takes us.

— Ron

[velociped]

…
2005-05-18 18:28:12: Starting mp3 scan
2005-05-18 18:28:12: Starting web server from /share/hdd/data/public/conf/opt/share/mt-daapd/admin-root on port 3689
2005-05-18 18:28:12: Registering rendezvous names
…

Perhaps it is just me, but that path to the web admin interface looks awful screwy. Should it not simply be /opt/share/mt-daapd/admin-root (or more precisely, /share/hdd/conf/opt/share/mt-daapd/admin-root)?

The extra …data/public… in there makes me suspect there is still be some sort of path issue at play. Not sure what without more information regarding your setup. Seems like definitely something, though.

Herman

[dougyp]

I also have had the /tmp permissions issue since early this year. I think it was the first build that had the sqlite dependancy, early summer?

I’m running V2.3R25-uNSLUng-standard-2.12-beta slug – I know there are newer versions out there but I’m scared to upgrade ’cause I can’t find clear instructions anywhere and I’m dependant on that little unit now – can’t have it down!

In any case, I know /tmp isn’t supposed to be 777 but I have to do that in the mt-daapd startup or else it doesn’t start the daemon. SO I have a workaround but don’t like the loose permissions. (What the heck is that special perm setting for “real” unix /tmp? I don’t have one available to me – even my tivo has /tmp loose!).

Anyway, I did have mt-daapd crash on me today for no aparent cause other than sqlite went “resource not available” on me. Of course the log is gone and I can’t recall the name of the file that got paired up with songs.db in /opt/var/mt-daapd. It was songs.db-something Aparently the DB was busy so mt-daapd couldn’t read it and all crashed.

So – any ideas on the second one? I’ll of course post more if I catch it again. Also not sure about why I have /tmp permissions issues (“glad” to see someone else does though!)

Post edited by: dougyp, at: 2005/12/23 03:12

[rpedde]

/tmp is indeed supposed to be 777. everybody has to have a guaranteed writable location, and /tmp is it. That’s what it’s for.

As far as resource not available, what version are you running? Sounds like a leak in something… memory? File handles? Something.

There were some leaks that were fixed in the last couple nightlies. The latest nightly should be (??) relatively leak free, though. So if that’s what you were running, then something is indeed screwy.

— Ron

[dougyp]

Thanks for the reply.

Sorry, I am running the 20051122 nightly. I truly wish I’d noted the extra songs.db file and/or the error in the mt-daapd log – my bad. I recall now that the log error said something about a playlist not existing/available even though I know it did exist – which is consistent with the daemon not able to read the DB.

At the time the failure occured I was trying to connect with a windows iTunes client and my Soundbridge was already connected. The windows client was hung and not responding. That’s when I looked at the DB dir and saw the extra file. It was something like 9M in size and my songs DB is something like 7MB in size, that just struck me as odd. The NSLU2 was a bit…slugish 😉 at the time too.

Oh – as far as /tmp permissions. I was able to find a reference machine today – it SHOULD be 1777, (not rwxrwxrwx but rwxrwxrwt) – where “t” is the sticky bit. It means that the directory is fully writeable but only for your own files, one user shouldn’t be able to read or write anothers if they aren’t in the same group. Of course now that I’m at work I don’t have access to a slug to see if “chmod 1777 /tmp” even works!

-Doug

[Author]

Posts